SOA

SOA (Service-Oriented Architecture) is an architectural style that organizes application functionality into discrete, network-accessible services with well-defined contracts. Emerging in the enterprise in the early 2000s, often built on SOAP, WSDL, and an enterprise service bus, its goal was to break monolithic systems into reusable, composable capabilities that different parts of an organization could share. In many ways it is the direct ancestor of today’s API and microservices thinking.

• Service contracts - Each service exposes a defined interface, decoupling consumers from the implementation behind it.
• Reuse and composition - Capabilities are meant to be built once and recombined across many business processes.
• Loose coupling - Services interact over the network through their contracts rather than shared internals.
• Heavyweight tooling - Classic SOA leaned on SOAP, WSDL, and an enterprise service bus to broker and govern traffic.

I have written for years that the API movement is SOA’s lessons relearned — the same goals of reuse, contracts, and loose coupling, pursued with lighter-weight REST and simpler tooling that developers actually adopt. The enterprises that struggled with SOA often struggled again with APIs and microservices because the hard part was never the technology; it was the governance, discovery, and organizational discipline. That history is worth remembering now, as agent-driven consumption puts the same demands for well-described, discoverable services back at the center of the work.