Level 0 - Enterprise-level context
This section describes the enterprise-wide concepts that guide data and platform architecture decisions across the organisation. It sets the strategic and business context for all lower-level architectural decisions.
Why It Matters
Section titled “Why It Matters”A clear enterprise-level context aligns investments in data, capabilities, and infrastructure with the organisation’s strategic vision, operating model, and capacity. This alignment is required to deliver sustainable outcomes that suit the organisation’s context and long-term goals.
Table of Contents
Section titled “Table of Contents”- Org + Domain Definition
- Strategies and Objectives
- Key Systems and Data Assets
- Team Capabilities and Roles
- Governance Structures
- Funding and costing structures
Org and Domain Definition
Section titled “Org and Domain Definition”An understanding of the organisation’s structure and domains is required to set governance, environment, and metadata boundaries. While industry patterns and reference architectures can guide this work, each organisation is different. See Domain-Centric Design for more.
Recommended artefacts:
- Description of the organisational boundary, including any external organisations in scope.
- Description of domains and subdomains that impact the data governance and management model.
Strategies and Objectives
Section titled “Strategies and Objectives”Investing in data initiatives without a clear strategic context risks misalignment and wasted effort. A defined strategic context for data, technology, and governance helps initiatives to align with organisational goals, set priorities, have a clear scope, support governance, and build investment and benefits cases.
Recommended artefacts
- Assessment of relevant business, technology, and data/AI strategies, plans, and initiatives.
Key Systems and Data Assets
Section titled “Key Systems and Data Assets”Identifying and profiling key systems and data assets in the context of strategic benefits and use cases supports planning, design, and risk management.
Recommended artefacts
- Description of the organisation’s relevant systems and data sets (e.g. CMDB, Information Asset Register), including associated governance arrangements and technical characteristics.
Team Capabilities and Roles
Section titled “Team Capabilities and Roles”Clear responsibilities and capabilities for key teams are required to execute the data strategy, maintain accountability, fulfil all support functions, and keep costs predictable.
Recommended artefacts
-
RACI matrix for associated teams/parties with consideration of functions including but not limited to:
- Data lifecycle: creation, management, governance (quality, access), security, and consumption
- Data enablement: engineering, integration, analysis, reporting, and application development
- Data foundations: information architecture, infrastructure, and platform provisioning and management
- Operational support: DataOps, monitoring, and ongoing maintenance
-
Current and target operating and service management model
-
Maturity and skill assessment of key teams/parties relative to role definition
-
Strategy for using external partnerships and vendors to address capability gaps
Governance Structures
Section titled “Governance Structures”Governance frameworks and processes define how decisions are made, enforced, and improved across the data lifecycle. These may already exist in some organisations, while in others they may need to be developed.
Recommended artefacts
- Description of governance frameworks, policies, standards, processes, and bodies relevant to the scope of concern.
- In some cases, proposals and terms of reference for new governance structures.
Funding and costing structures
Section titled “Funding and costing structures”The allocation of funding and costs shapes the internal “marketplace” for data and analytics. These structures determine whether teams collaborate or compete, and influence speed of delivery and standards alignment. They also define the organisation’s capacity to scale and innovate. The architecture addresses this through:
- system-wide, domain, and role-level accountabilities.
- policies and guardrails to prevent bill-shock
- observability and optimisation
Cost governance now has two tracks: cluster policies with enforced tags for classic compute, and serverless usage policies (Public Preview) with budgets for serverless compute. Funding structures should anticipate both.
See:
Recommended artefacts
- Billing structures: including how cost centres map to reports, delegations, and observability (important for transparency and accountability)
- Cost allocation and chargeback models: needed to encourage reuse, manage shared services, and clarify ownership
- Budgeting and forecasting: provides sustainable funding for data platforms, products, and capabilities
- Cost optimisation and monitoring: helps manage platform efficiency and avoid waste, and sets out how the accountabilities for their control are distributed
Next Steps
Section titled “Next Steps”Once the enterprise-level context is established, proceed to Level 1 - Enterprise Architecture, which covers domain-centric design principles and architectural patterns that support the organisation’s strategic objectives.