Domain model

Dependra models your organisation as one connected graph, four layers deep — from the quarterly goals at the top to the firewalls at the bottom. Nothing lives in isolation: every entity connects downward to what carries it and upward to what depends on it.

Strategy & TransformationWhere you’re going — objectives, key results, cycles, initiatives
⇅
Business ArchitectureWho cares and how much — capabilities, processes, actors, financial impact
⇅
Application & DataWhat things are — applications, components, technologies, datasets
⇅
InfrastructureWhere things run — providers, zones, network paths
Impact Intelligence (computed — you never model this)Health · Blast radius · Incidents — derived from the four layers above
Signals climb up. Questions drill down.

That computed layer is the payoff for connecting the graph — a failure entering at the bottom rolls up into business impact and surfaces on the objective it threatens, and a strategy question at the top drills down to the exact component responsible.

The Dependra Metamodel

The complete metamodel in one picture — every entity type and how the layers connect:

The full Dependra metamodel: Strategy & Transformation (Objectives with Key Results, Initiatives) at the top, feeding down through Business Architecture (Business Domains, Capabilities, Business Processes, Commercial Segments, Impact Profiles, Actors), Application & Data (Applications, Components, Technologies, Datasets), and Infrastructure (Hosting Providers, Areas, Zones, Connectivity) — with Impact Intelligence (Health, Blast Radius, Incidents) as the output layer spanning them all.

Strategy & Transformation

Layer 1 · Where you’re going

The top of the graph: what the organisation is trying to achieve, and what it’s doing about it.

  • Cycle — A time-bounded OKR period (quarterly, annual, or custom) owned by a team. Moves through Planning → Active → Scoring → Closed. On close, selected key results carry forward into the next cycle with a fresh baseline and a lineage link back to their predecessor.
  • Objective — A qualitative goal — a direction, not a number. Belongs to a team, optionally sits in a cycle. Progress is the weighted average of its key results; there is no separate progress field to maintain by hand.
  • Key Result — The measurable outcome. Start value, target value, and a drive mode: manual check-ins, one of 104 computed landscape metrics, a Jira JQL feed, or values pushed from your own tooling. Because key results link to initiatives — and initiatives scope real components — a degraded component can flag a key result At Risk automatically.
  • Initiative — A project or programme with dates, CapEx/OpEx, and expected ROI. Linked to the specific key results it moves, and scoped to the applications and components it touches. The bridge between what we measure and what we’re doing about it.

Objectives can contribute to other objectives across teams and cycles, so a platform team’s quarterly goal ladders up into an organisation-level annual one. See Strategy & OKRs for the full model.

Note

Strategy & OKRs is available on Enterprise and custom plans.

Business Architecture

Layer 2 · Who cares and how much

The layer that turns an architecture graph into impact intelligence — the answer to “who cares, and what does it cost.”

  • Capability — Something your organisation delivers (“Accept payments”). Carries a criticality tier and regulatory exposure, belongs to a business domain, and is delivered by applications and components. When those fail, the capability degrades — visibly.
  • Business Domain — A grouping of related capabilities and datasets.
  • Business Process — A versioned workflow of steps. Processes consume capabilities, so an outage doesn’t just mark a box red — it tells you which step of which process just stopped.
  • Actor — A user group, role, or system that uses a capability, as a beneficiary or an operator. Carries an estimated user count, so impact reports answer “who is affected, and how many.”
  • Segment — The commercial slices of your business: contracts, books of business, regional markets. If your revenue has line items, those are your segments. Most EA tools don’t have this concept, and it’s the reason they can only say “the capability is degraded.” The same capability usually serves several segments under different contracts with different revenue and different SLA terms — a transport operator’s “Transport passengers” capability serves a city bus contract and a regional rail contract; an insurer’s claims capability serves the broker channel, SME, and corporate books. Segments are what let an outage report say which contract is bleeding and whose SLA clock just started — not one blended number. (Not to be confused with Actors: Actors are who uses a capability; Segments are which commercial arrangement they use it under.)
  • Impact Profile — The entity that puts a financial figure on an outage. Per-capability (and optionally per-segment) economics: annual revenue and cost, hourly impact, how hard the dependency bites, and the SLA grace period and penalty. All amounts are in your tenant’s currency — Dependra is currency-agnostic; examples in these docs use euros. This is where “the database is down” becomes “€45K/hour and the SLA clock started.”
  • Dataset — A data asset with classification, legal basis, retention, and regulatory exposure. Datasets link to the components that master or consume them and to the dependency edges they flow across — the backbone of data lineage and the data-in-transit register.

Application & Data

Layer 3 · What things are

What you build, buy, and run.

Product Suite
  └── Application
        └── Component ──▶ Component   (dependency edge)
  • Product Suite — A collection of related applications under shared ownership.
  • Application — A distinct system with its own lifecycle. Carries lifecycle state, criticality tier, health, data classification, functional fit, owner team, RTO/RPO, annual cost, environment, tags, and custom properties.
  • Component — A deployable unit within an application, with a kind (below) that determines its type-specific metadata. Components carry health, technical debt, data classification, network exposure and protection mechanisms, and can be marked external or a stub.
  • Technology — What a component is made of: languages, frameworks, databases, runtimes. Technologies live on the tech radar (Adopt / Trial / Tolerate / Eliminate) and track end-of-life dates — so “what’s going obsolete underneath us” is a query, not a workshop.
  • Dependencies — Directed edges between components (or between applications). The graph blast radius traverses. See Dependencies.

Component kinds

Each component has a kind. Values are case-sensitive and serialized exactly as shown:

Kind Examples
WebAPI REST service, GraphQL endpoint
WebApp Customer portal, admin dashboard
Database PostgreSQL, MongoDB
Queue SQS queue, job queue
Cache Redis, Memcached
EventBus Kafka, Solace, SNS / Service Bus broker
Worker Background processor, consumer
Storage S3 bucket, blob storage
MobileApp iOS app, Android app
DesktopApp Windows client, desktop tool
ScheduledJob Nightly batch, cron job
Integration ETL pipeline, iPaaS flow
Identity Identity provider, auth service
Infrastructure Firewall, gateway, load balancer
Other Anything not covered above

Each kind can carry type-specific metadata — for example, a WebAPI can record its URL and protocols.

Infrastructure

Layer 4 · Where things run

Where components actually run — because blast radius that ignores the network is a guess.

Hosting Provider
  ├── Hosting Area   (an account, subscription or site)
  └── Hosting Zone   (a region or availability zone)
        └── Area × Zone  ◀── a Component is deployed here
  • Hosting Provider — A cloud provider, data-centre operator, or on-premises site (AWS, Azure, your own DC).
  • Hosting Area — A logical boundary within a provider (account, subscription, site).
  • Hosting Zone — A deployment zone within a provider (region, availability zone). Zones are provider-level and shared; an area–zone link places an area’s workloads into a zone.
  • Zone Connectivity — Directed network paths between area–zone pairings (internal, VPN, internet, direct-connect, peering, transit-gateway, private-link). When a zone or a link goes down, Dependra knows which components just lost their path — not just which ones live there.

Impact Intelligence — the computed layer

Output · Computed, never modelled

You never create a health record, a blast radius, or an incident by hand. They’re derived:

  • Health — Signals from your monitoring (Datadog, Grafana, Zabbix, checkmk — whatever watches your estate) land on components and roll up through the graph.
  • Blast Radius — For any component: everything downstream, the capabilities and processes affected, the actors hit, the revenue per hour exposed, and the SLA clocks started. Computed in seconds, across the full depth of the graph.
  • Incidents — Health degradations cluster into incidents with per-segment SLA tracking, penalty exposure, and a full impact ledger — the outage isn’t over until you can explain what it cost.

Two worked examples

The drawing below maps the complete metamodel onto two realistic organisations — an insurance company whose objective is to cut incident frequency by 20%, and a public transport operator aiming to reduce IT spend by 25%. Every layer is filled in: the objective and its key results at the top, the initiatives funded to move them, the business domains, segments and impact profiles that put financial figures and SLA terms on an outage, and the applications, components, datasets and hosting underneath. The numbers are illustrative, but the shape is what a real Dependra landscape looks like.

Two fully worked metamodel examples. An insurance company: objective 'Reduce incident frequency by 20%' with key results for incident frequency (120 to 96 per month), mean time to resolve (4h to 2h) and SLA fines (€85K to €25K), driven by an initiative to replace a home-grown incident list, mapped down through Billing & Collection, a private home insurance segment whose outage reaches 45,000 customers at €25K revenue per hour under a 99.99% SLA, to the applications, components and hosting underneath. A public transport operator: objective 'Reduce IT spend by 25%' with key results for quarterly IT spend (€12.4M to €9.3M) and ticket validation rate, driven by an initiative to rationalize three regional ERP systems into one, mapped down through a subway contract whose outage reaches 1.4 million travelers at €200K revenue per hour with €25K hourly fines.
Tip

Every entity supports a technicalName — a stable, human-readable identifier your scripts, manifests and API integrations reference instead of system-generated GUIDs.

Naming conventions

  • Use clear, consistent names for product suites, applications and capabilities.
  • Component names should reflect what the component does, not how it’s deployed.
  • Use tags for cross-cutting labels (e.g. pci, public-facing, legacy).
  • Document applications, components and capabilities with Markdown to keep knowledge current.