There’s a sequence that most architecture teams follow when they’re building a practice. It goes something like this: hire some architects, pick a framework, start producing artefacts, get some delivery wins under your belt, establish credibility — and then, eventually, put governance around the whole thing.
Governance comes last. It’s treated as a sign of maturity — something you earn the right to do once you’ve got the team and the capability in place.
I’ve watched this play out a dozen times. The governance never arrives. Or it arrives so late that it’s fighting against years of embedded habits, and the team resents it because they’ve been doing just fine without it, thanks.
The previous post in this series introduced XAF Connected Architecture and its two-layer structure: a Governance Core with pluggable domain modules. This post explains why the Governance Core goes in first — and why that sequence matters more than most teams realise.
Why Governance Gets Deferred
The instinct to defer governance makes sense on the surface. You want to prove that architecture adds value before asking people to follow rules. You want credibility before you try to change behaviour.
And governance has a branding problem. Most people hear “governance” and picture review boards that meet monthly, heavyweight document templates that take half a day to complete, and approval gates that slow everything down. If that’s what governance looks like, of course you’d put it off.
But that’s not the only way governance can work. And deferring it has real costs that compound quietly.
Without guardrails from the start, every technology choice is a one-off decision. There’s no way to tell whether teams are aligned to a common direction or drifting apart. By the time you notice the fragmentation, it’s already expensive to fix.
Without decision records, the rationale behind early choices vanishes. The architects who made them move on or forget the context. Two years later, someone inherits a system and has no idea why it was built the way it was — so they either leave it alone out of fear or rebuild it and reintroduce the problems the original design was meant to solve.
Without a tiered oversight model, everything gets the same treatment. Routine work gets over-scrutinised, creating friction. Risky work gets under-scrutinised because nobody has time. The architecture function becomes a bottleneck on the easy stuff and absent on the hard stuff.
The longer these patterns run, the harder they are to reverse.
Governance as Foundation, Not Roof
The shift in thinking is this: governance isn’t something you add on top of a mature architecture practice. It’s what you lay down so that practice can grow in a connected direction.
Consider what the XAF Governance Core actually contains. Guardrails define boundaries within which teams operate autonomously — they don’t require approval, they define what “yes” looks like upfront. Tiered oversight means routine work self-certifies against guardrails while high-risk work gets active architecture involvement. Decision records take fifteen minutes to complete and capture just enough context that future teams aren’t left guessing. Architecture passports attach living context to systems, not to project archives that get forgotten. A technical debt register makes trade-offs visible and owned. A registry makes reuse the easier path. And delivery integration embeds architecture at natural decision points rather than running it as a parallel activity nobody engages with.
None of this is heavyweight. None of it requires a formal Architecture Authority, a twelve-month implementation plan, or a tooling procurement exercise. It’s a set of habits and lightweight templates that create the connective tissue every other architecture activity depends on.
When governance goes in first, every domain module you add later inherits the same foundations. Security architecture, business architecture, data architecture — each one plugs into the same guardrails, the same decision records, the same traceability chain. You don’t have to retrofit connection between domains because connection was designed in from day one.
What the First Week Actually Looks Like
This is where most frameworks lose people. The gap between “you should do governance” and “go do this on Monday morning” is usually enormous.
With XAF, the minimum viable Governance Core is deliberately small. Week one looks like this:
Document your top fifteen guardrails. Five to ten technology guardrails covering your approved platforms, integration patterns, and hosting standards. Three to five security guardrails for your non-negotiable controls. Two or three strategic guardrails that reflect where the organisation is investing and divesting. These don’t need to be perfect. They need to be written down so teams can reference them instead of guessing.
Create a decision record template. One page. Completable in fifteen minutes. What was decided, what alternatives were considered, which guardrails it touches, what debt it introduces. The test isn’t whether every field is filled in — it’s whether someone unfamiliar with the decision could understand why you made it.
Create an architecture passport template. A living document per system — identity, current state, key decisions, guardrail compliance, integration points, outstanding debt. Someone should be able to read it in twenty minutes and understand what they’re looking at.
Identify who can approve. Even if it’s just a lead architect and a business sponsor. You don’t need a formal board. You need clarity about who says yes when a decision needs escalation.
Define the escalation path. Who do you ask when a guardrail doesn’t fit? When you need to deviate? When you’re stuck? This prevents paralysis and keeps decisions moving.
That’s it. Five things. Achievable in a week with one or two people driving it.
Why Starting Small Actually Works
Once the Governance Core is in place, you extend capability through Domain Modules. Business Architecture. Security Architecture. Data Architecture. Technology Architecture. Information Architecture. AI Architecture, Innovation Architecture. Each module plugs into the core, inheriting governance patterns and connecting to other domains through shared structures.
The key differentiator — and the reason the framework carries “Connected” in its name — is that domains connect by design, not by heroic effort. Strategy traces to capability traces to information traces to technology traces to solution. Security embeds at every layer rather than reviewing at the end. Innovation gets assessed against architecture readiness before scaling to production.
You don’t implement all six domains on day one. You start with the Governance Core, add the domain modules that match your current needs, and grow into the rest as maturity warrants.
Where to From Here?
This is the third post in a series exploring XAF Connected Architecture. The first post explored why architecture domains stay disconnected. The second post introduced the framework itself. Next up: Connecting Your First Domain: A Practical Implementation Walkthrough.
Ready to see what your Governance Core could look like?
Todd Johnson is the creator of XAF Connected Architecture and founder of InnovateX Solutions, a Queensland-based IT consulting firm specialising in enterprise architecture, cybersecurity, and digital transformation for government and enterprise clients.
