SOA (ang. Service-Oriented Architecture, architektura zorientowana na usługi) to styl architektury, w którym funkcje biznesowe są udostępniane jako usługi: samodzielne, wielokrotnego użytku, o jawnie zdefiniowanych kontraktach i luźnych powiązaniach. Historycznie SOA kojarzy się z korporacyjną szyną integracyjną (ESB), protokołem SOAP i ładem architektonicznym (governance); idea jest jednak ponadczasowa - jedna funkcja biznesowa, jedna usługa, wielu konsumentów.
Analityk spotyka SOA w dużych organizacjach przy mapowaniu zdolności biznesowych (business capabilities) na usługi i przy integracjach z systemami legacy. Praktyczna korzyść z myślenia usługowego: zmiana logiki w jednym miejscu zamiast w pięciu kopiach.
Przykład (MediFlow). Grupa medyczna, do której należy sieć 12 przychodni, ma usługę "Zarządzanie terminarzem" z kontraktem obejmującym operacje: sprawdź dostępność, zarezerwuj, odwołaj. Konsumują ją trzy aplikacje: nowa e-rejestracja, call center i aplikacja mobilna lekarza. Reguła "maksymalnie 3 aktywne rezerwacje pacjenta" żyje w jednym miejscu - w usłudze - więc obowiązuje identycznie we wszystkich kanałach. W starym świecie każda aplikacja miała własną kopię tej logiki i trzy różne wersje limitu, co wychodziło przy każdej skardze pacjenta.
Częsta pomyłka. Utożsamianie SOA z mikrousługami. Mikrousługi (microservices) to późniejsza ewolucja pokrewnej idei: usługi znacznie mniejsze, niezależnie wdrażane, bez centralnej szyny, z decentralizacją danych - SOA klasycznie operowała grubszymi usługami i centralnym ESB. Druga pomyłka: ogłaszanie "mamy SOA", bo istnieje kilkanaście webservice'ów. Bez kontraktów, wersjonowania, katalogu usług i ładu architektonicznego to nie architektura usługowa, tylko nieuporządkowany zbiór API - z wszystkimi wadami obu światów.