W tym roku ukazała się książka, której autorem jest Mark Wilkins: Amazon Web Services: podstawy korzystania z chmury AWS [zotpressInText item=”{5085975:SFA9HCDB}”]:
Książka sprawia wrażenie bardzo technicznej, ale pisana jest jasnym językiem i bogato ilustrowana. Na 464 stronach opisano usługi chmurowe oferowane przez Amazon. Autor na szczęście nie miał ambicji zastąpienia swoją książką oryginalnej dokumentacji, nastawił się (moim zdaniem) na wyjaśnienie mechanizmów działania poszczególnych usług i to właśnie wzbudziło moją sympatię do autora. Jeżeli po książkę sięgną developerzy to pewnie dlatego, że ją po prostu znaleźli w toku zawodowych poszukiwań.
Ja polecam tę książkę architektom bo pozwala zrozumieć to co robią developerzy. Polecam ją także analitykom, którzy w zasadzie także są architektami, co mechanizmów biznesowych aplikacji ale jednak to także już architektura. Analitycy pewnie nie małą część tej książki przewiną jak taśmę filmu z wesela przyjaciół, jednak początkowe rozdziały opisujące ogólnie te usługi, oraz te dotyczące magazynowania danych, są bardzo pouczające. To ostatnie polecam szczególnie tym z Was, którzy nadal są wyznawcami religii SQL/relacyjnej … Dowiedzą się paru ciekawych rzeczy 🙂 o bazach NoSQL.
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.
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.
