WDROŻENIA
Migracja po dwóch dekadach
Efekt gwarantowany
ANALIZY
Czwarta fala
Przyszłość to usługi i aplikacje
PRODUKTY
Maszyna dla danych
Migracja dobrze policzona
popularne
Najczęściej czytane
WYWIADY
EN FACE: Sebastian Ryszard Kruk...
Coraz więcej inteligencji
Luksusowa analiza
Wyzwanie SOA
18 grudnia 2007
Jacek Bugajski Przygotowując przedsiębiorstwo do wdrożenia systemu ERP w architekturze SOA trzeba wziąć pod uwagę co najmniej pięć kluczowych czynników: centralizację i zwiększenie stopnia wykorzystania zasobów IT, standaryzację wzorcowych metadanych i procesów oraz wygodę i bezpieczeństwo korzystania z nowych rozwiązań.Computerworld — Producenci systemów ERP i innych aplikacji biznesowych szczycą się tym, że ich systemy zbudowane są w oparciu o architekturę SOA. Cóż to jednak właściwie oznacza dla potencjalnych użytkowników tego typu systemów? Czy są oni gotowi na implementację systemów zgodnych z tą architekturą? Jak przygotować organizację na ich wdrożenie? To tylko niektóre z pytań, przed którymi stają potencjalni użytkownicy systemów ERP.
Czas jasnych definicji
Architektura zorientowana na usługi wymaga jasnego zdefiniowana obszarów działania przedsiębiorstwa oraz opisu usług, których dotyczą. Wszystko to musi być określone szczegółowo, najlepiej metodą "góra-dół", a więc od najbardziej generalnych zasad do poziomu implementowanych usług. Definicja usługi musi być na tyle ogólna, aby w miarę możliwości mogła być w przyszłości używana w innych obszarach. W małych firmach nie stanowi to dużego wyzwania. Jednak w większych organizacjach, które zwykle są na etapie przekształceń, fuzji bądź konsolidacji, projektowanie serwisów i procesów w sposób na tyle ogólny, by uwzględniały konsekwencje zachodzących zmian, będzie stanowić poważne wyzwanie. Dlatego dobrze jeśli w procesie tym biorą udział przedstawiciele wszystkich łączących się firm lub działów.
Projektując nowe procesy należy wziąć pod uwagę co najmniej pięć czynników, stanowiących kluczowe wyzwania dla całego przedsięwzięcia. Przede wszystkim centralizację zasobów IT. Umożliwia ona scalanie procesów i ułatwia zarządzanie całym rozwiązaniem, co prowadzi do zmniejszenia liczby systemów. Im mniej systemów, tym niższy całkowity koszt ich utrzymania.
To oznacza również maksymalizację wykorzystania istniejących obecnie zasobów. Podejście SOA zakłada także wykorzystanie tego co już istnieje. Nie ma więc sensu robienie wszystkiego od początku. Znacznie lepszym wyjściem jest stworzenie rozwiązań, które pozwolą na dialog pomiędzy starszymi aplikacjami według standardów SOA.
Projektowanie nowych procesów musi odbywać się zgodnie z założeniami zakładającymi standaryzację wzorcowych metadanych i procesów. Każdy projekt implementacji rozwiązań opartych na SOA musi uwzględniać etap ich modelowania, definiowania i standaryzacji. Pozwala on na zbudowanie "wzorca" rozwiązania ERP. Powinien zająć się tym komitet standaryzacji, którego zadaniem jest przede wszystkim definiowanie standardów procesów w różnych obszarach biznesowych oraz współpraca z właścicielami danych w poszczególnych obszarach. Celem ich działań powinno być zbudowanie modelu danych podstawowych i metadanych. Metadane pozwolą w jasny i przejrzysty sposób zdefiniować standard wymiany informacji pomiędzy systemami, a standard danych podstawowych ujednolić i scentralizować ich zarządzanie.
Ważnym, choć często pomijanym aspektem projektów związanych z architekturą SOA jest optymalizacja wdrażanych rozwiązań pod kątem łatwości korzystania z nich. Oznacza to nie tylko pracę nad stworzeniem przyjaznego interfejsu, ale także, a może przede wszystkim unifikację dostępu do danych. Służą temu różnorakie rozwiązania portalowe, umożliwiające czerpanie danych z różnych źródeł i prezentację ich w zunifikowanej formie.
Ostatnim elementem istotnym z punktu widzenia projektów implementacyjnych jest oczywiście bezpieczeństwo. Przy tak złożonych architekturach i modelach wymiany danych bardzo łatwo o lukę bądź wyciek cennych informacji.
Najpierw koncepcja, potem system
Mając zaplanowany model danych i pewną wizję architektury, możemy przystąpić do wyboru rozwiązania i dostawcy. Nie warto przy tym iść na skróty. Firmy, które zaczynają od wyboru systemu, często mają później kłopoty z implementacją rozwiązania. Muszą dokonywać drogich rozszerzeń i modyfikacji systemu, co odbija się czkawką podczas zmian wersji i uaktualnień systemu.
Wybierając rozwiązanie trzeba uwzględnić kwestię odpowiednich repozytoriów danych podstawowych, usług, procesów oraz metadanych, które tak naprawdę definiują najniższy poziom połączeń. Brak takich repozytoriów pozbawia inne systemy centralnego punktu, który wskazuje im odpowiednie usługi. Oparcie repozytorium na niekompletnych bądź źle zdefiniowanych danych rodzi problemy związane chociażby z elastycznym modelowaniem danych.
W doborze rozwiązania opartego na SOA bardzo ważne jest określenie, na ile jest to rozwiązanie, które wspiera budowę nowych funkcji w oparciu o SOA, a na ile posiada już zaimplementowane funkcje i logikę biznesową. Większość rozwiązań obecnych na rynku reklamuje zgodność z architekturą SOA. Jest ona jednak realizowana poprzez kolejne "łaty" w postaci warstw pośredniczących. Zaś same rozwiązania nie mają wiele wspólnego z koncepcją SOA i brak im odpowiednich repozytoriów.
Jak w praktyce wygląda realizacja tych koncepcji przez różnych dostawców? Firma SAP promuje podejście zakładające realizację koncepcji SOA od strony biznesowej. Określa to mianem eSOA, czyli architektura zorientowana na procesy gospodarcze. Oracle posiada całą gamę aplikacji zgodnych z SOA oraz rozwiązań do budowania systemów opartych na SOA. Nadal nie ma jednak w pełni zintegrowanego rozwiązania ERP realizującego tę koncepcję. Także firma Microsft oferuje dziś przede wszystkim platformę integracyjną oraz rozwiązanie do zarządzania procesami biznesowymi oparte na koncepcji SOA, a nie aplikację biznesową w pełni realizującą tego typu model.
wydrukuj
Komentarze
Ten artykuł nie ma jeszcze żadnych komentarzy. Twój może być pierwszy...
tel.: (+48 22) 321 78 00 fax: (+48 22) 321 78 88
© copyright 2012 IDG Poland SA