[toc]
Usługi na sztuki czy kompleksowe pakiety
SOA moim zdaniem zagroziło zintegrowanym systemom np. ERPII i nie tylko. Pojawiło się światełko w tunelu dla szybko wdrażanych aplikacji na życzenie z jednoczesną możliwością oceny ich rentowności.
SOA: usługi na miarę, system jak ulał
Service Oriented Architecture (ang. Architektura Zorientowana na Usługi) to idea tworzenia systemów informacyjnych w postaci niezależnych komponentów. Każdy komponent to obiekt ze ściśle zdefiniowaną funkcjonalnością. Celem każdego komponentu jest wsparcie konkretnego procesu biznesowego.
O jakie procesy chodzi? Tu wagi nabiera modelowanie procesów zorientowane na produkty. Projektowanie tego typu rozwiązań wymaga modelowania na kilku poziomach. Należy wykonać model procesów średniego poziomu. Jest to model nazywany czasem mapą procesów na drugim poziomie. Ten poziom obrazuje produkty ale jeszcze nie dotyka szczegółów wykonywania czynności. Model na tym poziomie nazywany bywa także wewnętrznym łańcuchem wartości firmy. Na tym poziomie np. fakturowanie (wystawienie faktury) jest to jeden proces kończący się produktem, którym jest tu faktura.
Gdyby teraz wymaganiem było wsparcie procesu fakturowania należało by użyć komponentu Fakturowanie, zasilić go danymi do faktury (dane kontrahenta i związane z nim upusty i terminy płatności, produkty lub usługi oraz ich ceny i wolumeny i inne) by uzyskać produkt procesu czyli fakturę.
Ale o tym jak zinformatyzować tak całą firmę w dalszej części.
Usługi: idea stara jak informatyka
Idea budowy aplikacji czy całych systemów przystających do pojedynczych potrzeb nie jest nowością. Modelowanie procesów jest znane od czasów pojawienie się metodologii zarządzania jakością. Dostępne wcześniej technologie oraz niemalże zupełny brak standardów skutecznie jednak uniemożliwiały implementacje takich pomysłów.
Metody projektowania aplikacji oraz technologie ich implementacji były bardzo hermetyczne. Programy były zintegrowanymi (nie raz są i w obecnych czasach) wielkimi zbiorami wywołujących się podprogramów operującymi bezpośrednio na zbiorach danych. Praktycznie uniemożliwiało to jakiekolwiek powtórne użycie jakiegokolwiek fragmentu kodu.
Przełomem w tej dziedzinie było pojawienie się obiektowych metod analizy oraz spopularyzowanie obiektowych języków programowania takich jak C++, .NET czy Java. Metody te w połączeniu z dojrzałą wiedzą o modelowaniu procesów i zarządzaniu zorientowanym na procesy dały dopiero możliwość projektowania i tworzenia systemów zorientowanych na usługi.
Czym jest SOA
Przede wszystkim nie jest to żadna technologia a tylko architektura. Mimo tego, że często słyszy się opisy SOA brzmiące jak opisy technologii nie jest nią ona. Nazwał bym tę architekturę raczej zbiorem zaleceń, dobrych praktyk, wzorców oraz wskazówek do projektowania. Jakich? Droga od opisu organizacji do implementacji ma kilka etapów. Każdy z nich to analiza i model kolejnej warstwy.
Proces tworzenia systemu w architekturze SOA zaczyna się od wdrożenia w organizacji metod zarządzania zorientowanych na procesy. Podstawą jest zbudowanie poprawnego modelu procesów i zoptymalizowanie go.
Kolejnym etapem jest określenie, które procesy jakimi usługami chcemy wspierać. Ten etap powiązany jest z analizą rentowności projektu. Każdy wybór procesu powinien się wiązać z oceną wartości jaką proces wnosi do całego łańcucha wartości organizacji, wartość ta decyduje o dopuszczalnym koszcie implementacji usługi wspierającej ten proces.
Po dokonaniu wyboru procesów, które będziemy wspierać zasobami IT przystępujemy do analizy wymagań i projektowania. Ten etap kończy się projektem architektury obiektowej komponentu.
Rysunek 1: Model implementacji architektury SOA
Kolejny krok to implementacja. Tu z pomocą może przyjść MDA czyli architektura sterowana modelem (ang. Model Driven Architecture). MDA to ścieżka od modelu obiektowego do kodu wykonywalnego aplikacji.
Opis tego procesu pozwala przypuszczać, że czas od projektu do wdrożenia może trwać nawet kwartał. Jak to się dzieje??
Projektowanie i wdrażanie nowych systemów w standardach
Model biznesowy firmy, informacje i dane jakich firma wymaga do sprawnego funkcjonowania to już jeden organizm. Stało się faktem, że żadna firma na rynku już nie będzie w stanie konkurować bez sprawnego zarządzania informacją. Do zarządzania informacją i przetwarzania danych zaś potrzebne są sprawnie działające i przede wszystkim łatwe w ich rozwijaniu systemy. Warunek taki spełniają obecnie zorientowane na procesy systemy tworzone w technologiach obiektowych.
Drugi warunek sprawności organizacji to optymalizacja jej wewnętrznej wydajności. Tu wkraczamy dla odmiany w zarządzanie i jego procesową naturę. Postrzegam tu właśnie miejsce dla architektury SOA. Firmę i jej miejsce w rynkowym łańcuchu wartości można, moim zdaniem, jednoznacznie opisać tylko za pomocą modelu procesowego zorientowanego na produkty. Zasoby (tu system IT) potrzebne do realizacji tej strategii analizujemy i realizujemy już obiektowo.
Jak już wspomniano historycznie namiastką takich opisów i analiz były procedury w księgach jakości ISO. Do pełnej analizy wymagany jest jednak opis (mapa procesów) uwzględniający cały obraz firmy.
SOA to architektura wskazująca naturalny proces projektowania systemów IT: model procesowy firmy (organizacji), analiza procesów z perspektywy zasobów IT jakimi mogą być wspierane, na bazie tej analizy powstaje lista usług na rzecz procesów biznesowych jakich oczekujemy od nowego systemu.
Następnie w procesie analizy obiektowej usługi te transponowane są na model obiektowy przyszłego systemu IT. Analiza obiektowa powinna dać jako produkt także opis dziedziny systemu czyli reprezentację rzeczywistych obiektów w systemie. Jest to podstawa modelu danych dla powstającego systemu. Kolejne etapy to już projekt obiektowego programu (aplikacji) i jego implementacja.
Jak widać architektura zorientowania na procesy to wydajna i skuteczna metodologia projektowania, modyfikowania i wdrażania funkcjonalności w systemach IT. Jedyne czego trzeba przestrzegać to praca od samej góry: model biznesowy organizacji, model procesów biznesowych, struktura workflow (scenariusze działań czyli wewnętrzny opis procesów), lista oczekiwanych usług systemu IT i sam system składany z komponentów. Tak to widzę.
Te trzy elementy: model biznesowy, model procesów, usługi IT stanowią pewną całość. Ubranie opisu usług w ciało to właśnie obiektowe technologie w IT, architektura SOA i MDA, języki i notacje i standardy XML, BPEL, BPMN, UML, XMI, obiektowe języki programowania.
Co po systemach zintegrowanych
Przewiduję powolne odchodzenie od idei systemów zintegrowanych. Dotychczasowa ich zaleta czyli pełna integracja przestaje być zaletą a staje się garbem. System zintegrowany będzie można ?skleić? z komponentów różnych producentów. Technologia obiektowa bardzo ten proces ułatwiła.
Drugim powodem przewidywanego przeze mnie odejścia od idei typowych systemów zintegrowanych 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 biznesowego. Z tego też powodu rośnie zainteresowanie systemami typu middleware. Do tej pory były one wykorzystywane rzadko i raczej w dużych firmach, głównie w sektorze finansowym z uwagi na ich koszt. Obecnie rozwiązanie to staje się coraz popularniejsze. Dlatego?
Pojawienie się standardów w modelowaniu, ustanowienie modelowania pełnowartościowym etapem projektu (a nie ekstrawagancją), otwieranie się technologii, pojawianie się standardów wymiany metadanych i modeli torują więc drogę do znacznego obniżenia kosztów i usprawnienia tworzenia systemów opartych o komponenty. To wszystko powoduje, że nie trzeba jednego wielkiego systemu zintegrowanego. Wystarczy tak zwany motor procesów biznesowych i specjalizowane systemy, mogą one pochodzić od różnych producentów i pracować na różnych platformach.
Czyż koniec quasimonopolu dostawców systemów?
No i okazało sie, że standardy sprawdzone same się bronią. Microsoft W BizTalk Server będzie supportował BPEL (Business Proces Execution Language, oparty na XML język skryptowy opisu procesów między innymi w systemach BPM i workflow management używany już między innymi w niektórych systemach CASE). Oracle także ?rozumie? BPEL. Modelowanie staje się normą a otwartość standardem. Notacje UML i BPMN stają się standardem modelowania.
Co to znaczy? Moim zdaniem to, że powoli staje się coś o czym pisałem swego czasu w jednym z moich wcześniejszych artykułów. Monopolistę zaczęli doganiać konkurenci. Monopolista zaczyna czuć pokorę: już nie wyznacza sam standardów de’facto (np. formaty plików dokumentów, narzędzia programistyczne, interfejsy komunikacyjne). Tracąc powoli rynek na rzecz rozwiązań konkurencji dostrzegł, że to co było przewagą rynkową (zamknięte rozwiązania) stało się w dalszej perspektywie hamulcem. Przyszła pora na otwartość i konkurowanie jakością a nie szantaż ponad 80% udziałem w rynku (vide współpraca Microsoft i Novell).
Dostawcy systemów MRPII/ERP są obecnie quasi monopolistami u swoich obecnych klientów: jakakolwiek zmiana funkcjonalności wymaga kontaktu z dostawca systemu praktycznie bez możliwości zmiany tego stanu rzeczy, zakładając że nie rezygnujemy całkowicie z posiadanego systemu na korzyść innego. System komponentowy pozbawi ich tego monopolu. Będzie możliwe zakupienie moduły lub pojedynczego komponentu i innego dostawcy.
Oczekiwane kierunki rozwoju systemów IT
Albo analiza procesowa i obiektowa albo na margines życia. Coraz powszechniejsze zrozumienie idei zorientowania na procesy, interoperacyjności (w tym zarządzanie łańcuchami dostaw), architektury SOA (która moim zdaniem doskonale się wpasowuje w metody zarządzania zorientowanego na procesy i reorganizację w firmach) powoduje stawianie takich wymagań także dostawcom rozwiązań IT. Te które się do tego nie dostosują, moim zdaniem odejdą z rynku.
? Jarosław Żeliński 2007
Tel.: 608 05 90 20
A016_Pakiety_zintegrowane_ERP_i_SOA
