Service oriented architecture
Definition
Service oriented architecture
Service oriented architecture is a software design style in which business functions are built as separate, reusable services that talk to each other over a network. Despite the name, it has nothing to do with IT service management or service design.
The approach belongs to enterprise software architecture, the same family as the enterprise architecture framework and event driven architecture. A reader who arrives expecting service desks or service catalogues is in the wrong room.
The National Institute of Standards and Technology defines service oriented architecture (SOA) as principles and methodologies for designing software as interoperable services, each a business function that can be reused for different purposes.
Key takeaways
- The style splits a system into reusable services with published contracts between them.
- It is an architecture idea, unrelated to IT service management and to service design.
- Shared middleware and shared databases made many early implementations brittle.
- Microservices carry the same principles forward with smaller services and independent teams.
How it works
Service oriented architecture works by splitting a system into services that each own one business function and expose it through a published contract. Anything that needs that function calls the service instead of rebuilding the logic.
| Element | What it does | Typical form |
|---|---|---|
| Service | Owns one business function end to end | Credit check, pricing, address lookup |
| Contract | States the inputs, outputs and errors | Published interface definition |
| Registry | Lists what exists and where to find it | Searchable index for developers |
| Bus or gateway | Routes, transforms and secures calls | Enterprise service bus, API gateway |
| Governance | Decides who may publish or change a service | Architecture review board |
Four ideas hold the style together:
- A service is defined by a business function, not by a database table.
- The contract is published and versioned, so callers are never surprised.
- Services stay stateless where they can, so any instance can answer a request.
- Discovery is explicit, so a developer can find what exists without asking anyone.
Reuse is the whole argument. One pricing service called by four applications beats four pricing rules that drift apart — which is why banks, telecoms and airlines adopted the style through the 2000s.
Granularity is the judgement call. Too coarse and the service becomes a second monolith behind an interface; too fine and one simple request fans out into a dozen network calls that must all succeed.
The contract matters more than the code. An application programming interface (API) is how that contract gets published today, and one careless change to it breaks every caller at once.
Central middleware was the weak point. A bus that routes everything becomes the thing that fails for everything — and the team owning it becomes the queue every project waits in.
Versioning is where most programmes bleed. Running two versions of one contract side by side is expensive, and retiring the old one needs a named owner with the authority to say no.
Someone has to hold the line on contracts and versions. That job usually belongs to the enterprise architect, who decides what may be published and what must be retired.
Security moves to the edge of every service. Each call has to be authenticated and authorised on its own, because the old assumption that anything inside the network is trusted no longer holds.
Cost shows up in operations rather than in the build. Monitoring, tracing and a shared release calendar are the bill that arrives once the first four services are live.
Microservices are the successor idea rather than a rival one. In its 2023 whitepaper on microservices, Amazon Web Services lists service oriented architectures among the proven concepts microservices combine, alongside agile development.
Examples
Retail banking in Europe. A bank exposes balance, payment and customer lookup as shared services so mobile, branch and call centre applications read the same record — that shared record is the point of the style.
Airline reservations. Seat availability, fares and ticketing have been shared services for decades, which is how a single booking appears identically in an airline app, a travel agent terminal and a partner carrier’s own website.
Government tax systems. Several national tax authorities expose identity, assessment and payment as separate services, so accounting software built by third parties can file a return without touching the core.
Wrapping an older core system. Companies rarely rewrite enterprise resource planning (ERP). They wrap it in services so warehouse, commerce and reporting tools can read it without another point to point integration.
Related terms
- Event driven architecture: services react to published changes instead of calling each other directly.
- Data mesh architecture: the same ownership idea applied to data products rather than to functions.
- Information architecture: how content and navigation are organised for people, not for systems.
- Enterprise architecture framework: the method that governs which services should exist at all.
- Application programming interface (API): the published contract a service is consumed through.
FAQ
Is service oriented architecture the same as IT service management?
No. IT service management runs support services for users, such as incidents, requests and catalogues, while this is a way of structuring software. The shared word is an accident of naming, and the two disciplines rarely share a team.
Is SOA dead?
No, it was absorbed — most of its principles now live inside microservices and API programmes, which is where new systems actually get built.
What is the difference between SOA and microservices?
Size, ownership and deployment. SOA services tend to be large, shared and released together, while microservices are small, owned by one team and deployed on their own schedule. The principles are the same; the blast radius of a change is not.
Do you still need an enterprise service bus?
Rarely for new work. API gateways and event routers cover most of what a bus did, without one central component that everything depends on. Existing buses usually get shrunk rather than switched off.
Does this style make outsourcing easier?
Yes, because a published contract lets an external team own and run one service without ever having to read the rest of the system.
Use the provider research on Outsource Accelerator when you scope that kind of handover.
Independent
