How to run an architecture time allocation baseline with your team

One of the first things we do in any engagement is measure how an architecture team actually spends its time. Not what the job description says. Not what leadership assumes. Not even what the team would guess on a good day. The real allocation, across the work that matters.

That number turns out to be some of the most useful data a practice can hold. It shows where the productivity drag really sits, what improvement would genuinely move the needle, and where AI augmentation has something to recover. It also turns the leadership conversation from opinion into evidence.

You don't need anyone to run this for you. It takes about half a day, and what you learn is worth far more than the time it costs.

The four domains

Architecture work sorts cleanly into four categories. We've found the same frame holds whether you're a team of two or a team of twenty.

Architecture Modeling is the time spent putting information into the repository: interviews and workshops to gather what's true, creating and editing elements in Sparx EA, diagramming, writing descriptions and metadata, and wiring up the relationships between elements. The output is content in the repository.

Architecture Analysis is the time spent getting insight back out of the model — impact analysis (if I change this application, what breaks?), dependency mapping, compliance reporting, cross-system queries, pulling data to support a planning decision. The output is answers to specific questions.

Architecture Governance is the time spent keeping the repository trustworthy and the team working to standard: standards checking, review-board prep, completeness validation, MDG Technology conformance, logging architectural decisions, capturing lessons learned. The output is consistency you can rely on.

Stakeholder Engagement is the time architects spend fielding questions and briefing people who aren't architects: emails about who owns a system, current-state diagrams for a planning session, explaining why a decision went the way it did, sitting in meetings mostly to answer questions the model should already answer. The output is alignment.

Between them, these four will absorb nearly all of your team's time. There's always a sliver of miscellaneous — admin, training, the work that fits nowhere — but it usually stays under 10%.

The exercise, step by step

Here's the whole thing as a sequence you can run in an afternoon.

How to read the result

Once you've aggregated the estimates, compare your profile to a typical one. Most teams land somewhere close to this:

• 35–40% Architecture Modeling (creating and editing repository content)
• 25–30% Architecture Governance (standards, reviews, completeness)
• 15–25% Architecture Analysis (answering questions)
• 5–15% meaningful Stakeholder Engagement (conversations that actually change minds)

If your numbers look like that, you're operating normally — which usually means a lot of rote work and quiet frustration about how little real analysis you get to do.

A healthier profile, once AI carries the mechanical load, shifts toward:

• 25–30% Architecture Modeling (AI drafts content, architects review and decide)
• 15–20% Architecture Governance (automated checking, with people handling the exceptions)
• 30–35% Architecture Analysis (more of it, because the cost of a query collapsed)
• 20–25% meaningful Stakeholder Engagement (fewer "who owns this?" interruptions)

The distance between your current profile and that target is the prize. If you're spending 40% of your week on modeling and governance and you'd rather it were 20%, that recovered time is a concrete productivity gain — and it's exactly the work that well-targeted AI Augmented Architecture is built to give back.

Some variation is healthy, not a problem. A governance-heavy team may simply be in a high-regulation environment; an engagement-heavy one may support a large, distributed organization. The real question is alignment: does this allocation match our priorities? When half the effort goes to answering email and analysis is what actually drives strategy, you have something to fix.

What to do with the baseline

Treat this as a recurring measure, not a one-off. Repeat it quarterly — annually is too slow, because the work changes faster than that. As you introduce automation, watch whether governance time genuinely comes back, and whether stakeholder self-service shrinks the engagement domain or just changes its texture.

Keep the worksheet you used — the four domains and your team's split. Run it again in two quarters and you'll have evidence, not a hunch, about whether your improvements are landing.

The teams that get the most out of AI augmentation are the ones that measure the baseline first, name the target, and then hold themselves to moving toward it. This exercise is how that accountability starts. For a deeper look at where the hours really go, see what 70–80% of architect time actually goes on — or get the whole team into the same picture starting with your architects.

Ready to establish your baseline and turn it into a plan? Paralysis to a Plan runs your team through this exercise as the first step toward a scored, fundable roadmap.