Where architect time goes, and how AI-augmented work changes it

Much of an architect’s week goes to manual, repetitive work: capturing current-state data, transcribing it from source systems, drawing diagrams, compiling reports and running governance checks. NovoCircle’s whitepaper Intelligent Automation for Enterprise Architecture notes that architects spend over half their time on analysis, much of it wrangling data, and a good deal more transcribing what they see into the tool. Very little of that work needs architectural judgment. AI-augmented, the architect decides what should be done and AI does the mechanics, which leaves more of the week for the judgment only an architect can supply.

Many enterprise architecture leaders treat AI augmentation as an ambition without first looking at where the hours land. Once you look, the manual share stops reading like a fact of life and starts reading like a problem you can act on. It is the cost of a way of working that was designed before AI could do the mechanics.

The work sorts into four domains. For each, this article sets out how the work is done by hand today, how it is done AI-augmented, and what that asks of the architect.

Architecture modeling

Today, by hand. Architecture modeling is where a large share of architect time goes, and current-state capture is the worst of it. An architect interviews stakeholders, reads system documentation, cross-references a CMDB export and keys the results into the repository by hand. Diagrams run the same way: views built from a blank canvas, layouts nudged into shape, descriptions written for elements that already exist in some source system.

AI-augmented. The architect gives the AI a design specification, an inventory or a set of meeting notes, and says which modeling language to use. The AI proposes the elements and relationships, builds them in the repository and lays out the diagrams. The architect reviews the proposal and approves what holds up.

The skill it asks. Deciding what to model and how, which is the architecture, and reading the result critically. Transcribing it was never the architecture.

Architecture analysis

Today, by hand. Impact assessment, relationship discovery and cross-system reconciliation all force architects to compile information before they can interpret it. The compiling takes days. The interpretation, the part that needs an architect, often takes hours.

AI-augmented. The architect asks the question, and the AI traverses the Sparx EA repository, finds every downstream element a proposed change would touch, and reconciles it with other sources the architect points it at. The architect reads a consolidated view instead of assembling one.

The skill it asks. Asking a precise question, and knowing when the model is too thin to answer it. A traversal over an incomplete model returns an incomplete answer that looks complete.

Architecture governance

Today, by hand. Standards validation, completeness checking and review-board preparation land on senior architects, because they know what correct looks like. Much of that time goes to checking that elements carry the required attributes, that stereotypes conform to the MDG Technology profile, and that a submission is complete enough to review.

AI-augmented. The architect writes the rules once. The AI runs them against any diagram or package and reports what is missing before anything reaches a review board. Automation checks completeness, people own correctness.

The skill it asks. Turning what “correct” means for your team into rules that can be checked, and spending review time on rationale.

Stakeholder engagement

Today, by hand. Every time a business stakeholder needs to know something about the technology estate, an architect fields it. Which applications support the payments capability? What does this infrastructure change affect? Each answer already sits in the EA repository, and getting it out costs an architect an afternoon.

AI-augmented. Stakeholders ask in plain language and get answers from the model through a governed interface, or read them on a dashboard built from it. Routine questions stop routing through a person.

The skill it asks. Keeping the model current enough to answer, and deciding which questions should still come to an architect.

What this means for your team

The manual share is a structural condition more than a reflection on any team. Modeling tools were built to hold models. They were not built to cut the effort of populating them, to run the compliance checks governance demands, or to put architecture data in front of people who are not architects. AI-augmented work changes that, and the architect’s role moves toward deciding, reviewing and explaining.

Your own split is a baseline you can measure and move. The place to start is to look at where your team’s hours land. Our piece on running a time allocation baseline shows how, and your architects can map the result against the four enterprise architecture domains above.