Service-Oriented Architecture, or SOA, is an architectural paradigm for organizing software as a collection of services that are accessible over a network and described by explicit interfaces. The OASIS Reference Model for Service Oriented Architecture, an official standard approved on October 12, 2006, defines SOA as “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.” This last clause is central: SOA was conceived to let capabilities owned by different teams, departments, or companies be combined without tight coupling.
The Reference Model defines a service as “a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies.” In this view a service is not a piece of code but a contracted point of access to some capability. The model also defines a contract as “an agreement by two or more parties,” covering interface agreements, quality of service, and commercial terms. Contracts and prescribed interfaces are what make services usable across ownership boundaries.
OASIS frames three core dynamics that any SOA must support: visibility, by which providers and consumers can discover one another; interaction, mediated through shared information and behavior models; and real-world effect, the actual results produced by invoking a service. The Reference Model deliberately stays technology-neutral, describing concepts rather than mandating any particular protocol, so that it applies equally to SOAP-based systems, message-bus deployments, and later styles.
In practice, enterprise SOA of the 2000s was usually built on SOAP web services and a central Enterprise Service Bus that routed and transformed messages between services. The promise was reuse: expose a capability once as a service, and many applications could consume it. SOA delivered the conceptual vocabulary of services, contracts, and loose coupling that later architectures inherited.
The microservices movement of the 2010s is in many ways a reaction to heavyweight enterprise SOA. It kept the idea of independent, contract-bound services but rejected the central bus, favoring smaller services, lightweight protocols such as REST over HTTP, and decentralized governance. Understanding SOA’s definitions clarifies what microservices kept and what they discarded.