The Data Stewardship Approach to Data Governance: Part 9

This is the ninth article in a continuing series.  This installment discusses the Operational Data Steward.

This is the ninth chapter in a series of articles by Robert S. Seiner. This article or chapter (so to speak) has been a long time coming (at least a few months). I hope that it was worth the wait and please trust that future articles should be posted more quickly. J  If you have questions about past, present and future chapters, please contact me at rseiner@kikconsulting.com.

The past few chapters have discussed the KIK Data Governance Framework© that is demonstrated in the diagram below. In the past two articles (Ch 7) & (Ch 8), I focused on the middle section of the pyramid and described the responsibilities of the Data Domain Steward and the Data Steward Coordinator. I referred to these two roles as the pivotal roles as they have primary responsibility for operationalizing “non-invasive data governance”™. This chapter focuses on the bottom layer of the KIK Data Governance Framework© of roles & responsibilities, the Operational Data Stewards. The articles in the next few issues will address the side-bars of the pyramid and the tower sticking out of the top. Please address all comments and questions about past and future portions of the framework to the author through email. Thanks.

Stewarding Data On a Daily Basis

If you subscribe to the “Non-Invasive Data Governance”™ approach, Operational Data Stewards exist throughout the organization. If this is new to you, please go back and read the prior articles in the series to gain a better understanding about why and how the “Non-Invasive Data Governance” approach is called non-invasive. Operational Data Stewards, as part of their daily routine and work-effort have some level of responsibility (not necessarily authority) over the data they define, produce and use.

Several years ago, the CIO at a state government organization in Florida stated to me, “If you can see the data, you have responsibility for how you use the data you can see. If you can update the data, you have responsibility for how you update or enter the data. If you define the data that is used by your part of the organization, you have responsibility for making certain it is consistent with the standard way we define that data it.” This is a very simple statement that perfectly describes how an operational data steward becomes an operational data steward.

I was recently asked if ‘everybody’ in the organization is an Operational Data Steward. I guess the argument could be made to answer that question “yes” since everyone, at some point in time, comes in contact with data or uses data as part of their everyday job. Formally engaging or providing data awareness to ‘everybody’ in the organization is not a bad idea. Formally engaging everybody in the same way is not a good idea. Let me explain …

Scenario: To keep it simple, in ABC Company, in XYZ division, there are three data analysts that use the data in the data warehouse to create business intelligence reports. The data analysts, directed by a lead data analyst, share their reports with three executives, two other division managers, and the results are posted on the intranet for others to see, read and use. The case could be made to say that the data analysts are data users and data producers (thus potentially stewards), the executives that use the data to make decisions are data users, and in fact everybody that reads that reports on the intranet is a user of the data. The people that defined the data for the data warehouse are certainly stewards, as well as the people that extracted, transformed and loaded that data to the data warehouse. All of these people could be identified and recorded as stewards of this particular data in this particular instance. Lots of operational stewards … but is it too many to keep track of and to engage? The answer to that question is really up to you.

For the extremely detailed (over-detailed?) or perhaps smaller organization, all of the people mentioned in the previous paragraph and the data they steward could be recorded in a steward repository (meta-data repository of data about the stewards) and this meta-data could be used to communicate, coordinate and communicate around the data to a very fine and detailed level. Other organizations may decide that the lead data analyst should be identified and recorded as the data producer steward and that the executives should be recorded as the data users. The answer is different by organization, division or even project when deciding the operational data steward roles that will be formalized in your organization.

Not One Steward Per Data

One of the many facets of the “Non-Invasive Data Governance”™ approach is that data stewards do not need to be assigned. Another facet is, unlike how many organizations proceed, is that more than one steward typically exists for each subject area or domain of data. If your organization has multiple versions of any type of data (and who doesn’t), that means that more than one person is defining, producing and using that data in the enterprise. If companies identify that there are, for example, five (5) versions of customer data, all with their own versions of address, each with variances on the customer name, that are all being defined for the purposes of the people that define them, that should indicate that there is more than one operational steward for that type of data across the enterprise. Do they work together? Do they know each other exist? Is there any level of coordination or cooperation between these individuals? Formalizing data governance in a non-invasive way will be a strong building block toward a well defined level of coordination and cooperation.

If you go back two chapters in this series, I discuss the role of the data domain steward. The data domain steward has a somewhat different level of responsibility for the data that crosses business units and functional areas. Data in data warehouses, master data management solutions, ERPs, … all require the enterprise perspective (responsibility or accountability) which is handled by the data domain steward.

Single Business Area Vs. Cross Functional Areas Decision Making

So we now recognize that the bottom slice of the pyramid represents the operational layer of the organizations. Many organizations want to push a large percentage (if not all) business unit-specific data issues and decision-making down to somebody at the operational business unit level. These decisions are typically made by the role (in this framework) of the operational data stewards – or people that are presently informally involved in the definition, production and usage of the data level. Should these decisions affect data that crosses business units (and much of the data does or will), the Data Domain Steward (Chapter 7) is typically engaged from that enterprise (rather than business unit) perspective.

Identify Operational Data Stewards First

One question I get asked all the time is “Once I am a steward, how much of my time will be spent stewarding?” I always respond to that question by saying “If you are the steward, how much time do you presently spend stewarding?”. That results in a long pause every time. The truth is, you should have been identified as an operational data steward because of what you are presently doing. If you are spending 4 hours a week in data standards meetings, 3 hours a week documenting your processes for managing data you use, and 3 hours a week generating reports (status and such) for your management and/or the clients, you are already spending time stewarding data.

Operational Data Steward Identification Questionnaire

The following series of questions can be used to anticipate the first concerns or questions from your operational data stewards:

QUESTION: Now that I have been identified as an Operational Data Steward, how will my present work change and how much time will I need to spend stewarding data? Let’s start with …

• Is there a specific subject area or domain of data where you have a lot of knowledge?
• Do you ever represent your part of the organization in major or minor projects, specifically those projects that require integration of data across the business units and information system?
• Do you spend much of your day using data in a specific domain, producing that data or even defining that data?
• Do you attend meeting where decisions are made regarding the definition, production or use of that data?
• Do you ever call, email, text somebody else in your organization regarding using their data?
• Does anybody ever call you regarding use of your data?
• Do you ever discuss the “data” with your boss or bosses, how they were calculated or derived?
• How much time do you spend already doing all this data “stuff”?

ANSWER: That should be the amount of time that you will be spending as an operational data steward. And notice that we said “already doing this stuff.” Stewards will continue doing this stuff, however the goal should be to help them do this stuff more efficiently and effectively.

“But wait. That means none of my work will change?”

“Hold on there, bucko. The goal is to get better at what we already do and to address the opportunities to improve where we don’t do things well. There will be some formalization of what we do well.”

Pause and then “Oh”

So … in other words, one of the early steps of a data governance program should be to identify the people that are already stewarding data, record that information in a way that it can be shared, and start to build from that knowledge. First identify. Not … First assign. This is an early key to a “Non-Invasive Data Governance” program.

Second, Recognize Operational Stewards

Once you have recorded information about the operational data stewards, the question is “what’s next”? It obviously is not enough just to identify and record who the stewards are. And for certain, you cannot go to that person and say, “We identified and recorded you as an operational data stewards so ‘go do steward stuff’.”

So … what do you tell a person that has been identified, recognized so to speak, as an operational steward? Well the first thing you may tell them is nothing. The chart below shows the operational improvements that many organizations seek out for short, mid and long term operational improvements and points out that the shortest of term improvement may come from just knowing and understanding who the stewards are.

From this information you can improve:

• Communications of new or changed business rules pertaining to specific data
• Communications of new or changed compliance rules pertaining to specific data
• Identification of appropriate people to engage around issues pertaining to specific data

Educate Operational Stewards Third

When you have identified and recognized your Operational Data Stewards, the immediate thoughts often turn to getting the data stewards involved in “stewarding” data. My suggestion is that you take time prepare for engaging the stewards. Often times, once a Data Steward has been identified and recognized, the first questions out of their mouths are – “How much time will I spend stewarding data and how will my work change?” You must be prepared to answer these questions.

Successful organizations look at “Non-Invasive Data Governance”™ from “pro-active” and “reactive” perspectives. The education for the data stewards should address both of these perspectives. In the proactive mode – an operational data steward’s activities around the data are formalized into existing processes (as mentioned earlier) such as a lifecycle methodology or standard operating procedures. In the reactive mode – stewards are engaged to analyze, research and resolve data issues. In both cases, the Operational Data Stewards should already be involved in these types of activities.

The education of the Operational Data Steward could be as simple as communications around the management of data that they define, produce and use. Several organizations that I work with have focused on “Data Awareness Programs” that generally improve information flow around the compliance, security, privacy and classification of critical data. The education of the Operational Data Steward could be as detailed as focused walk-throughs of existing processes and methodologies with a focus on process re-engineering and total quality improvement.

• Before engaging Operational Data Stewards, it is important for them to understand:
• How and why they were identified, recognized and recorded as data stewards
• What “Non-Invasive Data Governance”™ is and why it is a practical and pragmatic approach to data governance
• What it means for their data association to be formalized
• How they will continue to do – what they do – with an emphasis on governing and stewarding data
• The importance of taking the role of Operational Data Steward seriously

Education before engagement should always be a rule of thumb. Especially when it comes to data governance.

And When That is all Completed, Engage Operational Stewards

This next section of this article is taken from a response to a handful of questions a friend sent me seeking assistance to sell data governance into her organizations. She asked “What will we ask the business team to do in this program?” The full answer, covering the data governance team, the data governance council, data domain steward and data steward coordinators covered in the previous articles of this series, can be found at http://www.tdan.com/view-articles/7596.

My response to my friend was as follows … “The people in the business areas will be identified by their existing relationship to the data that will be governed.  These people are recognized as operational data stewards, people that already define, produce and use data as part of their function.  Initially these people are just identified and recorded but time commitments over-and-above their existing time commitment is not requested.  This can change over time but the amount of time they spend and the activities that they are presently involved bin do not have to change significantly.  Note: many organizations that engage operational stewards as part of an analytic reporting, data warehousing, master data management initiative first think that the time requirement for stewarding data becomes very great and they ‘blame’ it on the data governance initiative.  Truth is, this time (or more) would be spent with or without data governance in place.”

When engaging operational stewards, the “Non-Invasive Data Governance”™ approach suggests that you want to steer clear of “interfering” with these stewards existing work (to whatever extent possible). The short-term results of a non-invasive program should be improvements in communications, the mid-term improvements in coordination and cooperation, with the longer-term improvements focusing on day-to-day operational activities and building governance of data into the culture.
  

The Operational Data Steward plays an important role in a data governance program. As mentioned in the last two articles (Chapters 7 & 8), I consider the tactical roles of the Data Domain Steward and the Steward Coordinator to be the “pivotal” roles of the program. The Operational Data Stewards are often the worker-bees, managing data for their business function and cross-business functions when those types of initiatives are in progress. The Operational Data Steward must be communicated with, educated in the discipline that is required around the data they define, produce and use, and engaged day-to-day as they always have been (with formal formality, so to speak) in their interaction with the data.

The next article in the series will detail the two side-bars to the pyramid framework shown above. The two side-bars represent the Data Governance Planning/Program Team and the role of Information Technology in the “Non-Invasive Data Governance”™ approach. Please feel free to contact me via email to discuss this article in greater detail or to find out how to implement a “Non-Invasive Data Governance”™ program at your organization.

Copyright © 2008 – Robert S. Seiner
The Data Administration Newsletter, LLC
KIK Consulting & Educational Services, LLC