You’ve adopted a framework. Probably more than one.
Maybe TOGAF gave you the development methodology. Zachman provided the taxonomy. SABSA shaped your security architecture. BIZBOK guided your capability modelling. SAFe tried to embed architecture into agile delivery.
All of them brought something to the table. And yet, despite the investment — the certifications, the workshops, the tailored methodology documents — your architecture domains are still producing excellent work that doesn’t connect. The previous post in this series explored why that happens. This one explores what to do about it.
The Framework Trap
The pattern plays out the same way every time. Organisations adopt a framework expecting it to solve the integration problem, and then discover that the framework mostly describes what architecture should produce — not how to make it work in practice.
TOGAF tells you what artefacts to create at each phase of the Architecture Development Method. It doesn’t tell you how business architecture outputs actually feed technology architecture decisions. Zachman gives you a comprehensive taxonomy for organising what you produce. It doesn’t tell you which artefacts are essential versus nice-to-have when you’ve got three architects and a deadline. SABSA maps security to business requirements beautifully. It doesn’t address what happens when the security architect and the solution architect disagree under delivery pressure.
None of that makes these bad frameworks. They were designed to describe the what — the scope, the artefacts, the conceptual model. What they leave to individual interpretation is the how: the practical mechanics of connecting domains, scaling governance, and embedding architecture in delivery.
That’s the gap. And it’s exactly the gap where architecture practices fall apart.
What’s Actually Missing
Frameworks aren’t wrong. They’re just incomplete where it counts — practical implementation in organisations with competing priorities, limited time, and imperfect conditions.
Five things consistently fall through the cracks.
Connection between domains. Business priorities need to trace through capability investment, information requirements, technology choices, and solution design. Not because someone manually maintains the links, but because the framework makes traceability systematic. Most frameworks describe each domain well. None of them solve the handoffs.
Governance that enables rather than controls. Traditional governance adds gates — more reviews, more approvals, more checkpoints. Teams respond by going around it. What’s needed are guardrails: boundaries defined upfront so teams can move autonomously within them and deviations become conversations, not violations.
Oversight proportional to risk. A routine technology refresh and a core banking platform migration don’t warrant the same governance scrutiny. But most frameworks apply one-size-fits-all oversight. The result is either over-governance of low-risk work or under-governance of high-risk work — usually both.
Accountability that outlasts individuals. When architecture knowledge lives in people’s heads and project archives, every departure is a knowledge loss event. Decisions, context, and rationale need to persist with systems, not walk out the door when architects move on.
Architecture embedded in delivery. When architecture runs parallel to delivery — producing artefacts in its own cadence that delivery teams are expected to consume — it becomes optional. Architecture needs to embed at natural decision points in whatever methodology the organisation uses.
A Different Starting Point
XAF Connected Architecture was built to solve these five problems — not by replacing existing frameworks, but by providing the connective tissue they leave to chance.
The starting point is different: governance first, domains second, connection by design.
At the centre is the Governance Core — seven foundational components that every organisation needs regardless of size or maturity. Guardrails define boundaries within which teams operate autonomously. Tiered oversight scales scrutiny to actual risk. Decision records capture significant decisions with just enough context for future traceability. Architecture passports attach accountability to systems, not people. A technical debt register makes debt visible, owned, and managed. Delivery integration embeds architecture at natural decision points. An architecture registry makes reuse the path of least resistance.
Not optional extras you bolt on when you’re “mature enough.” You start with these.
Around the Governance Core, pluggable domain modules extend capability into business architecture, security architecture, data and information architecture, technology architecture, application architecture, and innovation architecture. Each module inherits the same connective tissue — the same guardrails, the same decision records, the same traceability chain.
The difference that matters? Domains don’t just coexist. They connect systematically. Strategy traces to capability traces to information traces to technology traces to solution. Security embeds at every layer, not as a review gate at the end. Business priorities flow through to technology decisions because the framework makes that flow structural, not accidental.
Start With What You Need
XAF is modular by design. You don’t adopt the whole thing on day one.
Start with the Governance Core. Get your guardrails documented, your decision record template in place, your tiered oversight model defined. That’s your minimum viable architecture governance — and it’s achievable in a week, not a quarter.
Then plug in domain modules as you need them. If security is your most pressing concern, start there. If business-technology alignment is the pain point, start with business architecture. The core doesn’t change; it just gets company.
That’s a world apart from traditional frameworks that demand comprehensive adoption before delivering any value. XAF is built for architecture teams that need to ship outcomes — not spend twelve months building a theoretical foundation before anyone notices the difference.
It works alongside TOGAF, SABSA, BIZBOK, and everything else you’ve already invested in. It’s not a replacement. It’s the integration layer they’re missing.
This is the second post in a series exploring XAF Connected Architecture — what it is, why we built it, and how to implement it. The first post explored why architecture domains stay disconnected despite talented teams. Next up: Start With the Core: Why Governance Is the First Thing You Implement (Not the Last).
Want to see how XAF Connected Architecture fits your organisation?
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.
