Na stronach www.modernanalyst.com pojawił się kolejny ciekawy artykuł, kluczowe tezy to:
The two major areas for change driving the new IS shift are the desire or need to:
(1) manage business process and business rules as separate but closely related and connected resources and
(2) decompose software or programming code into reusable modules, called services, managed by a service oriented architecture (SOA) infrastructure. The SOA infrastructure manages and mediates services used in a business process.
(A New Information Systems Paradigm: What does a Business Analyst Needs to Know?).
To kolejne źródło, które publikuje “przepowiednię” mówiącą, że kluczowy wpływ na rozwój i projektowanie systemów informatycznych będą miały dwie kluczowe kompetencje i analityków i projektantów: zarządzanie procesami biznesowymi i regułami biznesowymi jako odrębnymi, powiązanymi obszarami, opisującymi organizacje oraz umiejętność dekompozycji oprogramowania na samodzielne odrębne moduły-usługi, których można niezależnie używać np. w architekturze SOA. Architektura SOA daje możliwość niezależnego przyporządkowania potrzebnych usług do konkretnych procesów biznesowych.
W 2007 roku pisałem, że przewiduję powolne odchodzenie od idei systemów zintegrowanych. Dotychczasowa ich zaleta czyli pełna integracja przestaje być zaletą a staje się garbem. System zintegrowany można już ?skleić? ze specjalizowanych aplikacji, komponentów. Technologia obiektowa bardzo ten proces ułatwiła. Drugim powodem przewidywanego odejścia od tej idei są ogromne kłopoty z oceną rentowności wdrożenia systemu ERP. Nie raz jest to po prostu wręcz niemożliwe z powodu braku możliwości oceny jakim kosztem wspieramy pojedynczy proces biznesowy bo trudno z jednego ogromnego systemu wykroić koszt wsparcia pojedynczego procesu. (Czy to już nadchodzący koniec zintegrowanych ERP?).
W roku 2011, rok temu można było zauważyć, że rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego ?super systemu? ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci ?gotowej? tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. Dobry system ERP to środowisko programistyczne (tak zwany framework, szkielet). Systemy, nawę je ?zapóźnione?, nadal wymagają ingerencji w ich kod by cokolwiek osiągnąć. Kompromisem jest sytuacja, w której system ERP ma bogaty interfejs (tak zwane API, Application Programming Interface) pozwalający na integrację dedykowanych podsystemów lub właśnie zewnętrznych komponentów czyli korzystania z możliwości jakie daje Cloud Computing). Przyszłość to komponenty? (Biznes wychodzi z objęć systemu ? monolitycznego ERP).
W ubiegłym roku na konferencji SOA Executive Forum miałem referat Jak rozumiane SOA odejdzie do lamusa? Co nastąpi po SOA?. Poruszyłem kilka spraw:
- SOA jako Service Oriented Architectute, czym było jako technologia?
- SOA jako Service Oriented Analysis a cóż to takiego?
- SOA jako nowoczesna architektura systemów wspomagających zarządzanie
- Nowe czasy: architektura oparta na komponentach rynkowych czyli SaaS, Clod Computing i inne
Duże zainteresowanie wzbudziło wtedy rozwinięcie skrótu: [[Service Oriented Analysis]]. Otóż analiza procesów biznesowych i następująca po niej analiza wymagań, a być może dalej obiektowe projektowanie, prowadzi właśnie do “orientacji na usługi”. Przypadek użycia w UML (i jako wymaganie w obiektowym paradygmacie) to nic innego jak usługa systemu. Nic nie stoi na przeszkodzie, by je – te usługi – implementować “oddzielnie i niezależnie. Otrzymamy wtedy znane od lat COTS. Powyższy diagram jasno pokazuje, że “system” wspomagający zarządzanie to pakiet usług wspomagających konkretne procesy biznesowe i nie koniecznie będący jednym zintegrowanym pakietem oprogramowania ERP II.
Podejście takie jest wygodne gdyż pozwala projektować i wdrażać nawet bardzo złożone systemy metodą kolejnych kroków-komponentów, spokojnie można je nazwać etapami a całość, zwinnym projektem. Jednak z drugiej strony ta zwinność, to nie może być “rzut na taśmę bez analizy i projektowania”.
Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. 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.. Co więc robić?
- Opisać strategie rynkową firmy,
- Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów),
- Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych,
- Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści,
- Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi.
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. (W co inwestować w kryzysie c.d. – SOA)
Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.
Co do założeń to zgoda, ale praktyka często weryfikuje stwierdzenie “… zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego.”
Obecnie SOA w wymiarze konkretnych realizacji, to wielka i skomplikowana “biurokratyczno/technologiczna maszyna” w żaden sposób nie nawiązująca do chwalebnej idei zwinności 🙁
Ale nadal mam nadzieję na przełom w tym względzie 🙂
hm… trudno wskazać granice pomiędzy biurokracja a technologią, osobiście traktuję SOA jako “wzorzec architektoniczny”, a nie produkt tej czy innej firmy, nie raz za pieniądze mające się nijak do korzyści z posiadania…
@Jarek Żeliński
Nie chodzi mi o konkretny produkt, ale same podejście w realizacji, które w przypadku SOA oznacza wyprodukowanie stosu skomplikowanych procedur, listy interfejsów do zrealizowania, aby przyłączyć system. Duża nadmiarowość i skomplikowanie, które mają niby przynieść elastyczność, powodują, że nikt tego nie ogarnia, a proste operacje dołączenia nowego systemu lub zmiany, albo powodują paraliż organizacyjny, albo też zabierają znacznie więcej czasu niżby określenie “zwinność” sugerowało.
Właściwie od samego początku określenie SOA, było dla mnie podejrzane:) Pracując wiele lat w różnych rolach (administrator, programista, analityk, szef projektu) zawsze uważałem informatykę jako “Service”. A tu nagle: złota myśl, eureka, oświecenie: “zróbmy oprogramowanie tak by świadczyło usługi” 🙂
BTW: Czy może słyszał Pan o jakimś pełnym wdrożeniu SOA? W Polsce. Gdzieś na świecie? Przyznam się, że zastanawiałem się ostatnio nad tym i niestety nie byłem w stanie znaleźć takiego przykładu 🙂
To wszystko zależy od tego jak zdefiniujemy SOA. Jeżeli literalnie, czyli Architektura Zorientowana na Usługi, to w zasadzie mamy komponentowe systemy obiektowe szanujące zasadę, wg. której każdy komponent – podobnie jak klasy – ma ściśle określona odpowiedzialność. Takie widywałem…
@Jarek Żeliński
“wg. której każdy komponent ? podobnie jak klasy ? ma ściśle określona odpowiedzialność. ”
Wydaje mi się, że to nie wystarczy by coś mogło zostać nazwane SOA. Obecnie wiele systemów nieSOA, można tak opisać i nie “powstanie” SOA :). Np. ERP – odpowiada za wystawianie faktur:) W dużym skrócie, w moim rozumieniu realizacja SOA to przejrzyste, proste i explicite określone interfejsy. Tak i programowe, jak i takie, za które odpowiedzialny jest człowiek.
Ale jeżeli uznać, że każdy komponent jest widziany poprzez (i tylko) swój interfejs to mamy konsensus :), SOA to pojęcie “worek” dlatego napisałem, że to jedynie “architektura” a nie technologia czy nawet produkt (co starają się wmawiać dostawcy produktów z akronimem SOA w nazwie). W kwestii interfejsów, GUI (graficzny interfejs użytkownika) to tylko wierzchołek góry lodowej, systemy składają się z wielu komponentów, wiele z nich nie ma bezpośredniego kontaktu z ludzkim użytkownikiem, obecnie najbliżej do SOA ma chyba to co nazywamy cloud computing.
Could Computing to dobry przykład udanego SOA np. Google App Engine.
A co do narzędzi to powinny one wspierać maksymalnie architekturę na jak najniższym poziomie implementacji – języki programowania, CSV, GUI designers itp. Nie da się zrealizować założeń konkretnej architektury dowolnym narzędziem IT. Stary, dobry i ekstremalny przykład do pisanie ERP w assemblerze 🙂 Technicznie możliwe, ale sił, motywacji, czasu i pieniędzy nie starczy.
Hm… jeśli dobrze rozumiem to interfejsy świadczące usługi powinny być chyba na “wysokim” poziomie np. Webservice, REST, JASON…???
@Jarek Żeliński
Tak, zgadza się. Tylko zawsze trzeba czymś je “sklejać”: mapować informację przesyłaną przez nie; oraz zmieniać same interfejsy: poprawiać i rozbudowywać.
WebService napisany w assemblerze słabo się konserwuje (maintenance) 🙂
Mapowanie w językach niskiego poziomu też niezbyt sprawnie się robi i przejrzyście wygląda 🙂
faktem jest, że “format danych” jest ważny, tu kłania się brak standardów ale ich raczej nie będzie dlatego jestem zdania, że w API powinny być udostępniane tylko całe obiekty a nie poszczególne pola bo to łatwiejsze (jedno zapytanie i mapowania i odsiew po stronie pytającego).
Tak, format dany jest istotny – cały czas zadziwia mnie, ze do tej pory rzadko używane są standardowe formaty np. do faktury 🙂
Mapowanie obiektu to nie jest dobre rozwiązanie i nie zawsze możliwe.
Integrowane systemy często są “zastane” i nie modyfikowalne. Przy nowych systemach nie ma sensu tworzyć dodatkowych interfejsów tłumaczących, a lepiej zachować natywny i najlepiej zintegrowany technologicznie interfejs API. A integrację przeprowadzić za pomocą dodatkowej aplikacji integracyjnej. Dzięki temu uzyskujemy wysoki poziom aplikacji: żadna nic nie wie o pozostałych – oczywiście poza aplikacją integrującą :).
Co prawda powstaje wtedy SPOF (Single Point Of Failure), ale jest kilka sposobów na zabezpieczenie się przed awariami lub rozproszenie SPOF.