Roadmap

Where We Are

XAF Connected Architecture launched with a complete Governance Core and five domain modules. The foundation is solid — organisations can implement meaningful architecture governance today with what exists.

Current State (v1.0)

Governance Core Complete:

• Tiered Oversight
• Decision Records
• Architecture Passport
• Technical Debt Register
• Guardrails Framework
• Delivery Integration
• Architecture Registry

Domain Modules Complete:

• Business Architecture
• Technology Architecture
• Security Architecture
• Information Architecture
• Data Architecture
• Innovation Architecture

This covers the core governance machinery and the domains where most organisations feel the most pain first. But we're not done.

What's Coming

Phase 1: Domain Coverage

The immediate priority is completing domain module coverage. Three modules are in development:

Application Architecture

Application portfolio management, rationalisation approaches, and the governance wrapper that ensures application decisions connect to business priorities. This module addresses the "why do we have 47 CRM systems" problem — not by mandating consolidation, but by making the portfolio visible, the costs transparent, and the rationalisation path clear.

Key content:

• Application portfolio inventory and health assessment
• TIME model (Tolerate, Invest, Migrate, Eliminate) with governance integration
• Application lifecycle stages and decision triggers
• Capability-to-application mapping that connects to Business Architecture
• Portfolio rationalisation patterns that actually work
• Build vs buy decision framework with guardrails

Integration Architecture

Integration is where complexity lives. Every point-to-point connection that bypasses standards creates debugging archaeology for future teams. This module provides the patterns, governance, and visibility to manage integration as architecture rather than afterthought.

Key content:

• Integration pattern catalogue with decision criteria
• API standards and governance (design, versioning, lifecycle)
• Event-driven architecture patterns and when to use them
• Integration platform guidance (iPaaS, ESB, API gateway decisions)
• Legacy integration patterns for systems that won't talk nicely
• Integration debt identification and remediation approaches

Identity Architecture

Identity cuts across everything. Who can access what, how they prove who they are, and how we manage the lifecycle of access decisions. This module addresses identity as an architecture domain, not just a security checkbox.

Key content:

• Identity architecture patterns (centralised, federated, hybrid)
• Authentication standards and technology selection
• Authorisation models (RBAC, ABAC, policy-based)
• Identity lifecycle management
• Zero Trust identity implications
• Consumer vs workforce vs machine identity
• Integration with Security Architecture module

Data Architecture Expansion

The current Data Architecture module covers the governance-connected fundamentals — data models, pipelines, quality, classification, and registry integration. But DMBOK identifies knowledge areas we've deliberately deferred. Phase 1 includes expanding coverage into some of these areas.

Key expansions: - Document & Content Management — unstructured data governance, content lifecycle, records management integration - Data Warehousing & Business Intelligence — full BI architecture, semantic layers, reporting platform governance - Big Data & Data Science — advanced analytics architectures, ML data pipelines, feature stores, data lakehouse patterns - Data Mesh considerations — domain-oriented data ownership, data products, federated governance patterns - Real-time data architecture — streaming patterns, event sourcing, CDC approaches

Phase 2: Framework Maturation

Once domain coverage is complete, focus shifts to strengthening the framework itself.

Solution Architecture (Exploration)

Solution Architecture sits at the intersection of enterprise governance and delivery execution. It's where XAF's guardrails meet real project constraints. The question isn't whether Solution Architecture matters — it's how to represent it in the framework without duplicating what already exists.

Options under consideration:

• Standalone module focused on the solution architect role and how they work within XAF
• Integration guidance woven through existing modules (Delivery Integration, Guardrails, Decision Records)
• Practitioner's guide rather than a domain module — "how to be a solution architect using XAF"

This needs proper thinking, not just another module for the sake of completeness.

Metrics & Reporting

"Add when scaling" is fine advice, but organisations that scale need concrete guidance on what to measure and why. This component will provide:

• Architecture health indicators that matter
• Governance effectiveness metrics (are guardrails being followed? are decisions being recorded?)
• Portfolio health dashboards
• Technical debt trending
• Executive reporting templates that communicate architecture value

This also needs proper thinking first — metrics done badly create perverse incentives. We'll get this right rather than fast.

XAF Community

Architecture practitioners learn from each other. A community around XAF could provide value that documentation alone can't — real implementation stories, pattern sharing, problem-solving support, and feedback that shapes the framework's evolution.

Options under consideration:

• Discussion forum for practitioners implementing XAF
• Contribution model for community-developed patterns and extensions
• Case study sharing from real implementations
• Regular community calls or events
• Integration with InnovateX's broader practitioner network

The question isn't whether community would be valuable — it's what format serves practitioners best without creating maintenance overhead that distracts from framework development. We're exploring options before committing to a model.

Future Horizons

Beyond Connected Architecture, the XAF family will expand to address related but distinct challenges.

XAF Connecting Platforms

A separate framework applying XAF principles to platform architecture and platform engineering. How organisations build, govern, and evolve internal platforms that delivery teams consume.

Different problem space. Same philosophical foundation. Separate documentation.

XAF Product Operations

Applying XAF principles to product-mode operating models. How architecture governance adapts when work is organised around products rather than projects.

Again — related principles, distinct application, separate framework documentation.

Platform Accelerators

XAF is tool-agnostic by design. But tool-agnostic doesn't mean organisations shouldn't get a head start. Future accelerators will provide ready-to-use templates and configurations for common platforms:

• EA Tool templates and import configurations
• architecture management setup
• Documentation space templates and page structures
• Development integration patterns

No timeline on these — they'll come when demand justifies the investment.

What's Not On the Roadmap

Some things won't be added, and that's deliberate:

Formal Maturity Model

XAF is pluggable by design. Organisations start with the Governance Core, add domain modules as needed, and scale governance to context. A prescriptive maturity model contradicts that philosophy. The "Getting Started" guidance already covers minimum viable implementation through full-scale deployment.

Industry-Specific Variants

XAF adapts to context without requiring industry-specific versions. Government organisations can use the same framework as commercial enterprises — the operating model adaptations section in each module handles contextual differences. Creating "XAF for Government" or "XAF for Healthcare" fragments the framework and creates maintenance burden without adding genuine value.

Training & Certification

Not planned. Maybe not ever. XAF is designed to be implementable by competent architects reading the documentation. If the documentation isn't clear enough to implement without formal training, the documentation needs fixing — not a training program.

Reference Implementations

"XAF for Azure" or "XAF for AWS" would be immediately dated and context-specific. The framework provides patterns; organisations apply them to their context. Reference implementations create false precision and maintenance overhead.

Roadmap Summary

How This Evolves

The roadmap isn't fixed. It evolves based on:

• Implementation experience from real organisations using XAF
• Feedback from the architecture community
• Emerging challenges that existing modules don't adequately address
• InnovateX client engagement patterns

If something's missing that should be here, or something's planned that shouldn't be — that's a conversation worth having.

XAF Connected Architecture | Developed by InnovateX Solutions