Enterprise Continuum and Architecture Repository

Enterprise Continuum

The Enterprise Continuum is a way to classify and understand architecture and solution assets from generic to organization-specific. It helps practitioners ask:

What can be reused?
How specialized is this asset?
Is it an architecture concept or an implemented solution?
What evidence exists from similar problems?

The continuum is a classification concept, not merely a physical folder.

Architecture and Solutions Continua

The Enterprise Continuum can be viewed through two related dimensions:

the Architecture Continuum, from foundational concepts toward organization-specific architectures; and
the Solutions Continuum, from generic products and services toward organization-specific implemented solutions.

flowchart LR
    subgraph Architecture Continuum
      FA[Foundational] --> CA[Common-system] --> IA[Industry] --> OA[Organization-specific]
    end
    subgraph Solutions Continuum
      FS[Foundational solutions] --> CS[Common-system solutions] --> IS[Industry solutions] --> OS[Organization-specific solutions]
    end
    FA -.realized by.-> FS
    CA -.realized by.-> CS
    IA -.realized by.-> IS
    OA -.realized by.-> OS

The categories are aids, not rigid boxes.

Architecture Repository

The Architecture Repository is the organized store and management mechanism for architecture assets. It may span multiple tools rather than one database.

Common logical areas include:

Area	Purpose
Architecture Metamodel	Types of content, relationships, and rules
Architecture Capability	Roles, organization, governance, skills, and method
Architecture Landscape	Baseline, transition, and target state descriptions
Standards Information Base	Adopted standards, products, versions, and lifecycle
Reference Library	Patterns, reference models, templates, and reusable guidance
Governance Log	Decisions, compliance findings, waivers, risks, and debt

Some organizations also maintain requirements, roadmaps, portfolios, service catalogs, and configuration data in connected systems of record.

Reference Library

Store reusable assets such as:

principles and policies;
industry and enterprise reference architectures;
patterns and anti-patterns;
approved templates;
standard viewpoints;
reusable building blocks;
lessons learned;
example decisions; and
vendor-neutral evaluation criteria.

Each item should have an owner, status, applicability, version, and review date.

Standards Information Base

A practical standards catalog records:

standard or technology;
category and scope;
lifecycle status;
approved versions;
rationale;
exceptions;
owner;
effective and review dates; and
migration implication.

A simple lifecycle:

Status	Meaning
Emerging	Evaluate or experiment; not generally approved
Preferred	Default choice for new work
Permitted	Allowed in defined contexts
Contained	No new adoption; maintain while migrating
Retired	Remove or replace

Avoid confusing “standard” with “one product for everything.” Standards should state their scope and allow justified exceptions.

Architecture Landscape

Organize the landscape so users can navigate:

level: strategic, segment/domain, capability/product, solution;
state: baseline, transition, target;
time horizon;
business scope;
architecture domain;
owner and authoritative source.

The landscape should answer real questions such as “Which target platforms affect this product?” or “What capabilities depend on this legacy application?”

Governance Log

The governance record should include:

architecture decisions;
review outcomes;
compliance evidence;
approved exceptions and expiry;
architecture debt;
unresolved risks and issues;
owners and due dates; and
links to affected requirements and assets.

This creates institutional memory and prevents teams from repeatedly reopening settled decisions without new evidence.

Tooling principles

Choose tools based on required behaviors:

shared vocabulary and relationships;
version control and history;
search and discoverability;
access control;
review and approval;
reporting and visualization;
links to strategy, portfolio, delivery, CMDB, and risk systems;
export and portability.

A wiki plus version-controlled models may outperform a sophisticated repository that nobody maintains. Ownership and workflow matter more than tool prestige.

Repository operating rules

Define authoritative sources for each content type.
Avoid uncontrolled duplicate records.
Assign owners and review cycles.
Mark stale or superseded content visibly.
Capture decisions and exceptions with architecture changes.
Automate collection where reliable sources already exist.
Archive for traceability, but keep current views easy to find.
Measure use and usefulness, not just item count.

Next: Capability and governance