SOA: marzenia o wspólnym języku biznesu i IT

Budowanie SOA

SOA: marzenia o wspólnym języku biznesu i IT

Proces budowania SOA

Budowanie SOA przebiega na ogół dość powoli, głównie z powodu dużej liczby zależności. Najtrudniejszym elementem przy budowaniu SOA nie jest technologia - są nim natomiast procesy biznesowe, które trzeba na nowo opisać, aby zapewnić bazę tej architektury, oraz bardzo często kontrowersyjne przetasowania ról i odpowiedzialności, które w wyniku tego następują.

Jednak i strona technologiczna niekoniecznie musi być łatwa. Po zakończeniu planowania i ustaleniu strategii, powinna być zapewniona infrastruktura dla usług i ich komunikatów, wraz z zarządzaniem platformami, aplikacjami i systemami już istniejącymi.

Ostatecznym celem SOA jest sprawna infrastruktura, łącząca aplikacje na poziomie abstrakcji, który scala wiele platform i domen w ramach przedsiębiorstwa. Praktyczne inicjatywy SOA zaczynają się od powiązania zestawu procesów biznesowych, który powinien zapewniać wyraźne korzyści ze względu na większą elastyczność, np. w warunkach nieustannie zmieniającego się rynku lub konieczności wdrażania nowych usług w biegu z powodu konkurencji. W niektórych punktach to "odgórne" podejście spotyka się z "oddolną" rzeczywistością - istniejącymi zasobami oprogramowania i infrastruktury.

W takiej sytuacji technolodzy muszą podjąć kluczowe decyzje dotyczące platform, na których budowane będą usługi, jak również o tym, jak te usługi będą eksponowane i zarządzane. Niektóre firmy mogą wybierać ESB (Enterprise Service Bus) do łączenia usług, podczas gdy inni mogą skupiać się na usługach opartych na standardach zaprojektowanych w celu wielokrotnego wykorzystania.

Przedsiębiorstwa implementują SOA, aby mieć możliwość reagowania na potrzeby biznesowe w czasie zbliżonym do rzeczywistego. W ten sposób SOA często jest metodą naprawiania systemów, które od lat tkwią w stanie dysfunkcjonalnym.

Stosując SOA, organizacje mogą wpływać na istniejące systemy w dynamicznym środowisku, wydzielając istotę aplikacji w postaci usług, które mogą być przegrupowywane szybko w nowe rozwiązania. Nie jest to jednak łatwe do osiągnięcia. SOA to tak wiele zmiennych elementów, że często trudno jest wyizolować zasady, które wskażą drogę do sukcesu.

Na podstawie dotychczasowych doświadczeń można wyodrębnić kilka zasad przydatnych przy konstruowaniu SOA: ocenę wartości nowych rozwiązań dla biznesu, rozpoznanie zasady budowy SOA, uwzględnienie czynnika ludzkiego w procesach biznesowych i skoncentrowanie się na rozwiązaniach długofalowych.

W wielu nowoczesnych firmach istniejące architektury przedsiębiorstwa często utrudniają przeprowadzanie szybkich zmian. Działy IT często bywają opóźnione przy wspieraniu zmian biznesowych, co może znacząco ograniczać osiąganie sukcesów w biznesie.

Ocena korzyści z implementacji SOA

Organizacje implementują SOA z dwóch głównych powodów. Po pierwsze, z chęci uzyskania możliwości zmniejszenia kosztów projektowania poprzez stosowanie usług wielokrotnego użytku. Usługi takie mogą być budowane wewnątrz firmy lub poza nią, a im więcej usług, które mogą być wykorzystywane przez różne systemy, tym lepszy wskaźnik zwrotu z inwestycji. Powód drugi, to zdolność do szybkiej zmiany infrastruktury IT w procesie jej adaptacji do zmiennych potrzeb biznesu. Może to zapewnić firmie przewagę na rynku i zwiększyć szansę przetrwania w dłuższym okresie.

Kilka czynników może pomóc w ocenie wartości wielokrotnie używanych usług, wśród nich jest ich liczba, złożoność oraz stopień "używalności" w różnych systemach. Złożoność każdej usługi jest kluczem do oceny jej wartości, która może być zdefiniowana jako liczba funkcji i cech obiektów, które tworzą usługę. Szczególnie ważna jest liczba instancji, w których można spodziewać się praktycznego wykorzystania usługi.

Chociaż określenie stopy zwrotu z inwestycji (ROI) jest trudne do przedstawienia w postaci konkretnej wartości pieniężnej, to jednak nie jest to niemożliwe. Trzeba tylko ustalić kilka elementów dotyczących biznesu, obejmujących stopień zmian w czasie, zdolność adaptacji do zmian i relatywną wartość zmian. Stopień zmian w czasie jest w rzeczywistości liczbą określającą, ile razy w ustalonym przedziale czasowym biznes przekształca się w celu dostosowania do rynku.

Kiedy ocenia się spodziewaną wartość SOA, istotne jest poprawne opisanie bieżącej zdolności biznesu do wprowadzania zmian i projekcji, w jakim stopniu ta zdolność zwiększy się po wdrożeniu SOA.

Możliwe zastosowania WS-RT

1. Użytkownik opisuje system do utworzenia (taki jak wyposażanie w serwer Windows 2003), wybierając z biblioteki istniejących modeli IT, następnie wysyłając komunikat WS-RT Create do narzędzia aprowizacyjnego Windows Server 2003, zdefiniowanego w modelu.

2. Narzędzie aprowizacyjne tworzy/konfiguruje/wykrywa niezbędne zasoby.

3. Narzędzie aprowizacyjne zwraca Endpoint Reference, kod XML, który pozwala na wysłanie komunikatu web services do miejsca przeznaczenia tworzonego systemu (Windows 2003 server).

4. Późniejsze zmiany konfiguracyjne są wykonywane przez uaktualnienie modelu z użyciem komunikatu WS-RT Put. Narzędzie aprowizacyjne rekonfiguruje system i zwraca kod kompletacji, potwierdzający rekonfigurację.

Ostatecznie relatywną wartością zmian są pieniądze uzyskane jako bezpośredni rezultat zmian w biznesie.


TOP 200