Your IT landscape, documented, governed, and always current
Most medium-to-large organizations cannot confidently answer a basic question: what do we have, and how does it fit together? Diagrams drawn at project kickoff never get updated. Knowledge lives in senior engineers' heads. Documentation and code drift apart until nobody trusts either.
Architecture documentation shouldn't be a side project — it should be a side effect. The Architecture as Code framework makes it one: C4 on the outside, Claude Code on the inside. A living, governed, auto-generated architecture site, backed by an open-source tool we built and a set of Claude Code skills that enforce the governance loop — from intake, to grounding docs in real code, to drift detection, to PR validation.
Built by TrotStar Technologies
structurizr-mkdocs-generatr
Open-source tool that generates a full MkDocs Material site from a Structurizr DSL workspace. The engine behind every architecture site we deliver.
The C4 Model — architecture at the right level of detail
The C4 Model, created by Simon Brown, is a hierarchical way to describe software architecture using four levels of zoom:
- System Context — the big picture: your system, its users, and the external systems it talks to.
- Container — zoom into a system to see its deployable units: APIs, databases, message brokers, front-ends.
- Component — zoom into a container to see its internal building blocks and responsibilities.
- Code — the lowest level: class diagrams or similar, generated from source where needed.
Combined with bounded contexts from Domain-Driven Design, the model links business capabilities to the systems that support them — making architecture meaningful to both engineers and stakeholders.
How it works — six skills that govern the landscape
Claude Code skills turn the architecture repo into a governance pipeline: intake → detail → ground truth → drift check → assess → ship.
- /c4-add-system — intake. Turns a product submission into a complete software system in DSL: containers, relationships, and an introduction doc.
- /c4-add-container — detail. Extends an existing system with a new container, inferring peer relationships and applying consistent tags.
- /c4-document-system — ground truth. Reads the actual code repository and generates technical documentation grounded in real APIs, data models, and authentication patterns — not best-guess boilerplate.
- /c4-audit-system — drift check. Compares the documented architecture against live code and surfaces missing entities, outdated descriptions, and broken relationships.
- /c4-review — assess. Evaluates a system against the Azure Well-Architected pillars (reliability, security, cost, operations, performance) and produces a dated report.
- /c4-validate-changes — ship. Validates pull requests for naming conventions, required metadata, documentation completeness, and consistency with peer systems.
The skills are versioned in the repo — not prompts someone reinvents per project. That's what takes this from "a C4 diagram generator" to a governed architecture practice.
Example — Bounded context diagram
Each business capability maps to a bounded context with its own entities and relationships. This example shows how Club Strategy Management connects to Marketing & Sales.
Example — C4 System Context diagram
The top-level view shows all software systems, their users, and how they interact. Every box is clickable and drills down into container and component views.
Example — Systems, personas & dynamic workflows
Auto-generated persona pages, system deep-dives with container diagrams, and animated dynamic views showing how systems collaborate at runtime — like gameday operations across ticketing, stadium, and security systems.
What the framework produces
- Grounded technical docs — API references and data models pulled straight from each system's code repository
- Drift detection — audits that flag where documentation and code have diverged
- PR gates — validation on every change for naming, required metadata, and cross-system consistency
- Well-Architected reviews — dated, repeatable assessments across the five pillars
- Architecture Decision Records — tracked in the repo alongside the model
- A navigable MkDocs Material site — dark/light mode, section tabs, C4 views at every level, business capability map, persona pages, deployment views
- Git-based governance — branch, PR, review, merge, auto-deploy
- Integrations — Atlassian Compass sync, Power BI feeds, Azure connectors for live deployment data
- Writing guide — embedded C4, Mermaid, PlantUML, and Markdown support
Live demo — BelFoot FC Digital Architecture
A fictional football club showcasing 28 software systems, 13 business capabilities, 18 personas, 4 deployment environments, and 6 ADRs.
Proven at scale
- Government institution: 150+ applications, 5 development teams, 4 environments, 20+ ADRs. Described internally as "a foundational pillar of the IT department."
- International organization: Architecture governance across cloud-native integration solutions serving agencies worldwide. Replaced scattered documentation with a single governed source of truth.
- Energy company: Integration architecture documentation across enterprise service bus, shared services, and cloud-native interfaces.
- Industrial services provider: 30+ interfaces documented with automated Canonical Data Model and Interface Design Document generation — cutting onboarding time for new integration developers.
Best fit for
- Large organizations (50+ applications) with undocumented or poorly documented IT landscapes
- Organizations preparing for cloud migration who need to understand current state