ESB: nie kupować
Firma ThoughtWorks, w której pracuje Martin Fowler (autor klasycznej pozycji 'Enterprise Integration Patterns') w Radarze Technologicznym na 2011 rok rekomenduje podobnie jak rok temu wstrzymanie procesu analizy możliwości wdrożenia ESB w firmie. Doświadczone osoby powiedzą: 'Ja już dawno wiedziałem, że ESB jako produkt to marketingowa ściema. Całą architekturę trzeba przemyśleć i zaprojektować od podstaw'. Pudełkowe ESB daje złudne poczucie, że kupiło się i wdrożyło ESB (albo nawet SOA), natomiast niewłaściwe zastosowanie produktu (które ma miejsce w więcej niż 50% przypadków) powoduje powstanie niewiadomo czego. Tak więc lepiej nie oszukiwać siebie i zarządu.Trzeba też powiedzieć prawdę, że dla dostawcy dużo bardziej korzystny finansowo jest makaron integracyjny (a jeśli nie można tego kierunku eksploatować to można pomyśleć o rozwiązaniach typu vendor-lock-in np. fajny framework implementujący super pattern, ze słabą dokumentacją, nie do obczajenia przez innego dostawcę).
2 komentarze:
>Trzeba też powiedzieć prawdę, że >dla dostawcy dużo bardziej >korzystny finansowo jest makaron >integracyjny
Dlatego klient nie powinien bawić się z dostawcami w przepychanki "polityczne" i sensownie zarządzać własną architekturą.
>(a jeśli nie można tego kierunku >eksploatować to można pomyśleć o >rozwiązaniach typu vendor-lock-in >np. fajny framework >implementujący super pattern, ze >słabą dokumentacją, nie do >obczajenia przez innego dostawcę).
Przyczyną słabej dokumentacji może być też niedbalstwo klienta, albo niekoniecznie przemyślane standardy dokumentacyjne, które już w samym zalążku uniemożliwiają stworzenie naprawdę dobrej dokumentacji.
Za złą architekturę klient odpowiada w takim samym stopniu jak jego dostawcy.
Klient nie powinien ufać w 100% dostawcy i przyjmować wszystko to co mu się mówi na piękne oczy. Jeśli sam nie ma zasobów do sprawdzenia dostawcy powinien posiłkować się np. niezależnym audytem.
Zgadzam się, że winę za złą architekturę ponosi finalnie klient.
Prześlij komentarz