An architectural pattern where software components provide services to other components through a communication protocol over a network. Services are loosely coupled, reusable, and can be independently deployed and maintained.
Service Oriented Architecture
Service Oriented Architecture (SOA) is an architectural style in which software capabilities are exposed as discrete, network-addressable services that other components consume over a shared communication protocol. It grew out of the enterprise middleware and web services era, and it established many of the ideas — loose coupling, reuse, contracts — that the API economy later inherited and simplified.
- Loose coupling - Services are designed to be independent, so a consumer depends on a contract rather than on another system’s internals.
- Reusability - A single service is meant to be built once and reused across many applications and business processes.
- Standardized contracts - Interfaces are described formally (historically WSDL and SOAP over an enterprise service bus) so producers and consumers agree on the shape of every exchange.
- Composability - Services can be orchestrated and composed into larger workflows and business processes.
In practice SOA is the heavyweight ancestor of today’s Microservices and web APIs. Most of the organizations I work with have quietly traded the enterprise service bus and SOAP envelopes for lighter REST and OpenAPI contracts, but the governance instincts SOA introduced — cataloging services, versioning contracts, and reusing capabilities — are exactly what make an estate legible to both humans and, increasingly, agents. The vocabulary changed; the discipline did not.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
SOA vs API - The Humans Win
2013-03-10
SOA Cloud 2012 Service Technology Symposium
2012-09-11
