The SOA reflex is the problem

Sometimes one sentence in a job posting is enough, and somewhere inside you hear an old ESB manual slam shut.

In a staff engineer role, it said, roughly:

You lead the technical migration of our legacy monolith towards a modular, service-oriented architecture – from planning to hands-on delivery.

This sentence triggers me.

Not because services are bad. Not because modularization is wrong. Not even because “service-oriented” is inherently evil.

But because this phrasing smells like an old enterprise reflex:

Legacy monolith broken? Then let’s build a service-oriented target architecture. With planning. Governance. Service boundaries. Integration logic. And probably PowerPoint.

The problem isn’t the word “service.” The problem is the reflex behind it.

SOA wasn’t stupid

It would be cheap to shout “SOA is dead” now and feel modern for saying it.

SOA was a reasonable answer to real problems. Companies had point-to-point integrations, sprawling technical landscapes, monoliths, direct database coupling, proprietary interfaces, and dependencies nobody could cleanly explain anymore.

The idea of making capabilities accessible through services wasn’t absurd. On the contrary: a lot of modern architecture styles stand on ideas you also find in service-oriented approaches. Loose coupling. Contractual interfaces. Reusable capabilities. Clear responsibilities. Technical decoupling.

Services aren’t the problem.

Centralized intelligence is the problem.

The old SOA reflex is dangerous

In practice, SOA often turned into something other than the nice architectural promise.

Domain orientation turned into a service inventory. Decoupling turned into centralized integration logic. Reuse turned into a dependency web. Architecture turned into governance. Knowledge turned into an expert monopoly.

That’s the part that’s dangerous in 2026.

When a legacy monolith can no longer deliver, it doesn’t help much to just break it apart into technically named services and lay a central integration layer over the top. The monolith hasn’t disappeared. It’s just changed shape.

Before, it was a deployable problem. Afterward, it’s a distributed problem with a meeting series.

Bad boundaries produce services but no autonomy. At that point, you don’t have a modern system landscape. You have a distributed monolith with better merchandising.

The old criticism didn’t come out of nowhere

Back in the late 2000s, SOA was already being viewed much more critically. A Burton Group study, later often cited in a Gartner context, roughly found “only 1 in 5 SOA projects successful.” The reported numbers: about half were clear failures, and another roughly 30 percent were neither clearly successful nor completely failed. So roughly only 20 percent were unambiguously successful.

That’s not a law of nature. It’s also not proof that every service-oriented architecture has to fail.

But it’s a warning sign.

A 2014 paper on SOA governance picked up this Burton Group number again, also pointing out that only one in five SOA projects had actually been successful. What’s interesting here isn’t so much the exact percentage. What’s interesting is that SOA apparently didn’t suffer from a lack of tools, standards, or diagrams.

SOA often suffered because organizations didn’t take their own dependencies seriously enough.

It gets even clearer with ROI. Gartner was quoted in 2009 saying that a lot of SOA initiatives weren’t cleanly measuring their return on investment: roughly 40 percent of SOA users, according to this, weren’t measuring when ROI was reached. Among non-adopters, about half couldn’t articulate or demonstrate the business value.

That’s harsh.

If you can’t explain or measure the business value, you’re not building architecture. You’re building an integration program with a glimmer of hope.

Bus factor with enterprise vocabulary

My experience with SOA landscapes isn’t that nobody there was smart. On the contrary.

There were often very smart people working there. Too smart for the system.

A handful of architects knew why service A talked to service B over route C. A handful of integration specialists knew which transformation in the ESB really mattered. A handful of old hands knew why the central data model couldn’t be touched at exactly this spot.

And when these people left, got sick, or got hit by the proverbial bus, the system was still technically standing there.

But hardly anyone still understood it in business terms.

That was bus factor as an architecture principle. Just with enterprise vocabulary.

You didn’t have a robust system. You had a knowledge monopoly with an SLA.

That’s not decoupling. That’s centralizing understanding.

Modern migration asks differently

Modern architecture shouldn’t ask first:

What does the brilliant target system look like?

It should ask first:

Which teams need to be able to make which business decisions independently?

That’s a different mode of thinking.

Team autonomy matters more than abstract system beauty. Good boundaries let a team change, test, and deploy in a way that makes business sense, without synchronizing with five other teams. Bad boundaries look clean on the diagram but create coordination overhead, ticket chains, release coordination, and integration anxiety in reality.

Architecture has to be measured by delivery capability, not by how pretty the diagram looks.

That’s why the strangler fig approach matters so much as a counter-model. Not because the name sounds pretty. Strangler fig isn’t a romantic nature image. It’s an antidote to big-bang architecture.

The idea: you don’t replace the monolith in one big heroic overhaul. You build new functionality around the old system, pull individual flows out, encapsulate business fault lines, learn from real usage, and make the old monolith smaller step by step.

That’s less spectacular than a target-architecture presentation.

But it has one advantage: it can actually work.

EDA isn’t a magic wand, but it’s a better mode of thinking

In 2026, we talk more often about event-driven architecture, business events, loose coupling, autonomous teams, and the ability to change independently.

Good.

But please, not naively.

EDA doesn’t magically solve every problem. Events bring their own pain along: debugging, event versioning, schema evolution, consistency models, observability, business coordination, reprocessing, ownership. Anyone who introduces events without discipline isn’t building modern architecture. They’re building logfile bingo with Kafka.

Still, the mode of thinking is interesting.

EDA isn’t modern because events sound cooler than services. EDA is interesting when business events enable real autonomy.

A good event doesn’t say: “Record 4711 was changed.”

A good event says something meaningful in business terms:

• An invoice was approved.
• An order was canceled.
• A membership was activated.
• A payment failed.
• A review was completed.

Events like these can respect context boundaries. They let other business areas react without central integration logic orchestrating every decision.

That’s the difference.

Not central control. Instead, business responsibilities that communicate with each other through stable events.

The DRY reflex is part of the problem

A lot of SOA landscapes loved reuse.

Central models. Central schemas. Central services. Shared data types. Defined once, used everywhere.

Sounds efficient.

Is often dangerous.

Because reuse can be coupling wearing an efficiency costume. Especially with domain models, shared model knowledge isn’t automatically a win. It can mean several business areas pulling on one shared term until it belongs to nobody anymore.

Vaughn Vernon, in a DDD context, has pointed out, roughly, that DRY doesn’t simply mean “no duplicate lines of code” — it primarily means “don’t repeat knowledge.” It’s about knowledge, not cosmetic duplicates.

Sometimes a separate model per domain context is cleaner than one central model that everyone uses and nobody owns.

Shared models aren’t an architecture trophy. They’re a liability you take on deliberately.

Warning signs of SOA reflexes

If one of these sentences comes up during a monolith migration, it’s worth listening closer:

• “We’ll define the target architecture first.”
• “We need a central data model.”
• “The team can build the feature, but integration is done by another team.”
• “All services run through a central layer.”
• “Reuse is our main goal.”
• “We’ll divide it along business lines later.”
• “For us, events are technical change notifications.”
• “Deployment is distributed, but decisions are centralized.”
• “Only two people understand the integration logic.”

Each individual sentence can be explainable in a specific context.

Together, they form a pattern.

And that pattern isn’t called modernization. It’s called relapse.

What you should do instead

You shouldn’t divide a legacy monolith along technical lines first. You should look for business fault lines.

Where does the system change often? Where do business conflicts arise? Where do teams have wait times today? Where is data ownership unclear? Where do releases need to be coordinated? Where does coupling prevent real product development?

That produces better architecture questions:

• Which business responsibility can a team genuinely own?
• Which data belongs to that responsibility?
• Which decisions can this team make independently?
• Which interfaces does it need toward the outside?
• Which events express genuine business facts?
• Which parts of the monolith can be strangled incrementally?
• What business value do these boundaries create?
• Which risk gets reduced?
• Which delivery capability gets improved?

You should only build new services where responsibility, data ownership, and pressure to change actually line up.

You should only use EDA where business events genuinely enable loose coupling.

A central data model shouldn’t be treated as a cure-all.

Shared models should be scrutinized skeptically.

Integration can’t be allowed to become the new monolith.

And architecture knowledge can’t be spread across three people who are never allowed to go on vacation at the same time.

”Service-oriented” has to mean more in 2026

Anyone saying “service-oriented architecture” in 2026 should explain very precisely what they mean.

If what’s meant is: business responsibilities, clear ownership, autonomous teams, stable interfaces, the ability to change independently — good. Then we’re talking about something meaningful.

If what’s meant is: a central integration layer, a central data model, a service catalog, a governance board, technical reuse, and target-architecture theater — then it’s a warning sign.

SOA wasn’t stupid. But the old SOA reflex is dangerous.

Services don’t rescue a monolith if the organization keeps thinking centrally. Distributed deployment isn’t distributed responsibility. Technical services aren’t business autonomy. And an integration hub isn’t an architecture model just because it attracts a lot of arrows.

The real test is simple:

Can a team understand, build, test, and deploy a business change without first synchronizing with half the organization?

If not, the architecture isn’t autonomous. No matter how many services it has.

SOA rarely failed because of services. SOA failed because companies mistook centralized intelligence for architecture.

So anyone breaking apart a monolith in 2026 shouldn’t ask how many services come out of it.

They should ask how much business autonomy comes out of it.