What 70–80% of architect time actually goes on — and how AI changes it

The short version: somewhere between 70 and 80 percent of a typical architect's week disappears into manual, repetitive work — capturing current-state data, transcribing it from source systems, drawing diagrams, generating reports, and running governance checks. None of it requires architectural judgment. All of it is work AI can take off the architect's plate, which is what frees the remaining 20 to 30 percent to grow.

Plenty of enterprise architecture leaders treat AI augmentation as an ambition without first looking at where the hours actually land. Once you do, that 70-to-80 figure stops reading like a statistic and starts reading like a problem you can act on. The number is the tax your team pays for a way of working that was designed before AI existed — and the tax is optional.

The work sorts into four domains. The diagram below shows roughly how the week splits, and how much of each domain is mechanical effort rather than design thinking.

Architecture modeling: where most of the time goes

Architecture modeling is where the largest share of architect time vanishes, and current-state capture is the worst offender. An architect interviews stakeholders, reads system documentation, cross-references a CMDB export, and keys the results into the repository by hand. The tool ends up populated — but populating it took no architectural judgment whatsoever.

Diagram creation runs the same way. Architects build views from a blank canvas, nudge layouts into shape, and write descriptions for elements that already live in some source system. Deciding what to model is architecture. Transcribing it into a diagram is not.

This is exactly the kind of transcription AI can absorb. Point an extraction step at a design specification or a set of meeting notes and it proposes the relevant elements and relationships; the architect reviews the proposal and approves what holds up. The blank-canvas tax goes away without the architect losing a single decision.

Architecture analysis: speed is the bottleneck

The second drain is architecture analysis. Impact assessment, relationship discovery, and cross-system reconciliation all force architects to compile information before they can interpret it — and the compiling is where the days go. The interpretation, the part that actually needs an architect, often takes only hours.

AI inverts that ratio. A query can traverse the Sparx EA repository, surface every downstream element a proposed change would touch, and return it in minutes rather than over a week of manual cross-referencing. Pull from several source systems at once, reconcile them, and the architect is handed a consolidated view to read instead of a backlog of records to assemble.

Architecture governance: the senior-architect bottleneck

Governance work parks the opportunity cost on your most experienced people. Standards validation, completeness checking, and review-board prep all land on senior architects because they are the ones who know what correct looks like. That recognition is real judgment — but a large slice of governance is not judgment at all. It is verifying that elements carry the required attributes, that stereotypes conform to the MDG Technology profile, and that a submission is even complete enough to review.

That checking is rule-based and fully automatable. A completeness check can run against any diagram or package and flag what is missing before anything reaches a review board. Done well, this does not strip judgment out of governance — it clears away the rote checking that was burying it.

Stakeholder engagement: the hidden time cost

The fourth domain is the least visible and just as expensive. Every time a business stakeholder needs to know something about the technology landscape, an architect has to field it. Which applications support the payments capability? What does this infrastructure change actually affect? Each answer already sits in the EA repository; getting it out is what costs an architect an afternoon.

Surface that data through a governed interface and a large category of routine questions stops routing through a person. Stakeholders get answers faster, and architects get the hours back for work only they can do.

What the number actually means for your team

The 70-to-80 figure is not a benchmark for some hypothetical team — it describes a structural condition that holds across most EA practices. Modeling tools were built to model. They were never built to cut the manual effort of populating those models, to automate the compliance checks governance demands, or to put architecture data in front of people who are not architects. The friction is baked into the workflow, not into your team.

Teams that measure this honestly tend to find two things: their real starting number is higher than they guessed, and the improvement comes faster than they feared. Modeling usually shows the biggest early gains, because manual transcription is the most obviously mechanical work in the building.

None of this is a fixed property of your practice. It is a baseline — and a baseline is something you can move. The place to start is to look honestly at where the hours land, which is exactly what your architects can map against the four enterprise architecture domains above.