I’ve Seen This Movie Before

Years ago, we called it Service-Oriented Architecture. Before that, distributed computing. Before that, object-oriented decomposition and separation of concerns. The vocabulary shifts every few years, but the business question keeps coming back wearing a different hat:

That was the problem then. It’s still the problem now.

When I updated my old SOA Right Away material to map it against today’s AI architecture conversations, the correspondence was almost embarrassing. Standardized service contracts became tool schemas and MCP specs. The Enterprise Service Bus became the AI orchestrator. UDDI service registries became agent registries. Loosely coupled components became model-agnostic interfaces.

The patterns from GRASP — General Responsibility Assignment Software Patterns — and classic OOP didn’t disappear. They just got rebranded.

The reason so many AI workflows feel needlessly complex right now is that teams are rebuilding the same solutions to the same problems without recognizing the map they already have. This is one of the core tensions between business architecture, enterprise architecture, and development: each layer tends to rediscover the wheel rather than inherit the lessons above it.

---

The Hype Cycle Is Not New. But AI Made It Worse.

Here’s a pattern that repeats in IT every few years: a new technology arrives, the industry loses its mind, and suddenly every interview, every team standup, and every conference talk becomes a trivia contest about tooling.

We’re deep in that cycle right now.

Instead of asking what business problem are we actually solving, conversations devolve into debates about which orchestration framework to use, which model won the latest benchmark, or whether you’re current on whatever was released four Tuesdays ago. The stack changes so fast that even experienced engineers feel behind — and that anxiety drives people toward tool mastery instead of problem clarity.

This has always been a challenge in IT. But AI made it significantly worse for two reasons.

First, the tooling changes faster than any previous cycle. Not annually. Not quarterly. Sometimes weekly. Second — and this is the part people aren’t saying loudly enough — AI has made it easier than ever to generate code without understanding the problem underneath it.

We used to call it copy-paste coding. You grabbed something from a book, a forum, or a blog post, dropped it in, and shipped it. The code worked, mostly, but no one could tell you why. Now we call it vibe coding. The delivery mechanism changed. The temptation didn’t.

---

Coding Is No Longer the Bottleneck. That Should Terrify You.

Here’s the part that doesn’t get said in polite company: writing code used to be the candy.

You sat through the ambiguous requirements meetings, tolerated the ticket backlog, dealt with the organizational friction — and eventually you got to the fun part. You got to build. That reward loop kept a lot of engineers motivated through everything else.

AI just took a big bite out of that reward.

The model can write most of the code for you now. Which means code is rapidly becoming what it probably should have been in many contexts all along: a black box hidden behind a contract.

But here’s the critical difference. AI-first programming works only if you can articulate the business problem clearly before you generate a single line of code. It requires product requirement documents. System architecture definitions. Clear thinking about what a service is supposed to do, what its inputs and outputs are, and where the boundaries live.

That work was always necessary. But it was easy to skip because you could just start coding and figure it out along the way. That shortcut is closing.

---

The Real Obstacle to AI Adoption Nobody Is Talking About

There’s a question underneath all of this that most AI conversations never reach:

Not in a philosophical sense. In a documented, operational sense.

Do you have your workflows mapped? Your value streams identified? Your capabilities defined? Do you know which of your processes are deterministic — rules-based, repeatable, automatable — and which are stochastic, requiring judgment, context, and human discretion?

Most organizations don’t. Not because the work isn’t important, but because it was never required to ship software. You could build around the gaps, paper over them with tribal knowledge, and move on.

AI doesn’t let you do that.

To deploy an AI system that reliably executes a business process, you have to be honest about what that process actually is. You have to separate the parts that follow rules from the parts that require judgment. You have to define the contract before the model can honor it.

That is hard work. It’s not glamorous. It doesn’t come with a cool GitHub repo or a demo you can post on LinkedIn. But it is now the work.

This is the real obstacle to enterprise AI adoption — not model quality, not compute costs, not security concerns. It’s the fact that most organizations haven’t documented their standard work well enough to automate it cleanly. The old SOA material I’ve been updating put it plainly: the risk in tactical, project-by-project approaches is duplicate investments, incompatible infrastructure, and brittle solutions. That warning landed in 2008. It lands just as hard today.

---

What This Means for IT Leaders and Architects

If you’re a CIO, CTO, or enterprise architect, the AI conversation in your organization isn’t primarily a technology decision. It’s an architectural honesty question.

Before you invest in another model, another platform, or another proof of concept, ask four questions:

• Do your teams understand the business problem well enough to define the contract before touching the code?
• Have you mapped which processes are rules-based and which require judgment?
• Do you have value streams and capabilities documented at a level where an AI system could act on them reliably?
• Are your architects and engineers being evaluated on problem-solving — or on tooling trivia?

If the answers are uncomfortable, that’s useful information. The AI conversation is premature until the architecture conversation happens first.

---

The Shiny Nouns Will Keep Changing

SOA became microservices. Microservices became serverless. Serverless became AI-native. The vocabulary will keep shifting.

But the underlying question — how do we build modular, reusable, loosely coupled systems that align to what the business actually needs — has not changed and will not change.

The teams that recognize that pattern will stop chasing every new framework and start building the architectural foundation that makes any framework work.

That’s what SOA Right Away was about when it was written. It’s what the updated SOAi framing is about now.

---

Tags: #AIArchitecture #SOA #SOAi #EnterpriseAI #AIFirstProgramming #VibeCoding #ContractFirst #BusinessArchitecture #ITLeadership #AIAdoption #GRASP #OOP

Software development is going through a fundamental transition.

On one side, people believe AI will replace developers.
On the other side, people believe nothing will change.

Both perspectives miss what’s actually happening.

The role of the architect is evolving.

For most of the history of software engineering, the workflow looked like this:

Problem → Architecture → Developers implement → System runs

The architect defined the system.
Developers translated the design into code.

Today, something significant has changed.

AI can now generate large portions of the implementation — which means the translation layer between architecture and code is shrinking.

Instead of this:

Architecture → Developers → Code

We are starting to see this:

Architecture → AI → Code

This doesn’t eliminate developers.
But it changes where the leverage sits.

The bottleneck in software development is no longer writing code.
It’s designing systems clearly enough that the code can be generated correctly.

In many modern AI projects, the most important artifact is no longer the code repository.
It’s the System Architecture Document — the SAD.

The SAD defines:

• System boundaries
• Component contracts
• Schemas and data flows
• Orchestration patterns
• Governance and telemetry

Once those are defined clearly, AI can generate much of the implementation.

---

What this looks like in practice

We recently shipped a voice AI platform running 14 independent AI assistants — each serving a different business vertical — from a single production environment. Restaurant reservations. Loan origination. Homecare coordination. Legal intake.

No two assistants share code. But they all share architecture.

Before a single line was generated, we defined session boundaries, API contracts, capacity pools, and orchestration rules in a System Architecture Document. That document governed how every assistant requested a voice session, how capacity was allocated across user tiers, and what happened when a session ended — release the slot, report usage, reset state.

The orchestration layer — what we call the Capacity Orchestrator — became the most important component in the system. Not because it was the most complex to build, but because it was the most precisely specified. The SAD told AI exactly what to generate. The result was a platform that scales across verticals without breaking isolation between them.

That’s the pattern. Precise architecture. Generated implementation. Governed at runtime.

---

The second shift: architects as governors

But a second responsibility is emerging for architects.

AI systems introduce intelligence into the architecture itself.

Agents make decisions.
Recommendation engines influence behavior.
Models adapt over time.

This means architects are no longer just designing software systems.
They are designing systems that make decisions.

And those systems require governance. Observability. Guardrails.

The architect is no longer just a system designer.
The architect is now a governor of intelligent systems — responsible for ensuring that:

• AI components behave within defined boundaries
• Systems remain observable and auditable
• Complex workflows remain coherent

---

Ironically, the rise of AI is pushing software development back toward something architects have always known.

Code is not the system.
Architecture is the system.

AI is simply changing how that architecture becomes reality.

The architects who understand that shift won’t just adapt to the next generation of software.

They’ll design it.

---

Interested in how modular AI orchestration works in practice? Explore the SkillBots.AI platform at SkillBots.ai.

Tags: #AIArchitecture #SystemDesign #SADVibeCode #AIGovernance #VibeCoding #OpenAI #SkillBotsAI #EnterpriseAI #ProductManagement #SoftwareArchitecture