SOA: czy damy jej radę własnymi siłami?
Tags: BPMS, ESB, platformy integracyjne, platformy SOA, SOA
Wielokrotnie spotykałem się z sytuacją, w której starano się doszukiwać wartości wykorzystania architektury SOA w kontekście wdrożenia konkretnego systemu. Tymczasem niezależnie czy to będzie CRM, elektroniczne kanały dostępu czy platforma procesów biznesowych, to nie ma sensu rozważanie korzyści z wdrożenia SOA w ramach pojedynczego projektu. Powiem więcej: taka analiza najpewniej wykaże, że koszty tak prowadzonego projektu będą większe! Siłę architektury SOA można dostrzec dopiero w perspektywie kolejnych wdrożeń. Kiedy wykorzystujemy w następujących po sobie różnych projektach zarówno sprzęt, oprogramowanie narzędziowe, jak też stworzoną specjalnie na nasze potrzeby funkcjonalność, to wtedy dostrzegamy oszczędności zasobów i czasu wdrożeń. Niebagatelne też jest optymalizowanie pracy administratorów odpowiedzialnych za mechanizmy integracji systemów, kiedy mogą zajmować się jednym, spójnym środowiskiem.
Wspomniana perspektywa rozwoju architektury SOA pokazuje, że jej budowa nie kończy się zbudowaniem systemu, lecz tworzona infrastruktura ciągle żyje i zmienia się, wraz z ze zmianami w jakimkolwie z systemów firmy. Pozwala to już nawet intuicyjnie odczuć, że jej budowa jest czymś odmiennym od “zwykłych” — nawet dużych — projektów informatycznych. Kierujemy się bowiem perspektywą długofalowego wykorzystywania tworzonych funkcji, tak więc inaczej wyglądać musi organizacja osób zaangażowanych w projekty, na co innego muszą zwracać uwagę architekci czy analitycy projektujący usługi. Trochę upraszczając można powiedzieć, że uczestnicząc w budowie kolejnych systemów informatycznych możemy się uczyć na swoich błędach. Możemy w ten sposób się doskonalić, dochodząc do perfekcji i projektując za kolejnymi razami coraz lepsze systemy. Inaczej jest z platformą SOA. Jest ona budowana dla firmy raz — nie ma możliwości jej doskonalenia w kolejnych odsłonach. Dlatego tak trudno jest bez doświadczenia od razu dobrze “ustawić” projekt wdrożenia platformy SOA.
Z faktu tego wynika więc, że podczas wdrożenia nowej architektury kluczowe jest podparcie się ekspertami z doświadczeniem. Skąd ich wziąć, skoro nie można wykształcić we własnej firmie? Zasadniczo są dwa wyjścia: jedno, to zatrudnić osoby, które już wdrażały SOA. Drugie rozwiązanie, to skorzystać z usług firm zewnętrznych. W pierwszym przypadku w oczywisty sposób trudno będzie skompletować pełen “zespół z doświadczeniem”. Konieczne by było bowiem od nowa ludzi zatrudnić, lub przynajmniej solidny trzon zespołu. I do tego dobrać pracowników ze specyficznymi kwalifikacjami — niezbyt szeroko dostępnych na rynku. W drugim przypadku jest dużo prościej — można oprzeć się na doświadczeniach zespołu zewnętrznego, który już na innych wyćwiczył swoje umiejętności, a nam może przekazać wszystkie dobre praktyki. Do tego dochodzą oczywiście też inne, standardowe korzyści outsourcing’u. Wśród nich wymienić warto też tę, że budując własny, specjalizowany zespół, zakładamy cały czas strumień prac w ramach własnej platformy SOA o niezbyt zmieniającym się natężeniu. Tymczasem zamawiając te prace na zewnątrz nie musimy ponosić kosztów przestojów, czy przekwalifikowania kadry.
Ostateczny wybór modelu pracy nad architekturą SOA musi jednak pochodzić z przeprowadzonej analizy korzyści oczekiwanych po takim wdrożeniu. W końcu nie inaczej jest, gdy zastanawiamy się nad jej rozwiązaniami techcznimymi, czy miejscu w naszej organizacji. Bo wdrożenie architektury SOA ma nie być kwestią mody, lecz racjonalnych przemyśleń.



Drukuj
Poleć znajomemu

Lipiec 15th, 2009 at 8:07 am
Bardzo często spotykam artykuły o SOA pisane w kontekście implementacji. I tu chyba jest podobnie. Daleki jestem od krytyki artykułu, raczej postrzegam go jako próbę opisu systemu za pomocą przypadków użycia. A wg. mnie przypadki użycia są dopiero konsekwencją łańcucha procesów w firmie i decyzji o zakresie projektu.
Otóż system (każdy) to zespół powiązanych i wzajemnie oddziaływujących elementów sławiących pewną logiczną całość. Paradoksalnie w definicji systemu znanej z ogólnej teorii systemów nie ma mowy o celu systemu jako takim, istnieje jednak darwinowskie pojęcia przetrwania (tu np. firmy na rynku). Takie spojrzenie tłumaczy nie raz wiele, miedzy innymi nieudane wdrożenia czegokolwiek z powodu dążenia silnych jednostek do zachowania swojego status quo a nie do „chwały i zysków pracodawcy”.
Ale gdzie tu SOA? Po kolei.
Organizacja, każda, ma jasno określony cel, ten wymaga zasobów a te wymagają ich dostarczenia i zarządzania nimi. To najprostszy moim zdaniem i najlepszy metamodel organizacji a oprogramowanie to jeden z takich zasobów. Tak więc w większości przypadków firmy wymagają: pracowników, finansowania, sprzątania i wielu pewnie innych, równie wartościowych i potrzebnych działań. Rzecz w tym, że np. firmy cel rynkowy mają jeden, każda niemalże inny a zapewnianie zasobów i zarządzanie nimi nie raz stanowi tajemnice handlową itp. (modeli biznesowych jest chyba tyle ile firm a to modele biznesowe tworzą wartość na rynku i przewagę nad konkurencją).
Problem więc, jaki ma do rozwiązania wiele firm, to dopasowanie do swoich potrzeb, innych niż maja wszystkie inne firmy w tym konkurenci, narzędzi pomagających w zarządzaniu takim systemem. I tu pojawia się wyższość SOA jako metody budowy systemu informatycznego nad systemami ERP, które są jednak dość sztywnymi konstrukcjami opartymi na jakiś wybranym, ale jednym, modelu funkcjonowania. Konfigurowalność tych systemów jest daleka od ideału.
Podstawową więc wyższością, dającą przewagę na rynku, jest zwinność organizacji mającej luźno powiązane elementy (zasoby, w tym informatyczne) współpracujące ze sobą na bazie „kontraktów”. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. W tym kontekście możliwe jest oszacowanie zwrotu z inwestycji w SOA jako wdrożenie sposobu realizacji strategii informatyzacji firmy. SOA jako projekt technologiczny bez podbudowy zarządczej moim zdaniem nie ma żadnego sensu gdyż to strategia zarządzania jest w stanie pokazać jakim kosztem jest sens ta strategie wdrażać. Pytanie o zwrot z inwestycji w SOA bez tej wiedzy moim zdaniem pozostanie bez odpowiedzi z powodu braku danych.
Lipiec 30th, 2009 at 12:39 pm
Daleki jestem od tego, by SOA traktować jako projekt technologiczny. Takie podejście jest najkrótszą drogą do wdrożenia nowej architektury na zasadzie “bo tak się robi”, bez oglądania się na koszty i zyski. Nie będziemy mieć wtedy SOA, tylko wdrożoną technologię komunikacyjną. Ale jak widać tego nie wyraziłem dostatecznie wyraziście w artykule… Wspomniana przeze mnie dynamika przedsiębiorstwa (wyrażająca się w następujących po sobie projektach i wymagająca częstych zmian we wspomagających systemach IT), która nadaje sens tej architekturze, pochodzić może oczywiście tylko ze strategii firmy i podejścia do jej obsługi przez IT.
Warto jednak sobie też powiedzieć, że jest wiele odcieni szarości pomiędzy modelem jednego, scentralizowanego, monolitycznego systemu obsługującego całą firmę, a dostarczaniem funkcjonalności poszczególnych obszarów biznesowych w postaci niezależnych komponentów, z których “zwinnie” będą korzystać wszyscy potrzebujący. Kiedy jesteśmy uprawnieni, żeby daną organizację określić jako zbudowaną na architekturze SOA, a kiedy nie? Myślę, że można by wiele czynników wymienić. Oczywiście najważniejsze będą te biznesowe (określające właśnie zarządzalność organizacji, zgadzam się). Ale w końcu mówimy o technologii, tak więc rzeczywiste osiągnięcie tego oczekiwanego stanu opierać się będzie na sposobie zaimplementowania określonej idei.
Grudzień 27th, 2009 at 10:03 pm
Jest takie znane powiedzonko: jak zjeść słonia? gryz po gryzie. Wdrożenie SOA, podobnie jak każda inna duża transformacja sposobu zarządzania rozwojem IT, to właśnie słoń. Słonia należy zjadać gryz po gryzie, a SOA należy wdrażać stopniowo, raczej metodą ewolucji niż rewolucji. Sugestia, jakoby wdrożenie SOA było jakimś “projektem”, który wykonuje się w kilka miesięcy, i to jeszcze najlepiej przy użyciu ludzi nieznających firmy, tj. ludzi z zewnątrz, jest… raczej nie szczera. A już stwierdzenie, że SOA wdraża się raz na zawsze, bez możliwości poprawiania tego co się wdrożyło (z tego właśnie autor wywodzi wniosek, jakoby najlepszym wyjściem było zatrudnić “ekipę fachowców” z zewnątrz, no bo skoro wdrażamy na hura i bez możliwości zmiany, to powinni to zrobić fachowcy) to mocne przegięcie.
Oczywiście, ludzie którzy wiedzą jak to zrobić są niezbędni, ale w przeciwieństwie do tego co napisał autor, uważam że wystarczy bardzo wąski zespół ekspertó (3 osoby to już aż nadto), który zajmie się pilotowaniem programu. Proste umiejętności techniczne, takie jak np. implementacja usług w danej technologii można łatwo nabyć, a więc można łatwo przeszkolić własnych ludzi. Zespół wdrażający SOA powienien - w idealnym przypadku - składać się z dobrze znającej firmę osoby z wewnątrz, która kierowała by wdrożeniem, oraz jednego czy dwu konsultantów z zewnątrz, najlepiej każdy z innej firmy, których zadaniem byłoby sugerowanie kierownikowi wdrożenia (temu z wewnątrz firmy), co robić dalej.
Grudzień 28th, 2009 at 5:06 pm
Całego słonia połkniętego naraz (a nie “gryz po gryzie”) to chyba tylko w “Małym Księciu” widziałem na obrazku. Natomiast co do gryzienia po kawałku, to też mi się przypomniała anegdota: Sąsiad z dołu pyta sąsiada z góry:
- “Co to za stuki ostatnio u pana słyszę?”
A on na to:
- “Mam prosiaka z protezą”.
- “Co???”
- “Tak, zachciało mi się golonki, a co będę całego zabijać, zepsuje mi się, zanim zjem”.
Podobnie z tym słoniem: możemy go nagryźć z losowej, najładniej wyglądającej strony. Tylko może się okazać, że to nie był właściwy koniec. Podobnie z wdrażaniem SOA.
Na pewno nie zlecimy całego wdrożenia firmie zewnętrznej, bo może dostarczyć nam czarną skrzynkę z napisem “SOA”, ale o reużywalności, komponentowości i innych “…ościach” będziemy mogli tylko… poczytać w zagranicznej prasie. Więc oczywiście człowiek z “wewnątrz” jest potrzebny. Natomiast widziałem już kilka wdrożeń własnymi siłami, które potem miały nowe otwarcie, całkiem różne od poprzedniego. Po prostu korzystajmy z doświadczeń innych. Uważam, że temat ma zbyt wiele niuansów, przez co łatwo popełnić błędy mimo książkowego trzymania się pryncypiów.
Poza tym, w podanym przypadku w sumie się chyba nie różnimy zdaniem: jedna osoba z wewnątrz oraz dwie z zewnątrz - to oznacza jednak większość z zewnątrz…