Gotowi na SOA

Systemy oparte na modelu SOA staną się chlebem powszednim w przedsiębiorstwach przemysłowych, różne będą tylko sposoby ich implementacji

W niedalekiej przyszłości każde przedsiębiorstwo decydujące się na nowe lub modernizujące istniejące systemy IT będzie musiało wypracować strategię wdrażania modelu architektury zorientowanej na usługi, czyli SOA (Service Oriented Architecture). Wynika to z faktu, że wszyscy dostawcy oprogramowania dla biznesu prędzej czy później zaczną stosować tego rodzaju rozwiązania. Wszystkie nowe produkty opierają się na modelu SOA, niezależnie od tego, czy dostawca oferuje gotowe aplikacje (jak Oracle i SAP), czy narzędzia do tworzenia indywidualnych rozwiązań (jak IBM). 

Osoby odpowiedzialne za zakup oprogramowania mogą się zastanawiać, czy architektura zorientowana na usługi przyniesie oczekiwane korzyści. Przyszłość pokaże, czy model ten spełni pokładane w nim nadzieje. Jednak już teraz menedżerowie powinni rozumieć ideę modelu SOA i jego wpływ na sposób prowadzenia działalności gospodarczej.

Sam termin Service Oriented Architecture został ukuty przez analityków firmy Gartner (Stamford, Connecticut) w połowie lat 90. ubiegłego wieku. Określa się nim specyficzne podejście do metod programowania aplikacji. W ostatnich latach na temat architektury SOA powiedziano i napisano tak wiele, że czasem trudno poprawnie ocenić jej rolę w generowaniu wartości dodanej.

Z badania przeprowadzonego przez firmę Saugatuck Technology wynika, że zainteresowanie rozwiązaniami opartymi na modelu SOA wykazują wszystkie firmy, przy czym największych inwestycji w ciągu najbliższych lat należy spodziewać się ze strony małych i średnich przedsiębiorstw

Tymczasem model SOA charakteryzuje się kilkoma cechami, o których decydenci powinni pamiętać:

  • łatwość integracji,
  • możliwość wielokrotnego stosowania tych samych składników oprogramowania,
  • krótszy czas od decyzji o zakupie do uruchomienia,
  • niższy koszt posiadania.

Zastanówmy się, jak każda z wymienionych cech wpływa na sposób zarządzania przedsiębiorstwem. Łatwość integracji wynika ze sposobu projektowania architektury SOA umożliwiającego budowanie systemu na bazie niewielkich, oddzielnych komponentów. Elementy te, zwane usługami, łatwo łączy się ze sobą za pomocą powszechnie stosowanych przez programistów standardów wysokiego poziomu. Dzięki temu dodawanie lub wymiana usług w ramach infrastruktury IT – bez konieczności pisania nowych interfejsów – znacząco zmniejsza złożoność projektów integracyjnych.

Opracowana raz usługa może zostać wdrożona w dowolnej liczbie przypadków. Na przykład usługa uzyskiwania danych o kliencie może być wykorzystana w dowolnym procesie wymagającym takich danych. Dotychczas odpowiedni fragment kodu należało pisać od nowa w przypadku każdego procesu z osobna.

Łatwość integracji oraz możliwość wielokrotnego stosowania tych samych komponentów w konsekwencji mogą skrócić czas potrzebny do uruchomienia funkcji i obniżyć koszt posiadania wszystkich aplikacji opartych na modelu SOA. Teoretycy twierdzą, że dzięki architekturze SOA pojawi się nowa generacja szybkich, niezwykle efektywnych systemów IT. Naturalnie życie zweryfikuje tego rodzaju zapewnienia (patrz: ramka „Jak sprawić, by zamiast SOA nie pojawiło się rozpaczliwe SOS!”).

Nadzieje związane z potencjalnymi korzyściami skłoniły wielu dostawców do umieszczenia w ofercie rozwiązań opartych na modelu SOA. Wpływ tego zjawiska na rynek przejawia się na dwa sposoby. Więksi gracze rynku ERP – jak Oracle czy SAP – forsują wśród swoich klientów modernizowanie dotychczasowych rozwiązań na bazie nowej generacji produktów zgodnych z modelem SOA. Z kolei dostawcy infrastruktury informatycznej, jak IBM, Microsoft czy BEA Systems, za pomocą oferowanych narzędzi zachęcają klientów, aby uzupełniali istniejące aplikacje pakietowe o rozwiązania opracowywane specjalnie dla posiadanych przez nich systemów. Wynika z tego, że firma, która chce stosować aplikacje oparte na architekturze SOA, musi zdecydować, czy kupić gotowe rozwiązania od dostawcy aplikacji promującego swą własną platformę SOA, czy cały system opracowywać samodzielnie (patrz tabela: „Oferta rozwiązań opartych na modelu SOA”). 

Jak sprawić, by zamiast SOA nie pojawiło się rozpaczliwe SOS!

 

Może się okazać, że architektura zorientowana na usługi (SOA) ma więcej zalet w teorii niż w praktyce. Przed podjęciem decyzji o inwestowaniu w system oparty na modelu SOA warto więc przeanalizować kilka zagadnień.

 

– Model SOA to poważne wyzwanie. Nie działa w ten sposób, że błyskawicznie scala fragmenty kodu i elementy systemów w jedną funkcjonalną całość. W rzeczywistości wymaga długoterminowej strategii i dyscypliny podczas wdrażania.

 

– Architektura SOA, podobnie jak inne rozwiązania techniczne, sama nie podkręca wskaźnika zwrotu z inwestycji. O zwrocie z inwestycji decyduje zawsze sposób, w jaki technika zostanie wykorzystana. Nie warto zatem rozpoczynać projektów związanych z modelem SOA, jeżeli w przedsiębiorstwie brakuje jasnej koncepcji dotyczącej wykorzystania techniki i jej owoców.

 

– Dobry system wymaga dobrej woli pracowników. Można posłużyć się metaforą – przy budowie domu mamy do czynienia z fazą projektowania, przygotowania terenu, wylewania fundamentów itd. Podobnie jest w przypadku modelu SOA, który od początku wymaga zaangażowania użytkowników w określanie i opracowywanie usług stosowanych potem przez całą firmę. Oddziały firmy, które chcą szybkich rozwiązań o wąskiej funkcjonalności, nie przyczynią się do długoterminowych korzyści wynikających ze stosowania modelu SOA.

 

– Model SOA wiąże się z podejściem scentralizowanym. Istota tej architektury polega na znormalizowaniu usług i komponentów, co najlepiej osiąga się dzięki pracy centralnego zespołu lub grupy roboczej zarządzającej architekturą.

Liderzy chcą SOA

Prawdopodobnie pierwszej weryfikacji modelu SOA dokonały duże i innowacyjne firmy, które opracowywały własne rozwiązania. W ostatnich latach tacy giganci, jak Motorola, Amazon.com, American Express czy eBay, stosowali model SOA z dwóch powodów. Po pierwsze – tworzyli aplikacje, których nie było jeszcze na rynku. Po drugie – modernizowali dotychczasowe aplikacje o znaczeniu strategicznym, opracowując w ramach ścisłej architektury zestaw usług wykorzystywanych w zależności od potrzeb do obsługi nowych procesów biznesowych. Badanie przeprowadzone niedawno wśród szefów informatyki przez nowojorską firmę doradczą Merrill Lynch wykazuje, że ponad 90% menedżerów uważa wdrożenie modelu SOA za inicjatywę o kluczowym znaczeniu.

Pozytywne sygnały dotyczące popularności koncepcji SOA pojawiły się także w innych badaniach, na przykład w raporcie „Web Services Impact on Fortune 500 Companies” firmy Sand Hill Group (San Francisco) czy „SOA Adoption: Business Benefits Drive Strong Demand” firmy Saugatuck Technology (Westport, Connecticut). Na zorganizowanej przez Sand Hill Group konferencji Software 2006 dyrektor informatyczny Motoroli, Toby Redshaw, informował, że firma rozwija w swojej sieci korporacyjnej prawie tysiąc usług, na których opiera się ogromna liczba działających aplikacji i procesów.


„Uruchamiając kolejne usługi, będziemy pozbywać się wielu dotychczas działających aplikacji pakietowych”

Toby Redshaw, dyrektor IT w Motoroli


– Uruchamiając kolejne usługi, będziemy pozbywać się wielu dotychczas działających aplikacji pakietowych – stwierdził Redshaw. W ciągu minionych czterech lat Motorola zredukowała roczny budżet IT z 1,4 mld USD do mniej niż 1 mld USD.

Prawie wszyscy dostawcy oprogramowania dla przedsiębiorstw dynamicznie wdrażają lub modernizują pakiety aplikacji w oparciu o model SOA i usługi internetowe (Web services). Dowodzą oni, że architektura SOA przyspiesza tworzenie aplikacji, umożliwia szybką rekonfigurację i wdrożenie, a także zmniejsza koszty obsługi. Jednym z najlepiej sprzedawanych produktów IBM jest właśnie platforma do tworzenia i uruchamiania aplikacji opartych na architekturze SOA – system WebSphere. Dostawcy oferujący narzędzia SOA, tacy jak Tibco i BEA, mogą pochwalić się tempem wzrostu wyższym od przeciętnego w branży. Fakty te dowodzą, że przedsiębiorstwa coraz częściej chcą nie tylko kupować, ale i tworzyć swoje systemy informatyczne.

IBM nie tylko oferuje narzędzia i usługi, dzięki którym przedsiębiorstwa mogą dostosowywać oprogramowanie do swoich potrzeb, ale i sam stosuje model SOA. Opracowuje znaczną liczbę usług, które mogą być współużytkowane i wykorzystywane w wielu procesach. Dzięki tej architekturze IBM, podobnie jak Motorola, zmniejszył liczbę działających u siebie aplikacji aż o 75%.

Oferta rozwiązań opartych na modelu SOA

Dostawca

Produkt oparty na modelu SOA

Dostępność na rynku

Jaki produkt trafia do klienta?

BEA

WebLogic

Obecnie

Rozwiązania opracowane przez programistów, dostosowane do potrzeb konkretnych firm

IBM

WebSphere

Obecnie

Rozwiązania opracowane przez programistów, dostosowane do potrzeb konkretnych firm

Microsoft

.NET, BizTalk Server 2006

Obecnie

Produkty zewnętrznych dostawców oprogramowania, rozwiązania opracowane przez programistów, dostosowane do potrzeb konkretnych firm

Oracle

Fusion

Od 2008 r.

Warstwa pośrednicząca i aplikacje Oracle

SAP

Enterprise Services Architecture

Od 2007 r.

Aplikacje SAP

Dlaczego właśnie SOA?

Wymienione korzyści dotyczą również produktów oferowanych przez dostawców aplikacji. Opracowują oni własne rozwiązania, które wychodzą poza formułę tradycyjnego pakietu modułów funkcjonalnych. Jednocześnie zaś wielu dostawców z trudem potrafiwskazać wymierne korzyści wynikające ze stosowania modelu SOA.

Doskonałe argumenty przemawiające na korzyść modelu SOA przedstawił Henning Kagermann, dyrektor generalny SAP, prezentując wydanie systemu Enterprise Services Architecture (ESA) 2007:

  • w modelu SOA konfiguracja oprogramowania nie jest wyłącznie procesem technicznym, ale i biznesowym,
  • systemy oparte na architekturze SOA konfiguruje się pięć razy szybciej niż tradycyjne,
  • całkowity koszt posiadania spada o połowę,
  • szybkość wprowadzenia zmiany, czyli nowej działalności lub procesu biznesowego, przebiega dziesięć razy szybciej.

Jeżeli zapewnienia dyrektora SAP okażą się prawdziwe, systemy oparte na modelu SOA przyniosą długoterminowe wymierne korzyści, szczególnie w zakresie oszczędności w budżecie informatycznym. Redukcja kosztów może między innymi wynikać z automatyzacji działań, które dotąd wykonywali integratorzy systemów i wewnętrzne zespoły informatyków. Korzyści wynikające ze stosowania architektury zorientowanej na usługi są zatem podobne do tych, jakie zapewnia koncepcja „applistructure” (połączenie warstwy aplikacji i infrastruktury). W ostatecznym rozrachunku na modelach tych skorzystają firmy, które przeznaczą większą część budżetów informatycznych na innowacje w zakresie systemów IT.

 

W gąszczu norm

 

Fundamenty SOA stanowi ogromna liczba norm i specyfikacji. Opracowania te można podzielić na trzy grupy:

 

  • Opracowania dotyczące składni podają zasady formatowania, lokalizacji i funkcji usług.
  • Opracowania dotyczące kontekstu opisują znaczenie przesyłanych danych i odnoszą się do zagadnień określanych mianem semantyki biznesowej, normalizującej pojęcia „klient” czy „adres”.
  • Opracowania dotyczące pojęć opisują pojęcia zawarte w przesyłanych danych.

 

Wymienione opracowania to zaledwie szczyt góry lodowej. Microsoft, IBM, Oracle czy SAP stosują własne, o wiele bardziej szczegółowe specyfi kacje.

Autor: Erik Keller, MBT USA