SOA — service-oriented architecture — was born with a simple promise: stop integrating systems with point-to-point patches and start exposing functionality as reusable services. The promise won. Today it lives under other names — APIs, microservices, event-driven architecture — but the principle is the same, and it remains the most important architecture decision for anyone who wants to integrate systems without creating a monster.

In this article, we explain what SOA means in practice in 2026, what has changed since the days of the enterprise service bus, and how to implement the concept step by step.

The problem SOA came to solve

Before it, integrating meant stitching: each pair of systems got a custom connection, the so-called point-to-point integration. With five systems, you could live with it; with thirty, it became a web where any change broke something — and no one knew what.

SOA flipped the logic: each business capability — looking up an order, issuing an invoice — becomes a service with a clear contract, published once and consumed by whoever needs it. In the first generation, that mediation was the job of the ESB, the enterprise service bus. It worked, but the centralized bus became a bottleneck — and the evolution moved on.

Today’s SOA: APIs, microservices, and events

In 2026, the SOA principle materializes in three dominant practices:

• Managed APIs — services exposed through web standards, with a gateway handling security, versioning, and usage limits. It is the common language of integration: it is how ERP, e-commerce, banks (via Open Finance and PIX, Brazil’s instant-payment system), and partners connect.
• Microservices — decomposing applications into small, independent services, each deployable on its own. It is SOA taken to the limit — with the caveat that not every system needs it.
• Events — instead of asking, systems announce: “order created,” “payment approved.” Event-driven architecture also decouples systems in time, which makes it ideal for distributed operations.

Likewise, the SAP world has absorbed the principle: modern ERP extension happens outside the core, consuming standardized APIs — the so-called clean core, which preserves the ability to upgrade the system. It is a central practice in our SAP projects.

How to implement it, step by step

1. Map the existing integrations — which systems talk to each other today, and through which patches. This map tends to frighten — and to motivate.
2. Identify the business services — next, list the reusable capabilities: customer lookup, stock position, invoice issuance. A good service is born from the process, not from the database table.
3. Establish the contract and the gateway — standardize how services are exposed, authenticated, and versioned. Without governance, SOA becomes the same chaos under a new name.
4. Migrate by priority — then replace the point-to-point connections, starting with the most fragile or the most expensive to maintain. No big bang.
5. Measure reuse — finally, the success indicator: how many consumers each service has. A service with a single consumer is point-to-point integration in disguise.

The benefits that justify the effort

Agility is the most visible: a new system connects in days, not months, because the services already exist. Flexibility comes with it — replacing a system stops being high-risk surgery, since the contract isolates consumers from providers. And cost drops in compound fashion: every reused service is an integration that did not have to be built again.

This foundation is also a prerequisite for what comes next: cloud used to its full potential, data flowing into analytics, and AI assistants acting on systems safely. Not by chance, mature development teams treat the service layer as an internal product, with an owner and an evolution roadmap.

There is also the distributed-work factor: with teams and operations spread out — office, home, branches —, services accessible from anywhere with strong authentication stopped being a luxury. Well-governed SOA is what allows that distribution without multiplying risk.

In short, SOA won so completely that it stopped needing the name. What matters is the principle: services with contracts, reuse, and governance. Start small, govern from the very first service, and let the web of fragile integrations die by replacement.