Bardzo często spotykam artykuły o SOA pisane w kontekście implementacji. Daleki jestem od krytyki technologii i technologicznych ofert różnych integratorów IT, raczej postrzegam takie technologiczne oferty 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 a nie ?narzuconą lista funkcjonalności?.

Street, K. (2006). Building a Service Oriented Architecture with BPM and MDA. 2(1), 8.

Otóż system (każdy) to zespół powiązanych i wzajemnie oddziaływujących elementów stanowią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, niezależnie co jest ich głównym przedmiotem działalności, 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ą) nie istnieje więc, mioim zdaniem, jeden model ?dobrego i sprawdzonego systemu? (choć dostawcy systemów ERPII są innego zdania).

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 tą strategie wdrażać. Pytanie o zwrot z inwestycji w SOA bez tej wiedzy moim zdaniem pozostanie bez odpowiedzi z powodu braku danych.

Co więc robić?
Skoro mamy metamodel ?Organizacja, każda, ma jasno określony cel, ten wymaga zasobów a te wymagają ich dostarczenia i zarządzania nimi.? To warto sobie powiedzieć, że właściwa (najskuteczniejsza) kolejność to taka:
1. Opisać strategie rynkową firmy
2. Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów)
3. Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych
4. wskazać (zdefiniować) zasoby, także informacyjne, dla tych procesów
5. wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści
6. zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi
7. opracować strategię zapewnienia tych zasobów
Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).