soa: młot na erp mlot na erp.pdf · (dyrektor marketingu giełdowego), elektrim s.a. (menedżer...

3
24 TENDENCJE BUSINESS APPLICATIONS REVIEW 04/2007 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ł Architektura Zorientowana na Usługi (ang. Servi- ce Oriented Architecture) to idea tworzenia syste- mów informacyjnych w postaci niezależnych kom- ponentów. Każdy komponent to obiekt ze ściśle zde- finiowaną funkcjonalnością. Celem każdego kom- ponentu jest wsparcie konkretnego procesu biz- nesowego. O jakie procesy chodzi? Tu wagi nabiera modelo- wanie procesów zorientowanych na produkty. Pro- jektowanie tego typu rozwiązań wymaga modelowa- nia na kilku poziomach. Należy wykonać model pro- cesów średniego poziomu. Jest to model nazywany czasem mapą procesów na drugim poziomie. Ten po- ziom obrazuje produkty, ale jeszcze nie dotyka szcze- gółów wykonywania czynności. Model na tym pozio- mie 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łoby użyć komponentu Fakturo- wanie, zasilić go danymi do faktury (dane kontrahen- ta i związane z nim upusty i terminy płatności, pro- dukty 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 przysta- jących do pojedynczych potrzeb, nie jest nowością. Modelowanie procesów jest znane od czasów poja- wienia się metodologii zarządzania jakością. Do- stę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. Pro- gramy były zintegrowanymi (nieraz są i w obecnych czasach) wielkimi zbiorami wywołujących się pod- programów, operującymi bezpośrednio na zbio- rach danych. Praktycznie uniemożliwiało to jakie- kolwiek powtórne użycie jakiegokolwiek fragmen- tu kodu. Przełomem w tej dziedzinie było pojawienie się obiektowych metod analizy oraz spopularyzowanie obiektowych języków programowania, takich jak SOA: młot na ERP Jarosław Żeliński Absolwent Wojskowej Akademii Technicznej, nauczyciel akademicki. Pracował m.in.: w Bonair S.A. (zarządzał projektami, realizawał anali- zy przedwdrożeniowe, dyrektor marketingu i sprzedaży), w Apexim S.A. (dyrektor marketingu giełdowego), Elektrim S.A. (menedżer rozwoju produktów, stworzył m.in. strategię integracji i rozwoju spółek interne- towych), w Optimus S.A. (doradzał zarządowi firmy w obszarze nowych strategii i usług), w Exatel S.A. (kierował zespołem planowania i ana- liz). Obecnie jest członkiem Stowarzyszenia Doradców Gospodarczych. Od 2004 roku, jako niezależny konsultant. Specjalizuje się w tworzeniu modeli biznesowych, map i modeli procesów biznesowych oraz w ana- lizach strategicznych. Wydawca portalu IT-Consulting.pl. Od 2004 ro- ku współpracuje jako partner z firmą konsultingową MILSTAR Sp. z o.o. Od 2005 roku wykłada na Wydziale Przedsiębiorczości Akademii Mor- skiej w Gdyni.

Upload: others

Post on 18-Jul-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: SOA: młot na ERP Mlot na ERP.pdf · (dyrektor marketingu giełdowego), Elektrim S.A. (menedżer rozwoju produktów, stworzył m.in. strategię integracji i rozwoju spółek interne-towych),

24

TENDENCJE

BUSINESS APPLICATIONS REVIEW 04/2007

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łArchitektura Zorientowana na Usługi (ang. Servi-ce Oriented Architecture) to idea tworzenia syste-mów informacyjnych w postaci niezależnych kom-ponentów. Każdy komponent to obiekt ze ściśle zde-finiowaną funkcjonalnością. Celem każdego kom-ponentu jest wsparcie konkretnego procesu biz-nesowego.

O jakie procesy chodzi? Tu wagi nabiera modelo-wanie procesów zorientowanych na produkty. Pro-jektowanie tego typu rozwiązań wymaga modelowa-nia na kilku poziomach. Należy wykonać model pro-cesów średniego poziomu. Jest to model nazywany czasem mapą procesów na drugim poziomie. Ten po-ziom obrazuje produkty, ale jeszcze nie dotyka szcze-gółów wykonywania czynności. Model na tym pozio-

mie 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łoby użyć komponentu Fakturo-wanie, zasilić go danymi do faktury (dane kontrahen-ta i związane z nim upusty i terminy płatności, pro-dukty 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 informatykaIdea budowy aplikacji, czy całych systemów przysta-jących do pojedynczych potrzeb, nie jest nowością.

Modelowanie procesów jest znane od czasów poja-wienia się metodologii zarządzania jakością. Do-stę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. Pro-gramy były zintegrowanymi (nieraz są i w obecnych czasach) wielkimi zbiorami wywołujących się pod-programów, operującymi bezpośrednio na zbio-rach danych. Praktycznie uniemożliwiało to jakie-kolwiek powtórne użycie jakiegokolwiek fragmen-tu kodu.

Przełomem w tej dziedzinie było pojawienie się obiektowych metod analizy oraz spopularyzowanie obiektowych języków programowania, takich jak

SOA: młot na ERP Jarosław Żeliński

Absolwent Wojskowej Akademii Technicznej, nauczyciel akademicki. Pracował m.in.: w Bonair S.A. (zarządzał projektami, realizawał anali-zy przedwdrożeniowe, dyrektor marketingu i sprzedaży), w Apexim S.A. (dyrektor marketingu giełdowego), Elektrim S.A. (menedżer rozwoju produktów, stworzył m.in. strategię integracji i rozwoju spółek interne-towych), w Optimus S.A. (doradzał zarządowi firmy w obszarze nowych strategii i usług), w Exatel S.A. (kierował zespołem planowania i ana-liz). Obecnie jest członkiem Stowarzyszenia Doradców Gospodarczych. Od 2004 roku, jako niezależny konsultant. Specjalizuje się w tworzeniu modeli biznesowych, map i modeli procesów biznesowych oraz w ana-lizach strategicznych. Wydawca portalu IT-Consulting.pl. Od 2004 ro-ku współpracuje jako partner z firmą konsultingową MILSTAR Sp. z o.o. Od 2005 roku wykłada na Wydziale Przedsiębiorczości Akademii Mor-skiej w Gdyni.

Page 2: SOA: młot na ERP Mlot na ERP.pdf · (dyrektor marketingu giełdowego), Elektrim S.A. (menedżer rozwoju produktów, stworzył m.in. strategię integracji i rozwoju spółek interne-towych),

25

TENDENCJE

BUSINESS APPLICATIONS REVIEW04/2007

C++, .NET czy Java. Metody te w połączeniu z doj-rzałą wiedzą o modelowaniu procesów i zarządza-niu, zorientowanym na procesy, dały dopiero możli-wość projektowania i tworzenia systemów zoriento-wanych na usługi.

Czym jest SOA?Przede wszystkim nie jest to żadna technologia, a tyl-ko architektura. Mimo tego, że często słyszy się opi-sy SOA, brzmiące jak opisy technologii, nie jest nią ona. Nazwałbym tę architekturę raczej zbiorem za-leceń, 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 anali-za i model kolejnej warstwy.

Proces tworzenia systemu w architekturze SOA za-czyna się od wdrożenia w organizacji metod zarzą-dzania zorientowanych na procesy. Podstawą jest zbudowanie poprawnego modelu procesów i zopty-malizowanie go.

Kolejnym etapem jest określenie, które proce-sy jakimi usługami chcemy wspierać. Ten etap po-wiązany jest z analizą rentowności projektu. Każdy

wybór procesu powinien się wiązać z oceną war-tości, jaką proces wnosi do całego łańcucha war-tości organizacji, wartość ta decyduje o dopusz-czalnym koszcie implementacji usługi, wspierają-cej ten proces.

Po dokonaniu wyboru procesów, które będziemy wspierać zasobami IT, przystępujemy do analizy wy-magań i projektowania. Ten etap kończy się projek-tem architektury obiektowej komponentu.

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 standardachModel biznesowy firmy, informacje i dane, jakich fir-ma 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 spraw-

Rysunek 1. Model implementacji architektury SOA

�������������������������������������

���������������������������������������������

�����������������������������������������������������

�������������������������������������

���������������������������

Page 3: SOA: młot na ERP Mlot na ERP.pdf · (dyrektor marketingu giełdowego), Elektrim S.A. (menedżer rozwoju produktów, stworzył m.in. strategię integracji i rozwoju spółek interne-towych),

26

TENDENCJE

BUSINESS APPLICATIONS REVIEW 04/2007

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.

nego zarządzania informacją. Do zarządzania in-formacją 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 tech-nologiach obiektowych.

Drugi warunek sprawności organizacji to opty-malizacja jej wewnętrznej wydajności. Tu wkracza-my dla odmiany w zarządzanie i jego procesową na-turę. Postrzegam tu właśnie miejsce dla architektury SOA. Firmę i jej miejsce w rynkowym łańcuchu war-

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 syste-mach IT. Jedyne, czego trzeba przestrzegać, to praca od samej góry: model biznesowy organizacji, model procesów biznesowych, struktura workflow (scena-riusze działań, czyli wewnętrzny opis procesów), lista oczekiwanych usług systemu IT i sam system, składa-ny z komponentów.

wanie systemami typu middleware. Do tej pory by-ły one wykorzystywane rzadko i raczej w dużych fir-mach, głównie w sektorze finansowym z uwagi na ich koszt. Obecnie rozwiązanie to staje się coraz popularniejsze. Dlaczego?

Pojawienie się standardów w modelowaniu, ustano-wienie modelowania pełnowartościowym etapem pro-jektu (a nie ekstrawagancją), otwieranie się technolo-gii, 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 jed-nego wielkiego systemu zintegrowanego. Wystarczy tak zwany motor procesów biznesowych i specjalizowa-ne systemy, mogą one pochodzić od różnych producen-tów i pracować na różnych platformach.

Czyż koniec quasi-monopolu dostawców systemów?No i okazało sie, że standardy sprawdzone same się bronią. Microsoft W BizTalk Server będzie supporto-wał BPEL (Business Proces Execution Language, opar-ty na XML język skryptowy opisu procesów między in-nymi w systemach BPM i workflow management uży-wany już między innymi w niektórych systemach CA-SE). Oracle także „rozumie” BPEL. Modelowanie sta-je 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 doga-niać konkurenci. Monopolista zaczyna czuć pokorę: de facto już nie wyznacza sam standardów (np. for-maty plików dokumentów, narzędzia programistycz-ne, 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 Mi-crosoft i Novell).

Dostawcy systemów MRPII/ERP są obecnie quasi-monopolistami u swoich obecnych klientów: jakakol-wiek zmiana funkcjonalności wymaga kontaktu z do-stawcą 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łu lub pojedynczego komponentu i innego dostawcy.

Oczekiwane kierunki rozwoju systemów ITAlbo analiza procesowa i obiektowa, albo na margi-nes życia. Coraz powszechniejsze zrozumienie idei zo-rientowania na procesy, interoperacyjności (w tym za-rządzanie łańcuchami dostaw), architektury SOA (któ-ra moim zdaniem doskonale się wpasowuje w meto-dy zarządzania, zorientowanego na procesy i reorga-nizację w firmach) powoduje stawianie takich wyma-gań także dostawcom rozwiązań IT. Te, które się do te-go nie dostosują, moim zdaniem odejdą z rynku. n

tości można, moim zdaniem, jednoznacznie opisać tylko za pomocą modelu procesowego, zorientowa-nego na produkty. Zasoby (tu system IT), potrzebne do realizacji tej strategii, analizujemy i realizujemy już obiektowo.

Jak już wspomniano, historycznie namiastką ta-kich opisów i analiz były procedury w księgach ja-koś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 pro-ces projektowania systemów IT: model procesowy firmy (organizacji), analiza procesów z perspekty-wy zasobów IT, jakimi mogą być wspierane, na ba-zie tej analizy powstaje lista usług na rzecz pro-cesów biznesowych, jakich oczekujemy od nowe-go systemu.

Następnie, w procesie analizy obiektowej, usługi te transponowane są na model obiektowy przyszłe-go systemu IT. Analiza obiektowa powinna dać, jako produkt, także opis dziedziny systemu, czyli reprezen-tację rzeczywistych obiektów w systemie. Jest to pod-stawa modelu danych dla powstającego systemu.

Te trzy elementy: model biznesowy, model proce-só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 pro-gramowania.

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ę gar-bem. 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 zintegrowa-nych są ogromne kłopoty z oceną rentowności wdrożenia systemu ERP. Nieraz jest to po prostu wręcz niemożliwe z powodu braku możliwości oce-ny, jakim kosztem wspieramy pojedynczy proces biznesowy, bo trudno z jednego ogromnego syste-mu wykroić koszt wsparcia pojedynczego procesu biznesowego. Z tego też powodu rośnie zaintereso-