Technology Architecture Domain Module

Making technology decisions visible, deliberate, and aligned.

Technology Architecture is where the rubber meets the road. It's the discipline that governs what technologies you use, what platforms you run on, how systems integrate, and how your technology landscape evolves over time.

Most organisations make technology decisions reactively. A project needs a database, someone picks one. A team wants to try a new framework, they just start using it. Six months later, you've got seventeen different ways to solve the same problem, nobody knows what's supported, and every new initiative feels like reinventing the wheel.

This module provides the practical foundation for technology architecture that creates coherence without killing innovation — a Technology Radar that makes decisions visible, platform and product inventories that show what you've got, and the integration patterns that keep things connected.

What This Module Provides

How It Plugs Into the Governance Core

Technology Architecture doesn't operate in isolation. It connects to every component of the Governance Core:

Guardrails Framework — Technology guardrails define what's in and what's out. "Azure is our primary cloud." "API-first for all integrations." "No new Java 8 projects." These become the boundaries within which solution decisions happen.

Decision Records — When a decision involves technology selection, platform choices, or integration approaches, the technology architecture context gets captured. "We chose Kubernetes because it's in our 'Adopt' ring and aligns with our containerisation strategy."

Architecture Passport — Each system's passport includes its technology stack, platform dependencies, and radar alignment. This makes technology currency visible across the portfolio.

Tiered Oversight — Technology risk factors into oversight tier. Systems using experimental technologies, unsupported platforms, or non-standard patterns typically warrant higher scrutiny.

Technical Debt Register — Technology debt is often the biggest category. Unsupported versions, deprecated patterns, platforms approaching end-of-life — all need visibility and management.

Architecture Registry — This module populates the technology layer of your registry: platforms, products, radar positions, integration patterns, and the relationships between them.

Core Artefacts

Technology Radar

The Technology Radar is the centrepiece of this module. It's a structured way to communicate which technologies your organisation endorses, which are emerging, and which should be avoided.

Why it matters: Without a radar, technology decisions happen in isolation. Teams duplicate effort evaluating the same tools. Skills fragment across too many technologies. Support burden grows as the technology estate sprawls. The radar creates a shared vocabulary for technology conversations.

The Rings

A radar organises technologies into rings that communicate their status:

Movement matters. Technologies move between rings as your understanding evolves. Something in Assess might move to Trial after successful experiments. Something in Adopt might move to Hold when better alternatives emerge or support ends.

The Quadrants

Technologies are also organised by category. Common quadrants include:

Adapt these quadrants to your context. Some organisations split platforms and infrastructure. Others add quadrants for specific domains like AI/ML or security.

Keeping the Radar Alive

A radar that never changes is a radar nobody trusts. Build in regular review cadences:

Governance for new entries:

1. Team proposes technology via standard request (template below)
2. Technology Architecture assesses against criteria
3. If approved, enters radar at appropriate ring (usually Assess or Trial)
4. Sponsor team shares learnings, influencing future movement

Platform Inventory

Platforms are the foundation that applications run on — cloud services, container orchestration, database services, integration middleware. The Platform Inventory tracks what platforms exist, their status, and who's accountable for them.

Why it matters: Platform decisions have long-term consequences. They're expensive to change, create dependencies, and shape what's possible. Knowing what platforms you have, their health, and their trajectory is fundamental to technology strategy.

Platform Status Definitions

Product Catalogue

Technology products are distinct from platforms. A product is something your organisation builds and operates — an API, a shared service, a reusable component. Products have owners, roadmaps, and consumers.

Why it matters: Products enable reuse and reduce duplication. When a team needs payment processing, identity management, or notification services, the product catalogue tells them what already exists before they build their own.

Product Lifecycle Stages

Technology Standards

Standards create consistency. They reduce cognitive load, enable mobility between teams, and make support practical. But standards that are too rigid kill innovation. The goal is "just enough" standardisation.

Why it matters: Without standards, every team makes different choices. Code reviews become arguments about style. Onboarding takes forever. Shared services can't assume anything about their consumers.

Standard Categories

Integration Patterns

Integration patterns define how systems connect — the approaches, protocols, and platforms that make interoperability possible.

Why it matters: Integration is where complexity lives. Without agreed patterns, every connection is bespoke. Debugging becomes archaeology. Changes ripple unpredictably.

Pattern Categories

Tooling Options

The artefacts in this module can live in various tools depending on your maturity and budget:

The structure matters more than the tool. Start simple, migrate when you outgrow it.

For the Technology Radar specifically, a simple visual representation helps communication:

                        ADOPT
                    ┌─────────┐
                    │  Tech1  │
                    │  Tech2  │
              ┌─────┴─────────┴─────┐
              │        TRIAL        │
              │  Tech3    Tech4     │
        ┌─────┴─────────────────────┴─────┐
        │            ASSESS               │
        │    Tech5      Tech6      Tech7  │
  ┌─────┴─────────────────────────────────┴─────┐
  │                   HOLD                      │
  │      Tech8           Tech9                  │
  └─────────────────────────────────────────────┘
                     RETIRE

Many organisations use ThoughtWorks-style radar visualisations. Tools like Build Your Own Radar can generate these from simple data files.

Operating Model Adaptations

Project-Based Organisations

In project-based models, technology decisions get made within project contexts. The risk is fragmentation — each project making independent choices.

Product-Based Organisations

In product models, product teams have more autonomy over technology choices. The risk is inconsistency — each product becoming an island.

Roles and Responsibilities

In smaller organisations, the Technology Architecture Owner function might be part of a broader EA or infrastructure role. In larger organisations, it might be a team. The function matters more than the structure.

Common Pitfalls

Radar becomes a graveyard — Technologies enter but never leave. The radar loses credibility when it contains things nobody uses or that were retired years ago. Build in active retirement.

Everything is "Assess" — If half your radar is in Assess, the radar isn't providing guidance. Be decisive. Move things to Trial or remove them.

Standards without enforcement — Standards nobody follows aren't standards. Build compliance checking into delivery pipelines and review processes.

Platform inventory becomes stale — A platform inventory that doesn't reflect reality is worse than none. Tie updates to change management and contract renewals.

Product catalogue becomes aspirational — Listing products that don't really exist or aren't really supported creates frustration. Only include products that are genuinely consumable.

Integration patterns without examples — Abstract patterns are hard to follow. Provide reference implementations, code examples, and templates.

Technology decisions made elsewhere — If projects routinely bypass the radar, the radar isn't working. Either the process is too slow, the ring assignments are wrong, or there's no consequence for ignoring it.

Extending to Deeper Frameworks

XAF Technology Architecture provides the governance-connected fundamentals. For organisations wanting deeper technology architecture practice, established frameworks offer comprehensive methodology:

The goal isn't XAF or these deeper frameworks — it's XAF for governance integration, with deeper methodology available for those wanting comprehensive technology architecture practice. Start with what XAF provides. Extend when you need more depth.

Integration with Other Domain Modules

Technology Architecture provides the "how" that other domains shape and consume:

Technology Architecture is often where decisions land — business priorities and security requirements shape what goes on the radar, and the radar shapes what gets built

Populating the Architecture Registry

This module provides the content that populates the technology layer of your Architecture Registry. If you've established the registry structure from the Governance Core but have empty technology architecture sections, this is where the content comes from.

What goes in the registry:

Relationship integrity: The power of the registry comes from relationships. Every application should link to its technology stack. Every product should link to its platform dependencies. Every technology should show which applications use it. Without these relationships, you have lists instead of architecture.

Registry vs. source artefacts:

The registry answers "what do we have and how does it connect?" The source artefacts answer "why, and what's the detail?"

Keeping it current:

Tip: If you're using the Architecture Passport, the technology stack section of each passport should align with registry entries. When a passport is updated, the registry relationships should update too. This is easier when both live in the same tool, but even with separate tools, build the linkage into your process.

What Success Looks Like

You know Technology Architecture is working when:

• Teams reference the radar when making technology decisions, without being told to
• New technology requests follow the assessment process because it's seen as valuable, not bureaucratic
• Platform and product ownership is clear — people know who to talk to
• Technology currency is visible — you know what's current and what's drifting
• Standards are followed because they make sense, not because compliance demands it
• Integration patterns are consistent enough that connecting systems is predictable
• Technical debt related to technology choices is visible and managed

Outcome Metrics:

Getting Started

Week 1 — Minimum Viable Radar

1. List your obvious Adopt technologies — What are you clearly standardised on? Put them in Adopt.
2. Identify your Hold technologies — What should teams stop adopting? Put them in Hold.
3. Note known retirements — What's actively being phased out? Put them in Retire.
4. Pick one quadrant — Don't try to do everything. Start with your most contentious area.
5. Publish and communicate — Even a rough radar is better than none.

Month 1 — Add Platforms and Products

1. Inventory your platforms — List your cloud accounts, major infrastructure, key platforms.
2. Identify platform owners — Someone must be accountable for each platform.
3. List consumable products — What internal products exist that teams should know about?
4. Connect radar to platforms — Which platforms relate to which radar technologies?

Quarter 1 — Standards and Patterns

1. Document key standards — Start with the ones that cause the most friction when inconsistent.
2. Define integration patterns — What are your sanctioned ways for systems to connect?
3. Build assessment process — How do new technologies get evaluated?
4. Review and refine radar — What's changed? What should move?

Ongoing

• Quarterly radar reviews
• Platform health assessments
• Standards relevance checks
• Technology debt visibility in debt register
• Assessment process refinement

Related Guardrails

Technology guardrails typically reference this module's artefacts:

Guardrail ID: [GRL-TECH-XXX]
Name: [Guardrail name]
Category: Technology

Statement:
[Clear, actionable statement of the guardrail]

Rationale:
[Why this guardrail exists]

Radar Reference:
[Link to relevant radar entries]

Standard Reference:
[Link to relevant standards]

Pattern Reference:
[Link to relevant integration patterns]

Deviation Process:
[How to request deviation]

Related Guardrails:
[Links to related guardrails from other domains]

Example technology guardrails:

• "New applications must use technologies in the Adopt or Trial rings. Assess-ring technologies require explicit approval and a sponsor commitment."
• "All inter-service communication must use a documented integration pattern."
• "Platform dependencies must be to Strategic or Tactical status platforms only."

Technology Architecture connects what's possible with what's permitted. Done well, it creates the coherent technical foundation that makes everything else easier.

XAF Connected Architecture | Developed by InnovateX Solutions