SOA to nie jest worek z usługami!

Często spotykam się z podejściem, w którym ogranicza się SOA do roli worka z usługami. Zgodnie z tym podejściem trzeba mieć dobry worek – tj. ESB + rejestr UDDI – i to w zasadzie powinno wystarczyć, by osiągnąć korzyści związane z SOA. Otóż nie wystarczy!

Przeważnie struktury organizacyjne firm są dużo bardziej skompilowane niż to, co daje się wyrazić na dowolnym rysunku. W szczególności, firma, a także jej poszczególne piony – w tym IT – składają się z kilku (-nastu, -dziesięciu, -set) niezależnych grup. Często grupy te posiadają duże autonomie.

Kilka spośród wspomnianych grup w pionie IT zainteresowanych jest „wdrożeniem SOA”, tj. – tłumacząc na nieco bardziej przyziemny język – chciałoby zacząć przygodę z implementacją nowych projektów w oparciu o WebService’y. No i zaczynają.

Po pewnym czasie pada decyzja o „wdrożeniu SOA” na poziomie korporacyjnym, które to wdrożenie polegałoby na synchronizacji wysiłków tychże niezależnych grup. Zaczyna się kucie żelaza.

Postanawia się, że trzeba zainstalować ESB i rejestr UDDI, aby usługi wytwarzane przez poszczególne grupy mogły być łatwo „upubliczniane”. Po chwili dochodzi się do wniosku, że w zasadzie to nie jest potrzebne jedno, wspólne ESB. Różne grupy mają swoich różnych faworytów a ponadto (co pewnie ważniejsze) każda z grup chce mieć pełną kontrolę nad środowiskiem – tak jak to było do tej pory – aby móc pracować w sposób najwygodniejszy dla siebie. Mamy więc kilka instancji ESB (co akurat nie ma rzeczywiście większego znaczenia) oraz wspólny rejestr UDDI. Upiiii! Udało się! … No tak, tylko co się udało? Oczywiście udało się wiele, ale nie jesteśmy jeszcze nawet blisko pełnego wdrożenia SOA.

To co otrzymaliśmy w efekcie to „worek usług” – usługi wytwarzane są przez kilka niezależnych grup, które po prostu rejestrują to co zrobią w UDDIu i spodziewają się, że będzie to użyteczne dla innych.

Naturalnie jeden worek drugiemu nierówny – worek świeżych pomarańczy dla przykładu to całkiem miła perspektywa; tyle że w praktyce otrzymamy raczej worek podgniłych bulw niewiadomego – i zapewne bardzo różnego – gatunku, bliższego raczej ziemniakom niż cytrusom. Dlaczego tak marnie oceniam perspektywę zawartości worka, do którego wrzuca się na zasadach opisanych w poprzednim akapicie? O tym poniżej.

Wszystko dzieje się za sprawą rozbieżności celów i konfliktu interesów. Wyobraźmy sobie taką – zupełnie codzienną – sytuację: do jednej z grup używających SOA w modelu worka usług przychodzi przedstawiciel biznesu i składa żądanie wykonania nowej aplikacji, dostarczającej jakichś tam, bliżej jeszcze nie określonych, funkcjonalności. Od razu pada też termin – ma być za 3 miesiące! Po krótkich przepychankach namaszcza się kierownika projektu, któremu stawia się jeden cel i w którego interesie leży osiągnięcie tego celu. Tym celem jest naturalnie dostarczenie wspomnianych funkcjonalności na czas!

Aplikacja ma między innymi wysyłać maile i w razie potrzeby rejestrować eskalacje. Usługa do wysyłania maili jest już zaimplementowana i zarejestrowana w UDDIu, ktoś tam wykonał też system obsługi reklamacji, który udostępnia – poprzez usługi zarejestrowane w UDDIu – funkcjonalność związaną z eskalacjami. Super! Wystarczy jeszcze napisać 4 usługi do przeglądania danych klientów i 2 do przeglądania danych zamówień. Józek zna świetny framework do robienia GUI dla WebService’ów (polecam TIBCO GI – patrz artykuł „TIBCO General Interface – Warstwa widoku dla SOA”); damy radę! Byle tylko działać szybko. Jakie mają być usługi? Po pierwsze mają działać a po drugie mają być dostarczone na czas, tj. za miesiąc, żeby było na czym testować GUI.

Usługi SOA – przy przyjęciu modelu „SOA jako worek usług” – będą właśnie takie jakie mogą być, jeśli jedynym stawianym celem będzie poprawność działania i czas dostarczenia. Oczywiście wszystko to są cele zupełnie zasadnicze, ale brakuje jeszcze postawienia co najmniej dwu celów: jakości i spójności. To, jak bardzo mogą się różnić miedzy sobą worki z usługami wykonanymi z, albo bez stawiania tych celów, oraz co precyzyjnie kryje się za celami pod kryptonimem „jakość” i „spójność” to już osobna dyskusja.

Oczywiście łatwo powiedzieć, że należy najzwyczajniej w świecie postawić odpowiednie cele, tyle że przede wszystkim trzeba mieć komu je stawiać i trzeba kogoś kto w sposób obiektywny oceni, w jakim stopniu cele te są osiągane. W modelu opisanym powyżej, gdzie SOA to worek, do którego wrzuca się dowolnie usługi wykonane przy okazji implementacji projektów biznesowych, nie ma osób ani mechanizmów, które pozwalałyby na stawianie i osiąganie tych celów.

SOA to oczywiście jest w dużej mierze pewna kolekcja usług, tyle że powinna to być kolekcja budowana świadomie, nie zaś luźny worek. Ważne jest, aby ta kolekcja usług była rozwijana i utrzymywana przez grupę powołaną w tym właśnie celu. Nadrzędnym, a najlepiej jedynym celem tej grupy powinno być dostarczanie usług, które oprócz tego że działają i są dostarczane sprawnie, są także wykonane zgodnie z wszelkimi kanonami sztuki. Różnica między produktami takiej dedykowanej grupy (zwanej Centrum Kompetencyjne SOA) a zsumowanymi produktami grup które mają postawione zupełnie inne cele (tj. cele zaspokajania bieżących potrzeb biznesu) może być krytyczna – krytyczna dla oceny, czy SOA ma sens czy nie.

Proces wytwórczy usług SOA, w podejściu nastawionym na jakość i wartość ponad-projektową, opisałem w artykule „Proces dostarczenia usług w architekturze SOA”.