How enterprise architecture teams are responding to the Kernaro release

The short version: the first weeks of the Kernaro AI Hub rollout have produced a consistent surprise. The software installs cleanly and the value is real — but the work that decides how fast that value arrives happens in the repository, not the deployment. Teams that fixed their model first are pulling ahead of teams that deployed first and assessed second.

The Kernaro AI Hub reached general availability in early 2026, and Kernaro Assist — the in-EA companion for architects — landed only a few weeks ago. So this is an early read, not a retrospective. But across the teams we have worked with so far — financial services, insurance, healthcare, and a couple of tech firms — the same observations keep coming back. Different industries, different starting points, the same lessons.

What's landing fastest: stakeholder self-service

The stakeholder layer of the Hub is the quickest path to visible value, and it isn't close.

Once it's live, business stakeholders start asking their own questions: show me the capability decomposition for customer service; which applications support order management; what's the technology roadmap for the data platform. Questions that used to land in an architect's inbox and wait — sometimes for weeks — now return an answer in the time it takes to type them.

That changes the politics of the whole program. The return on investment is legible to non-technical people in language they already use, on day one. No team that started here has regretted it. This is the use case that buys organizational momentum for everything that follows.

The install is the easy part. What separates the teams getting value from the teams still waiting for it is the state of the model underneath.

Productive, with friction: Kernaro Assist

Kernaro Assist is genuinely useful inside Sparx EA, but adoption is narrower than the marketing would suggest — and that is exactly what we expected this early. Architects reach for it on the safe, tactical work first:

• Drafting element descriptions and documentation
• Checking naming against the team's own conventions
• Generating quick data-object or interface specifications
• Writing descriptions in bulk after a landscape import
• Sweeping a capability map for consistency

What they are not handing it yet is the work that carries real architectural weight — making design decisions, redrawing a system landscape, challenging an existing model structure, or rethinking how the architecture is organized. That reticence is healthy. Assist is a copilot for the mechanical work, with the architect keeping the judgment and the accountability.

Here is the part worth underlining. The teams getting the most out of Assist are not the ones with the richest tooling — they are the ones with governance already in place. If you have standards (naming conventions, element-type rules, relationship constraints encoded in your MDG Technology), Assist amplifies them. If you don't, it produces a lot of plausible text that you still have to read line by line.

The surprise: how much MDG remediation it takes

Nearly every team hit the same wall, and almost none saw it coming: the repository looks fine until you query it.

When you pull the model through EA GraphLink — the read-only MCP server inside the Hub — inconsistencies that are invisible in the normal authoring experience light up. An ApplicationComponent that should decompose and doesn't. A Capability with no owner, or five. DataObjects referenced everywhere but never actually defined. Technology elements that are in use but never made it into the standards register.

None of this breaks Sparx EA. People navigate around the gaps without thinking. But an AI system reading the same model has no intuition to fill them in, so the gaps surface immediately — and they show up in the output.

Most teams budgeted a week or two to clean this up. In practice it has run considerably longer before the output is reliable enough to publish without heavy editing — closer to a couple of months for several teams, and more for the ones whose models had drifted furthest. The framing shifts from "our Sparx EA looks fine to us" to "our Sparx EA needs structural work before AI can amplify it." That is a data-quality problem, not a technology problem. It is fixable — but it takes the time it takes.

The teams that handled it best treated remediation as a parallel workstream rather than an afterthought: a small group focused on model quality while the platform stood up alongside them. By the time Assist was fully in their hands, the repository was ready — and they reached dependable output noticeably sooner than teams that tried to deploy and clean up at the same time.

What nobody planned for: the governance questions

Who signs off on AI-generated content? There is no settled answer yet, and the question arrives faster than most teams expect.

Approaches vary. Some treat every Kernaro-drafted description as exactly that — a draft that needs human review before it ships. Others accept output that passes semantic validation (does it faithfully represent the model?). One team built a tiered rule: internal-only documentation is auto-approved once it validates, while anything bound for an external stakeholder still goes past an architect.

None of these is wrong. But they are all different, and each one is a governance decision most teams had never had to codify before. The framework that works in one organization may not transfer to the next — but knowing the question is coming, and that it is non-trivial, is half the battle.

One pattern that travels well: treat Kernaro output the way you treat code from GitHub Copilot. It's useful, it's usually right, and it still needs review. The review is far quicker than authoring from scratch — but it is not zero.

Better than expected: what teams do with EA GraphLink

EA GraphLink is plumbing. It isn't glamorous, and we braced for slow uptake. We were wrong — and wrong about why.

We assumed teams would use it to feed Kernaro. Instead they are wiring it into their own workflows: internal queries, systems-integration mapping, compliance reporting, and pumping architecture context into tools they already run. Because the Hub's MDG Technology maps the physical Sparx schema onto a GraphQL schema, that live model becomes something other systems can actually query.

"Can we query approved technologies from our infrastructure-as-code pipeline so a build fails when it uses something off-standard?" — that one question, once GraphLink could answer it, opened a conversation about architecture governance that simply wasn't happening before. "Can we generate a current-state application-dependency view inside our systems-engineering tool?" — yes, same source. GraphLink is quietly becoming the foundation teams build their own architecture tooling on, which is a more interesting story than AI integration alone.

The pattern underneath all of it

Strip away the specifics and one observation remains: the technical deployment is straightforward; the organizational and repository readiness work is what sets the speed of value.

Kernaro installs. Pro Cloud Server runs. GraphLink queries return. The work that decides the outcome sits on either side of that. Before: assessing your MDG Technology and repository quality, defining a governance model, agreeing on use cases and success metrics, and securing a sponsor. After: reshaping workflows around the new tools, training people, watching quality, and evolving the governance as you learn what holds up.

Teams that approached this as "deploy the tool and see what happens" consistently took longer to reach value than teams that approached it as "assess where we are, plan the change, then deploy the tools as part of that plan." That readiness assessment is exactly what Paralysis to a Plan is built to produce — a scored picture of repository quality, MDG consistency, and the automations worth attempting first.

Where this leaves you

It is still early, and the headline is encouraging: Kernaro works, GraphLink works, Assist is finding its footing. The open question is no longer technical. It is how to structure adoption so a working platform turns into a changed way of practicing — which is a question about your team, not the software.

If you're weighing up Kernaro, start with clarity about where your repository and your governance actually stand, not with the install. The technical capability is already proven. The organizational work is where the difference gets made. For the wider picture of how this reshapes the practice, see AI Augmented Architecture.