23 grudnia 2009

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”.

14 grudnia 2009

Wdrożenie SOA metodą małych kroków

SOA jest strategią w dużej mierze specyficzną: trudno oszacować zwrot z inwestycji; trudno stwierdzić czy dany – wdrożony w jakiejś firmie - zestaw mechanizmów i procedur to już SOA, czy jeszcze nie; trudno nawet powiedzieć co to jest SOA. Oczywiście chodzi o takie SOA które dostarcza to czego się po nim spodziewamy; bo jeśli sam fakt „wdrożenia SOA” ma kogokolwiek uszczęśliwić, to nic nie stoi na przeszkodzie żeby przykleić tę etykietę do czegokolwiek, w dowolnej chwili.

Nie sposób ocenić perspektywy zwrotu z inwestycji w SOA, zatem zapewne warto postarać się tę inwestycję – w sensie kosztu – zmniejszyć. Koszt można skutecznie zmniejszyć obierając strategię wdrożenia nazwaną przeze mnie tutaj - mało innowacyjnie - strategią małych kroków.

Sedno strategii małych kroków można przekazać w kilku zdaniach. Przede wszystkim unikamy dużych inwestycji w SOA samo w sobie. Podłączamy się raczej do projektów które mają już uzasadnienie biznesowe (i budżet) z racji dostarczania pożądanych funkcjonalności. Zacznijmy więc od nakreślenia naszej wizji – wymarzmy sobie, jak byśmy chcieli by nasze SOA wyglądało – i zacznijmy wdrażać po kawałeczku przy okazji realizacji kolejnych projektów, mających swoje niezależne uzasadnienie i finansowanie.

Najprawdopodobniej postęp wdrożenia SOA będzie blokowany, jeśli tylko zacznie ono być postrzegane bardziej jak kula u nogi (ryzyko), niż jak światełko w tunelu (szansa). Zadbajmy więc o odpowiedni dobór projektów pilotażowych – projektów które staną się naszym poligonem doświadczalno-wdrożeniowym.

Należy wybierać takie projekty-piloty, które mają duże szanse powodzenia – aby uniknąć ryzyka zwalenia winy na SOA, w razie gdyby projekt-pilot zakończył się fiaskiem.

Należy wybierać takie projekty-piloty w których istotna – najlepiej krytyczna – część funkcjonalności w sposób naturalny może być zaimplementowana za pomocą zestawu usług i w których fakt implementacji tych funkcjonalności za pomocą usług znacznie upraszcza implementację aplikacji samych w sobie (tj. reszty projektu nie będącej usługami).

Wybierajmy takie projekty-piloty, które dają szansę na re-używanie usług, a więc projekty używające w dużym zakresie tych samych obiektów (danych) biznesowych.

Implementujmy i testujemy przy okazji implementacji projektów-pilotów narzędzia i procesy uniwersalne – tj. należące do infrastruktury SOA - ułatwiające implementacje, utrzymanie i dokumentację usług, tak aby z czasem SOA zaczęła wnosić większy bagaż korzyści niż kosztów. Taka marchewka szybko zacznie przyciągać jednostki zewnętrzne. Oczywiście pod warunkiem, że uda nam się owe jednostki zewnętrzne przekonać, że marchewka jest duża.

Metodą przeciwstawną do metody drobnych kroków jest metoda inicjalnej inwestycji. Jeśli zależy nam na czasie, dysponujemy znacznymi środkami, dobrym zespołem ludzi, którzy wiedzą co i jak oraz nie boimy się, że może się nie udać, to… to mimo wszystko nie koniecznie warto się decydować. Wdrożenie SOA jest przedsięwzięciem na tyle skomplikowanym, że zawsze powinien to być proces szyty na miarę. Szycie wymaga czasu i… wielu poprawek krawieckich, tym bardziej że środowisko w którym szyjemy ma tendencje do zmieniania się w czasie.

Rzecz jasna całkiem bez inwestycji nie obędzie się tak czy inaczej. Tak czy inaczej trzeba oddelegować do tych zadań kilka osób, przynajmniej w częściowym wymiarze. Tak czy inaczej nie obędzie się bez jakichś serwerów. Tak czy inaczej trzeba rozważyć kwestię oprogramowania – być może najtaniej (biorąc pod uwagę koszt roboczogodzin programistów) będzie kupić jakiś dobry, kompletny produkt.

Osobnym problemem strategicznym jest wybór między marchewką i kijem. Ja osobiście jestem zwolennikiem mariażu, tj. należy zadbać o to, aby SOA było przede wszystkim atrakcyjne (marchewka), ale należy też aktywnie zachęcać niezależne jednostki istniejące w firmie, by przynajmniej spróbowały podporządkować się opracowanym regułom i technikom tworzenia rozwiązań w architekturze SOA (kij). Oczywiście dając tymże jednostkom prawo do zgłaszania obiekcji.

9 grudnia 2009

Fix na problemy z aplikacjami WWW w IE8

Jeśli ktoś ma aplikację WWW, która wygląda OK w IE7 a w IE8 zaczęła się rozłazić - i naturalnie chciałby to poprawić - to okazuje się, że jest na to prosty sposób. Wystarczy dodać nagłówek:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />