If your data strategy is the map, your operating model is the vehicle. The operating model explains how the Data & Analytics Management function will operate to meet the objectives defined in the Data & Analytics Management Strategy and the requirements of a Data & Analytics Management Policy. It defines the people and ownership, governance, processes, and tooling needed to operate the function.
Learn more about how to design a data strategy and how to choose an operating model:
Introduction
There is a natural sequence of work that should take place, perhaps guided by experts, that should inform design decisions for your operating model, use an industry-standard construct to establish a baseline for your operating model and ultimately, design the current state operating model that will support the journey to your target state.
Why is this important to organisations investing in their data capabilities?
- Formalises the adoption of a Data & Analytics Management framework.
- Organises the data logically to improve accountability, understanding and accessibility.
- Defines accountability and responsibilities for each role.
- Improves decision-making with clearly defined data governance.
- Defines a tool stack for known capabilities / future requirements.
- Establishes a formal approach for funding data management.
- Enhances the data culture and drives value across the organisation.
Step 1: Standard document hierarchy
Many organisations will have a mash of guidelines, policies and procedures; some will be fit for purpose, others needing revision. However, until there is understanding, consensus and adoption of a framework, these documents of yesteryear will continue to collect dust.
Aligning the governance and documentation of the Data & Analytics Management function with an organisation-wide governance approach, all the while achieving the objectives of these documents, is much like building the car while driving it.
You will need a Standard Document Hierarchy to give some mental structure to the activity:
| Document Type | Definition | Commentary |
|---|---|---|
| Principle | A statement of belief or foundational concepts that provide guidance for decision making and behaviours. | Principles may originate from the organisation, legal or regulatory sources. |
| Policy | High level directive that expresses goals and represents management expectations for legal, regulatory and organisational requirements | Policies, standards and processes are audited for compliance. Although care should be taken to reduce ambiguity, circumstances change and compliance enforcement may become less restrictive e.g. in the case of de-regulation. |
| Standard | A rule or set of rules that define expected actions for achieving compliance with associated policies. | |
| Process | A series of steps that when executed in order achieve the desired outcome. | |
| Procedure | A low level step or task in a process that specifies how to achieve an activity. Depending on governance rigour, procedures may be auditable. | Procedures are more granular descriptions of steps within a process with role assignment. |
| Guideline | Recommended best practices that: 1) support implementation of a standard or interpretation of policy requirements; or 2) address areas not covered by existing policy documents. |
Guideline compliance is not enforced. It can cover emergent topics e.g. using AI to deliver work products. |
| Principle | A statement of belief or foundational concepts that provide guidance for decision making and behaviours. | Principles may originate from the organisation, legal or regulatory sources. |
| Policy | High level directive that expresses goals and represents management expectations for legal, regulatory and organisational requirements | Policies, standards and processes are audited for compliance. Although care should be taken to reduce ambiguity, circumstances change and compliance enforcement may become less restrictive e.g. in the case of de-regulation. |
| Standard | A rule or set of rules that define expected actions for achieving compliance with associated policies. | Policies, standards and processes are audited for compliance. Although care should be taken to reduce ambiguity, circumstances change and compliance enforcement may become less restrictive e.g. in the case of de-regulation. |
| Process | A series of steps that when executed in order achieve the desired outcome. | Policies, standards and processes are audited for compliance. Although care should be taken to reduce ambiguity, circumstances change and compliance enforcement may become less restrictive e.g. in the case of de-regulation. |
| Procedure | A low level step or task in a process that specifies how to achieve an activity. Depending on governance rigour, procedures may be auditable. | Procedures are more granular descriptions of steps within a process with role assignment. |
| Guideline | Recommended best practices that: 1) support implementation of a standard or interpretation of policy requirements; or 2) address areas not covered by existing policy documents. |
Guideline compliance is not enforced. It can cover emergent topics e.g. using AI to deliver work products. |
Applying this standard hierarchy to your existing documentation should help to align your Data & Analytics Management objectives with the organisation’s existing governance protocol and culture. Any data governance documentation not aligned to an organisation-wide approach is likely to compound the risk of failure if only because you’re rowing in a different direction to the current.
A fast-moving technology business under constant pressure to innovate will not tolerate cumbersome Data & Analytics Management processes. Conversely, a large financial institution operating in an intensely regulated market will not comfortably operate in ambiguity over what they can and cannot do with the mountain of data they are already likely collecting. These examples are to demonstrate the importance of context, and that the objectives of these documents must be achieved while aligning to the organisation’s culture and expectation of regulation.
RECOMMENDATION
Adopt a standard document hierarchy but make sure it aligns with the existing governance protocol and culture of your organisation.
Step 2: Governance guardrails
The standard document hierarchy lays the groundwork for the policy, standards, processes and procedures. However, there are two additional documents that together form a set of documents to act as the organisation-wide guardrails governing the Data & Analytics Management function. The operating model is one of the core documents within the governance guardrails. These documents must be in sync and will continually evolve toward the ‘future state’ Data & Analytics Management capabilities defined in the framework.
Let’s divide governance guardrails documents into 2 categories:
| 1 - What we will do | 2 - How we will do it |
|---|---|
|
D&A Management Principles Foundational values that the organisation aspires to by managing its data effectively. ↓ D&A Management Strategy Clearly defines the scope and goals of the function and necessary capabilities. Watch the webinar on-demand for free. ↓ D&A Management Policy Absolute statements that establish rules about data and regulatory compliance. *D&A = Data & Analytics |
D&A Management Operating Model Defines the people, ownership, governance, processes, and tooling to enable the function - the 'vehicle'. Watch the webinar on-demand for free. D&A Management Standards The statement of rules required to achieve the policy, aligned to the capability model. D&A Management Processes Formal process design for consistent and sustainable execution of the standards. D&A Management Role-Based Procedures Descriptions of process execution and activities aligned to specific job roles. |
| 1 - What we will do | 2 - How we will do it |
|---|---|
|
D&A Management Principles Foundational values that the organisation aspires to by managing its data effectively. ↓ D&A Management Strategy Clearly defines the scope and goals of the function and necessary capabilities. Watch the webinar on-demand for free. ↓ D&A Management Policy Absolute statements that establish rules about data and regulatory compliance. *D&A = Data & Analytics |
D&A Management Operating Model Defines the people, ownership, governance, processes, and tooling to enable the function - the 'vehicle'. Watch the webinar on-demand for free. D&A Management Standards The statement of rules required to achieve the policy, aligned to the capability model. D&A Management Processes Formal process design for consistent and sustainable execution of the standards. D&A Management Role-Based Procedures Descriptions of process execution and activities aligned to specific job roles. |
It is an emerging trend to codify your guardrail documents as metadata, allowing you to prove compliance by dashboard reporting from your metadata repository.
When properly designed, role-based procedures become outputs of the policy, standards and process. The practitioner can trust that if the procedures are followed, they will deliver on the requirements in the other documents – it’s the ultimate one-stop-shop for role clarity.
If you are at the beginning of the exercise, it is worth considering whether you wish to place the Operating Model before the Data Strategy to create ‘quick wins’ that buy you greater freedom to operate. The early demonstrations of value can be applied to a larger set of data value use cases which becomes more concrete as your data strategy progresses.
RECOMMENDATION
Make it easy for your practitioners to access the documentation and consume what they need to execute their role.
Step 3: Operating levels
While your Data & Analytics Management framework will largely define the capabilities and components required to achieve a data control environment, it will not prescribe how to execute the capability at different levels of the organisation. The operating model must identify the activities and roles at various operating levels of the organisation. A data leader must provide the context and relevance for execution and begin to adapt the operating model to account for its size, complexity, geography and culture. For example, GDPR may influence how data is managed in Europe, but not in the US; a data science team specialised in marketing may have little to do with how financial data is formatted for an annual report.
Here’s a model for operating levels of an organisation you could adapt:
The extent to which the organisational structure is functional, matrixed, flat or hierarchical will become clearer as you define the relationship between level and activity. This activity is important because it will help to expose structural weaknesses in how data, and decision making about data, are managed. This activity should be done with a representative amount of business counterparts as you begin to map Data & Analytics Management activities to broad organisational needs, through regional and unit needs, all the way to domain specific needs.
RECOMMENDATION
Understand the operating levels of your organisation and determine how Data & Analytics Management needs to be executed at that level. What must be executed locally close to the business subject matter expertise of the process and data? Versus central execution as a service that can achieve efficiency, consistency, and scale.
Step 4: Accountability matrix
The enterprise data management council notes that there is a new generation of architectures (data mesh / fabric / lakehouse) and new cloud platforms that radically challenge the traditional ‘command and control’ monolithic architectures of the traditional enterprise.
Despite the new and shiny, are your teams still asking questions like this:
- Where does the data reside?
- Who has access to what?
- Who owns it?
- Who can change it?
If so, there is an urgent need to align your business’s business and data elements.
The accountability matrix is a construct that can identify the types of stakeholders across the organisation (the ‘data ecosystem’), the high-level roles and the relationships between the stakeholder types. It identifies stakeholder roles across business, data management and technology:
The accountability matrix helps identify business & technical oriented stakeholders aligned to the business element and data element. When there is an alignment of people/process, data and technology, and role-based procedures are followed, there is a tectonic shift towards the ‘target state,’ and data simply becomes a ‘way of working’.
RECOMMENDATION
Creating a blackline between what the business does versus technology brings clarity to Data & Analytics Management accountability.
Step 5: Data perspectives
This model shows the relation between the business and technical views. Separating the two creates defined accountability for the business to manage the business element and the technology to manage the data element. In this model, we’re talking about metadata.
If a business stakeholder has defined requirements for data, then the technical stakeholder must be able to execute the requirements to provide the data. Friction between the two occurs when the requirements are not clear – for example, if a business term is bound to multiple data elements. Imagine asking your organisation’s definition of a ‘customer’. It could be a Salesforce account ID, it could be a payor in Oracle, it could be a customer number in your helpdesk.
The point is that the business term may have different (or encompass multiple) data elements depending on the context and the only reasonable way for a technical oriented stakeholder to execute the business requirements is to have the capability to look it up in a catalogue, trace its lineage, extract/process the data, and ultimately provision it back to the ‘Business View’.
Metadata management is often an afterthought to a regulatory request or crisis. Being able to find the appropriate data element matching a business element requires a level of efficiency. The data likely exists, but if you can’t find it, it might as well never have existed. The speed and efficiency with which data can be provisioned for analysis and presented as insights matter greatly in today’s operating environment. Slow means eaten by the market!
RECOMMENDATION
The business and technical perspective is achieved in your data catalogue by recording the business perspective in the business glossary and technical perspective in the data dictionary with the business element and data element linked.
Next steps
In conclusion, we end with a short story about the Data Steward and the Data Zen Master…
There was once a young Data Steward who sought out the Data Zen Master.
The steward boldly states, “I am seeking knowledge.”
To which the Zen Master calmly replied, “Is that so? Which knowledge do you seek?”
The young steward pondered the question intently. After a moment of silent reflection, he responds, “I seek to know the starting point of all of this.”
The Zen Master smiled, a wistful glint in his eye, and quietly sent him this link on WhatsApp!
If you are interested in taking your Data & Analytics capabilities to the next level, we highly recommend joining our Data Leadership Series – our monthly online events where we engage, educate, and excite data leaders about the topics that really matter.
Contents
- Introduction
- Step 1: Standard document hierarchy
- Step 2: Governance guardrails
- Step 3: Operating levels
- Step 4: Accountability matrix
- Step 5: Data perspectives
- Next steps
Webinar
We discussed this topic – and much more! – with our lovely guest speakers in the 2nd online event of our Data Leadership Series. Catch up now!
