Coverage Expectation

Coverage Expectations define the desired coverage level for a specific business architecture domain within an organization or one of its units. Each expectation states the target level, why that level is needed, and optionally the strategy that supports it and the lifecycle stage it applies to.

Schema: coverage-expectation.schema.json
Specification: JSON Schema Draft-07

Overview

What is a Coverage Expectation?

A Coverage Expectation specifies:

• Which domain it applies to
• Where it applies (an organizational unit, or the whole organization)
• Target coverage level for the domain
• Justification for that level (e.g. compliance, risk, opportunity)
• Strategic link to the strategy that supports it
• Lifecycle stage, when the expectation is tailored to elements at a particular stage

Relationship to Other Coverage Records

A coverage template provides typical levels; an expectation sets the level for a particular organization or unit. Coverage status records compare achieved coverage with the expectation's targetCoverageLevel (as expectedCoverageLevel).

Expectation Attributes

Attribute	Type	Required	Description
coverageExpectationID	String	✓	Unique identifier for the coverage expectation
domain	String	✓	The business architecture domain this expectation applies to (e.g. "Capability", "Strategy", "Information")
orgUnit	String or null		The organizational unit this expectation applies to; null when it applies to the whole organization
targetCoverageLevel	Enum	✓	The desired level of coverage for the domain
lifecycleStage	Enum or null		Lifecycle stage this expectation applies to, used to tailor expectations to the development phase of the domain's elements
justification	String	✓	Reason for the desired coverage level (e.g. compliance, risk, opportunity)
linkedStrategy	String or null		Link to the Strategy element supporting this expectation
createdBy	String	✓	User or system that created this record
createdAt	Date-time	✓	Timestamp of creation

Target Coverage Level (targetCoverageLevel)

Value	Description
none	The domain is not documented
minimal	A few entities are recorded with little detail
documented	Core entities and their attributes are recorded
analysed	Relationships, dependencies and gaps have been analysed
governed	Ownership, review and change control are in place
optimised	The domain model is maintained continuously and used to drive decisions and improvement

Lifecycle Stage (lifecycleStage)

The shared lifecycle stage list; null or omitted when the expectation applies at every stage.

Value	Description
ideation	Idea being explored
planning	Scope and approach being planned
design	Being designed
development	Being built
implementation	Being implemented or rolled out
launch	Being launched
operational	In operation
enhancement	Being enhanced
optimization	Being optimized
retirement	Being retired

Example

Finance Unit Capability Expectation

{
  "coverageExpectationID": "cexp-001",
  "domain": "capability",
  "orgUnit": "OU-Finance",
  "targetCoverageLevel": "analysed",
  "justification": "Required for budgeting accuracy and integration with forecasting process",
  "linkedStrategy": "strat-2025-03",
  "createdBy": "admin@org.com",
  "createdAt": "2025-07-01T10:30:00Z"
}

Organization-Wide Expectation for Operational Services

{
  "coverageExpectationID": "cexp-002",
  "domain": "service",
  "orgUnit": null,
  "targetCoverageLevel": "governed",
  "lifecycleStage": "operational",
  "justification": "Operational services must have clear ownership and change control for service-level reporting",
  "linkedStrategy": null,
  "createdBy": "admin@org.com",
  "createdAt": "2025-07-01T10:45:00Z"
}

Usage Guidelines

Creating Realistic Expectations

1. Base on actual capacity — Don't overcommit
2. Start from a template — Adjust a coverage template's levels rather than starting from scratch
3. Justify every level — justification should name the compliance, risk or opportunity driver
4. Prioritize ruthlessly — Set high levels only for the highest-value domains
5. Track actively — Review coverage status against each expectation

Expectation vs. Actual Tracking

Domain	Expected	Achieved	Gap	Status
Capability	analysed	documented	1	Approaching
Policy	governed	governed	0	Met
Performance	documented	minimal	1	Approaching
Service	governed	none	4	Not started

Adjusting Expectations

When expectations are missed:

1. Analyze root cause — Why did we miss?
2. Revisit the level — Is the target still justified?
3. Address blockers — Remove dependencies
4. Communicate early — Don't wait until the next assessment

For Data Engineers

Coverage Expectations can drive data catalog population sprints. Align your data documentation milestones with business architecture coverage expectations to ensure data assets are documented in parallel with the capabilities and processes they support.

Related Documentation

• Coverage Template — Typical coverage levels by sector and size
• Organization Goal — Weight domains and set gap tolerances
• Coverage Status — Compare achieved coverage with expectations