100 lines
4.2 KiB
Markdown
100 lines
4.2 KiB
Markdown
|
# Source Summary — ITCC v0.1
|
||
|
|
|
||
|
|
Faithful précis of `source/ITCapabilityCanonV0.1.md` and `source/capabilities.yaml`.
|
||
|
|
No canon judgement here; comparison lives in `comparison-matrix.md`.
|
||
|
|
|
||
|
|
## Identity
|
||
|
|
|
||
|
|
- **Name:** Information Technology Capability Canon
|
||
|
|
- **Short name:** ITCC
|
||
|
|
- **Version:** 0.1, status *draft baseline*
|
||
|
|
- **Companion data:** `capabilities.yaml` — declared by the document (§17) as the
|
||
|
|
initial machine-readable representation
|
||
|
|
|
||
|
|
## Stated purpose
|
||
|
|
|
||
|
|
Define **what an information system must be able to do**, independently of how it
|
||
|
|
is implemented, positioned deliberately between product and technology:
|
||
|
|
|
||
|
|
```text
|
||
|
|
Business / Product → requires → Capability → provided by → Service
|
||
|
|
→ implemented by → Technology → consumes → Resources → Cost
|
||
|
|
```
|
||
|
|
|
||
|
|
The document states (§15) that ITCC is intended to become a capability-oriented
|
||
|
|
component of the wider InfoTechCanon, governed by "import; do not duplicate".
|
||
|
|
|
||
|
|
## Object model (§3)
|
||
|
|
|
||
|
|
| Object | Meaning |
|
||
|
|
|---|---|
|
||
|
|
| Capability | Abstract, implementation-independent ability that may be required or provided |
|
||
|
|
| Profile | Constrained specialization of a capability, preferred over new capabilities |
|
||
|
|
| Requirement | A system's statement that it needs a capability at a minimum maturity |
|
||
|
|
| Provider | Operational entity providing a capability in a context |
|
||
|
|
| Implementation | Concrete technology/product/configuration used by a provider |
|
||
|
|
| Resource | Economic resource consumed while providing: C, S, N, I, P |
|
||
|
|
| Evidence | Information supporting a capability or maturity claim |
|
||
|
|
| Maturity | Quality/operational standing **of a provision**, never of the abstract capability |
|
||
|
|
|
||
|
|
## Inclusion rules (§4)
|
||
|
|
|
||
|
|
A concept enters the canon only if it is implementation-independent, reusable,
|
||
|
|
demandable, providable, testable, profileable, and stable.
|
||
|
|
|
||
|
|
## Exclusions (§5)
|
||
|
|
|
||
|
|
Technologies (PostgreSQL, Keycloak, Stripe), protocols and standards (REST,
|
||
|
|
OIDC, OpenTelemetry), product features (password reset screen), and
|
||
|
|
domain-specific business capabilities (hospital admission, insurance
|
||
|
|
underwriting).
|
||
|
|
|
||
|
|
## Structure (§6, §7)
|
||
|
|
|
||
|
|
Eight navigation domains over 41 capabilities; the underlying model is asserted
|
||
|
|
to be a **graph**, not a tree:
|
||
|
|
|
||
|
|
| Domain | Capabilities |
|
||
|
|
|---|---|
|
||
|
|
| Identity & Access | lifecycle, authentication, authorization, federation, organization |
|
||
|
|
| Data & State | transactional, object, cache, backup, archive, search |
|
||
|
|
| Integration & Communication | api, messaging, exchange, notification, traffic |
|
||
|
|
| Runtime & Automation | execution, configuration, scheduling, workflow, deployment |
|
||
|
|
| Operations & Assurance | observability, alerting, audit, recovery, continuity |
|
||
|
|
| Security & Governance | secrets, keys, policy, vulnerability, governance.evidence, governance.lifecycle |
|
||
|
|
| Commerce | metering, billing, payment, entitlement |
|
||
|
|
| Intelligence | generation, extraction, embedding, retrieval, reasoning |
|
||
|
|
|
||
|
|
Each capability carries `id`, `name`, `purpose`, `profiles`, `qualities`,
|
||
|
|
`evidence`, and optional `depends_on` / `may_use`.
|
||
|
|
|
||
|
|
## Relationship types (§9)
|
||
|
|
|
||
|
|
`depends_on`, `may_use`, `composes` (capability-to-capability);
|
||
|
|
`requires`, `provides`, `implements`, `consumes` (landscape-to-capability).
|
||
|
|
|
||
|
|
## Maturity scale (§10, §11)
|
||
|
|
|
||
|
|
`D0` Absent · `D1` Experimental · `D2` Available · `D3` Usable · `D4` Production ·
|
||
|
|
`D5` Reliable · `D6` Scalable · `D7` Strategic. Claims are per provision and per
|
||
|
|
environment; the same provider may hold different levels in dev/staging/prod.
|
||
|
|
|
||
|
|
## Resource and cost model (§13)
|
||
|
|
|
||
|
|
`C` Compute · `S` Storage · `N` Networking · `I` Intelligence · `P` Platform.
|
||
|
|
Cost attaches to provisions and implementations, not to abstract capabilities,
|
||
|
|
enabling capability-oriented FinOps questions.
|
||
|
|
|
||
|
|
## Evolution stance (§16, §19)
|
||
|
|
|
||
|
|
Conservative: prefer profiles over new capabilities, treat capability IDs as
|
||
|
|
durable interfaces, require explicit migration semantics for rename/removal,
|
||
|
|
introduce provisionally and promote only after repeated practical use. v0.1
|
||
|
|
explicitly does not aim at completeness.
|
||
|
|
|
||
|
|
## Proposed ownership split (§15)
|
||
|
|
|
||
|
|
ITCC owns *what abstract abilities exist*; a "CILM" landscape model owns *what
|
||
|
|
entities exist and what state they are in*; CARING keeps specialized
|
||
|
|
access-governance semantics and may import ITCC concepts.
|