Before microservices became fashionable, enterprises were already trying to solve service boundaries.

We called it Service-Oriented Architecture, or SOA.

SOA addressed a practical enterprise problem: how can dozens—or sometimes hundreds—of systems reuse capabilities and exchange information without creating point-to-point integration chaos?

The answer introduced ideas that remain familiar today:

  • Reusable business services
  • Explicit contracts
  • Orchestration
  • Central integration
  • Enterprise Service Buses

What it also taught us

SOA solved important problems. It also taught us important lessons.

Centralization can become a bottleneck. Governance can turn into bureaucracy. An Enterprise Service Bus can become the place where every transformation and business rule goes to hide, slowing change across the organization.

But dismissing SOA as old architecture misses the larger point.

Many current conversations about APIs, service contracts, integration platforms and composability address the same underlying concerns: ownership, reuse, interoperability and controlled change.

The technologies evolve. The architectural problems often repeat.

Experience helps us recognize both the useful patterns and their failure modes sooner.