What SOA is
Service-oriented architecture organises an organisation's software as a set of coarse-grained business services — Customer, Billing, Claims, Inventory — each exposing capabilities through a formal, technology-neutral contract, discoverable and reusable across the enterprise.
The unit of design is a business capability that many applications need. If three different applications all need "calculate premium", SOA says build it once as a service and let all three consume it, whatever language they are written in.
The principles
- Standardised contract. The interface is published and versioned (WSDL/SOAP historically, OpenAPI or gRPC today) and is independent of implementation language.
- Loose coupling. Consumers depend on the contract, never on the internals or the deployment location.
- Abstraction. The service hides its data store and logic entirely.
- Reusability and composability. Services are designed to be assembled into higher-level business processes.
- Discoverability. A registry lets teams find what already exists rather than building a fourth customer lookup.
- Autonomy. A service controls the logic it encapsulates.
The enterprise service bus
The defining infrastructure of classic SOA. The ESB sits between consumers and providers and handles cross-cutting integration concerns:
consumer -> [ ESB ] -> provider
|
+- protocol bridging (SOAP <-> JMS <-> file drop <-> FTP)
+- message transformation (XSLT, field mapping)
+- content-based routing
+- orchestration of multi-step processes
+- security, throttling, auditing, monitoring
Benefit: legacy mainframe and a modern web app can integrate
without either knowing about the other.
Risk: routing rules become business logic, owned by the
integration team, invisible to the service teams.This is smart pipes, dumb endpoints. Microservices deliberately inverted it — dumb pipes, smart endpoints — after a decade of ESBs turning into central bottlenecks that nobody dared change.
Contracts and governance
SOA takes contracts far more seriously than most microservice estates do, and this is the part worth stealing:
- Contracts are published artifacts with owners, versions and deprecation policies.
- Backward compatibility is a governance rule, not a courtesy.
- A service registry records who consumes what — so you know the blast radius of a change.
- SLAs are explicit per service, not implicit per team.
SOA vs microservices
| Dimension | SOA | Microservices |
|---|---|---|
| Service size | Coarse — a whole business capability | Fine — independently deployable unit |
| Data | Sharing a database is acceptable | Database per service, non-negotiable |
| Communication | Via ESB, often orchestrated | Direct or via a dumb broker |
| Reuse | Primary goal | Secondary — duplication is preferred to coupling |
| Governance | Central, top-down | Federated, tooling-enforced |
| Deployment | Often coordinated, on shared app servers | Independent per service |
| Organisational fit | Enterprise integration across departments | Product teams shipping continuously |
The single deepest difference is reuse versus independence. SOA optimises for not building the same thing twice; microservices accept duplication to avoid the coupling that shared components create.
How SOA programmes failed
- The ESB became the system. Business logic accumulated in transformation and routing rules that no service team owned or tested.
- Centralised bottlenecks. A single integration team gating every change meant lead times measured in quarters.
- Shared databases. Services that could not change their schema were not autonomous in any meaningful sense.
- Reuse-driven design. Services generalised to serve everyone served no one well and could never be changed safely.
- Vendor-led adoption. Many programmes bought a product and called it an architecture.
Where SOA still wins
- Integrating systems you cannot rewrite — mainframes, vendor ERPs, partner protocols. Something must bridge SFTP, SOAP and Kafka, and that something is an ESB or an integration platform by another name.
- Regulated environments where every message must be auditable, replayable and centrally monitored.
- Genuinely enterprise-wide capabilities — identity, payments, KYC — where one authoritative implementation is the point.
Today it usually appears as an API gateway plus an integration layer plus event streaming, with the routing rules in version control and the services owning their own data. That is SOA principles with the microservice correction applied.
Interview framing
Strong answer
"For enterprise integration I'd use SOA-style coarse services with formal contracts: one Customer service, one Billing service, published OpenAPI, explicit versioning and SLAs. I would not put business logic in the bus — the integration layer only does protocol bridging and routing, kept in version control and tested. Each service owns its own store so the schema can evolve. The failure mode to design against is the ESB becoming a central bottleneck, so orchestration lives in a named service owned by a team, not in middleware configuration."
Follow-ups
- When is reuse the wrong goal?
- How do you evolve a contract with twelve unknown consumers?
- Where would you draw the line between an ESB and an API gateway?