Enterprise Architecture in the AI Era

The role is shifting

Enterprise architects have spent the last two decades focused on integration -- connecting systems, managing APIs, rationalizing application portfolios, ensuring data flows between departments. That work isn't going away, but it's getting a new layer on top.

AI introduces concerns that traditional enterprise architecture frameworks weren't built for. Where does training data come from, and who's responsible for its quality? How do you version and deploy models across environments? Who decides when an AI system's output is trustworthy enough for production decisions? These are architecture questions, but they don't fit neatly into existing patterns.

The enterprise architect's job is evolving from "how do we connect these systems" to "how do we govern, scale, and trust AI across the organization."

New concerns on the table

Model lifecycle management is the first thing that catches architects off guard. Models aren't like traditional software -- they degrade over time as data distributions shift. You need a lifecycle that covers training, validation, deployment, monitoring, retraining, and retirement. This means infrastructure for experiment tracking, model versioning, A/B testing in production, and automated retraining triggers.

Traditional change management processes don't account for models that need to be retrained monthly. The architecture needs to support frequent, safe updates without the heavyweight release processes that enterprises typically use.

Data lineage for AI goes beyond traditional data governance. You need to know not just where data is and who owns it, but specifically which data was used to train which model, what transformations were applied, and whether the training data still represents the real world. When a model makes a bad prediction, you need to trace it back to the data that shaped its behavior.

This is especially important for regulated industries. If an auditor asks why your loan approval model rejected an applicant, "it's a neural network" isn't an answer. You need lineage from the decision back through the model to the training data and the features that drove the prediction.

Responsible AI frameworks are no longer optional. Bias detection, fairness metrics, explainability requirements, and human oversight mechanisms all need to be architected into the system, not bolted on afterward. The architect's job is to define where these checks happen, who reviews them, and what happens when a model fails a fairness test.

The enterprise AI stack

Most organizations are converging on a layered stack, even if they don't call it that.

Data platform sits at the bottom. This is your data lake, data warehouse, or lakehouse -- Snowflake, Databricks, BigQuery, whatever. The key requirement for AI is that it supports both analytical queries and the large-scale data access that training pipelines need. Data quality monitoring belongs here too.

Feature store bridges the gap between raw data and model inputs. It computes, stores, and serves features consistently for both training and inference. Without this, every team computes features differently, and you get inconsistency between what models were trained on and what they see in production.

Model registry is your version control for models. Every trained model gets registered with its metadata -- who trained it, on what data, with what hyperparameters, what its evaluation metrics look like. Think of it as an artifact repository specifically for ML. MLflow, Weights & Biases, and SageMaker Model Registry are common choices.

Serving layer handles inference. This ranges from simple REST endpoints for low-throughput use cases to optimized serving frameworks (Triton, TensorRT, vLLM) for high-throughput or latency-sensitive workloads. The architecture needs to support multiple serving patterns -- synchronous request-response, batch inference, and streaming.

Monitoring layer watches everything. Model performance (is accuracy drifting?), data quality (are input distributions changing?), infrastructure health (are serving latencies acceptable?), and business impact (are AI-driven decisions producing the expected outcomes?). This is where most organizations are weakest.

Adapting traditional frameworks

TOGAF and Zachman weren't designed for AI, but they're not useless either. They need adaptation rather than replacement.

In TOGAF's Architecture Development Method, AI adds new concerns to every phase. Business Architecture now includes AI use case prioritization and ROI frameworks. Data Architecture now covers training data management and feature engineering. Technology Architecture now includes GPU infrastructure, model serving, and MLOps tooling. The gap most teams miss is in the Opportunities and Solutions phase -- evaluating build-vs-buy for AI capabilities, which is a different calculus than traditional software.

Zachman's "what, how, where, who, when, why" framework extends naturally. "What" includes models and training data alongside traditional data entities. "How" includes training pipelines and inference workflows. "Who" includes new roles -- ML engineers, data scientists, AI ethics reviewers.

The adaptation that matters most: both frameworks assume relatively stable artifacts. Enterprise systems change quarterly or annually. AI systems change continuously -- models retrain, data distributions shift, new use cases emerge. The architecture practice needs to become more iterative, closer to how platform teams work than how traditional EA functions operate.

The AI governance challenge

Governance is where enterprise architects can add the most value, because nobody else in the organization is positioned to do it.

You need answers to questions like: Which teams are allowed to deploy models to production? What evaluation criteria must a model pass? How is access to training data controlled? What happens when a model underperforms? Who approves the use of AI in customer-facing decisions?

The governance model should be lightweight enough that teams can move fast but structured enough that the organization isn't exposed to unnecessary risk. A heavy approval process that takes six weeks kills AI adoption. No process at all leads to models in production that nobody understands, nobody monitors, and nobody can explain to a regulator.

The sweet spot is a tiered approach. Low-risk use cases (internal tools, analytics, content drafts) get a light-touch review. High-risk use cases (credit decisions, medical recommendations, automated hiring) get a thorough review with bias testing, explainability requirements, and ongoing monitoring commitments.

The skills gap

Here's the uncomfortable reality: most enterprise architects don't have the technical depth in ML/AI to do this work well yet. Understanding system integration patterns doesn't automatically translate to understanding model training pipelines, feature stores, or GPU infrastructure.

What architects need to learn is not how to train models -- that's the ML team's job. It's how the pieces fit together. What does a healthy MLOps pipeline look like? What are the failure modes of model serving at scale? How do feature stores work and why do they matter? What does model monitoring actually measure?

The architects who succeed will be the ones who invest in understanding the AI stack at an architectural level -- not as practitioners, but as people who can ask the right questions, spot the gaps, and design systems where all the pieces work together.

The ones who treat AI as "just another technology" and try to govern it with existing processes are going to struggle. AI has fundamentally different characteristics than traditional software -- it's probabilistic, it degrades over time, it depends on data quality in ways that deterministic systems don't, and it introduces fairness and bias concerns that have no equivalent in traditional architecture.

Where to start

If you're an enterprise architect figuring out where to begin: start with governance and the data platform. Governance because the organization needs guardrails before AI proliferates, and data platform because every AI capability depends on having good data infrastructure.

Don't try to build the full stack at once. Pick one high-value use case, build the end-to-end pipeline for it, and use that experience to inform the broader architecture. The patterns you discover in practice will be more useful than any reference architecture you could design in theory.