Enterprise Architecture in the Age of Cloud and AI

For decades, enterprise architecture operated on assumptions that rarely needed questioning: predictable infrastructure, measured release cycles, centralized control. These weren’t weaknesses: they were rational responses to the environment that existed. The discipline built itself around stability.

Cloud and AI have quietly dismantled that foundation. Not through disruption in the dramatic sense, but through a constant demolition of the conditions EA was designed for. Teams now deploy independently, often without coordinating with a central function. Infrastructure is provisioned and discarded in hours. Data products evolve on timelines that architectural review cycles were never built to match.

The instinct, at this point, is to declare EA obsolete. Based on my personal point of view, I don’t think that’s right: I’ve seen what happens when organizations act as if it is. What happens is something, maybe, predictible: governance collapses. Technical debt accumulates invisibly and strategic coherence gives way to a patchwork of local decisions that nobody owns.

The problem isn’t the discipline. It’s the operating model behind it.

Static models, that could be considered boring but they maintained diagrams were designed for environments where decisions could wait. But unfortuntely, as you like it or not, that environment is gone. What remains is a continuous stream of consequential choices made at speed, often below the threshold where traditional architecture ever engaged.

Architecture, then, has to move. Not to abandon rigor, but to embed it differently: closer to the point of decision, faster in its feedback loops, more comfortable with incomplete information. Less documentation, more continuous judgment.

That’s a harder thing to build than a framework. It requires people who can hold both the technical and the strategic simultaneously and organizations willing to rethink where architectural authority actually lives.

That shift is what this series is about.

Based on my personal experience, the most persistent misconception I encounter is that architecture is something you produce. A diagram. A reference model. A set of standards committed to a shared drive and reviewed annually. In practice, these artifacts matter far less than the decisions they’re supposed to inform: it seems a solid and qualified ecosystem but in fast-moving organizations, the gap between the two has become impossible to ignore.

What architecture actually needs to do is guide judgment at the point where judgment is exercised. That means being present as a shared frame of reference that teams can apply without waiting for a central function to weigh in.

In practical terms, this requires four things to be explicit and well-understood across the organization: what good looks like in a given context; which trade-offs are acceptable and under what conditions; where teams have genuine autonomy to decide; where consistency is non-negotiable (and why).

That last qualifier matters. “Non-negotiable” without explanation generates workarounds. With explanation, it becomes a design constraint that teams can reason around intelligently.

The underlying shift here is from control to clarity. These sound similar. They aren’t. Control concentrates decision-making; clarity distributes it. Control creates bottlenecks in the name of quality, on the other side clarity enables speed without sacrificing coherence.

I’ve worked with organizations that confused the two for years (but I understand that): the approach seems on one side strange, on the other side natural for that kind of companies: investing in governance structures that slowed delivery without meaningfully improving outcomes. The architecture function was visible, but its value wasn’t. Decisions still got made; they just got made around it.

When the boundaries are clear and the reasoning behind them is legible, teams don’t need permission. They need orientation. That’s a fundamentally different thing to design for.

The scale problem in modern architecture isn’t complexity in the abstract: i prefer define it like the surface area in the concrete. A major cloud provider (like Google, AWS or similar ones) now offers hundreds of distinct services. Data platforms release meaningful changes on weekly cycles. AI models are shifting the economics of automation and decision support faster than most governance structures were designed to respond.

Each of these, in isolation, is manageable. Together, they create an environment where the number of consequential architectural choices has expanded by an order of magnitude. On the other side, the cost of making those choices poorly is no longer contained to a single system or team.

What I see most often isn’t reckless decision-making. It’s well-intentioned local optimization. A team selects the right tool for their context, makes a reasonable call on data ownership, deploys a model that performs well within their scope. Everything seems great at this stage, don’t you think too? But the problem surfaces later, at the integration points: when coherence is needed and nobody designed for it.

This is where architecture has to be specific. Not in the form of exhaustive standards, but in terms of four areas where ambiguity is genuinely expensive:

• cloud service boundaries and what determines them
• data ownership and lineage, particularly as products are shared across domains
• AI governance and how model lifecycle decisions get made and reviewed
• integration patterns for systems that were never designed to work together.

Getting these right doesn’t mean imposing uniformity. Some variation is not only acceptable but I can consider it completely correct. Different domains have different requirements and pretending otherwise produces architecture that looks consistent on paper and fractures in practice.

That distinction, between variation by design and variation by default, is where coherent architecture begins.

Early in my advisory work, I encountered a pattern so common it had become invisible to the organizations living inside it: an architecture function that was formally respected and practically bypassed. The diagrams existed. The review process existed. And yet, by the time a design reached the architects, the real decisions had already been made. The review had become a ritual: necessary to complete, irrelevant to the outcome.

The problem wasn’t the people. It was the position. Architecture had been placed outside the flow of work, which meant it could only react to decisions rather than shape them.

Changing that requires more than goodwill. It requires architecture to be present at the moments that actually matter: when product strategy is being set, when quarterly priorities are negotiated, when funding is allocated, when technical designs are reviewed before commitments harden, when data governance decisions establish patterns that will compound for years.

These aren’t architecture meetings. They’re the meetings where architectural choices get made whether architects are in the room or not. The question is whether those choices are made with intent.

When architects operate as partners in these conversations: based on my experience they bringing a view of consequences, trade-offs and second-order effects; for sure, what I see is that they can change the quality of the decision without slowing it down. On the other side, when they operate as gatekeepers, they add friction without adding value: a scenario where teams learn to route around them.

The distinction comes down to what the architect is optimizing for. The difference I think it’s quite simple to explain: a gatekeeper protects a standard, a partner protects an outcome. I can assure that both care about quality: but only one is aligned with how delivery actually works.

Speed and coherence are not in tension. They become compatible when architecture is embedded early enough to inform the work, rather than arriving late enough only to audit it.

Redesigning an architecture function is rarely the hard part. The harder part is designing one that doesn’t gradually revert, that doesn’t accumulate process until it resembles exactly what it replaced.

The operating models I’ve seen hold up over time share a common characteristic: they’re built around mechanisms, not meetings. Lightweight, repeatable structures that embed judgment into the organization rather than concentrating it in a single function.

In practice, this means five things working in combination:

• Principles that are specific enough to guide real decisions: not values statements, but reasoned positions on trade-offs that teams can apply without interpretation
• Guardrails that define the edges of acceptable variation, making fragmentation visible before it becomes structural
• Decision records that capture not just what was decided, but why in a way that allow to create a trail of reasoning that survives personnel changes and serves as institutional memory
• Domain ownership aligned with product teams, so architectural accountability sits with the people closest to the work, not in a separate function reviewing it from a distance
• Review rituals calibrated to surface coherence issues early, without adding the kind of overhead that trains teams to treat governance as an obstacle

None of these elements have to be isolated in the company. What matters is how they interact. What i saw in my experiences is that:

• Principles without guardrails produce inconsistency
• Guardrails without domain ownership produce compliance theater
• Decision records without review rituals accumulate without being read

The goal is a system that evolves alongside the business: that can absorb change without requiring constant redesign and that distributes architectural judgment broadly enough to scale.

That’s a different ambition than maintaining a canonical architecture document. The organizations that have gotten this right treat architecture less as a function to be resourced and more as a capability to be built: distributed, durable and embedded in how the work gets done.