Rozdział: SOA: usługi na miarę, system jak ulał 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ł 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ą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. 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 1
Rozdział: Czym jest SOA 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. 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 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. 2
Rozdział: Czym jest SOA Rysunek 1: Model implementacji architektury SOA 3
Rozdział: Projektowanie i wdrażanie nowych systemów w standardach 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 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. 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. 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 4
Rozdział: Co po systemach zintegrowanych (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 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. 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. 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. 5
Rozdział: Oczekiwane kierunki rozwoju systemów ERP 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. Oczekiwane kierunki rozwoju systemów ERP 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 j.zelinski@it-consulting.pl Tel.: 608 05 90 20 6