Quick Links to sections on this page:
Data Governance Operating Model Framework
To understand the Operating Model, consider the analogy with an operating system on a personal computer. The operating system and the installed third-party applications constrain the types of files (read: assets) you can create, read or modify. The folder structure (read: Communities and Domains) of your files enables you to modify and publish your content (read: Assets, Relations and Attributes) more effectively and it provides a basic mechanism to share and assign read or write permissions (read: Roles). If you realize that the files (read: Assets) you produce are not at the level you had anticipated when setting up the operating system, it may be due to several causes: lack of productivity or the instruments that constrain your productivity, the latter issuing a reconsideration of the applications you utilize, or the way files and folders are organized.
The Data Governance Operating Model establishes the foundation for all your data stewardship and data management activities.
It can be subdivided into three categories each addressing a key design question.
- ‘What is to be governed?’ in terms of Structural Concepts:
- ‘How is it to be governed?’ in terms of Execution and Monitoring Concepts:
- ‘Who governs it?’ in terms of Organizational Concepts:
Data Governance Operating Model Design Procedure
The DG Operating Model Design Procedure (OMDP) brings us answers to these ‘what/how/who’ questions in a step-wise procedure with measurable deliverables.
The OMDP is a partial adaptation of the Conceptual Schema Design Procedure, which was originally intended for fact-oriented conceptual database schema modeling. The fact-oriented approach was later standardized by OMG in Semantics Of Business Vocabulary And Rules (SBVR).
The OMDP procedure consists of the following steps:
- Divide the universe of discourse into manageable subareas.
- Apply the OMDP to each subarea.
- Integrate the resulting sub-models into a global operating model.
For each subarea, the operating model design procedure is performed in following steps.
- OMDP Step 1 – Transform Familiar Examples into Asset Types, Attribute Types and Relation Types
- OMDP Step 2 – Validate the Identified Types with Other Examples
- OMDP Step 3 – Check for Types to be Combined
- OMDP Step 4 – Add Constraints and Validation Rules
- OMDP Step 5 – Determine Status Types for all Identified Asset Types
- OMDP Step 6 – Determine Role Types for all Identified Asset Types
- OMDP Step 7 – Design and Implement Execution and Monitoring Workflows
- OMDP Step 8 – Identify Communities and Domains
Dividing the universe into manageable subareas can be done in different ways:
- Take a slice – ‘steel thread’ of the whole data governance case as subarea, and extend it gradually with new business domains.
- Take a business case – such as business glossary – as a subarea, and leverage that result with other business cases such as reference data.