01
Start with the decision.
Before creating another artifact, understand what someone is trying to decide. The model should serve the conversation—not the other way around.
Practical enterprise architecture for people doing the work
Make complexity easier to see.
Enterprise architecture deals with complicated things. That doesn't mean the way we explain them has to be complicated too.
The Visual Enterprise Architect is a collection of practical thinking, visual tools, and lessons from doing enterprise architecture in the real world. It's for architects and technology leaders who want their work to be understood and, more importantly, used.
Because the value of enterprise architecture isn't in the artifact.
It's in the decision the artifact helps someone make.
Featured Thinking
How much authority are we actually giving AI?
AI adoption isn't just about what the technology can do anymore. An equally important question is what we're allowing it to do on our behalf.
As AI moves from answering questions to recommending decisions, initiating work, and acting with greater independence, traditional ways of talking about automation start to fall short.
That's why I created the AI Authority Ladder—a practical way to describe increasing levels of AI authority and create a common language for conversations about autonomy, decision rights, governance, risk, and accountability.
PAPER 01 · PUBLISHEDThe AI Authority Ladder
A practical framework for deciding what AI should be allowed to do — Assist, Recommend, Decide, or Act.
Read the paper →
The right authority for the right work.
A Different Way to Practice EA
Architecture should make the decision clearer.
Enterprise architecture has no shortage of frameworks, models, repositories, standards, diagrams, and governance processes. Those things can be valuable. But producing them isn't the goal.
The goal is to help an organization understand what it has, where it's going, what needs to change, and what decisions have to be made along the way.
02
Make the relationships visible.
Applications don't exist in isolation. Neither do capabilities, data, platforms, infrastructure, investments, risks, or AI agents. Architecture becomes useful when people can see how those things connect.
03
Make tradeoffs understandable.
Most architecture decisions involve cost, risk, value, timing, complexity, and competing priorities. Good architecture makes those tradeoffs easier to see.
04
Connect strategy to action.
A future-state diagram isn't transformation. Architecture has to help translate direction into priorities, roadmaps, investment decisions, and work.
05
Build what people will use.
A beautifully designed architecture artifact that nobody comes back to isn't particularly valuable. Sometimes the right deliverable is a sophisticated model. Sometimes it's a one-page drawing that finally gets everyone talking about the same problem.
The test is whether it helps.The Toolkit
Built for the work.
Some ideas are useful to read about. Others become much more useful when you can pick them up and try them. The Toolkit is where I'm collecting the frameworks, canvases, worksheets, diagrams, and workshop approaches I use to make architecture conversations more productive.
FRAME
Turn a complicated problem into something people can understand and discuss.
ASSESS
Understand what you have, what matters, and where attention is needed.
DECIDE
Make options, dependencies, risks, and tradeoffs visible.
ROADMAP
Connect architecture decisions to priorities and movement.
GOVERN
Create enough structure to keep architecture connected as the organization changes.
Use what helps. Adapt what doesn't.
These aren't intended to become another methodology an organization has to implement. They're tools for doing the work.
Field Notes
Things I'm seeing in the work.
Not every useful observation needs to become a framework or a 20-page white paper. Field Notes are shorter thoughts about patterns I keep seeing, questions organizations are wrestling with, approaches that work, and things I think enterprise architects should be paying attention to.
When an AI agent becomes part of the architecture
If an autonomous agent performs work across multiple systems, who owns it—and where does it belong in the architecture?
Your application inventory isn't portfolio intelligence
Knowing what applications you have is useful. Knowing what decisions you should make about them is something different.
The CMDB isn't the architecture
A CMDB can provide critical technology context, but expecting it to answer every architecture question creates problems of its own.
Governance doesn't need another meeting
Good governance isn't about creating more approval gates. It's about making it clear who gets to make which decisions, using what information.
What's Changing
Enterprise architecture is changing with the enterprise.
Cloud changed what architects needed to understand. Platforms changed it again. Product operating models blurred traditional boundaries between business and technology. AI may change the practice more fundamentally than any of them.
We're entering an environment where software won't simply support work. Increasingly, it will participate in the work—interpreting information, making recommendations, coordinating activities, taking actions, and learning from the people around it.
What is an AI agent in the enterprise architecture? Who owns it? Who is allowed to train it? How much authority should it have? How do we rationalize an autonomous workforce?Those are architecture questions.
From the Visual EA Library
Go deeper when you need to.
The Visual EA Library brings together longer-form thinking, guides, papers, and other resources that explore these ideas in more depth.
PAPER 01 · PUBLISHED
The AI Authority Ladder
A practical framework for deciding what AI should be allowed to do, with a take-it-with-you assessment worksheet.
Read the paper →BOOK
The Visual Enterprise Architect
Many of the ideas behind this site are also being collected into a book about practicing EA in a way that is visual, practical, and connected to decisions.
About the book →COMING NEXT
Managing AI Agents in Enterprise Architecture
What happens when autonomous agents become part of the enterprise landscape—and how EA needs to adapt.
Coming soonAbout the Practitioner
This comes from doing the work.
I'm Jennifer Scarlato, an enterprise architecture and technology strategy practitioner. I've spent my career working with organizations trying to make sense of complicated technology environments and turn that understanding into decisions.
I created The Visual Enterprise Architect because I've learned that some of the best architecture work doesn't begin with a framework. It begins with understanding the problem, getting the right people into the conversation, and finding a way to make something complicated clear enough that everyone can move forward.
This site is where I'm sharing what I've learned.
More about me →Speaking & Conversations
Bring the conversation into the room.
I speak with architecture teams, technology leaders, executives, practitioners, and students about modern EA, visual decision-making, portfolio intelligence, AI governance, and how the role of the architect is changing.