SOA jest rozwiązaniem długofalowym. Nie należy tu oczekiwać mierzalnego ROI w krótkim czasie. Dla większości przedsiębiorstw wartość inwestycji będzie rozpoznana po latach, nie po miesiącach.

Dobrą zasadą jest uzyskanie środków na inwestycje i zaangażowanie zarządu organizacji, aby mieć realną siłę przebicia dla projektu, a także środki do przekonywania ludzi o długofalowych wartościach i znaczeniu SOA dla przedsiębiorstwa. Jeżeli SOA jest implementowana jako jeszcze jedno szybkie załatanie potrzeb, to może wprowadzić jeszcze większy bałagan do technologicznej infrastruktury przedsiębiorstwa. Bez długofalowego zaangażowania w SOA w ramach organizacji, nawet najprostszy projekt SOA ma małą szansę na sukces.

Określenie reguł budowy

Chociaż wielu ludzi ma pewne wyobrażenie czym jest SOA, to jednak niewielu ma jasną ideę, jak zaimplementować taką architekturę. Każda sytuacja jest inna i nie można znaleźć jednego, kanonicznego zestawu reguł. Pomimo to pojawiają się pewne wspólne wzorce, które mogą być pomocne w zrozumieniu drogi postępowania.

Po pierwsze, powinno się rozpoznać cele biznesu. Ważna jest artykulacja celów na wstępie, w tym zdefiniowanie, co jest sukcesem przedsięwzięcia.

Po drugie, powinno zdefiniować się domeny działania. Konieczne jest zdefiniowanie zakresu SOA w przedsiębiorstwie. SOA lepiej implementować w małych krokach, np. przez włączanie pojedynczych oddziałów lub jego części do architektury SOA. Ogromny plan, obejmujący już na starcie całe przedsiębiorstwo, rzadko zadziała. Mały sukces prowadzi do większych strategicznych sukcesów w miarę upływu czasu.

Powinno się także rozpoznać całą semantykę aplikacyjną w obszarze działania. Trudno radzić sobie z informacjami, których znaczenia się nie rozumie. Niezmiernie ważne jest zidentyfikowanie wszystkich semantyk aplikacji (metadanych), które istnieją w domenie. Racjonalna struktura dla semantyk aplikacji powinna ustalać sposób i formę powiązań specyficznych aplikacji z właściwościami procesów biznesowych.

Ważne jest także rozpoznanie wszystkich usług dostępnych w domenie. Najlepszym sposobem rozpoczęcia tego procesu jest utworzenie katalogu. Jest to repozytorium informacji o dostępnych usługach wraz z dokumentacją dla każdej usługi - zawierającej opis, co ona wykonuje, informacje przekazywane do usługi, informacje wychodzące z usługi itp. Taki katalog jest używany (wraz z semantykami aplikacji) do definiowania punktów integracji dla wszystkich systemów w domenie.

Po rozpoznaniu wszystkich procesów w domenie można przystąpić do sporządzenia listy możliwych procesów biznesowych istniejących w domenie. Po ustaleniu dostępnych usług i informacji, konieczne jest zdefiniowanie mechanizmów współdziałania obejmujących wszystkie procesy najwyższego, średniego i najniższego poziomu. W wielu wypadkach procesy te powinny być zautomatyzowane lub częściowo zautomatyzowane.

Następnie należy dokonać wyboru zestawu technologii. Właściwej technologii SOA nie można wybrać bez wykonania solidnego rozpoznania wymagań. Aby zrobić to poprawnie, często konieczne będzie wdrożenie projektu pilotowego, sprawdzającego, jak pracują wybrane technologie. Czas poświęcony na wybór prawidłowej technologii może być niekiedy porównywalny z czasem przeznaczonym na projektowanie SOA. Jednak jest to właściwa inwestycja, ponieważ zły wybór może praktycznie uniemożliwić implementację SOA.

I na końcu, testowanie i ocena. Istotne jest przygotowanie procedury krok po kroku określającej, jak SOA będzie testowana po zaimplementowaniu. Plan testu jest dlatego tak ważny, ponieważ testowanie rozwiązań SOA jest niezwykle trudne. Orientacja na usługi wprowadza nowe zależności, a SOA, także z uwagi na naturę, powinna być rozszerzalna w kierunku aplikacji, które dzisiaj jeszcze nie istnieją. Co więcej, w wielu SOA systemy źródłowe i docelowe są krytyczne dla biznesu i nie mogą być stawiane w stan offline. Testowanie tych systemów może być trochę skomplikowane, ale pomimo to musi też być wszechstronne.

SOA a czynnik ludzki

SOA jest budowana dla ludzi i zarządzana przez ludzi, tak więc trzeba zawsze brać pod uwagę jej wpływ na pracowników, na równi z wpływem na architekturę przedsiębiorstwa.

Przy budowaniu SOA należy dysponować zdolnością rozpoznania tradycyjnej architektury przedsiębiorstwa w kontekście technologii SOA. Dla większości organizacji jest to zbyt wysoka poprzeczka. Na wczesnych etapach mogą być potrzebni zewnętrzni konsultanci, a wewnętrzne szkolenia o podejściach i taktyce są sprawą nieodzowną.