Across the Arc: The Jobs of a Maturing Architecture Practice, and How They Change on Sparx EA

Most architecture teams can start a model. The job that stalls is finishing it across the organization and keeping it current as projects deliver. A practice grows through recognizable stages, and at each one different people take on a different job: capturing what the organization knows, building a connected model, agreeing a shared vocabulary, governing the model so others can contribute, and opening it to the people and tools that need answers. This paper follows those jobs in Sparx Enterprise Architect. For each, it sets out how the work is done by hand today, how it is done AI-augmented, and what it asks of the people doing it, so you can see where your team stands and what finishing the job takes.

The defining step is the move from drawing diagrams to maintaining a connected model, where a box stops being a picture and becomes a typed element with identity, properties and relationships you can query. Sparx EA was designed around that idea, and the same repository can then carry a governed vocabulary, delegated contribution and access for other tools without being rebuilt. A team already running a governed, consistent repository has a head start on everything that follows.

Where every practice starts: knowledge in people’s heads

At some point complexity outruns the people who carry it. It happens gradually, and for a while nobody notices, because someone compensates: a senior engineer who has been there for twelve years and knows which systems are fragile, an IT director who reviewed every implementation, a solution architect who built the integration layer and knows from memory how it behaves under load.

These people are the organization’s institutional memory. When something breaks, someone calls them. The map they carry is accurate, and it exists nowhere except in their heads.

The trigger is usually a version of the same event. A retirement takes the map out of the organization overnight. A major initiative depends on dependencies nobody wrote down. A security audit shows that nobody can answer basic questions about data flows. Each time, the organization finds that it cannot operate strategically on a map that only one person can read.

The arc, job by job

Building a connected model

Who does it. Architects, often a small team with a large backlog of drawings, spreadsheets and interview notes.

Today, by hand. Each box is redrawn in EA as an element, each line becomes a typed relationship, and each diagram is rebuilt from the elements. It is slow, so the model covers the domains someone had time for and stays thin everywhere else.

AI-augmented. The architect decides what to model and in which language, then gives the AI the source material: an application inventory, a Visio file, a capability list. The AI builds the elements, relationships and navigable diagrams in the repository, and the architect reviews the result. Once content is in a model, it can be questioned: what applications support this capability, what systems send data to this component. Rename an element once and it changes everywhere it appears.

The skill it asks. Knowing which content matters and how it should be modeled, and reading the AI’s result critically. A model that looks complete and is wrong does more harm than a gap that everyone can see.

The move from diagrams to a connected model is the biggest step in EA practice maturity. Governance, automation and AI answers all build on it.

Agreeing a shared vocabulary

Who does it. A lead architect or model owner, with the architects who will follow the rules.

Why it matters. Sparx EA uses MDG Technology to define the semantic structure of a modeling language in the repository: element types, relationship types, permitted connections, required attributes and stereotypes. A drawing tool supports a language such as ArchiMate only at the notation level, so you can draw something that looks right and is structurally invalid. A defined metamodel is what makes a repository something people who did not build it can trust.

Today, by hand. The lead architect writes conventions into a document, authors the MDG by hand, and spends review time catching the same mistakes again.

AI-augmented. The architect designs the governance intent: which concepts exist, what each must carry and how they may connect. The AI helps turn that into the MDG and a set of validation rules, applies them across the existing model, and reports what does not conform.

The skill it asks. Deciding what the organization needs its model to say, and stating it precisely enough to check.

Governing so others can contribute

Who does it. Review boards, junior architects and project teams, with the EA team as steward.

Today, by hand. Senior architects check every submission for missing attributes and wrong relationships before anyone can discuss the design, so the EA team becomes the bottleneck.

AI-augmented. The rules defined in the previous stage run against a package before it reaches review, and the AI reports what is incomplete. Contributors fix the gaps before submitting, and the review board spends its time on rationale and tradeoffs. Automation checks completeness, people own correctness.

The skill it asks. Reviewing for judgment rather than completeness, and keeping the rules current as the practice learns.

Opening the model to people and tools

Who it serves. Business stakeholders, delivery engineers, data teams and leaders, most of whom will never open Sparx EA.

Today, by hand. Architects export spreadsheets, generate documents and build slides on request. Each copy starts to drift the day it is made.

AI-augmented. The architecture stays in the repository, and people reach it where they work. Stakeholders ask questions in plain language through Kernaro AI Hub, or read the published model in Prolaborate. Leaders see dashboards in Power BI built on a reporting database over the repository, or through the Kernaro Connector when the organization has the Hub. The architect’s job shifts from producing copies to keeping the model current and deciding who can see what.

Why the platform matters more as the practice matures

Sparx EA is not the right tool for every organization at every stage. In the earliest stages the discipline matters more than the tool, and any structured modeling environment beats a folder of drawings. The platform matters more as the practice matures, because the governed metamodel, the API access and the ways other tools can read the repository decide what the later stages can deliver.

Teams that built their practice on Sparx EA reach those later stages with a governed repository and a consistent metamodel already in place. The remaining work is to finish the model and keep it current, which is the heart of AI-Augmented Architecture: the architect decides what should be done, and AI does the mechanics in the tool and the model. For why the platform earns that role, see Why Sparx EA.

If your organization is not yet committed to Sparx EA, or runs it alongside another platform, ask whether the practice you want to build needs these properties. For teams set on maturing past diagrams, the first move is a scored look at where the practice stands today, which is what Paralysis to a Plan delivers.