Running Architecture Reviews Using a Live Model Instead of Slides

The deck goes out forty-eight hours before the review board meets. Someone has spent an afternoon making sure the boxes line up, the arrow styles match, and nothing bleeds off the slide margin. By the time the meeting starts, the diagrams are already wrong in the small ways that don't matter much — a component renamed last week, a box moved two centimeters — and wrong in the one large way that does: nobody drew the thing the reviewer is about to ask about, because nobody knew in advance that they would ask. That gap, between what the deck anticipated and what the room actually wants to know, is where architecture reviews quietly stop earning their time slot.

What a review meeting is actually for

Strip away the ceremony and an architecture review has one job: catch a problem before it becomes expensive to fix. A proposed integration crosses a security boundary nobody flagged in the write-up. A new dependency creates a single point of failure that wasn't visible because the diagram was drawn at department level instead of system level. A retirement plan misses two consumers because the person who drew the landscape diagram eighteen months ago didn't know they existed either, and nobody has redrawn it since.

Catching a problem like that requires the reviewer to follow a thread wherever it leads, not to sit through a presentation of the thread the presenter chose in advance. "What else talks to that system?" "Show me this at the technology layer instead of the business layer." "You said this doesn't cross the boundary — walk me through why not." Those are the questions that justify the meeting existing at all. Everything else could have been a document circulated by email and read on someone's own time.

A slide deck is built for the opposite job: telling a story, once, to an audience that needs it explained rather than interrogated. Both jobs are real, and both come up regularly. The trouble is that most organizations run every review the same way regardless of which job is actually in front of them, because the deck is the tool everyone already knows how to make, and making a new one feels like the safe default even when it's the wrong shape for the meeting.

The familiar failure mode

The pattern is familiar enough that most architects can finish the sentence before you do. The presenter reaches slide eleven, the "target state" diagram, and someone on the review board asks a question the diagram doesn't answer: does the new reporting service reach across the boundary that's supposed to separate the restricted zone from the rest of the landscape? The presenter doesn't know — not because they're unprepared, but because that particular boundary crossing was never something this diagram was drawn to show. It was drawn to show the target state at a business level, and the question is a technology-level question about a specific relationship. The honest answer is "let me check and get back to you." Everyone nods. It goes on the action list.

What happens to that action item afterward is the part nobody likes to say out loud. Sometimes it gets resolved within the week, quietly, and folded into the next version of the deck. More often it sits for a month, gets picked up the day before the follow-up meeting, and gets answered in a rushed email rather than a redrawn diagram — because redrawing the diagram properly takes longer than answering the question in prose, and there's rarely time budgeted for it. The diagram itself, the thing that's supposed to be the shared reference for what the system looks like, never actually gets updated to reflect what was learned. It just accumulates a growing set of caveats that live in meeting minutes and inboxes instead of in the picture anyone will look at next.

Multiply this across every review a team runs in a quarter and the real cost becomes visible: not any single missed question, but an architecture documentation set that drifts a little further from reality after every meeting that was supposed to keep it honest. The review process, whose entire purpose is to catch drift before it compounds, ends up quietly contributing to it instead — a slow leak that nobody notices until an audit, an incident, or a new hire tries to trust the diagram and gets burned.

A concrete version of this shows up constantly around consolidation work. A team proposes replacing a legacy messaging queue with a managed alternative, and the deck for the review shows the three systems everyone remembers depending on it. Nobody objects, because nobody in the room has reason to doubt three systems out of, say, a dozen the team believes actually touch it. The migration proceeds. A month later a reporting job nobody diagrammed breaks overnight, because it read from the queue directly rather than through any of the three integrations that made it onto the slide. Nobody lied in the review — the deck could only ever contain what someone remembered to draw, and a live model's answer to "what depends on this" isn't bounded by anyone's memory in the same way. That distinction is invisible right up until it costs a weekend of incident response, at which point it becomes very obvious indeed.

What changes when the model is live in the room

Put the same review in front of a live, queryable model instead of a set of exported images, and the mechanics of the meeting shift in one specific way: the reviewer's question stops being a request for follow-up and becomes a query that gets answered inside the meeting, using the same screen everyone is already looking at.

An unanticipated question gets a real answer

This is the core of it. "Does this cross the restricted boundary" is not a question anyone can answer by staring harder at a business-layer diagram that was never drawn to show boundaries. It's a question you answer by filtering the model to the security boundary view, or by checking the relationship directly against the rule that defines the boundary. In Mooodels that's a few clicks against a canonical model, not a research task assigned to someone for next week. The reviewer gets to see the actual relationship, not a description of it, and gets to keep asking follow-up questions off the back of what they just saw — which is usually where the real finding shows up, three questions deep, in a thread that a deck could never have anticipated far enough in advance to include.

Switching views is a click, not a redraw

A review board rarely agrees on what altitude they want to look at something from. An executive sponsor wants the landscape view. The security lead wants the boundary view. The integration architect wants to see protocols and technology components, not business capabilities. In a deck, each of those is a separate diagram that someone had to think to prepare in advance, and if nobody thought to prepare the one the security lead actually wants, the meeting stalls. Against a live model, a different view is a different query over the same underlying elements — the landscape view, the dependency view, the security boundary view all come from one model, so switching between them mid-meeting costs nothing more than picking the next tab. Nobody has to have guessed correctly what the room would want to see.

Impact analysis happens on the spot, not as a follow-up

"What else depends on this" is the single most common unplanned question in any review that touches a retirement, a consolidation, or a replacement. Against a diagram, answering it means opening every diagram that might mention the system in question and checking by eye — which is slow enough that it never happens live, and unreliable enough that it misses whatever wasn't drawn. Against a live model, it's a graph traversal: select the element, run the impact query, and the dependents appear, upstream and downstream, drawn from actual relationships rather than from whichever diagrams happened to get made. The review board watches the answer arrive instead of waiting for someone to type it up afterward, and — just as importantly — the answer is the same one an engineer would get running the same query outside the meeting, because there's only one model to ask.

A proposed change gets checked against rules while it's still a proposal

Reviews exist partly to catch governance violations before they ship: a public-facing service that skips the approved gateway, a Tier-1 application without a listed owner, a relationship that quietly crosses a zone it shouldn't. Checking a proposal against rules like that by eye, from a diagram, is exactly the kind of thing an experienced reviewer is good at and exactly the kind of thing that's easy to miss when the diagram is dense and the meeting is running long. A model with deterministic rules built in can run that check live, on the actual proposed change, and surface a violation the moment the change is on the canvas — turning "we should double-check that against policy" into an answer the room already has before the next agenda item.

Running a review this way: the logistics

None of this requires a different meeting format, a longer time slot, or new governance process. It requires a few concrete changes to how the meeting is actually run, and they're worth being specific about, because "use a live model instead of slides" is easy to agree with in principle and easy to get wrong in practice if the logistics aren't deliberate.

Someone drives the model, and it isn't an afterthought role

A live review needs a driver — one person, screen-sharing, whose job during the meeting is to navigate the model in response to what the room asks for. This is a different skill from presenting a deck. Presenting a deck is mostly about pacing and narrative. Driving a live model is closer to pair programming: you need to know the tool well enough that switching to the security boundary view, or running an impact query, or filtering to a domain, happens in seconds rather than becoming its own mid-meeting delay while everyone watches someone hunt through menus. Pick the driver in advance, and pick someone who actually uses the tool day to day — not whoever happens to have the laptop plugged into the projector. A review that stalls because the driver can't find the filter panel loses the exact advantage it was supposed to have over a deck.

Screen-share the tool, not a folder of exported images

It's tempting to prepare a set of exported screenshots as a safety net — "in case something breaks" — and then default to clicking through those instead of the live tool once the meeting starts, because it feels safer. Resist this. The moment you're driving through static exports, you've quietly reverted to a slide deck with better production values, and the first unplanned question puts you right back to "let me get back to you." Screen-share the actual application, logged into the actual model, with the actual query and filter tools available. If connectivity or access is a real concern, solve that problem directly — test the connection beforehand, have the model open before the meeting starts — rather than solving it by falling back to pictures.

The meeting ends with an updated model, not a list of "update the diagram" tickets

This is the logistics change with the biggest payoff and the one teams skip most often. If the review surfaces a missing relationship, a stale owner field, a component that should be tagged differently, or a rename that never got made — fix it in the model during the meeting, or in the ten minutes immediately after, while the driver still has it open and the context is still fresh. The alternative is a follow-up ticket that reads "update the diagram to reflect X," assigned to someone who wasn't in the room for the discussion of why X matters, filed in a backlog that competes with actual delivery work. Anyone who has managed an architecture practice for more than a year knows how that ticket's story usually ends. A model that gets corrected live, in the room, by the person who understood the correction thirty seconds after hearing it, doesn't have that failure mode — because there's no handoff for the fix to get lost in.

Prepare the model, not just the narrator

A deck rewards preparing the story. A live review rewards preparing the data the story would have been built from. Before a live review, it's worth spending the same effort that used to go into building slides on cleaning up the part of the model that's actually going to get queried: making sure ownership fields are filled in for the systems under discussion, that recent relationships have actually been captured rather than left as a mental note, and that the views most likely to get asked for — the security boundary view, the dependency view for whatever's being retired or replaced — resolve to something sensible rather than an empty filter. This isn't extra work layered on top of running the review; it's the same discipline that used to go into building the deck, redirected at the thing that will actually answer questions instead of the thing that only looks like it will.

Where slides are still the right call

None of this is an argument that decks are obsolete, and it's worth being honest about where they still win, because the failure mode of over-correcting is just as real as the one this article opened with: dragging a live tool into a meeting where it actively makes things worse.

A large audience that needs a rehearsed, polished narrative

Live exploration works because a small review board can steer it — a handful of people who each have a specific question they need answered, taking turns asking. That dynamic collapses past a certain audience size. Present a live model to two hundred people at an all-hands or a steering committee update, and you don't get twenty productive unplanned questions; you get a driver clicking around a tool that most of the room can't follow, while the two or three people who actually wanted to interrogate something wait for a smaller, later conversation anyway. A large audience needs a story told once, in order, with the pacing and visual polish that a rehearsed deck delivers and a live tool generally doesn't. Rehearsal matters here in a way it doesn't for a five-person review: a live demo in front of two hundred people carries real risk of a stumble, a slow load, or a wrong click becoming the thing people remember, and none of that risk buys anything the audience actually needed.

An audience with no context

Open-ended navigation is only valuable to someone who already knows enough to know what to ask for. A new stakeholder, a client hearing about the architecture for the first time, or an auditor who needs a guided walkthrough rather than a search interface is generally better served by a curated sequence: here is the landscape, here is why it looks the way it does, here is the specific thing you need to know about. Handing that audience a live, queryable model and inviting them to explore is a way of transferring your own cognitive load onto someone who has no map for navigating it. That's precisely the audience a well-prepared deck, or a short guided walkthrough of the model with the navigation done for them rather than by them, is built for.

Running both, deliberately

The practical answer most teams land on isn't "always live" or "always slides," it's choosing on purpose based on the two questions this article keeps returning to: how many people are in the room, and how much context do they already have? A five-to-fifteen-person technical review board with domain context and specific questions to ask is exactly the audience a live model serves best — that's the room where an unplanned question is likely, valuable, and worth answering on the spot. A steering committee update, a client kickoff, or an all-hands is exactly the audience a rehearsed narrative serves best — that's the room where polish and pacing matter more than the ability to drill in.

Some teams run a light version of both in sequence: open a review with three or four curated views — the equivalent of a short, deliberate deck — to establish shared context quickly, and then switch into the live model once the questions start, so the first ten minutes have the pacing of a presentation and the rest of the meeting has the honesty of a tool that can actually be interrogated. That sequencing costs almost nothing if the curated views and the live model are the same underlying model to begin with — which is the entire point of building the tool this way rather than maintaining a deck and a repository as two separate things that inevitably drift apart from each other.

What doesn't work, in either direction, is pretending the choice doesn't need to be made. A review board sitting through a rehearsed deck when what they actually needed was to interrogate a specific dependency chain will leave with the wrong answer and a stack of action items nobody will finish. A steering committee handed a live canvas and told to explore will leave with no shared understanding at all. The tool isn't the decision — the size and the context of the room is. Mooodels supports both modes because both are real, but it's built with a specific bet: that most of the reviews architects actually run — the small, technical, question-driven ones where a wrong assumption is expensive to leave uncaught — are being run on the wrong tool today, and that fixing that one habit removes more silent drift from an architecture practice than almost anything else on the governance checklist.