Reference Architecture Template

template: reference-architecture
owner: "{name / role}"
status: "{draft | in review | endorsed}"
version: "{1.0}"
date: "{YYYY-MM-DD}"
applies-to: "{which systems, teams or programmes must follow this architecture}"

{Domain} Reference Architecture

Overview

{Two or three sentences: what capability this architecture provides, and for whom. Name the problem it solves rather than the products it uses.}

{What organises the model — for example the path data travels, the request flow, or the assets being protected — so readers know how to read the layers below.}

Scope

• In scope: {the capabilities, platforms and boundaries this architecture covers}
• Out of scope: {what it deliberately does not cover, and where that is addressed instead}

Principles

Component Model Layers

{A layer groups components that serve the same purpose. Describe each component as a capability — what it does — and keep products in the examples column, so the model stays valid when a product changes.}

1. {Layer Name}

{One or two sentences on what this layer is responsible for.}

2. {Layer Name}

{…}

Cross-Cutting Layers

{Capabilities that apply across every layer above, such as governance, security, operations and delivery.}

{Cross-Cutting Layer Name}

{…}

From Architecture to Patterns

{The reference architecture names the capabilities; patterns show how they are built. Link the patterns that implement each component so teams can move from "what" to "how".}

Key Decisions

{Decisions that shaped this architecture, recorded as ADRs.}

Roadmap and Lifecycle

{Where the organisation is moving from and to. Classify the products in use so investment follows the target state.}

Change History

template: reference-architecture
owner: "David Tirabassi, Enterprise/Solution Architect"
status: endorsed
version: "1.1"
date: 2026-09-22
applies-to: "Any organisation designing or tailoring an integration platform. The site's integration patterns and decision framework are built on this architecture."

Integration Reference Architecture

Overview

This reference architecture defines a comprehensive Integration Platform designed to establish an infrastructure that facilitates the seamless connection between data and service producers and the corresponding consumers. It outlines the essential capabilities required to manage APIs, route messages, transform data, and orchestrate services, wrapped in robust governance, security, and operational pipelines.

The model is organised around the path an integration takes: consumers on one side, producers on the other, and the integration layer that connects them. Five cross-cutting layers (information, governance, security, management and monitoring, and development and testing tools) apply across all three.

Scope

• In scope: the capabilities of an integration platform (API management, message routing and transformation, batch and change-data movement, file transfer, event streaming and workflow) and the governance, security, monitoring and delivery tooling around them.
• Out of scope: processing of event streams, which is a data-platform concern (see the Data Platform Reference Architecture), and the choice of products, which each organisation makes when it tailors this architecture to itself.

Principles

Component Model Layers

A layer groups components that serve the same purpose. Each component is a capability, and the examples column shows products for the main cloud platforms and the open-source options.

1. Consumers

Represents the various systems, platforms, and clients that consume and exchange data or services via the Integration Platform.

2. Integration Layer

The core functional engine of the platform, composed of specialized components that transform, route, orchestrate, and mediate data flows between disparate systems.

3. Producers

Represents the various systems, platforms, and databases that safely receive, produce, and exchange transactional data.

Cross-Cutting Layers

Capabilities that apply across the consumers, integration and producers layers above.

Information Layer

Provides a structured framework for data models and centralized vocabulary to ensure consistent semantic structures across services.

Governance Layer

Monitors and directs integration asset lifecycles, guaranteeing cataloging, versioning, reuse, and compliance across developer teams.

Security Layer

Active enforcement controls distributed across the platform to safeguard infrastructure, verify identity, manage keys, and shield transactions.

Management and Monitoring

Monitors availability, logs traces, triggers automated alerting, handles software exceptions, and administers batch jobs.

Development and Testing Tools

Capabilities that empower integration developers to model, write, test, package, and dynamically deploy integration services.

From Architecture to Patterns

The architecture names the capabilities; the pattern library shows how each is built. Every component in the integration layer that has patterns has one for each trust boundary, and the Integration Patterns and Decision Framework chooses between them.

Key Decisions

Roadmap and Lifecycle

Not applicable here: this reference model is vendor-neutral, so it doesn't classify products. An organisation adopting it records, for each component, the product it has chosen and whether that product is strategic, emerging, tactical, contained or being decommissioned.

Change History