Meet MOA - the new SOA
"Those who don't remember enterprise architecture are doomed to rebuild it." — Probably Santayana, if he'd worked at Oracle
There's a particular flavor of déjà vu that hits you when you've been in tech long enough. You're sitting in a conference talk titled "Building Composable AI Systems with the Model Context Protocol", and the speaker draws a box labeled Client connected to another box labeled Server, with a dotted line labeled Protocol between them, and your brain - uninvited, like a Spotify ad - starts playing the opening bars of the SOAP envelope spec from 2003.
Welcome to MOA - MCP-Oriented Architecture. The artist formerly known as SOA, now with vibes.
A Brief, Slightly Bitter History of SOA
In the early 2000s (for all you gen-z-ers out there), enterprise IT had a problem - hundreds of systems, none of which talked to each other, all written by people who had since fled to manage a vineyard in Sonoma. The solution, declared by men in pleated khakis at Gartner, was Service-Oriented Architecture - a beautiful dream in which every business capability would be exposed as a discoverable, loosely coupled, reusable service.
There would be an Enterprise Service Bus (the ESB - an internal Greyhound that nothing arrived on time on). There would be SOAP envelopes, WSDLs, UDDI registries - an alphabet soup so dense it could fortify a small village through winter. There would be governance committees. So, so many governance committees.
The vision was LEGO. The reality was IKEA furniture assembled in the dark by someone who skipped step 4.
SOA didn't die so much as it got rebranded. The cool kids escaped to microservices, dropped SOAP for REST, and pretended they'd never heard of an ESB. The boomer architecture went into the basement to live with Visio and the WS-* standards. But the ideas survived - discovery, contracts, loose coupling, composition - because they were good ideas. They were just clothed in bad XML.
Enter MOA
Fast-forward to late 2024. Anthropic releases the Model Context Protocol, an open standard for connecting AI models to tools and data sources. The pitch is genuinely good - instead of every AI assistant rebuilding the same integrations to GitHub, Slack, Notion, your filesystem, and the IRS, you write an MCP server once, and any MCP client - Claude, your IDE, your AI gurlfriend, your sentient teapot that returns code 418 over HTTP - can use it.
The metaphor that stuck was "USB-C for AI." Catchy, accurate-ish, and quietly suggestive of the same kind of vendor cartel agreement that produces actual USB-C. It worked. By 2026 there are MCP servers for everything. Want your LLM to control your espresso machine, query Snowflake, and post haiku to LinkedIn in the voice of your dead grandfather? There's a server. Possibly three, all incompatible in subtle ways. (Some things never change.)
This is the magucal world if MCP-Oriented Architecture we are living in. And if you squint, the org chart looks awfully familiar.
Where MOA and SOA Rhyme (Bob Dylan Voice)
Let's lay the cards on the table:
- Servers expose capabilities. SOA had services. MOA has tools, resources, and prompts. Different nouns, same vibe - "I do a thing; come call me about it."
- Discovery is a first-class concern. SOA had UDDI. MOA has registries and
list_tools. Neither has fully solved the problem of "how do I find the right one", which is the question that actually matters. - The protocol is the product. Both communities believe — with the conviction of a missionary at your screen door - that if everyone just agreed on the wire format, integration hell would end.
- There will be an Enterprise Bus. Mark my words. Someone, right now, is building "Enterprise Context Bus" and pitching it to a Fortune 500 CTO who still has a BlackBerry in his desk drawer for sentimental reasons.
- The diagrams look identical. Same boxes. Same arrows. A cloud labeled "the model" where SOA used to write "the ESB." Replace every MCP slide in 2026 with an SOA slide from 2005 and change the fonts, and three-quarters of your audience would not notice.
It's giving Stranger Things - same haircut, new decade.
Where MOA Is Actually Different (No, Really)
Now, I don't want to be the guy at the party going "this isn't new, my dad invented this in COBOL" because something genuinely is different this time, and it's worth naming.
1. The consumer is intelligent. SOA assumed the client was dumb code written by a sober adult who read the WSDL, as any adult should. That's why SOA needed such rigid contracts - one misplaced angle bracket and the whole thing fell over like a Jenga tower at a frat house. MOA assumes the client is an LLM that can read your tool description in English, infer what you probably meant, and make a reasonable call even when your schema is mid. This is the move from "the protocol carries the meaning" to "the protocol carries enough hints that an intelligent reader figures out the meaning." It's the Matrix "I know kung fu" moment, but for API integration.
2. Composition happens at runtime, not design time. SOA composition was a JIRA ticket and a six-month BPMN diagram approved by a steering committee. MOA composition is "hey Claude, use the GitHub server, the calendar server, and the email server to schedule a review for the PR that's been open the longest". The orchestration layer is no longer a workflow engine designed by men named Geoff - it's a model improvising in real time, like jazz^1.
- Sometimes bad jazz^2.
- Some will say that is a core characteristic of jazz.
3. Context is the unit of value. SOA shipped operations. MOA ships context. The "R" in resources and the "P" in prompts aren't just function calls - they're the model's working memory, its dossier on the world. This is closer to Inception than to Web Services - a tool isn't a thing you invoke, it's a layer of reality you load.
4. The economics are different. SOA's customer was an enterprise architect with a five-year roadmap. MOA's customer is anybody with a [insert popular AI service of the month] subscription and a weekend. The bottoms-up adoption pattern looks more like the early web than enterprise middleware, and that changes everything about how the ecosystem will evolve. SOA was sold. MOA spreads.
My Take, Briefly and With Some Pessim(Real)ism
MOA will probably go through the exact lifecycle SOA did:
- Hype. "MCP changes everything."
- Over-engineering. a.k.a. "Introducing MCP-Gateway-Mesh-Federation v2, now with built-in identity broker."
- Disillusionment., a.k.a. "Why are there 47 servers for PostgreSQL and none of them works?"
- Quiet survival. - The good ideas get absorbed into something with a new name in 2032, and a 22-year-old will tweet (because that is how it will still be called in 2032) about how they invented it.
The interesting question isn't whether MOA will repeat SOA's mistakes - it will, because humans run this - but whether the intelligent client changes the equation enough that the protocol actually works this time. I think it does. Slightly. Mostly because LLMs can read documentation, which is something developers were never willing to do.
In the meantime, I'll be over here writing my MCP server for make_tea(), watching with mild amusement as someone reinvents the ESB and calls it a "context fabric".
It's pronounced déjà vu, dear. We've been here before. The Avengers are just dressed differently this time - and one of them is the model itself.