Oracle Application Integration Architecture – pomysł na implementacje procesów biznesowych

Jadwiga Gnybek

 

Szybka zmienność konfiguracji procesów biznesowych wymusza wiele działań związanych z uelastycznieniem aplikacji wspomagających działanie tychże procesów. Dlatego też oczkiem w głowie wszystkich dużych dostawców aplikacji biznesowych jest stworzenie jak najlepszych warunków dla integracji procesów i zapewnienia ich współpracy z innymi aplikacjami.

 

Procesy biznesowe z natury rzeczy mają tendencję do przechodzenia pomiędzy jednostkami organizacyjnymi firmy, a co za tym idzie do przechodzenia przez obszary funkcjonalności wielu aplikacji. Stąd też zapotrzebowanie na medium łączące procesy i aplikacje, czyli Oracle Application Integration Architecture. Rozwiązanie pozwalające na skrócenie czasu i kosztów integracji aplikacji oraz uproszczenie i przyspieszenie implementacji procesów biznesowych.

Matnia systemów klasycznych

Przyczyną dzisiejszych problemów wielu firm jest sposób, w jaki przez ostatnie dziesięciolecia rozwijane były „klasyczne aplikacje biznesowe”. Rynek producentów aplikacji podzielony został bowiem według klucza funkcjonalnego. Jedne firmy postawiły na rozwój aplikacji HR, inne na obsługę księgowości, czy logistyki. W konsekwencji na rynku pojawiło się wiele samodzielnych wysokospecjalizowanych produktów. Sytuacji nie zmieniło gruntownie pojawienie się w sprzedaży systemów klasy ERP. Szybko okazały się one tworami mało elastycznymi i niezbyt podatnymi na zmiany. Ponadto rozwiązania zaprojektowane z myślą o konkretnych branżach z trudem dają się dostosować do firm działających w niszowych obszarach gospodarki. Dostosowanie takie zwykle tylko częściowo zadowala użytkowników, choć stanowi znaczącą pozycję w budżecie projektu wdrożeniowego. Trudno byłoby również znaleźć firmę, której udało się zaspokoić wszystkie swoje oczekiwania w stosunku do wsparcia informatycznego poprzez wdrożenie jednej cudownej, wszystkomającej aplikacji. Standardem jest zatem jednoczesne wykorzystywanie wielu specjalizowanych aplikacji, a co zatem idzie nieustanne integrowanie do wspólnej pracy produktów różnych dostawców, budowanych często w różnych technologiach. Zakładając nawet zadowalający stopień integracji tak skonstruowanego zbioru, praktyka wskazuje, że duża część istotnych operacji wykonywana jest poza dużymi aplikacjami typu CRM czy ERP, które (z powodu swej ściśle zdefiniowanej funkcjonalnej logiki) nie są w stanie obsłużyć dużej części „wyjątków”. Wszystko to z czasem przybiera kształt coraz bardziej pogmatwanej, pełnej interfejsów pajęczyny. Mamy tu zbiór systemów, których wzajemne zależności nie są udokumentowane na poziomie pozwalającym na bezpieczne i szybkie przebudowy. Co więcej, dokupywanie i łączenie z istniejącymi rozwiązaniami coraz to nowych aplikacji sprawia, że całkowita suma inwestycji w oprogramowanie wciąż rośnie.

Paradoksalnie, o ile rozwój firmy niekoniecznie wiąże się z krystalizacją jej oferty rynkowej, a co zatem idzie stabilizacji oczekiwań stawianych przed informatycznym wsparciem biznesu, o tyle rozrastająca się sieć aplikacji staje się coraz trudniejsza do modyfikacji. Jeśli zatem przyjdzie nam pracować na rzecz dynamicznie „poruszającej się po rynku” firmy, budując system źle (a może tylko „klasycznie”) zintegrowanych aplikacji, mamy szanse stać się klasycznym wąskim gardłem naszej organizacji.

W tej sytuacji jedynym wyjściem jest przyjęcie rozwiązań systemowych, które zapobiegną eskalacji problemu. Niezbędne jest zatem wybranie odpowiedniego dla danego sektora biznesu zbioru aplikacji, które zaprojektowane są z myślą o integracji oraz posiadają odpowiednio do tej integracji przygotowane środowisko, narzędzia, mechanizmy zarządzania.

Zmienny jak w telekomunikacji

Dobrym przykładem na duże przedsiębiorstwo oferujące szybko zmieniające się w czasie pakiety usług jest jakikolwiek operator telekomunikacyjny. Bez wątpienia prowadzenie działalności w tym obszarze łączy się z koniecznością wprowadzania częstych zmian, zarówno w asortymencie produktów jak i w sposobach ich sprzedaży. Bardzo różnorodna jest również gama produktów telekomunikacyjnych, co stwarza wiele wyzwań dla wspomagających procesy biznesowe systemów informatycznych. Telekomunikacja, to dziś przecież nie tylko telefony stacjonarne i komórkowe, ale również szerokopasmowy dostęp do Internetu, Voice Over IP i inne, coraz to nowe produkty. Zaraz za standardowym zbiorem produktów rośnie lista usług – takich, jak telewizja interaktywna, wypożyczalnie filmów i gier komputerowych, a wszystkie te produkty nie tylko trzeba sprzedać. Trzeba również nimi zarządzać i umożliwić klientom zarządzanie zakupionymi usługami. Jakby tego było mało, firmy telekomunikacyjne obejmują swoim zasięgiem wiele krajów. Powoduje to konieczność budowy lokalnych systemów informatycznych nakierowanych na obsługę konkretnej grupy klientów. Wszystkie te lokalne rozwiązania muszą jednak sprawnie łączyć się w jeden spójny organizm. Jak to zrobić? Najlepiej nowocześnie, kompleksowo i z pomysłem na system, poprowadzonym konsekwentnie od początku do końca.

Na kłopoty – Oracle

Propozycją pozwalającą zbudować infrastrukturę informatyczną zdolną podołać takim wyzwaniom jest z pewnością Oracle Application Integration Architecture. Pakiet ten zawiera bowiem wszystko co potrzebne do budowy nowoczesnego, elastycznego i wydajnego oprogramowania wspierającego nie poszczególne jednostki organizacyjne firmy, ale także przechodzące na wskroś tych jednostek procesy. Znajdziemy tu zatem opis sprawdzonych biznesowych rozwiązań, które pozwalają na konfrontację własnych implementacji z rozwiązaniami modelowymi. Doświadczenia zdobyte przez lata budowy i wdrażania rozwiązań biznesowych zebrane zostały w Industry Reference Models i standardach Enterprise Business Objects and Services. Drugim, nie mniej ważnym elementem tego pakietu jest środowisko technologiczne pozwalające na budowę stabilnej i łatwej w zarządzaniu architektury powiązanych ze sobą aplikacji.

 


Architektura integracji aplikacji

 

W budowie efektywnie działających systemów skutecznie przeszkadza struktura firmy. Podział na jednostki organizacyjne powoduje bowiem naturalne skłonności do wydzielania się grup pracowników przykładających najwyższą wagę do partykularnych interesów swojego zespołu. Antidotum dla tych tendencji jest bez wątpienia procesowe spojrzenie na pracę organizacji i narzucenie z tej perspektywy pewnych sprawdzonych i optymalnych wzorców. Jeśli firma nasza nie pokusiła się jeszcze o samodzielne wykonanie opisu swoich procesów biznesowych, może wesprzeć się przygotowanym przez Oracle Industry Reference Models. Jest on próbą uogólnienia dwóch kluczowych aspektów, jakie powinny zostać wzięte pod uwagę podczas budowy systemu informatycznego. Łączy logiczną reprezentację kluczowych procesów biznesowych z mapą przepływów danych związanych z obsługą tychże procesów.

Oracle’s Industry Reference Model stanowi wielopoziomową strukturę, która na poziomie “0″ zawiera opisy podstawowych procesów firmy – takich, jak obsługa klienta, zaopatrzenie, produkcja itp. Z poziomu tego możemy zagłębiać się w szczegóły każdego z tych procesów. Na poziomie „1” zobaczyć możemy poszczególne kroki w procesie oraz zdarzenia jakie proces mogą zainicjować. Poziom „2” pokazuje sposoby realizacji poszczególnych kroków procesu. Na najniższym, „3” poziomie znajdujemy natomiast informacje o sposobie implementacji informatycznego wsparcia dla poszczególnych działań, zawierające między innymi przepływy danych i działania podejmowane przez wspomagające ten proces aplikacje. Industry Reference Models stanowi zatem dobrą bazę do budowy własnego opisu przepływu procesów w oparciu o najlepsze, sprawdzone wzorce. Przyrównanie tego modelu do obrazu naszej firmy pokaże nam również obszary, które wymagają jeszcze standaryzacji i optymalizacji.

 


Industry Reference Model – poziom „0”

 

Mając już obraz firmy – takiej jaka jest lub jaką chcemy, aby była – można rozpocząć prace nad integracją. Są to prace, które zawsze stanowiły dla zespołów wdrożeniowych duże wyzwanie, a w kontekście projektów wdrożeniowych są zawsze procesem kosztownym i narażonym na duże prawdopodobieństwo niepowodzenia. Nadszedł więc czas, aby zapoznać się z Process Integration Packs.

Pakiet Integracji Procesów

Do najważniejszych zadań tego pakietu należy dostarczenie platformy łączącej warstwę procesową opisaną w BPEL z warstwą wspierających te procesy aplikacji. Jest tu więc miejsce na opis logiki biznesowej, zdefiniowanie ról biznesowych (business rules) oraz połączenie tego wszystkiego z serwisami webowymi. Dzięki zastosowaniu Enterprise Business Objects cała ta misterna konstrukcja jest „odporna” na wprowadzane zmiany i zapewnia nam pełną kontrolę nad modyfikacją procesów.

Jak łatwo zgadnąć, przepisem na to jak skonfigurować Process Integration Pack jest opis naszej firmy, który wykonamy na poziomie „3” Industry Reference Models. Innymi słowy informacje zapisane w Industry Reference Models stanowią projekt konfiguracji Process Integration Pack.

Teraz czas na zajęcie się bodajże najważniejszym elementem Process Integration Pack, czyli modułem Enterprise Business Objects and Services (EBO&S). Stanowi on bowiem generyczny obraz obiektów biznesowych – takich jak klient, zamówienie, faktura itp. Aby poprawnie wykorzystać ten moduł, dobrze jest zapoznać się z leżącymi u podstaw tego rozwiązania standardami, takimi jak Open Applications Group i UNIFACT. Dzięki nim mamy już gotowe szablony podpowiadające nam poprawny kształt obiektów biznesowych, które w następnym kroku będziemy musieli oczywiście dostosować do specyfiki naszej firmy. Uwzględnić tu też musimy informacje o aplikacjach które będą poddawane integracji np.: Siebel CRM, JD Edwards EnterpriseOne, PeopleSoft Enterprise, Oracle Transportation Management, Oracle Retail, itd. – każda z nich musi bowiem wnieść do tego modelu swój wkład. Będzie to punkt startu do budowy EBO, musimy zatem mieć świadomość, że od jakości wykonania właśnie tego etapu pracy w dużej mierze zależy powodzenie dalszych prac implementacyjnych, a w konsekwencji wydajność i stabilność przyszłego systemu.

Scenariusz prac polegający na mapowaniu aplikacji do generycznego modelu EBO umożliwia projektantom systemu maksymalnie szerokie spojrzenie na całość planowanych prac. Jest to jednocześnie sposób na prostsze i bardziej przejrzyste przedstawienie elementów, które będą tworzyły informatyczne wsparcie procesów biznesowych naszej firmy. Spojrzenie syntetyczne, ale umożliwiające zebranie optymalnej ilości informacji biznesowych niezbędnych do późniejszych prac – zarówno modernizacyjnych jak i utrzymaniowych. Do modelu tego łatwo także dołączyć kolejne aplikacje, lub zamienić jedną aplikację na inną o podobnej funkcjonalności. Zdefiniowane w ten sposób połączenia pomiędzy aplikacjami bardzo dobrze sprawdzają się również w sytuacji konieczności zmiany wersji jednego z elementów systemu. Generyczność tego modelu umożliwia bowiem łatwe zastąpienie starej wersji aplikacji nową, bez naruszenia istniejących powiązań.

 


Schemat powiązań pomiędzy Enterprise Business Object,
obiektami biznesowymi i aplikacjami

 

Warto w tym momencie podkreślić, że Enterprise Business Objects and Services są modułem niezależnym od Oracle Applications. W praktyce oznacza to możliwość integracji z aplikacjami różnych dostawców oraz dopisywanie własnych fragmentów systemu. Połączenie pomiędzy Oracle Applications i Enterprise Business Services realizowane jest za pośrednictwem web serwisów Oracle Applications. Obok standardowych serwisów spełniających rolę API, do wykorzystania mamy również „right-sized services”, które realizują dostęp do poszczególnych funkcjonalności – takich jak zakładanie konta nowego klienta. Ze względu na zdecydowanie bardziej złożone operacje jakie wykonują te serwisy, komunikacja z nimi wymaga niekiedy zgromadzenia większej liczby rozproszonych danych. Wykorzystanie tych dwóch mechanizmów pozwala na budowę systemów komunikujących się pomiędzy sobą znacznie bardziej optymalnie, a więc szybciej i wydajniej. Wszystkie zdefiniowane w systemie serwisy podlegają transformacji i połączeniu z Enterprise Business Services za pośrednictwem Application Business Connector Service (ABCS). Moduł ten stanowi część Oracle Fusion Middleware. Dzięki temu serwisy wszystkich aplikacji wchodzących w skład systemu dostępne są dla wszystkich użytkowników i mogą być łączone w kolejne konfiguracje. Serwisy te mogą być również rozbudowywane tak, aby spełniały coraz to nowe potrzeby biznesowe. Pełne zestawienie serwisów dostępnych w systemie przechowywane jest w Business Services Repository, będącym zarazem repozytorium serwisów wszystkich aplikacji Oracle.

Oczywiście przedstawione tu predefiniowane propozycje obiektów biznesowych nie zawsze zaspokajają w pełni potrzeby firm. Dlatego też zarówno Industry Reference Models jak i Process Integration Packs przewidują możliwość wprowadzania zmian dostosowujących zaproponowane procesy oraz obiekty do specyficznych potrzeb biznesowych. Zmiany te jednak nie mogą zaburzać ogólnej struktury systemu, ważne jest zatem aby ich wprowadzanie poprzedzone było gruntownym zapoznaniem się z dokumentacją pakietu. Warto również wspomnieć, że przedstawiona tu architektura nie wymaga dużej ilości kodowania. Zdecydowaną większość pożądanych zachowań systemu uzyskujemy bowiem wykorzystując w odpowiedni sposób funkcjonalności już istniejące. Jest to sposób z pewnością mniej czasochłonny, tańszy i pociągający za sobą mniejsze niebezpieczeństwo niekontrolowanych zmian funkcjonalnych poszczególnych aplikacji. Ułatwia to również proces podnoszenia wersji poszczególnych aplikacji systemu.

Tytułem podsumowania warto przypomnieć, że propozycja Oracle stanowi dość unikatowe połączenie warstwy aplikacyjnej z middleware. Zapewnia to spójność pomysłu na opis, organizację i zarządzanie logiką biznesową z realizującą tę logikę warstwą, łączącą poszczególne elementy systemu.