AI Can Actually Do in Enterprise Architecture

Every business wants AI in everything. Every transformation now has “AI-enabled” in the business case. Every stakeholder meeting includes the question: “But what about AI?”

There seems to be an omnipresent expectation to integrate AI or adopt AI in everything. The expectation that architects will somehow make everything “AI-powered” is growing. But here’s what nobody’s talking about: most organizations, including architecture teams, are still figuring out where AI actually helps and most importantly how to apply the various AI tools at our disposal to generate value.

Architecture is no different. Architects are actively experimenting with AI across the solution definition lifecycle – some areas showing genuine promise, others needing more work. Learning what works, what doesn’t, and where to be more creative in actually using the tools.

This isn’t a prescriptive guide on how to use AI in architecture. This is an honest reflection on what I’m seeing – where AI is delivering value, where it’s still experimental, and where human architectural judgment remains irreplaceable.

Consider this Part 1.

Approaching AI in Architecture

The question isn’t whether AI will change architecture work – it already has. The question is where and how it adds genuine value for architects doing architecture versus just using Copilot for email drafts and Teams meeting summaries.

This requires pragmatism and focus on outcomes. Not adopting AI because we should, but experimenting to find where it actually improves outcomes – faster design, better analysis, clearer communication, more thorough reviews.

This experimentation spans the solution definition lifecycle: requirements analysis and extraction, solution design and options generation, documentation and stakeholder communication, architecture reviews and validation. Some areas are showing clear wins. Some are promising but need more work. But almost all have revealed that AI simply can’t replace the architectural judgment that comes from experience. Yet. Having an experienced architect at the controls is crucial to drive context-focused outcomes.

What follows is an honest assessment of what I have observed so far – what’s working, what’s experimental, and why the people aspect needs consideration.

Where AI Actually Helps (When Architects Stay in Control)

I have seen genuine value in specific applications across the solution lifecycle. But every area where AI helps comes with a critical constraint. An experienced architect must remain at the controls. The value comes from augmentation, not automation.

Shaping Ambiguous Conversations

When working with product or business teams in pre-inception stages – those early, ambiguous conversations where the problem isn’t fully formed – AI models like Claude Sonnet help crystallize thought processes and shape discussions. Feed the model the fragments of conversation, the half-formed requirements, the competing stakeholder perspectives, and it helps structure thinking in ways that influence the next conversation productively.

But this only works when the architect drives the crystallization. The architect’s opinions, constraints, and context become the inputs. Without this, the model hallucinates solutions disconnected from organizational reality. Maintaining focus on the actual problem being solved – not the problem the AI thinks should be solved – remains the architect’s responsibility.

This delivers faster convergence on what’s actually being built, but only when the architect establishes the constraints and controls the inputs and validation.

Accelerating Requirements Analysis

Where requirements exist – even partially – AI models accelerate analysis within the context of the program problem statement. The model can analyze requirements, identify gaps, surface inconsistencies, and generate questions that drive clarity faster than manual analysis alone.

This is powerful but dangerous. The model has a tendency to fill gaps in understanding rather than just highlighting them. It wants to provide answers, not just questions. The architect must restrain this – using AI’s gap identification to drive clarity and confirmation from the business, not as a proxy for the product team’s thinking.

This accelerates gap analysis and question generation, but AI has a tendency to fill gaps rather than expose them. Architects must maintain accountability with the business for requirements definition, ensuring AI doesn’t become a substitute for actual stakeholder engagement.

Producing Architecture Artifacts

Architects routinely write solution documents, architecture strategies, domain definitions, entity models – the artifacts that capture and communicate architectural thinking. AI models are adept at producing these outputs at pace, generating first drafts, structuring content, and formatting documentation faster than manual creation.

This productivity gain is genuine, but it comes with a critical requirement. The architect must remain at the controls to ensure inputs and outputs are true to organizational context. The models will happily generate fanciful solutions or strategies that sound architecturally elegant but are completely disconnected from the reality on the ground – the legacy constraints, political dynamics, budget limitations, and organizational capacity that determine what’s actually feasible.

This delivers significantly faster artifact production, leaving architects to focus on nuanced conversations and navigating the messy middle where architecture actually happens. But architects must ensure outputs represent organizational reality, not theoretical ideals disconnected from what can actually be built.

Where Experimentation Continues

Some applications show promise but aren’t proven yet – learning what works, what doesn’t, and where the boundaries of practical application are still evolving

Codifying Architecture Guardrails

I believe Codifying architecture guardrails could be one of the most significant value generators from AI in architecture work. This would allow teams to establish specific sets of guardrails nuanced and relevant to their organization, technology estate, teams, skillsets and historical context – not generic frameworks that ignore organizational reality.

If these guardrails become the bedrock of architecture definition, the biggest value addition shifts. Manual review, debates, and decision making get significantly streamlined. Architects spend less time debating decisions & catching basic inconsistencies and more time on the nuanced conversations that actually require human expertise and architecture judegement.

But this requires governance for the guardrails themselves. Eventually, architects may end up managing the guardrails rather than reviewing every artefact manually. The guardrails would help automate solution definition and simplify decision-making processes – if they’re codified correctly.

The challenge is codifying guardrails that allow for practical and realistic application. Capturing the nuanced judgment experienced architects apply – organizational context, political realities, the “this will never fly because…” knowledge – doesn’t fit neatly into rules. Technical consistency is codifiable. Architectural wisdom based on organizational reality is harder.

From Guardrails to Automated Artefacts

Once guardrails are established, they become the foundation for automating solution artifact creation. Feed AI the program context, business drivers, solution impacts, and organizational guardrails, and it can generate architecture vision documents or solution definitions aligned to both templates and organizational constraints.

Every project is different. Solution impacts vary. Program context changes. Improving productivity for artifact creation without producing generic documents that miss the specific nuances making solution architecture useful for decision-making becomes the critical challenge.

AI can produce structurally correct documents quickly when given clear guardrails. Whether those documents capture the actual architectural thinking required for specific context remains inconsistent. Understanding where templating helps versus where it obscures real architectural decisions continues to evolve.

What About Governance?

If guardrails enable artifact automation, the next question is lifecycle management. Architects would need to manage not just the guardrails, but the lifecycle of artifacts generated from those guardrails. The governance challenge compounds – governing the guardrails that govern the artifacts that drive solution definition.

The appeal is significant: a self-improving system where guardrails refine based on outcomes, artifacts auto-update based on context changes, and architects focus on judgment rather than production. But how do you prevent what always happens – introducing bureaucracy in the name of control and governance, slowing everything down instead of enabling speed? How do you ensure guardrails don’t calcify into the very red tape they’re meant to eliminate?

This is complex work – and potentially the most transformative for architects if it succeeds.

The People Aspect

The technical challenge of applying AI to architecture work is real, but it’s not the hardest part. The harder challenge is adoption across a diverse team with varying levels of expertise and mix of skillset – each with different comfort levels, skepticism, and natural affinity for these tools.

Some team members take to AI naturally, experimenting freely. Others are more skeptical about the benefits, questioning whether the productivity gains are worth the risk of oversimplification or loss of architectural nuance. Both perspectives have merit.

Honouring the wisdom and experience that seasoned architects bring while embracing the speed, productivity, and efficiency gains the tools offer is the balance we need to strike. The architects with decades of experience have judgment that AI can’t replicate. Yet. But the tools can accelerate the expression of that judgment in ways that compound their impact.

It’s becoming clear that this isn’t a question of whether to adopt AI in architecture work. The technology and the tools have crossed a point of no return. The question is whether architects choose to embrace these tools proactively and shape how they’re applied, or whether they’re forced to adapt reactively as AI becomes table stakes for architecture work. The march of capability is relentless, and there’s only one direction it’s heading.

Those who learn to augment their architectural judgment with AI will outperform those who don’t – not because AI is better at architecture, but because the combination of human judgment and machine acceleration creates leverage that only human effort can’t match.

Part 1: Still Learning, Still Experimenting

This is where we are right now – seeing genuine value in specific applications, learning and experimenting in promising areas, and navigating the people challenges of adoption.

Are there areas where AI fundamentally won’t work? I don’t believe there are any. What I am observing are two consistent patterns – it’s a matter of figuring out how to apply AI effectively, not whether AI can be applied at all. And it is crucial that the architect be at the controls driving the tools.

Consider this Part 1 of an ongoing conversation.