Old estate. New demands. Contracts in between.
Most estates do not need rebuilding. They need clear boundaries, interfaces that are written down, and a way to change one part without a synchronised release across five teams. That is what service-oriented architecture is for, once the bus is taken out of it.
What you leave with
- Which parts of your estate need clear service boundaries, and which are fine as they are
- Where business logic has crept into the bus or the integration layer
- A first service to put a contract in front of, and what it would take
With a senior architect, not a salesperson. Sixty minutes, no cost, no obligation.
SOA is not the 2008 version any more.
Say “service-oriented architecture” and most people picture an enterprise service bus, a two-year programme and a vendor. That era earned its reputation. What survived it is the part that was always right: an estate is easier to change when every system exposes a contract, and nothing reaches inside anything else.
What went wrong last time
A central bus every team had to queue for, business logic hidden inside the middleware, and a change to one interface that broke three systems nobody had warned. The cost of a change kept going up rather than down.
What we do instead
Contracts first and no bus in the middle. Each service publishes what it promises and versions it, so a change is a new version rather than an outage. The middleware disappears into ordinary, testable code.
Why it matters again now
An AI agent choosing which service to call at runtime needs exactly what SOA asked for: a stated contract, clear ownership and predictable failure. The discipline came back, without the bus.
Read the researchDrawing boundaries that match the business, not the org chart.
Service boundaries
Where one system’s responsibility ends and the next begins, decided from how the business actually works rather than from who currently owns the database.
Contract-first interfaces
The interface is agreed and written down before the code. Consumers build against it, and a breaking change has to be a deliberate act rather than an accident.
Versioning and deprecation
More than one version live at once, a stated period of support, and a way to see who is still on the old one. This is what lets an estate change without a synchronised release.
Legacy, wrapped rather than rewritten
An old platform gets a contract in front of it and keeps running. Replacement then happens behind that contract, one piece at a time, with a way back.
Ownership
Every service has a name, an owner and a way to be called that does not depend on one person. Most architecture problems are really this problem.
A path off it
Where a service should eventually be replaced, retired or bought instead, we say so, with the order in which to do it and what each step buys you.
EAI, the service bus and the API gateway, each in its proper place.
Many estates run three generations of integration at once: a hub from the 1990s, an enterprise service bus from the 2000s and an API gateway from the 2010s. None of them has to go overnight. The useful question is what each one should still be doing.
EAI hubs and brokers
Hub-and-spoke brokers such as TIBCO, webMethods, Microsoft BizTalk and IBM MQ still move data reliably. They become a problem when every change has to queue behind the one team that owns the hub.
The enterprise service bus
WSO2, MuleSoft, Oracle SOA Suite and IBM Integration Bus are good plumbing. The trouble starts when business logic moves into the bus. We take it back out, into services with written contracts, and leave the bus to carry messages.
API gateways and management
AWS API Gateway, Azure API Management, Apigee on Google Cloud, Kong and WSO2 API Manager stay where they are: security, rate limits and a catalogue in front of the services. The contracts behind them, and what an AI agent needs to read, are what we design.
Read the researchWeeks, with a decision point at each end.
Map
What exists, what calls what, and which of those calls nobody knew about. Usually the first week produces a picture the organisation has never had on one page.
Draw
Proposed boundaries and contracts, with the reasoning and the trade-offs written in plain language so people outside engineering can argue with it.
Prove
One real service done properly, end to end, including versioning and the monitoring around it. Small enough to abandon if the approach is wrong.
Roll
The rest, in the order that reduces risk fastest, with your team doing more of it each time until we are not needed.
What an SOA engagement delivers
Contracts, ownership and a way to change one part of the estate at a time.
Service and contract design
Boundaries drawn from how the business works, interfaces described with OpenAPI, AsyncAPI or WSDL, and versioning rules everyone can follow.
ESB and integration platform review
WSO2, MuleSoft, Oracle SOA Suite, IBM Integration Bus or BizTalk: what should stay in the bus and what should move out.
Legacy wrapping
A contract in front of the mainframe, the AS/400 or the old .NET service, so it keeps running while it is replaced behind the interface.
API gateway and management
Security, rate limits, a catalogue and a developer portal on AWS API Gateway, Azure API Management, Apigee on Google Cloud, Kong or WSO2 API Manager.
Migration path
The Strangler Fig, done deliberately: new surface in front, traffic moved gradually, old paths retired when nothing calls them.
Agent readiness
The same contracts made readable by AI agents, so the estate can be called safely by assistants as well as applications.
Sound familiar?
- A change to one service needs a synchronised release across several teams
- Nobody can draw the current estate on one page
- The ESB has become the monolith everyone queues behind
- A legacy platform has no interface except its database
- You are planning AI agents and the services they would call are undocumented
A small, senior team that stays accountable.
- Architect-led. Every engagement is led by a senior architect who stays accountable for the decisions, from the first hour to the handover.
- Over twenty years of building and integrating software. Enterprise integration, cloud platforms, product delivery and now AI agents, across sectors where systems cannot fail.
- Independent and vendor-neutral. AWS, Azure and Google Cloud, and whatever platforms you already run. We recommend what fits, including doing less.
- Research, applied. The patterns we use are published openly on The Software Lens and applied by our R&D Wing, so you can read the reasoning before you hire us.
- We run what we recommend. We build our own product, Nexcubator, on the same architecture we design for clients.
- You own everything. Your repository, your cloud account and your documentation from the first week. Based in Ireland, working across the EU and beyond.
Questions we get asked
Is SOA not obsolete now that everyone does microservices?▼
They answer different questions. Microservices are about how small a deployable unit should be; service orientation is about what each unit promises to everyone else. A microservice estate without contracts is the same problem with more moving parts, which is why the discipline outlived the label.
Do we need an enterprise service bus?▼
Almost certainly not. A bus made sense when connecting two systems meant proprietary adapters and a licence. Today the routing and translation a bus did is ordinary code you can read, test and own, and keeping it out of the middle removes the queue everyone used to wait in.
We have one system nobody wants to touch. Where does that fit?▼
It gets a contract in front of it and stays where it is. New work builds against the contract rather than against the old system, which means the eventual replacement is a series of small steps with a way back at each one, rather than a single weekend everybody dreads.
What does this have to do with AI agents?▼
An agent decides at runtime which capability to use, so it needs what a good contract already states: what an operation does, what it may change and what it refuses. Estates that did this work are the ones where an assistant can be pointed at real systems safely.
One free hour. No pitch, no obligation.
Bring the problem you are stuck on: an integration that keeps breaking, a cloud bill nobody can explain, an AI project that is all demo and no product, or a platform you are about to invest in. You will leave with a straight answer and a written summary, whether or not you ever work with us.
- Architecture and integration review
- AI feasibility: what will actually work, and what will not
- AWS, Azure and Google Cloud cost and design
- Business process audit and ISO readiness
- Technical due diligence before you invest or acquire