Modelowanie procesów w ramach systemów SOA – część 2

0
1674

Wykorzystanie opisu działania organizacji poprzez zamodelowanie jej procesów biznesowych do zaprojektowania i implementacji dedykowanych systemów informatycznych wspierających działanie organizacji znacznie redukuje ryzyko budowy systemu niespełniającego stawianych przed nim celów. Strukturalność i precyzyjność mapy procesów biznesowych oraz mapy przepływu pracy pozwala przypuszczać, że stworzony w oparciu o nie system informatyczny dla organizacji będzie wspierał realizowane przez organizację procesy biznesowe. Metodyki modelowania procesów pod kątem ich późniejszego wykorzystania do projektowania systemów informatycznych postulują między innymi [23].

  • identyfikację procesu na podstawie modelu biznesowego i strategii przedsiębiorstwa,
  • wzajemne dostosowanie modelu procesów i strategii,
  • automatyzację wyłącznie procesów kluczowych z punktu widzenia realizacji strategicznych celów organizacji,
  • eliminację procesów generycznych, czyli takich, które nie przyczyniają się do realizacji strategii organizacji.

Jak zauważono we wstępie niniejszej pracy, przewagę rynkową nad konkurencją może dać wdrożony i ekonomicznie zasadny system, który ze względu na stawiane przed nim cele można określić mianem informacyjnego. Cele te stają się tożsame z celami analizy, modelowania i optymalizacji procesów biznesowych. Z tego powodu dla systemów informacyjnych są stosowane te same miary jak do analizy procesów biznesowych. Wzajemne przenikanie się koncepcji biznesowej przedsiębiorstwa wspieranej przez procesowe zarządzanie oraz systemów informacyjnych sprawia, że działy informatyki stają się kluczowymi jednostkami organizacji a architekci systemów informacyjnych powinni posiadać wiedzę i kompetencję zarządczą organizacji.

Na rynku rozwiązań IT istnieje wiele narzędzi wspierających modelowanie i optymalizację procesów. Narzędzia te można podzielić ze względu na ich funkcjonalność i przeznaczenie na następujące kategorie [23]:

  • narzędzia wizualizacji graficznej (np. Microsoft Visio),
  • narzędzia mapowania procesów (np. iGrafx FlowCharter),
  • narzędzia modelowania i symulacji procesów (np. iGrafx Process 2000, Corporate Modeler 8e, Aris Toolset, ProcessWise WorkBench, WorkFlow Analyser),
  • narzędzia typu CASE służące do projektowania systemów informatycznych (np. Select Enterprise, Rational Rose),
  • narzędzia modelowania procesów wbudowane w systemy klasy ERP (np. IFS Bussiness Modeler)

Poza wymienionymi zastosowaniami narzędzia do modelowania i optymalizacji procesów można zaklasyfikować ze względu na wspierane funkcje, a w szczególności:

  • możliwości generowania dokumentacji w formacie HTML,
  • kompatybilność z pakietami biurowymi,
  • możliwość wymiany danych z innymi narzędziami i systemami informatycznymi takimi jak systemy ERP, narzędzia CASE, systemy WorkFlow,
  • łatwością i intuicyjnością modelowania procesów,
  • możliwością pracy grupowej,
  • zastosowaniem wybranych notacji.

Wybór konkretnego narzędzia jest ściśle związany z charakterem wykonywanej pracy oraz preferencjami klienta. Narzędzia wizualizacji graficznej takie jak MS Visio są wykorzystywane podczas wizualizacji procesów, w przypadku, kiedy nie jest konieczne przeprowadzanie skomplikowanych symulacji. Narzędzia takie jak ProcessWise i WorkBench są stosowane do przeprowadzania symulacji procesów. W przypadku, gdy konieczne jest szybkie i precyzyjne przeanalizowanie zachodzących procesów oraz zaproponowanie ich usprawnień zastosowanie znajdują zaawansowane narzędzia modelowania i optymalizacji takie jak iGrafx Process.

Architektura zorientowana na usługi

Wymagania stawiane przed systemami IT wspierającymi działanie współczesnych przedsiębiorstw coraz częściej wymagają łączenia technologii różnych dostawców. Konieczność współpracy niekompatybilnych ze sobą systemów i technologii powoduje powstawanie nadmiarowych usług, redundancję danych oraz funkcjonalności. Wraz ze stopniem złożoności wzrasta awaryjność systemów. Najczęściej spotykany obecnie monolityczny model tworzenia aplikacji uzależnia użytkownika od producenta oprogramowania. Ma on do dyspozycji tylko taką funkcjonalność, jaką zaoferuje mu dostawca rozwiązania informatycznego.

Coraz trudniej też określić granicę, gdzie kończy się system informatyczny jednego przedsiębiorstwa a zaczyna system partnera biznesowego, kooperanta czy klienta. Z punktu widzenia użytkownika systemu ta granica może być całkowicie niedostrzegalna [14]. Z tego powodu systemy informatyczne przedsiębiorstw powinny mieć możliwość wzajemnej komunikacji w oparciu o zrozumiały dla nich protokół.

Z drugiej strony systemy informatyczne wymagają ciągłego dopasowania do zmieniających się potrzeb biznesowych i wymagań klientów. Uważa się, że koszty opieki i modyfikacji systemów wspierających działalność biznesową przedsiębiorstwa sięgają 70% ogólnych kosztów ich utrzymania [10]. Z tego powodu współczesne systemy informatyczne muszą umożliwiać elastyczne wprowadzanie zmian spowodowanych zmieniającymi się założeniami i wymaganiami biznesowymi. Zmiany te powinny być wprowadzane w sposób umożliwiający zachowanie całej niezbędnej istniejącej funkcjonalności. Przestój systemu informatycznego może pociągać za sobą poważne straty zarówno w aspekcie finansowym jak i prestiżowym dla przedsiębiorstwa, dlatego jego rozbudowa powinna odbywać się w sposób nieinwazyjny i bezpieczny dla całości funkcjonowania systemu.

Opisane w poprzednim rozdziale założenia systemu informacyjnego opartego o model procesów biznesowych przedsiębiorstwa pozwalają zaprojektować system precyzyjnie wspierający działalność organizacji zgodnie z jej strategią i koncepcją biznesową. Architekturą, w której tak zaprojektowany system można zrealizować, jednocześnie eliminując problemy integracji oprogramowania pochodzącego od wielu dostawców, zapewniającego wymianę danych i usług pomiędzy podobnymi sobie systemami, zapewniającymi odpowiednią elastyczność i wysoki poziom bezawaryjności jest architektura oparta o usługi SOA.

W ogólnym założeniu architektura SOA opiera się o pojedyncze moduły udostępniające dane, informacje i usługi. Moduły te są nazywane usługami Web (ang. Web Services). Korzystają one z dodatkowych zasobów informatycznych organizacji takich jak bazy danych, zasoby sieciowe inne serwisy niedostępne dla użytkowych aplikacji. Usługi Web przechowywane są abstrakcyjnej warstwie systemowej zwanej zasobnikami (ang. containers)[4, 8]. Zasobnik przechowuje kod serwisu, zarządza jego instancjami oraz zapewnia komunikację z pozostałymi elementami systemu. Usługi udostępniane przez Web Services mogą być zdalnie wywoływane przez programy tworzone w różnych technologiach [10]. Komunikacja pomiędzy elementami systemu odbywa się za pośrednictwem szyny ESB (ang. Enterprise Service Bus). Z szyny ESB korzystają aplikacje systemu SOA, których funkcjonalność wykorzystuje usługi udostępniane przez serwisy Web. Szyna ESB poprzez odpowiedni interfejs służy również do komunikacji z innymi systemami SOA [21].

Standaryzowanie protokołów komunikacyjnych daje możliwość udostępnienia w ramach SOA usług oferowanych przez serwisy różnych producentów oprogramowania. Serwisy te mogą być następnie wykorzystywane do budowania aplikacji wspierających realizację wskazanych procesów biznesowych organizacji.

Dzięki zastosowaniu technologii serwisów WWW aplikacje są uruchamiane w dowolnej przeglądarce internetowej, niezależnie od platformy. Nowoczesne technologie budowania aplikacji WWW, oparte o język Java, JavaScript i servlety, takie jak Google Web Toolkit, umożliwiają tworzenie interfejsu użytkownika o funkcjach, ergonomii i wyglądzie bardzo zbliżonym do aplikacji systemu Windows, łącząc zalety aplikacji typu desktop z możliwościami strony WWW.

W przypadku aplikacji monolitycznych istniejących w organizacji zachodzi konieczność dostosowania ich do systemu pracującego w ramach architektury SOA. Jeśli architektura aplikacji na to pozwala, można to osiągnąć poprzez wymianę warstw dostępu do danych aplikacji na pracujące zgodnie z logiką architektury SOA. Można też, bez wprowadzania dodatkowych zmian w istniejącej aplikacji za pomocą systemu zgodnego ze specyfikacją SOA, umożliwiającego komunikację poprzez szynę ESB, udostępnić jej usługi dla innych aplikacji systemu SOA. W obu wypadkach użytkownicy aplikacji pracują w znanym sobie środowisku bez konieczności zmiany sposobu pracy oraz uczenia nowego systemu informatycznego. Wadą obu rozwiązań jest pozostawienie aplikacji w stanie hermetycznym, z utrudnioną możliwością rozbudowania jej funkcji o nowe usługi udostępniane w ramach systemu SOA. W niektórych wypadkach, szczególnie, gdy aplikacja nie spełnia stawianych przed nią celów wynikających z modelu procesów biznesowych, należy rozważyć konieczność jej ponownej implementacji wykorzystując technologie dostępne w ramach SOA. Można również przypuszczać, że w przypadku rozwoju systemów SOA, aplikacje monolityczne integrowane w ramach tych systemów będą stopniowo zastępowane usługami i aplikacjami zgodnymi z logiką architektury zorientowanej na usługi

Z informatycznego punktu widzenia tworzenie aplikacji w architekturze SOA jest zadaniem trudnym. Wdrożenie systemu opartego o usługi może wiązać się z kosztami przewyższającymi rozwiązania oparte o tradycyjne technologie i architekturę. Korzyści z wprowadzenia systemu o architekturze SOA mogą być widoczne w dalszej perspektywie jego eksploatacji.

Rozwój standardów związanych z architekturą SOA i usługami Web jest monitorowany przez instytucję The Web Services Interoperability Organization (WS-I). Organizacja ta skupia z jednej strony najbardziej liczących się producentów związanych z usługami Web, takich jak BEA, IBM, Microsoft, jak również małe firmy programistyczne oraz podmioty zainteresowane wdrażaniem i używaniem technologii SOA. Działalność WS-I nie kończy się jedynie na określaniu specyfikacji. Organizacja gwarantuje, że produkty dowolnych producentów korzystających ze standardu będą mogły bezproblemowo współpracować ze sobą na zasadzie wymiany informacji. Opracowany przez WS-I profil podstawowy usług Web obejmuje bazowe usługi w warstwie komunikacyjnej. Obecnie prace organizacji koncentrują się na tworzeniu elementów infrastruktury usług Web, które pozwoliłyby odwzorować skomplikowane mechanizmy komunikacji biznesowej.

Podstawą protokołu komunikacyjnego jest niezależny od platformy język XML (ang. eXtensible Markup Language) XML będący podzbiorem języka SGML (ang. Standard Generalized Markup Language) [7]. Do zarządzania danymi XML stosuje się obiektowe modele danych XML DOM (ang. Data Object Model). Wbudowane w XML DOM parsery pozwalają z dokumentu tekstowego uzyskać łatwe do przetwarzania i nawigacji struktury danych. Udostępniane w XML DOM mechanizmy pozwalają na wyszukiwanie, edycję oraz wizualizację danych w obrębie jednego bądź wielu dokumentów XML. Dzięki standaryzowaniu składni języka XML dokument poprawny składniowo może być przetwarzany przez XML DOM dowolnego producenta. O ile na poziomie API każdy XML DOM może dysponować inną składnią i zakresem funkcji, to będące na wejściu i wyjściu dokumenty XML są zgodne z leksyką języka [7].

Dokument XML w modelu danych XML jest reprezentowany przez hierarchiczną strukturę węzłów XML (ang. XML nodes). Węzły zawierające elementy tekstowe, atrybuty, oraz inne węzły nazywane są elementami XML (ang. XML elements). Węzłem nadrzędnym dla całej struktury jest dokument XML (ang. XML dokument) zawierający jeden element główny (ang. document element). Większość XML DOM pozwala na zadawanie zapytań do dokumentu XML przy wykorzystaniu składni XSL (ang. eXtensible Stylesheet Language) – XQuery (ang. XML Query Language). Wynikiem zapytania XQuery jest lista węzłów XML spełniających warunki zapytania. Dokumenty XML mogą być transformowane za pomocą przekształceń XSLT (ang. XSL Transformations) oraz wizualizowane poprzez szablony XSL nazywane niekiedy XSL-FO (ang. XSL Formatting Objects). Wszystkie te mechanizmy sprawiają, że język XML doskonale nadaje się do przekazywania danych, dokumentów, komunikatów o nieokreślonej lecz usystematyzowanej strukturze. Jego zastosowanie w najniższej warstwie komunikacyjnej pozwala osiągnąć elastyczność i niezależność od platformy czy też producenta oprogramowania niezbędną do uzyskania przy założonym modelu architektury SOA.

Usługami bazowymi zdefiniowanymi przez WS-I są:

  • SOAP (ang. Simple Object Access Protocol) – oparty o XML protokół dostępu do obiektów (klas) umożliwiający zdalne wywołanie metod klasy wyposażonej w interfejs SOAP. Komunikacja między klientem a serwerem SOAP odbywa się poprzez protokół HTTP.
  • WSDL (ang. Web Services Description Language) – oparty o XML opisujący protokoły i formaty usług Web.
  • UDDI (ang. Universal Description, Discovery and Integration) – inicjatywa mająca na celu stworzenie uniwersalnego rejestru usług Web. W swoim założeniu UDDI ma umożliwić automatyczne wykrycie i integrację usługi Web w sieci Internet.

Elementami architektury SOA będącymi w opracowaniu przez WS-I są obecnie [14]:

  • WS-Policy i WS-Secutity Policy – standardy definiujące zasady działania usług Web,
  • WS-Adressing – technologia umożliwiająca warunkowe przekierowanie wywołania usługi,
  • WS-Eventing – realizowany w modelu subskrybująco-publikującym z wykorzystaniem technologii „push” standard realizujący odpowiednik zdarzeń systemowych w aplikacjach desktopowych,
  • Message Transmission Optimization Mechanizm – protokół umożliwiający przesyłanie dużych ilości danych poprzez rozbijanie ich na mniejsze pakiety.

Organizacja WS-I zatwierdziła język BPEL (ang. Business Process Execution Language), który pozwala modelować procesy biznesowe, łącząc poszczególne usługi. W chwili obecnej trudno jednoznacznie określić, które elementy architektury SOA opisane przez WS-I są już standardami przemysłowymi. Dla użytkowników najważniejszy jest zdefiniowany w profilu podstawowym zestaw usług, w oparciu o który można już budować aplikacje.

Modelowanie procesów a SOA

System stworzony w architekturze SOA dostarcza jako funkcjonalność końcową odbiorcy szereg bardziej lub mniej złożonych usług. Jeżeli system ten ma stanowić wsparcie zarządzania przedsiębiorstwem, przed jego zaprojektowaniem należy zidentyfikować, zamodelować oraz zoptymalizować procesy kluczowe dla organizacji, eliminując przy tym procesy generyczne. Tylko takie podejście da możliwość zidentyfikowania usług, jakie mają być realizowane w ramach systemu informatycznego [2].

Podczas projektowania systemu informatycznego następuje przejście od procesu biznesowego do usług niezbędnych do jego realizacji wspieranych przez odpowiednie funkcje systemu. Następuje tym samym automatyzacja kluczowych dla przedsiębiorstwa procesów biznesowych. Cykl życia systemu SOA składa się z czterech podstawowych elementów: planowania, implementacji, udostępnienia i zarządzania. Z tego punktu widzenia system SOA można podzielić na trzy warstwy: procesów biznesowych, wynikających z tych procesów usług oraz warstwy infrastruktury informatycznej [5] (rys. 8). Cykl życia polega na nieustannej interakcji pomiędzy tymi warstwami wynikającymi z dostosowania usług do modelu biznesowego organizacji, infrastruktury informatycznej do usług, usuwania błędów w fazie modelowania i implementacji, zmiany wymagań biznesowych.
Identyfikację procesów biznesowych organizacji można zrealizować stosując podejście oparte na encjach [1]. Podejście to identyfikuje procesy na podstawie odpowiedzi na pytania dotyczące podstawy działania organizacji na rynku (EBE – ang. Essential Business Entity), działań, które nie są wymagane przez rynek, ale są wynikiem podjęcia przez organizację decyzji o określonym sposobie funkcjonowania (DBE – ang. Designed Business Entity) oraz określenia działań prowadzących do udostępnienia produktów oraz usług oferowanych przez organizację (UOW – ang. Unit of Work). Wykorzystując to podejście należy udzielić odpowiedzi na pytania:

  • Co organizacja wytwarza?
  • Co organizacja sprzedaje?
  • Jakie usługi oferuje?
  • Z jakimi klientami zewnętrznymi i wewnętrznymi współpracuje?
  • Na jakie wydarzenia musi reagować?
  • Jakie informacje są przechowywane w systemach informatycznych?

Na podstawie odpowiedzi na te i podobne pytania określane są procesy kluczowe dla działania organizacji, oraz produkty (przedmioty, usługi lub informacje) wytwarzane przez te procesy. Na tej podstawie można dokonać wyboru procesów, których automatyzacja pozwoli na poprawienie funkcjonowania przedsiębiorstwa. Procesy te mogą zostać następnie zdekomponowane na pakiety usług i zaimplementowane przez dostawców różnych elementów zintegrowanego systemu informatycznego. Dzięki temu w systemie informatycznym wyeliminowane zostaną dane oraz usługi dublujące się w kilku procesach biznesowych. Usługa zapewniająca dostęp do bazy kontrahentów będzie mogła być wykorzystywana przez moduł finansowo-księgowy jak również przez oprogramowanie stanowiące wsparcie dla procesów działu marketingu czy serwisu. Architektura SOA gwarantuje, że dostawcy oprogramowania będą mogli korzystać z usług już dostępnych w ramach systemu.

Źródło: pmanager.pl

Literatura

[1]        AION Sp. z o.o. Modelowanie procesów biznesowych, Materiały prezentacyjne, Politechnika Wrocławska Centrum Kształcenia Ustawicznego, 2-3.12.2006
[2]        Bieberstein N. et al., Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals, IBM System Journal, vol. 44, no. 4, 2005, pp. 691 – 708
[3]        BPMI.org, Object Management Group, Business Process Modeling Notation (BPMN) Specification, http://www.bpmn.org/
[4]        Brown K., Reinitz R., Web Services Architectures and Best Practices, IBM WebSphere Developer Technical Journal (2003),
http://www-128.ibm.com/developerworks/websphere/techjournal/0310_brown/brown.html
[5]        Cox D. E., Kreger H., Management of the service-oriented architecture life cycle, IBM System Journal, vol. 44, no. 4, 2005, pp. 709 – 726
[6]        Dałkowski B., Hołodnik K., Podstawy zarządzania projektami. Analiza projektu, Get Manager 2006., Materiały prezentacyjne, Politechnika Wrocławska Centrum Kształcenia Ustawicznego
[7]        Erl T., Service-Oriented Architecture, Pearson Education, Inc. Pentice Hall PTR, New Jersey, 2004
[8]        Ferguson D. F., Stockton M. L., Service-oriented architecture: Programming model and product architecture, IBM System Journal, vol. 44, no. 4, 2005, pp. 753 – 780
[9]        Frączkowski K., Zarządzanie projektem informatycznym. Projekty w środowisku wirtualnym. Czynniki sukcesu i niepowodzeń projektów, Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław, 2003
[10]     Frączkowski K., Mazur Z., SOA – architektura zorientowana na usługi, Bazy Danych, nr 7, Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław, 2006
[11]     Główny Instytut Górnictwa, Przewodnik ISO 9000. Materiały informacyjne nt. wdrażania systemu zarządzania jakością wg norm ISO serii 9000 : 2000, Katowice, 2004, http://www.mgip.gov.pl
[12]     IDS-Sheer Polska Spółka z o.o., 10 kroków do wdrożenia SOA, http://www.ids-scheer.pl , 2006
[13]     IDS-Sheer Polska Spółka z o.o., Technologie IT przesądzające o kierunkach rozwoju branży IT w przyszłości, według raportu Gartnera, http://www.ids-scheer.pl , 2006
[14]     Kopacz T., Świat jako usługa, Computerworld, 30-2004
[15]     Majdan K, Zarządzanie procesowe w organizacjach RTD, Gazeta Innowacje nr 14 2002, http://www.gazetainnowacje.pl
[16]     MSI Polska, ARIS ProcessDay, http://www.msipolska.pl
[17]     Muszyński J., Borland: narzędzia modelowania dla SOA, Serwery Computerworld, http://serwery.computerworld.pl/news/98839.html , 09.2006
[18]     Paluśkiewicz  M., SOA na co dzień, Infovide, http://www.infovide.pl/docs/M_Paluskiewicz_SOA.pdf , Warszawa, 2004
[19]     PN-EN ISO 9001:2001: Systemy Zarządzania Jakością. Wymagania. Polski Komitet Normalizacyjny, Warszawa 2001
[20]     Quality Progress, Zarządzanie procesowe BPR, http://www.qualityprogress.com.pl , 2004
[21]     Schmidt M.-T. et al., The Enterprise Service Bus: Making service-oriented architecture real, IBM System Journal, vol. 44, no. 4, 2005, pp. 781 – 797
[22]     Szyjewski Z., Metodyki zarządzania projektami informatycznymi, Wydawnictwo Placet, Warszawa, 2004
[23]     Wróbel M., Modelowanie procesów biznesowych jako narzędzie doskonalenia organizacji, Centrum Rozwiązań Menedżerskich S.A., Warszawa, http://www.crm.com.pl/wiedza2.htm
[24]     White S., Using BPMN to Model a BPEL Process, IBM Corp., United States, http://www.bpmn.org/
[25]     Zawistowski T, Procesowe zarządzanie organizacją, Problemy Jakości, nr 09.2001, http://www.umbrella.org.pl
[26]     Żeliński J., Modelowanie procesów biznesowych, czyli pilnowanie hochsztaplerów, IT-Consulting, 2005, http://www.egospodarka.pl/

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ