Tech blog about all that is architecture

Category: Uncategorized

The Phoenix Project Missed One Role: The Architect

⚙️ Introduction

AI isn’t coming to the enterprise — it’s already here. But too often, it’s duct-taped to the edges of legacy systems, used tactically instead of strategically. <!–more–> For Enterprise Architects, the challenge is clear: how do we treat AI as a core capability, not an isolated tool?

This post outlines how to frame AI as an architectural concern, and where it fits in the modern EA blueprint.


🧩 Why AI Belongs in the EA Stack

Traditionally, EA has revolved around layers: business, application, data, and technology. But AI disrupts this model. It isn’t just a service or a tool — it’s a cross-cutting capability that touches:

  • Business models (autonomous decision-making)
  • Data pipelines (model training, real-time feedback loops)
  • Infrastructure (GPU clusters, edge compute, model inferencing)
  • Governance (ethics, explainability, regulatory frameworks)

As such, AI should be treated as a first-class concern in your EA metamodel — not tucked away under “advanced analytics.”


🛠️ How to Architect for AI

1. Add an AI Capability Layer

Introduce a dedicated layer or viewpoint in your architecture that explicitly represents:

  • ML/AI platforms (e.g. AWS SageMaker, Azure ML)
  • LLM orchestration tools
  • Data/model lineage tracking
  • Prompt engineering and knowledge retrieval pipelines

2. Treat Models as Assets

Architectural repositories need to version-control and govern ML models like source code. Use tools like MLflow or ModelDB, and design pipelines for:

  • Training
  • Validation
  • Deployment
  • Monitoring

3. Enable MLOps with EA Discipline

MLOps is chaotic without guardrails. EA can bring:

  • Platform standardization
  • Deployment governance
  • Data privacy and compliance baked into the flow

4. Rethink Decisioning Systems

With AI in the loop, decision flows need to be re-modeled:

  • When should AI recommend vs. act?
  • What escalation paths exist when confidence is low?
  • How does explainability factor in?

🔍 Case-in-Point: Prompt Pipelines

With the rise of LLMs, prompt engineering is becoming an architectural domain. You need to model:

  • Where prompts are generated
  • What context/data they include
  • How outputs are filtered, validated, or logged

This introduces “PromptOps” as an architectural consideration.


🚧 Challenges & Watchpoints

  • Shadow AI: Business units bypassing architecture to deploy AI tools — fast but fragile.
  • Ethics-as-a-Service?: You’ll need architecture patterns for audit trails, fairness checks, and consent frameworks.
  • Architect fatigue: Teams overloaded by the tooling sprawl. Your job is to curate, not just catalog.

💡 Final Thoughts

As AI reshapes how we build, operate, and govern technology, enterprise architecture must evolve. It’s not just about drawing the boxes — it’s about designing the brains that run them.

And the role of the architect?
Not just strategic… decisively intelligent.


👇 What’s Next?

Want the reference model I use for AI capability mapping? Drop me a message.

In the next post, I’ll explore PromptOps as an architectural pattern