Structured diagram studios for system design, workshops, and diagram-as-code.

The diagram route brings canvas, diagram, architecture, and automation studios into one workflow so workshops, incident flows, C4 views, and coded diagrams can be built, reviewed, and exported without moving between separate tools.

4 studios
135 templates
Open Diagram editor
Whiteboard sketch of a software architecture with Customer, Web Application, API Platform, Identity Provider, and Event Bus components linked by labelled arrows.

Browse templates

Every card is the real artefact. Studio templates open straight in their editor, interactive tools score and edit the framework itself, and Enterprise Architecture workspace templates open their full tool page.

Browse the architecture template library for reference models and pattern starters held outside the studio.

Collection
Topic
Framework

135 of 135 templates

Template catalogue

Opens in the Canvas studio

Opens in the Canvas studio

Opens in the Canvas studio

Opens in the Diagram studio

Opens in the Diagram studio

Opens in the Diagram studio

Opens in the Architecture studio

Opens in the Automation studio

Opens in the Automation studio

Opens in the Automation studio

Porter

PESTLE

Eisenhower

BCG

Cynefin framework: matching the decision approach to the problem

Clear, Complicated, Complex and Chaotic domains each prescribe a different decision approach, from best practice to novel action, with Disorder at the centre for questions not yet placed.

Cynefin

OKR

NIST CSF

ISO 27001

CIS Controls v8.1: the eighteen controls by implementation group

All eighteen CIS Critical Security Controls v8.1, numbered 01 to 18, each carrying the lowest implementation group that activates it. Choose a target group and the controls in scope take the red tint.

CIS Controls

MITRE ATT&CK Enterprise: coverage across the fourteen tactics

The fourteen enterprise tactics in kill chain order, from Reconnaissance to Impact, read down the left column and on down the right. Each card shows your declared detection coverage at one of four levels.

MITRE ATT&CK

AWS Well-Architected

Value proposition canvas: the value map answering the customer profile

The customer profile captures jobs, pains and gains on the right; the value map answers them on the left with products and services, pain relievers and gain creators. The fit connector between the halves is the test the canvas exists to run.

Strategyzer

Lean Canvas

Jobs to be done: the four forces that decide whether a customer switches

The job statement fixes what the customer is trying to get done. Push of the present and pull of the new drive the switch; anxieties about switching and habits of the present resist it. The customer moves only when the first pair outweighs the second.

Jobs-to-be-Done

RAID

DAMA-DMBOK wheel: eleven knowledge areas with Data Governance at the hub

Data Governance sits at the hub of the DMBOK wheel and the ten other knowledge areas sit around it, from Data Architecture to Data Quality. Each card carries the maturity you have claimed for that area on the one-to-five scale.

DAMA-DMBOK

GDPR Article 30 register: processing activities, purposes, bases and retention

Up to six processing-activity cards, each recording what the activity is, why the data is processed, which Article 6(1) lawful basis applies and how long the data is kept, the bones of an Article 30(1) record.

GDPR

NIST CSF

STRIDE threat canvas: six categories and the properties they violate

Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege, each card naming the security property the category violates and holding your threat and mitigation.

STRIDE

SABSA matrix: six layers by six questions, the 36 artefacts in one grid

The six SABSA layers from Contextual to Operational cross the six questions What, Why, How, Who, Where and When; every cell names the artefact a security architect produces at that intersection.

SABSA

OSI model

TCP/IP

ITIL 4

BPMN

Preliminary

Preliminary

Four quality tests a candidate architecture principle must clear

TOGAF runs every proposed principle through four named tests, understandability, robustness, completeness and consistency: clear all four and it is adopted, stop at any one and it is held, because a statement that fails a test is an opinion, not a principle fit to shape design.

Preliminary

Phase A, Architecture Vision

Which capabilities carry the most severe gaps and rank first to fix

Scoring each capability against process, data, application and skills turns a maturity assessment into an order of work: the row with the most severe gaps ranks first, and reading down a column names the dimension that fails most often and so earns investment before the rest.

Phase B, Business Architecture

Phase G, Implementation Governance

Phase B, Business Architecture

An Architecture Decision Record adopting the IEC CIM for the LTDS

One record captures one decision and the reasoning around it: the context that motivates it, the option chosen, the consequences accepted in taking it and the alternatives set aside, so a later team sees not just what was chosen but why and what was weighed against it.

Phase G, Implementation Governance

A transition roadmap of operable states, each proven before the next begins

A transition state is not a milestone on a slide but an architecture the business can actually run, so the roadmap moves from today's baseline to the target only when each state's evidence gate is passed, and the arrow into a state carries the work packages that deliver it.

Phase E, Opportunities and Solutions

Readiness heatmap of five capabilities across four dimensions

Each capability is scored on People, Process, Data and Technology: green is ready, amber needs work, and the accent cell is the dimension blocking rollout, so clearing Data first releases both Digital intake and Asset MDM before the single-row blockers.

Phase E, Opportunities and Solutions

Phase G, Implementation Governance

The Business Model Canvas filled in for a distribution operator

Osterwalder's nine blocks read as two halves hinged on the value proposition: the left half is the supply it takes to deliver, the right half is the demand it serves, and the bottom bands check that allowed revenue covers what the network costs to run.

Phase B, Business Architecture

The TOGAF Architecture Repository holds eight partitions

The Metamodel frames the work from the top and the Capability governs it from the bottom; between them six content partitions each answer one question, ending at the Solutions Landscape where delivered building blocks land, so every artefact has exactly one home.

ADM-wide

Phase B, Business Architecture

Phase C, Information Systems Architecture

ADM-wide

ADM-wide

ADM-wide

One accountable owner of truth behind every information domain

Every information domain traces to one accountable owner whose system is the source of truth, then out to the systems that consume it: a domain that is no system's source of truth is contested data waiting to break a downstream process.

Phase C, Information Systems Architecture

One register of every data entity and the system that masters it

Each core data entity is one row, tied to its domain, its authoritative source system, source type, quality and lifecycle. Naming one master per entity stops two systems both claiming it, and a live entity rated low quality is a flag the register surfaces rather than hides.

Phase C, Information Systems Architecture

Phase C, Information Systems Architecture

The model column is the conformance contract every consumer reads from

Every network-asset data domain runs one path: a system of record holds it, a model or standard defines the contract it must conform to, and consumers read it back, so landing each domain in a model the operator already runs gives every consumer a shape it can trust.

Phase C, Information Systems Architecture

Phase C, Information Systems Architecture

Phase C, Information Systems Architecture

Integration coupling scored across five dimensions

Each row scores how tightly two systems are coupled on one dimension, from data and timing to platform and transaction, on a shared one-to-five scale, and the tightest row is the one to loosen first, since that is where a change in one system most forces a change in the other.

Phase C, Information Systems Architecture

Application portfolio strategy on the Gartner TIME quadrant

Business value against technical quality and fit are the two axes that drive every placement: invest in strong high-value systems as the estate destination, migrate valuable systems on weak technology, tolerate sound but low-value systems, and eliminate the rest.

Phase C, Information Systems Architecture

The six hidden steps behind a published LTDS product

Between the operator's systems and the regulator's desk the LTDS clears six owned steps, mapped to CIM, validated, packaged, published and consumed, so any of the five steps the reader never sees is still a place the data can be wrong and needs its own owner and check.

Phase C, Information Systems Architecture

Phase D, Technology Architecture

Phase D, Technology Architecture

A service split earns its cost only when both change and failure are independent

A microservice pays back only in the quadrant where a part can both ship and fail on its own; when either property is missing the monolith is the honest call, and the partial quadrants qualify only once they add the controls the split demands.

Phase D, Technology Architecture

Phase D, Technology Architecture

The TOGAF Technical Reference Model as three entities and two interfaces

The TOGAF TRM is not a layered stack: the platform interface carries portability, the communications interface carries interoperability, twelve platform services sit as peers not layers, and a backplane of qualities spans all three entities.

Phase D, Technology Architecture

Phase D, Technology Architecture

Two consumer stacks resting on one shared telecom foundation

Operational technology and information technology both depend on the telecom layer, so telecom sets the ceiling on resilience: when a fibre cut, radio outage or power loss drops telecom, both stacks above it lose their links and fail with it.

Phase D, Technology Architecture

Preliminary

Preliminary

The four sponsor outcomes, with architecture and without

The same four outcomes a sponsor cares about, cost, delivery speed, risk and change, each land as a good result with enterprise architecture in place and a failure mode without it, and change bites hardest as the outcome that ties spend to the price control funding the network.

Preliminary

What enterprise architecture is, set beside its neighbours

Enterprise architecture spans business and IT across the whole enterprise over many years and owns a governed roadmap, where solution architecture designs one system for a release and IT strategy sets technology direction alone, so naming the neighbours fixes what it is.

Preliminary

ADM-wide

The two TOGAF Enterprise Architecture levels and what each one tests

TOGAF Enterprise Architecture has two levels: Foundation tests the core Standard, Practitioner tests applied use in context, and Business Architecture Foundation is a separate track.

ADM-wide

A Deliverable holds Artefacts built from reusable Building Blocks

A stakeholder signs off the outer Deliverable, architects produce the Artefacts nested inside it, and those Artefacts are composed from reusable Building Blocks; a Viewpoint is a lens, not a thing held, so it sits apart and reads across any level.

ADM-wide

Three problem-led reading paths through the TOGAF Standard

There is no single right way to read TOGAF, and front to back is the anti-pattern: pick the route that matches your problem, whether learning the framework, landing a programme or running governance, and each one enters and leaves the shared C220 core at a different point.

ADM-wide

The five checkpoints a London case study claim clears to its source

No claim enters the London Grid case study until it verifies down five stages to an Ofgem, NESO or licence record, the ground truth that anchors the chain. Fail any earlier stage, named in the amber reject lane, and the claim never enters the study.

ADM-wide

The enterprise boundary between functions the architect designs and serves

The first Preliminary deliverable is a single line through every function the architecture touches: inside it the architect designs, outside it the architect coordinates, complies or serves, and until the line is drawn no later phase has a scope to inherit.

Preliminary

Preliminary

Preliminary

The Phase A gate that turns the vision into a Statement of Work

The Architecture Vision reaches the signed Statement of Architecture Work only after four named checks pass, each owned by a sponsor or board, so one failed check holds the whole statement and returns the vision for another iteration rather than letting weak scope through.

Phase A, Architecture Vision

Phase A, Architecture Vision

The Phase B pipeline from Phase A inputs to Phase C and D outputs

Phase A inputs flow down into the in-phase architecture work, pass a single governance gate, and leave as a signed-off business architecture, so Phase C and D inherit only the artefacts that cleared the gate and never a raw draft.

Phase B, Business Architecture

Phase B, Business Architecture

Phase B, Business Architecture

Phase B, Business Architecture

Four architecture-theatre warning signs and the cure that returns each to a decision

Theatre is architecture activity that produces an artefact but no decision, and each of these four artefacts turns from warning to cure the same way: bind it to a named decision, a named owner and a review date rather than let it sit unread.

Phase B, Business Architecture

The three layers of the strategy domain, captured top down

Before any capability or value stream is drawn, business architecture captures strategy in three descending layers, the external vision, the strategic intent and its competences, then the priorities for this period, so every structure below can be traced back to a stated intent.

Phase B, Business Architecture

Phase B, Business Architecture

Traceability across the layers and across business domains

Vertical traceability links a strategic priority down through capability and value stream to the resources operations need, and horizontal traceability links the same elements across domains, so a change traces to its intent and can be tested for its knock-on before it is made.

Phase B, Business Architecture

From a business-layer gap log to a costed roadmap and business case

A gap log on its own changes nothing: the gaps are grouped into a roadmap sequenced by dependency and value, then justified by a business case that sets the investment against the expected benefit, which is what turns the analysis into a defensible plan.

Phase B, Business Architecture

The four architecture partitions and the governance each one pulls

Breadth and depth split the landscape into four partitions, each with its own owner: a local project gate, a domain board, a light central standards role, or a heavy central board for enterprise-wide deep work, which is the governance load that choice signs you up for.

Phase E, Opportunities and Solutions

ADM-wide

The London roadmap as a six-gate evidence chain to Ofgem

The roadmap exists because Ofgem reads it, so each of six gates names the function that owns it, the milestone it clears and the artefact it files, and the chain is only defensible end to end once first-year operation is evidenced at the closing gate.

Phase F, Migration Planning

The four operating models by process standardisation and integration

Standardising processes and integrating data are two independent choices, and where a business sits on both names its operating model, so a single regulated network operator, running one process on one shared set of data, lands in Unification.

Preliminary

Phase A, Architecture Vision

Phase C, Information Systems Architecture

The containers inside one software system and who calls each

Drawn once the context diagram has fixed the boundary, a C4 container view opens the system into the applications, services and data stores it runs, and labels who calls what, so the public-facing web app that carries the heaviest hosting and security review is clear at a glance.

Phase C, Information Systems Architecture

Application to organisation ownership and dependency matrix

Every application has exactly one Primary, the unit accountable for it, and any number of Uses dependants: two owners means none, and the GIS row shows why reach matters, since four of the five units depend on it so no change to it is ever a local decision.

Phase C, Information Systems Architecture

Phase C, Information Systems Architecture

Application coverage of the six business functions in Phase C

Full marks an application that meets a function on its own and Partial a contribution that needs others alongside it, so a function every application only touches partially surfaces as a tinted column with no Full, the tooling gap the matrix is built to expose.

Phase C, Information Systems Architecture

The Phase C application interaction matrix for a distribution operator

Each filled cell names the data one application sends to another, so a row is everything a system provides and a column everything it consumes: GIS feeds four of the other five as the integration hub, and the LTDS publication depends on five upstream feeds.

Phase C, Information Systems Architecture

The application to technology matrix bridging Phase C into Phase D

Runs on names the host, Stores in the persistence, Publishes via the distribution channel: seven of the eight applications converge on the shared Kubernetes and PostgreSQL stack, and only the SCADA historian sits off it on the OT network, reaching IT through the Kafka event bus.

Phase C, Information Systems Architecture

Business, application and technology behind one connection outcome

The ArchiMate layered viewpoint stacks the business, application and technology layers of one architecture: each layer's structure realises its own services, which then serve the layer above, so a business outcome traces down to the platform that carries it.

ADM-wide

Business interaction matrix: which unit provides which service to whom

Five distribution units sit as both providers and consumers, and each filled cell names the service the provider hands the consumer, so a new connection draws on all four other units and any interaction that lands in no cell is an undocumented dependency where handoffs fail.

Phase B, Business Architecture

Phase B, Business Architecture

Phase B, Business Architecture

Strategy to capability matrix for London Grid Distribution

Each course of action a strategy sets is tied to the capabilities it depends on, split into ones that must grow first and ones used as they stand, so a capability five strategies quietly rely on cannot be funded last or missed at planning time.

Phase B, Business Architecture

One accountable owner for every business capability

Six business capabilities run down the side and five organisation units across the top; the one unit that owns a capability is accountable for the outcome, and any number of units may contribute, so a row with two owners is a dispute to settle, not a fact to record.

Phase B, Business Architecture

One creating function per data entity across the operating model

Every entity is created by exactly one business function, so ownership is never contested: capacity measurement is created once and never updated, because telemetry is evidence, and Customer never reaches the publish column, keeping personal data out of open data by design.

Phase B, Business Architecture

One shared technology position for a GB network operator

A ThoughtWorks-style radar plots twelve technologies on four rings, Adopt to use with confidence, Trial to prove on real work, Assess to explore and Hold to start nothing new, so the Hold ring becomes the standing list of what to plan a move off.

Phase D, Technology Architecture

A new-connection service traced through five blueprint lanes

Everything below the line of visibility is invisible to the customer yet decides their experience: trace any step down its column and each backstage action and support process there has to succeed before the moment the customer sees in front of it can.

Phase B, Business Architecture

Where a connections customer's confidence dips across five stages

A journey map tracks what one developer does, thinks and feels from first enquiry to energisation: confidence rides high at discovery, collapses at Quotation where cost lands with no breakdown, then recovers once power is live, with each stage naming its fix.

Phase B, Business Architecture

Business Process Cooperation: a chain held together by one shared object

The ArchiMate Business Process Cooperation viewpoint relates processes to each other and their environment: three connection steps carry assigned roles, and the two early steps share one connection application they both read and update, which is what makes them cooperate.

Phase B, Business Architecture

The realisation trace from a business service to what delivers it

The one service the customer experiences is realised by a business process, which is carried by an assigned role and served by an application service and its component, so any change to the system beneath traces straight up to the service it touches.

Phase B, Business Architecture

A two level capability map read as an investment heat map

The ArchiMate Capability Map gives a structured overview of what the business can do, two levels deep, and doubles as a heat map: London Grid Distribution marks capacity assessment as its one priority because connection demand is outgrowing the tools that assess it.

Phase A, Architecture Vision

How outcomes and constraints realise a board-level goal

The Goal realisation viewpoint refines one high-level goal into concrete sub-goals, then separates outcomes that realise a sub-goal by achieving it from the principle and requirement that only influence how it is pursued: conflating the two is the common motivation-layer error.

Phase A, Architecture Vision

The ArchiMate motivation viewpoint in three bands

Nine ArchiMate motivation elements sort into three bands: why change is needed, what outcome is wanted, and which principles, requirements and constraints shape the answer.

Preliminary

Application components cooperate through named information flows and one shared data object

In the Application Cooperation viewpoint every arrow names the information one component passes to another, so a missing arrow is a missing integration and two arrows carrying the same data mark a duplicated system.

Phase C, Information Systems Architecture

Phase B, Business Architecture

What the ArchiMate Technology viewpoint places on the page

The Technology viewpoint shows the software and hardware behind the application layer: system software drawn inside a node runs on that node, the realises arrow names the service that software provides, and a network joins the cloud site to the on-premises device.

Phase D, Technology Architecture

How artifacts realise application components and deploy onto nodes

The Implementation and Deployment viewpoint traces each application component down to the artifacts that realise it and each artifact down to the node it runs on, so an artifact with no node cannot ship and a node holding every artifact reads as a concentration risk.

Phase D, Technology Architecture

ArchiMate plateaus and the gaps that move the architecture

The Migration viewpoint plots the move from a baseline to a target architecture as a row of plateaus, each a stable state, with a gap between each pair naming the work that closes the difference, so no change reaches the target without a step that delivers it.

Phase E, Opportunities and Solutions

The six layers of an enterprise architecture operating model

A board mandate gives the architecture function its authority, and that authority flows down through the people, cadence, tooling and engagement that run it, all aimed at one maturity target: without those layers named, architecture happens by chance and never matures.

ADM-wide

The five-stage assurance pipeline for London governance decisions

Five owned stages carry an LGD board decision from capture through assurance into a filed evidence pack, each handing the next a named artefact, so Ofgem can read the decisions from the repository without LGD legal in the room.

Phase G, Implementation Governance

ADM-wide

One business capability model, built by BIZBOK and adopted by TOGAF Phase B

BIZBOK produces the capability model and a cross-walk aligns its naming, a bridge carries the map to TOGAF Phase B, which adopts it and expands it into deliverables, so the model is built once and the two methods sign a single joint output rather than each rebuilding it.

Phase B, Business Architecture

The same four architecture concerns across TOGAF, DODAF and FEAF

DODAF and FEAF answer the same four concerns as TOGAF but ship a different artefact for each, so mapping a concern across the row reuses work only once you declare which equivalence is exact and which is partial.

ADM-wide

The Zachman Framework 3.0 as a thirty-six cell classification grid

Every artefact has one home where a perspective meets a question: six perspectives, Executive to Enterprise, cross six interrogatives, What to Why, so a perspective gives a complete view and a question threads scope to enterprise, named by Zachman 3.0 not the retired 1987 set.

ADM-wide

Four TOGAF misconceptions and the repair each

Each of the four beliefs that most often stall a TOGAF adoption has a lighter-weight repair in the Standard itself, so the method is tailored to the work in hand and scaled to the effort a change deserves, never obeyed wholesale.

ADM-wide

The TOGAF ADM is an iterative cycle of eight phases

The method turns as a ring, but it is iterative, not a single pass: you iterate within a phase, loop back between phases, and repeat the whole cycle, re-entering at the phase that fits rather than restarting at A. Requirements Management is two-way with every phase.

ADM-wide

The six readiness factors scored before the Vision is committed

TOGAF Phase A scores transformation readiness factor by factor, governance, funding, capability, culture, data and platforms, and stakeholder backing, so a weak factor becomes a named risk that shapes the plan rather than a late discovery that explains the slip.

Phase A, Architecture Vision

Phase C, Information Systems Architecture

Phase E, Opportunities and Solutions

ADM-wide