Enterprise Architecture
AI-assisted 8-layer enterprise architecture using a purpose-built meta-model. Richer, always current, lower cost than traditional EA.
Overview
Most enterprise architecture models cost a fortune to build, go stale almost immediately, and then sit unread.
Part of the reason is where they stop. They cover applications and infrastructure, with nothing joining them upward to why the organisation exists. So you end up with a careful description of what systems you have, which cannot answer the questions anyone actually asks. Which systems implement our regulatory obligations? Which capabilities serve which strategic goal? What breaks if that one ageing platform goes?
We do it differently: senior architects, working with an AI-assisted method built on a purpose-made meta-model.
The meta-model takes concepts from the Business Motivation Model, BIZBOK, TOGAF and ArchiMate and reduces them to one minimal schema of 32 entities across 8 layers. Small enough that a language model can hold it coherently. Complete enough to run from regulation all the way down to infrastructure.
There are two ways to engage. An assessment pulls your current state out of the documentation you already have, builds it into a knowledge graph, runs diagnostics over it and produces something evidence-based. Maintenance sets up a cheap ongoing capability so the model keeps pace with the organisation instead of decaying.
Both modes use our DOGRAG methodology, which constrains AI outputs to the 32 entity types and approved relationships. The AI cannot invent new entity types or arbitrary relationships. For organisations that prohibit cloud-hosted AI, the methodology runs entirely on locally deployed open-weight models within the organisation’s security boundary.
The 8-Layer Meta-Model
| Layer | Question | Key Entities |
|---|---|---|
| 1. Motivation | WHY does the organisation exist? | Vision, Mission, Goal, Objective, Strategy, Initiative, Policy, Regulation, Risk |
| 2. Value Delivery | WHY do stakeholders care? | Stakeholder, Value Proposition, Service, Value Stream, Value Stage, Outcome |
| 3. Capability | WHAT must the organisation do? | Capability, Capability Level, Capability Owner, KPI |
| 4. Operating Model | HOW is work performed? | Process, Activity, Business Rule, Case, Event |
| 5. Organisation | WHO performs work? | Organisation, Organisation Unit, Role, Actor |
| 6. Information | WHAT does the organisation manage? | Business Object, Data Entity, Record, Identifier |
| 7. Application | WHAT systems are used? | Application, Application Service, Component, Interface |
| 8. Technology | WHAT infrastructure supports them? | Platform, Node, Technology, Network |
The primary traceability chain — Regulation → Policy → Strategy → Initiative → Capability → Value Stage → Process → Application → Technology — enables questions that cross all layers. Traditional EA tools stop at the application-infrastructure boundary. This model connects systems all the way up to the regulatory obligations they exist to serve.
The Assessment Method
It starts with whatever already exists. Strategy papers, architecture diagrams, capability maps, system inventories, policy documents, org charts, process documentation. Nobody has to write anything new for us.
Those get read in two to four page sections, with the model mapping content onto the 32 entity types. Every extraction carries where it came from, how confident we are, and whether it describes something current or merely intended.
Then the duplicates get merged. Embeddings narrow the candidates, the model makes the semantic call, and anything uncertain goes to a person rather than being quietly resolved.
Relationships come only from the approved set. There are no free-form “relates to” edges, because those are how a graph becomes unqueryable.
Diagnostics follow: coverage, alignment, duplication and fragility across the graph. Most of these are ordinary deterministic queries with no model involved at all, which is the point.
What comes out is an executive summary, a layer-by-layer assessment, a findings register with evidence and risk ratings, and heat maps for capability maturity, application duplication, traceability coverage and dependency concentration.
Every entity carries a state attribute (current, target, transitional, retired, unknown). This forces the distinction between what exists and what is hoped for.
Why This Approach
| Dimension | Traditional EA | GoSource AI-Assisted EA |
|---|---|---|
| Scope | Application + infrastructure layers | Full 8-layer model, regulation to infrastructure |
| Creation cost | Months of skilled modeller effort | Days of AI-assisted extraction + senior review |
| Maintenance | Expensive periodic refresh projects | Continuous low-cost incremental updates |
| Currency | Stale within months | Always current from living organisational artefacts |
| Tooling | Expensive commercial tools (Sparx, Mega, BiZZdesign) | Open-weight LLMs + graph database + Python |
| Strategic value | Describes what systems exist | Answers cross-layer strategic questions with evidence |
Principles
- Evidence-traceable, not opinion-based. Every entity, relationship and finding points back to a source document, tagged as explicit, strongly implied or inferred. Anything without provenance gets flagged rather than quietly included.
- Senior judgement, not automation. The model does extraction and queries at a scale no person would attempt. Interpreting what the findings mean, how much risk they carry and what to do about them is done by architects.
- Data sovereignty by design. Sensitive architecture documentation does not leave the network. Locally deployed open-weight models with constrained decoding keep the output structured without sending anything out.
Policy Alignment
The approach follows the Australian Government Architecture Framework’s principles while carrying considerably more traceability than it asks for.
Entity types and relationships are drawn selectively from TOGAF and ArchiMate, so anyone already working in those will recognise most of the meta-model. And the human oversight, transparency and provenance tracking run throughout, which is what the Policy for Responsible Use of AI requires.
Evidence
The method is documented as the LLM-Optimised Enterprise Architecture Framework: 32 entities, 8 layers, the assessment methodology and a guide to deploying models locally.
In practice, the Home Affairs integration strategy applied these principles to take 700 ESB integrations down to 16 RESTful resources across 35 domains. ABF trade modernisation produced a modular future state with traceability running from business need to technology, using domain-driven design, value metrics and generative AI.
Steven Capell architected the meta-model. SFIA Level 6 in enterprise and business architecture, 30 years, and Vice-Chair of UN/CEFACT.
The graph runs on a custom 32-entity ontology in Neo4j or NetworkX, with JSON entity and relationship stores. Models are Llama 3.3 70B, Qwen 2.5 72B or DeepSeek-R1 70B deployed locally, constrained through Outlines or llama.cpp grammars. Diagnostics are Python and Cypher over deterministic traversals, and the documentation comes out as C4, Mermaid diagrams and Architecture Decision Records.