# 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.

```mermaid
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

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

[Next: Capability and governance](06-capability-and-governance.html)