Dashboard
Findings automated governance checks — EOL, AI Act, ownership, pipeline hygiene
Data quality & coverage
Review status stale = not reviewed in 90+ days
Portfolio snapshot
Technology obsolescence LeanIX-light — lifecycle / end-of-life risk
AI & governance EU AI Act tiers · accountability gaps · open high risks
Cost rollup annual application cost allocated by dimension
EA artifact coverage CSVLOD — which document types you actually hold
Modules & References
Every module in this repository and the framework it implements — so anyone can see why each part exists. P1 governance modules (AI registry, principles, decisions, risks) and P2 modules (stakeholders, controls, standards, waivers, work packages) were added from a researched roadmap.
| Module | Why it's here (framework basis) | Reference |
|---|---|---|
| AI System & Agent registry | Inventory every AI system/agent with an accountable human sponsor, autonomy, least-privilege scope and EU AI Act risk tier. Electricity operation is explicitly high-risk. | NIST AI RMF (Govern 1.6 inventory) · ISO/IEC 42001 · EU AI Act Annex III · agent identity / human-sponsor pattern |
| Architecture Principles | Enduring rules that guide design and selection decisions — Name / Statement / Rationale / Implications, applied as a set. | TOGAF Architecture Principles |
| Decision records (ADRs) | The log of why the architecture is the way it is: context, decision, status, consequences — linked to what they affect. | TOGAF Governance Repository (Decision Log) |
| Risk register | Initial vs residual risk + mitigation/treatment, linkable to any element; feeds enterprise risk, not a silo. | TOGAF Risk Management · ISO/IEC 23894 → ISO 31000 |
| Stakeholders & viewpoints P2 | Who cares, their concerns, influence and interest — the lens that drives which views the architecture must produce. | ISO/IEC/IEEE 42010 (architecture description: stakeholders → concerns → viewpoints) |
| Controls / compliance assessments P2 | Map AI systems, apps and risks to control frameworks; record status + evidence so audits and conformity work are traceable. | NIST AI RMF subcategories · ISO/IEC 42001 Annex A · EU AI Act · NIS2 |
| Standards register + waivers P2 | Approved standards with a lifecycle, plus governed, time-boxed, justified exceptions (dispensations) that expire. | TOGAF Standards Information Base · Architecture Governance (dispensations) |
| Work packages (Baseline→Target) P2 | Architecture-state flags on elements; gaps become work packages with effort and target dates that feed a real roadmap. | TOGAF gap analysis · Phases E–F (opportunities & migration planning) |
| Agent guardrail fields P2 | Per AI agent: least-privilege scope, HITL gate, sandboxing, guardrails, red-team and evaluation status. | OWASP Agentic Top 10 · CSA MAESTRO · agent identity / human-sponsor pattern |
| Building-block tag + maturity P3 | Flag elements as Architecture vs Solution Building Blocks (ABB/SBB), and self-rate capability maturity on the ACMM 0–5 scale. | TOGAF building blocks · Architecture Capability Maturity Model (ACMM) |
| Capabilities · Applications · Technology | Business capability anchor, application portfolio, and the technology layer with lifecycle/obsolescence risk. | TOGAF Business/Application/Technology architecture · LeanIX |
| Processes (flow) · Requirements (hierarchy) | High-level processes with ordered steps; strategic requirements with parent/child and acceptance criteria. | BIC (BPM) · ueffectiv (requirements) |
| EA Artifacts (CSVLOD) | EA documents classified by the six artifact types and three practice processes. | Kotusev — CSVLOD / "Enterprise Architecture on a Page" |
| Interfaces P3 | App-to-app data flows — the integration landscape — with a source→hub→consumer flow map; flows on end-of-life hosts are flagged. | TOGAF Application Architecture · LeanIX interfaces |
| Data objects P3 | The missing data domain: master/consumer lineage and AI training/inference usage, flagging training data without documented provenance. | TOGAF Data Architecture · EU AI Act Art. 10 (data governance) |
| Strategy & goals P3 | Goals and KPIs anchored to capabilities, with an executive capability heatmap by investment priority and maturity. | TOGAF Phase A · ArchiMate motivation (goals / drivers) |
| Roadmap P3 | Lifecycle dates, successors, renewals and gated AI go-lives on a half-year timeline with plateaus. | TOGAF Phases E–F (migration planning) · plateaus |
| Governance trail P3 | Append-only change log plus an approval pipeline for ADRs, standards and waivers, with a required-approvals threshold. | TOGAF Architecture Governance (change log & dispensations) |
| Architecture reviews P4 | The formal gate for new solutions and material changes — incl. the AI & agent review: scope, checklist with pass/fail evidence, verdict, conditions, and the ADR it produces. | TOGAF Architecture Governance (compliance review) · EU AI Act Art. 43 · ISO/IEC 42001 |
| Capability hierarchy & TIME P4 | Multi-level capability model (L1→L2) and the TIME portfolio decision (Tolerate / Invest / Migrate / Eliminate) suggested from business × technical fit. | Capability-based planning · Gartner TIME / application rationalisation |
| Designer P3 | Interactive whiteboard canvas: drag repository entities, draw flows that can create real Interface records, generate interface/lineage/capability/process maps from live data, and file drawings into the artifact register. | ISO/IEC/IEEE 42010 (architecture views) · CSVLOD artifacts |
| Traceability · Knowledge Graph · Diagram | Both-direction relationship explorer, force-directed map, and arranged landscape with export. | ISO/IEC/IEEE 42010 (views) · impact analysis |
| Cost rollup · Technology obsolescence · AI & governance panels | Cost allocated by dimension; end-of-life risk; EU AI Act tier mix and accountability gaps. | Portfolio management · NIST AI RMF · EU AI Act |
EA Framework
The structure this repository follows for EA artifacts (documents), based on the research-based "Enterprise Architecture on a Page" framework. Your capabilities, applications, processes and requirements are elements; artifacts are the documents that describe them.
The six general types of EA artifacts
Two dimensions: rows = Rules (decisions), Structures (descriptions), Changes (initiatives); columns = Business-focused vs IT / Technology-focused.
The three EA practice processes
Artifacts are produced and used across three interacting processes. Each artifact in your register is tagged with the process it primarily serves.
Strategic Planning
Aligning IT investment with business strategy over the long term. Uses Considerations, Visions, Landscapes & Standards.
Initiative Delivery
Delivering specific IT initiatives from idea to implementation. Uses Outlines then Designs.
Technology Optimization
Reducing complexity, risk and cost in the existing IT landscape. Uses Landscapes & Standards.
Diagram
Visual landscape of the repository. Drag nodes to arrange, drag the background to pan, click a node to edit it. Use the filters to choose which layers show. Positions are saved.
Knowledge Graph
A living force-directed map of how everything connects. Hover to highlight neighbours, click to edit, double-click to focus on a node and see only what it connects to, drag to nudge, scroll to zoom, drag the background to pan.
Traceability & Impact
Pick any record to see everything connected to it — in both directions. This is the payoff for recording the links: instant change-impact analysis and orphan-spotting.
Data & Backup
Everything is stored in the connected database via the API. Export regularly — and use exports to round-trip with LeanIX, BIC and ueffectiv.
⭳ Export
JSON keeps every record and link (use for backup and re-import). CSV is per-entity and flat (use to push into LeanIX / BIC / ueffectiv or share in Excel).
⭱ Import & reset
Import a JSON backup (replaces current data). Or import an Applications CSV exported from LeanIX (columns: name, businessOwner, lifecycle, hosting, criticality, annualCost — appended).
About KAM
A lightweight EA repository to record applications, processes and requirements and the relationships between them — built around a three-tool reality (LeanIX = capabilities & apps, BIC = processes, ueffectiv = requirements) where the cross-tool links aren't owned anywhere. Each record carries a System of Record and External ID so this can act as your reconciliation / boundary-object register, and a Last Reviewed date so staleness is visible. It is not a replacement for those tools — it's the connective tissue, or a fast way to run the Play 1 catalogue POC before everything is in LeanIX.