Enterprise architecture leaders talk about AI augmentation as an ambition. Most have not looked closely at where their architects’ time actually goes. When you do, the 70 to 80 percent figure stops being a statistic and starts being a problem you can do something about.
That number refers to the share of architect time consumed by manual, repetitive work: capturing current-state data, transcribing information from source systems, building diagrams, generating reports, running governance checks. It is the tax your architecture team pays for a process that was designed before AI existed. The tax is optional.
Architecture modelling: where most of the time goes
Architecture modelling is where the largest share of architect time disappears. Current-state capture, in particular, consumes hours that add no analytical value. An architect interviews stakeholders, reads system documentation, cross-references a CMDB export, and manually enters the results into the repository. The modelling tool ends up populated, but the population itself required no architectural judgement.
Diagram creation follows the same pattern. Architects build diagrams from scratch, adjust layouts, and write descriptions for elements that already exist in a source system somewhere. The decision about what to model is architectural work. The act of building the model from a blank canvas is not.
AI agents can handle the transcription side of this domain entirely. A document-to-model extraction agent reads a design specification or a set of meeting notes and proposes the relevant architecture elements and relationships. The architect reviews the output and approves what is accurate.
Architecture analysis: speed is the bottleneck
The second domain where architect time disappears is analysis. Impact analysis, relationship discovery, and cross-system data processing all require architects to compile information before they can interpret it. That compilation can take days or weeks. The interpretation takes hours.
Analysis agents reverse this ratio. An impact analysis agent traverses the Sparx EA repository, identifies every downstream element affected by a proposed change, and delivers results in minutes. A multi-system data processor pulls records from several source systems simultaneously, reconciles them, and presents a consolidated view for the architect to interpret.
Architecture governance: the senior architect bottleneck
Governance work concentrates the opportunity cost in a specific place: your most experienced architects. Standards validation, completeness checking, and review board preparation all land on senior architects because they are the ones who know what correct looks like. This is valuable judgement. But a significant portion of governance work is not judgement at all. It is checking whether elements have required attributes, whether stereotypes conform to the MDG profile, and whether submissions are complete enough to be reviewed.
That checking work is highly rule-based and fully automatable. A model completeness checker runs against any diagram or package and flags everything missing before the submission reaches a review board. Governance automation does not remove architect judgement from the process. It removes the rote checking that obscures it.
Stakeholder engagement: the hidden time cost
The fourth domain is less visible but equally expensive. Every time a business stakeholder needs a question answered about the technology landscape, an architect has to answer it. What applications support the payments capability? What is the impact of this infrastructure change? Each of these questions has an answer in the Sparx EA repository. Getting it out requires an architect.
Surfacing EA data through a governed AI interface removes the architect from this loop for a large category of routine questions. Stakeholders get faster answers. Architects get their time back for the work that requires them.
What the number actually means for your team
The 70 to 80 percent figure is not a benchmark for a typical team. It is a description of a structural condition that affects most EA practices. The modelling tools your architects use were designed for modelling. They were not designed to reduce the manual effort of populating those models with data, to automate the compliance checks that governance requires, or to surface EA data to people who are not architects.
Most teams who have done this work find that the starting number is higher than they estimated, and that the improvement is faster than they expected. Architecture modelling typically shows the largest early gains because the manual transcription work is the most obviously automatable.
The 70 to 80 percent is not a fixed property of your team or your practice. It is a starting point.
See how Amplify measures and changes the number →
Related: Why your Sparx EA repository is the most underused data asset in your AI strategy · What is AI Augmented Architecture
