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.
7 komentarzy:
Zgadzam się z ogólnym przekazem wpisu, ale szczególnie z jednym niekoniecznie. Napisałeś: 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.. Czyż nie jest to argument, aby wdrażać jakąkolwiek technologię/podejście (TePo)? To może nawet uzasadnić TePo nawet, jeśli jest do kitu, bo siła inercji projektu będzie tak silna, że niemoc TePo (i brak uzasadnienia jego stosowania) nie zostanie zauważona. Zaangażowani ludzie zrobią, co im kazano/proszono i co? Czy to oznacza, że mamy uzasadnienie dla wdrożenia XYZ (w tym przypadku SOA)? Niekoniecznie. To rozumowanie wzbudziło we mnie pewien niepokój i jakkolwiek całość materiału była w porządku, to ten kawałek musiałem zgłosić jako niepasujący do reszty.
Wszystko i tak będzie odebrane tak, jak zostanie zaprezentowane, a nie takim jakim jest - światem rządzi PR. Jeśli potrzebujesz jakiegoś nieudanego projektu, żeby uzasadnić potrzebę zmian, to proszę bardzo. Nie rozumiem natomiast twojego toku myślenia - skoro "brakuje" ci nieudanych projektów z przeszłości, to znaczy że wszystko funkcjonuje nieźle. Jeśli do tej pory wszystkie projekty się udawały, i nagle jeden - w którym "wprowadziłeś" elementy SOA - się nie udaje, to nie wiem jak chcesz z tego zrobić motywację do dalszego wprowadzania SOA. A jeśli projekty z przeszłości się często nie udawały, to czy potrzebujesz kolejnego, żeby uzasadnić potrzebę zmian?
A to ci dopiero numer, bo ja sądziłem, że zadałem pytanie, które właśnie teraz Ty zadałeś mi (!) Hmmm, jakby tu z tego wybrnąć?! Może tak - szukamy projektu, który o SOA nie marzył, ani go nie rozważał, ale my proponujemy na jego barkach wdrożenie SOA, bo spełnia kilka punktów naszej listy weryfikującej przydatność takiego projektu do naszego wdrożenia referencyjnego SOA. Tu pełna zgoda. Tak pisałeś u siebie. Tylko skąd się dowiedzieć, czy sukces takiego projektu, to sukces SOA? W końcu mogą być takie stany końcowe - SOA i projekt się udały, SOA nie, projekt tak, SOA tak, a projekt nie i w końcu ten najgorszy oba padły (mam nadzieję, że pogrupowałeś odpowiednio i podążasz moim tokiem myślenia :)). W swoim tekście omówiłeś przypadek - (tak, tak) oraz (tak, *), gdzie pary przedstawiają wynik zakończenia projektu i wdrożenia SOA. Ja pytam, czy może zajść przypadek końcowy (tak, ?) ?
Chmmm... mam nadzieje, że tym razem zrozumiałem twoje pytanie :)
Otóż nie chodzi o to, że wybieramy JEDEN projekt-pilot, na barkach którego wdrażamy SOA. SOA wdrażamy na bazie całej serii projektów-pilotów, po trochu, tak aby nie "obciążyć" zbytnio tych poszczególnych projektów-pilotów. Projekt-pilot kończy się sukcesem, ale wdrożenie SOA trwa... i trwa... i trwa. Przy okazji projektów-pilotów wprowadzamy po prostu kolejne elementy SOA. W pierwszym projekcie-pilocie możemy np. zaimplementować Model (ten z MVC) jako kolekcję usług sieciowych które udostępnimy i będziemy wywoływali poprzez jakieś ESB (często tak właśnie zaleca się zaczynać SOA, od prostego użycia ESB). W drugim projekcie-pilocie możemy do tego doinstalować UDDI. Potem możemy zaimplementować jakąś infrastrukturę do monitorowania, która np. będzie wysyłała jakieś alerty mailowe jak wywołanie usługi zakończy się błędem, itd. itd. Jak już osiągniemy pewne minimum na poziomie technologicznym, możemy zacząć myśleć o sprawach organizacyjnych (po osiągnięciu pewnej masy krytycznej, tj. pewnej liczby usług). Itd. itp. Krok po kroku, wkraczamy na kolejne poziomy rozwoju (oczywiście nie koniecznie w takiej kolejności w jakiej wymieniam powyżej) przy okazji kolejnych projektów-pilotów. Oczywiście część pracy należy wykonać jakby niezależnie od projektów-pilotów, tj. chociażby nakreślenie ogólnej idei. Postęp wdrożenia SOA na barkach kolejnych projektów-pilotów też trzeba przecież jakoś koordynować i nim sterować. No i właśnie to jest rola Centrum Kompetencyjnego SOA (CK SOA). Tzn. jest to ta "grupa ludzi" którą trzeba oddelegować do SOA, o której pisałem w artykule.
Podsumowując więc - wdrożeniem SOA kieruje Centrum Kompetencyjne SOA (CK SOA), które tworzy (i koryguje z biegiem czasu) road-mapę i wdraża oraz waliduje i dopracowuje swoje idee na barkach projektów-pilotów.
SOA można uznać za wdrożone, gdy wszystkie projekty które "pasują" do SOA będą wykonywane zgodnie z tym co opracowało i wdrożyło CK SOA i PMowie kolejnych projektów "biznesowych" będą chcieli "robić je w SOA", bo będą widzieli że jest to korzystne - tj. przyśpieszy i ułatwi dostarczenie końcowych funkcjonalności dla biznesu.
Teraz lepiej :) Wciąż brakuje mi odpowiedzi na moje pytanie odnośnie wniosków ze wyników projektów zakończonych stanem (tak, ?). Kto i kiedy zdecyduje, że zakończono część SOA faktycznie poprawnie. Samo wystawienie usług to jeszcze za mało. Mam wrażenie, że samo zakończnie pilotażowych wdrożeń SOA będzie przyczułkiem do wdrożeń, które zdecydują się na skorzystanie z tych usług. I tu pojawia się pytanie, dlaczego wskazywać na SOA jako przyczynę niepowodzenia, kiedy wystawione usług z poprzednich wdrożeń są jak najbardziej poprawne, ale ich wykorzystanie było niepoprawne? Potrzeba doświadczenia wdrożeniowego, nieprawdaż? Pewne pomyłki będą. I to nie tylko przy wdrożeniu SOA, ale przy wdrożeniu czegokowiek. I tutaj właśnie podniosłem temat, czy postawiłem pytanie, czy Twój artykuł nie dotyczy jakiegokolwiek wdrożenia, a SOA może być tylko przykładem, aby wpis był zgodny z tematyką bloga? Czy aby nie popularność SOA i niewytłumaczalna przez wielu chęć jego posiadania (szczególnie przez rządzących wysokiego szczebla, którzy zostali zindoktrynowani o wielkości tego typu rozwiązań) powoduje, że przywołuje się SOA jako ten typ rozwiązania, które należy wdrażać stopniowo?! Ja twierdzę, że dotyczy to jakiejkolwiek technologii czy metodyki, a jej rozległość i wpływ na organizację może być jedynie przybliżana przez poprzednie wdrożenia, w tej czy innych korporacjach. Stawiam tezę, że to co napisałeś, po zdjęciu SOA i zastąpieniu tego akronimu przez dowolny inny, będzie wciąż poprawne. I to nie tylko w świecie IT. Jakby prawda oczywista :)
"Kto i kiedy zdecyduje, że zakończono część SOA faktycznie poprawnie."
CK SOA. Ale tak naprawdę to nie chodzi o wystawianie ocen, tylko o wyciąganie wniosków i poprawianie tego co działa nie najlepiej.
"Samo wystawienie usług to jeszcze za mało"
Za mało na co? Na zakres pierwszego projektu-pilota? Ja uważam że to wystarczająco dużo. Na "wdrożenie SOA"? Oczywiście że za mało, ale po to są kolejne projekty-piloty żeby dokładać resztę.
"I tu pojawia się pytanie, dlaczego wskazywać na SOA jako przyczynę niepowodzenia"
No właśnie - chodzi o to żeby nie dawać innym tego typu amunicji. Wyobraźmy sobie taką sytuację - pod wpływem naszego nacisku, pewien PM odpowiedzialny za wykonanie projektu-pilota, tj. projektu dostarczającego funkcjonalności dla biznesu, godzi się na "wykorzystanie" "jego projektu". Wyobraźmy sobie teraz, że z jakichś przyczyn, projekt-pilot kończy się fiaskiem. PM chce wyjść z tego z twarzą (żeby nie być pociągniętym do odpowiedzialności np.) i zrzuca całą winę na nas, tzn. na SOA. Taka mała polityka, ale tak może się przecież zdarzyć. Jest dość duże ryzyko, że tak właśnie się zdarzy, a czym jest zarządzanie projektem jak nie unikaniem ryzyk właśnie (między innymi oczywiście)?
"Potrzeba doświadczenia wdrożeniowego, nieprawdaż? Pewne pomyłki będą. I to nie tylko przy wdrożeniu SOA"
Jasne że pomyłki będą. I właśnie dlatego - zwłaszcza przy wdrażaniu innowacyjnych i rozległych projektów - warto to robić przyrostowo, ucząc się na własnych błędach i poprawiając je stopniowo.
"czy Twój artykuł nie dotyczy jakiegokolwiek wdrożenia, a SOA może być tylko przykładem"
Pisałem mając na myśli SOA, ale zepewne można to w jakimś stopniu odnieść do projektów wdrożeniowych czegokolwiek. Aczkolwiek tylko w jakimś stopniu, nie w pełni. Chociażby klucz doboru projektów-pilotów może być różny.
"Czy aby nie popularność SOA i niewytłumaczalna przez wielu chęć jego posiadania (szczególnie przez rządzących wysokiego szczebla, którzy zostali zindoktrynowani o wielkości tego typu rozwiązań) powoduje, że przywołuje się SOA jako ten typ rozwiązania, które należy wdrażać stopniowo?!"
To jest mix dwu zagadnień. Po pierwsze - stopniowo należy wdrażać dlatego, że wdrożenie jest procesem niebanalnym. Zarówno technologicznie, jak i - głównie - procesowo.
A czy chęć wdrożenia SOA jest niewytłumaczalna? Jest wytłumaczalna i to bardzo prosto. Kadra zarządzająca ma pewien problem, i bardzo chce ten problem rozwiązać. Oczywiście managerowie nie mają szans wiedzieć na pewno, na ile skuteczne może być SOA, ale mają prawo wierzyć, że chociażby w części te wszystkie obietnice SOA są prawdziwe. Ja osobiście potwierdzam - są prawdziwe, ale tylko wtedy gdy SOA zostanie wdrożone w stopniu pełnym. Warunkiem użyteczności SOA jest jego pełna adopcja, bez ograniczania się do sfery technologicznej.
"Stawiam tezę, że to co napisałeś, po zdjęciu SOA i zastąpieniu tego akronimu przez dowolny inny, będzie wciąż poprawne. I to nie tylko w świecie IT. Jakby prawda oczywista :)"
Nie mam nic przeciwko takiej tezie. Piszesz w końcu że mam rację. Dlaczego miałbym się temu sprzeciwiać? :) A tak bardziej na poważnie - zgadzam się, że sama idea wdrażania stopniowego jest w ogólności słuszna w odniesieniu do skomplikowanych wdrożeń czegokolwiek. Tyle że jak wiesz, diabeł tkwi w szczegółach, a mi chodzi właśnie o zastanowienie się nad tymi szczegółami, tj. jak wdrażać SOA - specyficznie - żeby poszło gładko.
Czuję się usatysfakcjonowany :) Dzięki za cierpliwość.
Prześlij komentarz