Człowiek do zadań specjalnych

Przy wdrażaniu SOA ważne jest, aby dyrektor IT rozumiał, jak zmieni się model działania IT oraz całej organizacji, a wszyscy inni mieli świadomość, w jaki sposób organizacja będzie przechodzić od tradycyjnej architektury IT w stronę architektury zorientowanej na usługi.

Ważne jest, aby dyrektor IT rozumiał, jak zmieni się model działania IT oraz całej organizacji w momencie wdrożenia SOA. Ważne jest, aby wszyscy mieli świadomość, w jaki sposób cała organizacja i poszczególne jej działy będą przechodziły od tradycyjnej architektury IT w stronę SOA. W jaki sposób będą konsumowały serwisy, zarówno te, dostarczone wewnętrznie, jak i przez firmy trzecie, na przykład przez partnerów biznesowych.

Bardzo istotne jest też zrozumienie, że narzędzia i technologie samodzielnie nie są w stanie dostarczyć korzyści z SOA - procesy biznesowe, umiejętności oraz podejście są dużo ważniejsze! Na przykład, jeśli wdrożenie SOA ma zakończyć się sukcesem, świadomy dyrektor IT musi wdrożyć politykę i procedury służące kontrolowaniu środowiska SOA natychmiast po przejściu etapu "proof of concept". Rozwijając to zagadnienie, możemy podzielić te procesy kontrolne na trzy grupy: SOA Governance, SOA Service Management oraz Service Quality.
SOA Governance

O ile wiele organizacji używa dzisiaj serwisów, o tyle niewiele z nich używa najlepszych metod i doświadczeń (Best practices) do zarządzania nimi. To ewidentna pomyłka - duża część korzyści z wdrożenia SOA wynika z ponownego użycia serwisów i używania otwartych standardów, a to nie będzie możliwe bez zdefiniowanych i przestrzeganych procedur i polityk.

SOA Governance jest definicją i implementacją w organizacji polityk dla następujących działań:
- tworzenie nowych serwisów
- zmiana istniejących serwisów
- usuwanie serwisów na końcu ich cyklu życia
- udostępnianie serwisów firmom trzecim
- publikowanie i wyszukiwanie serwisów
- ponowne użycie serwisów
- monitorowanie SOA
- określanie wartości wnoszonej przez SOA
Jeżeli procesy odpowiadające za te działania nie są znane od samego początku, indywidualne projekty w sposób nieuchronny będą dążyły do wytwarzania serwisów, które nie będą zdolne do współpracy z innymi serwisami. Użycie i zarządzanie takimi serwisami jest bardzo trudne, w skrajnych przypadkach nawet niemożliwe! W efekcie środki wydane na implementację SOA są zmarnowane: ponieważ serwisy nie będą użyte ponownie, zwiększa się koszty przyszłych projektów. To pokazuje, w jaki sposób aplikacje budowane przy użyciu SOA mogą być droższe od tradycyjnych aplikacji.

Jednym z najtrudniejszych aspektów SOA Governance jest proces eskalacji oraz definiowanie i egzekwowanie obszarów odpowiedzialności. W tradycyjnej, scentralizowanej architekturze IT bardzo łatwo jest ustalić obszary odpowiedzialności oraz odpowiednie procedury eskalacyjne. W środowisku SOA tradycyjny model raczej się nie sprawdzi. Jeżeli serwis jest dostarczany przez firmę trzecią, co się stanie w przypadku awarii? Ten serwis może być krytyczny dla działania ważnej aplikacji. W jaki sposób znaleźć wtedy miejsce wystąpienia błędu i odpowiednie rozwiązanie problemu?

Bardzo ważne jest, szczególnie w przypadku używania serwisów od wielu dostawców, bardzo jasne zdefiniowanie oczekiwań i wymagań pomiędzy współpracującymi stronami: wyczerpujące zdefiniowanie odpowiedzialności, SLA, procedur eskalacji problemów, kosztów, kar w przypadku niedostępności serwisów. Ale przecież świadomy dyrektor IT i tak to robi, prawda?