Skip to main content
Created Jan 22, 2026Last updated Jul 6, 2026Version v0.2.0

Enterprise Architecture

This directory contains AMI’s enterprise architecture.

Use it to understand how enterprise intent flows into technology architectures using the cube methodology:

  1. Constraints are agreed first (assumptions, functionals, NFRs)
  2. Those constraints bind all downstream decisions
  3. Principles explain why choices are made
  4. Capabilities describe what must be possible
  5. Components show how systems are structured

Start here before reading any individual technology architecture.

Structural grammar (hard rules)​

The same shape repeats at every level; the vocabulary is closed.

At every level​

<scope>/
├── README.md               # identity + positioning
├── 00_outer-constraints/   # agreed first; bind everything below
└── 01_aspects/
    ├── principles-and-patterns/   # WHY
    ├── capabilities/              # WHAT must be possible
    └── components/                # HOW it is structured

Every block is an exercise with outputs. A directory's README.md defines the exercise; the artifacts in it are the outputs. Nothing exists outside a block: every artifact falls under one specific block, and depth is added as leaves inside a block (e.g. runtime-execution/actigraphy-measurement/), never as new siblings.

The enterprise cube (this level)​

  • Ring (00_outer-constraints/): business-and-it-strategy · business-and-technology-trends
  • capabilities/ — exactly: business-and-operating-model · business-functional-and-process
  • components/ — exactly: business-people-and-process · information-and-security · technology
  • principles-and-patterns/ — principles and patterns as separate outputs

The technology cube (each entry in components/technology/)​

  • Ring (00_outer-constraints/): functional-requirements · non-functional-requirements
  • capabilities/ — exactly: development/ (development architecture) · operational/ (operations architecture) · runtime-execution/ (run-time execution architecture)
  • components/ — exactly: application/ · data/ · platform/ · infrastructure/
  • principles-and-patterns/ — principles and patterns as separate outputs

Rules​

  • Closed vocabulary: never rename a block, never invent a sibling. Presence is expected but a not-yet-earned block may sit as scaffold (assessment-stage components)
  • Supporting-graphics directories (e.g. context-map/) may nest under 01_aspects — they illustrate, they never decide
  • Changing the vocabulary is a grammar change: it goes through architecture intake and lands as a decision record, never as an ad-hoc directory

Working vocabulary​

The "-ilities" — the checklist every technology cube's NFR exercise works through (each answered, even if the answer is "not a driver here"): scalability · performance · security · recoverability · maintainability · operability · availability · extensibility · resiliency · global expansion.

Working principles applied in every exercise and review: keep it short & simple · don't repeat yourself · don't reinvent the wheel · fit for purpose · black box (encapsulate) · divide & conquer · prepare for failure.

Outcomes this repo exists to produce: conceptualize new technology · technology organization roadmap · target-state architecture · application framework. If an artifact serves none of these, it does not belong here.