SOA: młot na pakiety zintegrowane ERP - IT

SOA: młot na pakiety zintegrowane ERP
6 listopada 2007
Pakiety zintegrowane ERP i SOA
Usługi na sztuki czy kompleksowe pakiety
SOA moim zdaniem wyznaczyło nowe kierunki w rozwoju systemów 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ł
O jakie procesy chodzi? Tu wagi nabiera modelowanie procesów zorientowane
na produkty. Projektowanie tego typu rozwiązao wymaga modelowania na kilku
poziomach. Należy wykonad 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 łaocuchem wartości firmy. Na
tym poziomie np. fakturowanie (wystawienie faktury) jest to jeden proces
kooczący się produktem, którym jest tu faktura.
Gdyby teraz wymaganiem było wsparcie procesu fakturowania należało by użyd
komponentu Fakturowanie, zasilid 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 uzyskad produkt procesu czyli fakturę.
Ale o tym jak zinformatyzowad 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.
Rozdział: 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.
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
© Jarosław Żelioski
http://IT-Consulting.pl
1
SOA: młot na pakiety zintegrowane ERP
6 listopada 2007
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śd 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 zaleceo, 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.
Kolejnym etapem jest określenie, które procesy jakimi usługami chcemy
wspierad. Ten etap powiązany jest z analizą rentowności projektu. Każdy wybór
procesu powinien się wiązad z oceną wartości jaką proces wnosi do całego
łaocucha wartości organizacji, wartośd ta decyduje o dopuszczalnym koszcie
implementacji usługi wspierającej ten proces.
Po dokonaniu wyboru procesów, które będziemy wspierad zasobami IT
przystępujemy do analizy wymagao i projektowania. Ten etap kooczy się
projektem architektury obiektowej komponentu.
© Jarosław Żelioski
Rozdział: Czym jest SOA
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.
http://IT-Consulting.pl
2
6 listopada 2007
Rozdział: Czym jest SOA
SOA: młot na pakiety zintegrowane ERP
Rysunek 1: Model implementacji architektury SOA
© Jarosław Żelioski
http://IT-Consulting.pl
3
SOA: młot na pakiety zintegrowane ERP
6 listopada 2007
Kolejny krok to implementacja. Tu z pomocą może przyjśd MDA czyli architektura
sterowana modelem (ang. Model Driven Architecture). MDA to ścieżka od
modelu obiektowego do kodu wykonywalnego aplikacji.
Opis tego procesu pozwala przypuszczad, że czas od projektu do wdrożenia może
trwad nawet kwartał. Jak to się dzieje??
Projektowanie i wdrażanie nowych systemów w standardach
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 łaocuchu wartości można, moim zdaniem, jednoznacznie opisad 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ą byd 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 dad 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.
Rozdział: 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 konkurowad 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.
Jak widad architektura zorientowania na procesy to wydajna i skuteczna
metodologia projektowania, modyfikowania i wdrażania funkcjonalności w
systemach IT. Jedyne czego trzeba przestrzegad to praca od samej góry: model
biznesowy organizacji, model procesów biznesowych, struktura workflow
© Jarosław Żelioski
http://IT-Consulting.pl
4
SOA: młot na pakiety zintegrowane ERP
6 listopada 2007
(scenariusze działao 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śd. 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
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 wykroid 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 pochodzid od różnych producentów i
pracowad na różnych platformach.
Rozdział: Co po systemach zintegrowanych
Przewiduję powolne odchodzenie od idei systemów zintegrowanych.
Dotychczasowa ich zaleta czyli pełna integracja przestaje byd zaletą a staje się
garbem. System zintegrowany będzie można „skleid” z komponentów różnych
producentów. Technologia obiektowa bardzo ten proces ułatwiła.
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śd
standardem. Notacje UML i BPMN stają się standardem modelowania.
© Jarosław Żelioski
http://IT-Consulting.pl
5
SOA: młot na pakiety zintegrowane ERP
6 listopada 2007
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 doganiad
konkurenci. Monopolista zaczyna czud 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ązao 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śd 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śd
innego. System komponentowy pozbawi ich tego monopolu. Będzie możliwe
zakupienie moduły lub pojedynczego komponentu i innego dostawcy.
Albo analiza procesowa i obiektowa albo na margines życia. Coraz
powszechniejsze zrozumienie idei zorientowania na procesy, interoperacyjności
(w tym zarządzanie łaocuchami dostaw), architektury SOA (która moim zdaniem
doskonale się wpasowuje w metody zarządzania zorientowanego na procesy i
reorganizację w firmach) powoduje stawianie takich wymagao także dostawcom
rozwiązao IT. Te które się do tego nie dostosują, moim zdaniem odejdą z rynku.
© Jarosław Żelioski 2007
http://it-consulting.pl
[email protected]
Tel.: 608 05 90 20
© Jarosław Żelioski
Rozdział: Oczekiwane kierunki rozwoju systemów ERP
Oczekiwane kierunki rozwoju systemów ERP
http://IT-Consulting.pl
6