In their Top 10 IT Issues, 2017, EDUCAUSE identified “data management and governance” as issue #6 and defined it as the need to “improve…the management of institutional data through data standards, integration, protection, and governance.”
We suggest the best way to consider the issue is through pragmatism, or practical solutions that consider the human and cultural elements of data use in organizations. Pragmatic data governance (data intelligence) can be understood as a series of standard, controlled, and understood processes which give clear stewardship and responsibility. The things that can be “pragmatically governed” include data definitions, reports and extracts, data requests, data quality, data access, and a data system inventory.
In part one of this series, we introduced the importance of accountability and trust to data governance. In part two, we discussed the idea of just-in-time data governance as a method to address the pace of data use. In part three, we discussed the best practices for successful data reporting. In this final installment, we will discuss the institutional shifts in culture that occur in the data request process when pragmatic data governance practices are implemented.
Data Discovery
The first cultural shift occurs in the data discovery phase. In this phase, a user discovers pre-existing reports as well as the definition of data attributes found in those reports. The pragmatic approach to this phase is to control and manage the discovery process. By presenting an informative view of existing reports and approved definitions, users can quickly understand the purpose and content of reports, and make content comparisons. Users can use (consult) a knowledgebase of pre-approved, defined data elements. It is clear who created the reports, and that the final outcome was approved by the requester. Within this managed view, the user can explore existing material and begin to formulate their own request within this context.
The discovery phase drives the user to select a pre-existing report or request a new deliverable. The main actor is the data user, acting alone in a self-service discovery environment.
Request for Deliverables
Another cultural shift occurs when the user moves from discovery to a formal request for a data deliverable. An initial request for a deliverable has two main actors – the data requester and a business analyst. The skills of the business analyst would include extensive understanding of the meaning of data, and some understanding (not necessarily exhaustive) of the technical aspects of the data. The business analyst guides the user in a conversation to gather requirements. To make this phase pragmatic, create obvious start and end points, allow the requester to track their request, and utilize a scripted, iterative communication process.
In the communication process, both parties should be able to comment and communicate directly on the requirements. The business analyst uses a script, and is primarily trying to understand the purpose for the request and the decisions that will be made using the deliverable item. The conversation should utilize pre-approved definitions and vetted reports as samples, similar to the content in the discovery phase. The business analysist should be prepared to conduct an iterative conversation, making multiple revisions as the purpose and goals are made increasingly clear by the requester.
From a pragmatic perspective, this scripted approach that assumes iteration, shifts the request process from an ad hoc one to a process that is standardized and repeatable. The process needs to be easy and pleasant to use, and there should be only be one request process. The mechanics of the process are repeatable and easy to follow by both parties. After the requirements have been drafted, the report is built.
Report Development and Delivery
The cultural shifts here are similar to the previous requirements phase. During the build process, the same iterative communication style is in place, but this time between report writer and requester, and the content is about the actual report not the requirements. Both parties can comment on the requirements or the draft report versions. Again, similar to the requirements phase, the process should be repeatable and easy to use by both parties. After the report is built, the process formally asks the requester for sign off. This request for approval by the requester is a key pragmatic step – pragmatic for what it asks and pragmatic for including it in the report build phase, not a separate phase.
How the Data Cookbook Enables Cultural Shifts
The Data Cookbook enables these pragmatic cultural shifts in several ways. It provides a knowledge base containing a report catalog and approved definitions. It provides several workflows that make the requirements gathering, report build, and delivery transparent and vetted (governed). Further, Data Cookbook contains a data system inventory including a lineage feature that connects these workflows to real technical metadata. The Data Cookbook also integrates directly with popular reporting tools so that governed content within Data Cookbook appears directly within a reporting tool. Finally, the Data Cookbook offers a community for knowledge-sharing, both within the organization and, when appropriate, external constituencies.
If you would like to discuss data governance or the Data Cookbook, please 
.
Check out the Pragmatic Data Governance Defined for Higher Education eBook
Contributors: James Willis, III, Brenda Reeb, and Brian Parish
(Image credit StockSnap_P6I4P86ITQ_DGCulturalShift_BP #1058)
