|
|
Chapter 7 |
In this chapter, I will start walking through the layers of the Operating Model where people in business areas take on the appropriate levels of accountability associated with the different roles of the model. In other words, this chapter will begin the layers of the pyramid diagram from the bottom up, starting with the different types of data stewards at the operational layers.
Chapter 7 addresses the Operational Layer of the Operating Model. The operational data stewards are located in this layer.
Non-Invasive Operating Model of Roles & Responsibilities with Operational Layer Highlighted
Operational Data Steward
If you subscribe to the Non-Invasive Data Governance approach, operational data stewards already exist throughout the organization. If this is new to you, please reread prior information to gain a better understanding of why and how I call the Non-Invasive Data Governance approach non-invasive. As part of their daily routines and work efforts, operational data stewards have some level of responsibility, though not necessarily authority, over data they define, produce and use.
Several years ago, the CIO at a state government organization said 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’s used by your part of the organization, you have responsibility for making certain it is consistent with the standard way we define that data.
This simple statement perfectly describes how an operational data steward becomes an operational data steward.
Rules for Becoming a Data Steward
I was recently asked if everybody in an organization is an operational data steward. One could argue that the answer is “yes” because everyone, at some time, comes in contact with data or uses data as part of their everyday jobs. Formally engaging or providing data awareness to everybody in the organization is not a bad idea. But formally engaging everybody in the same way is not a good idea. Let me explain.
A Data Steward Can Be Absolutely Anybody
If you follow or believe in the Non-Invasive Data Governance approach, you may have heard me say that you cannot tag each data steward, say “You’re it,” and expect him or her to start doing steward stuff. That’s not the way it works.
But I do say that each person who defines, produces, and uses data in your organization has a certain level of accountability or responsibility for how data are defined, produced, and used. Persons on the front line have accountability for entering data appropriately and accurately; persons who define data have accountability for making certain they’re not redefining something that’s been defined before. And certainly, individuals who use data have accountability for how they use data.
The problem is that right now, these levels of accountability are often informal, inefficient, and ineffective when it comes to the necessary levels of accountability that comprise a successful environment for governing your data.
Again, this is the main concept of the Non-Invasive Data Governance approach. If we can just formalize the accountability of these stewards of data and can convince management and the stewards that they, for the most part, already govern data, doing so will make communications with everybody from senior management on down much easier to digest. I can already hear data stewards saying, “Do you mean I already do this stuff?” Of course, your response would be, “Yes. We just want to put some formality around some of the things we already do.” And their response would be, “Oh, okay, I think I get it now.”
Being a Data Steward Describes a Relationship to Data, AND Is Not a Position
If you ask me, being a data steward is neither a position nor a title. Being a data steward describes a relationship between a person and some data, whether these data are a data element, data set, subject area, application, database—however granular you want to get with your association of steward to data.
Those who define data as part of their jobs should have formal accountability for making certain they record and make available a sound business description of the data they define. Or perhaps they should have accountability for identifying and using data that already exist somewhere else. Or they should have accountability to get the appropriate people involved in the efforts to define the data.
This person can be associated with Business Intelligence (BI), Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), Master Data Management (MDM), big data, package implementation, or data in the cloud effort where new data are defined for an organization. The Non-Invasive Data Governance approach calls for data definition stewards to become formally accountable for the quality of data definition.
Those who produce data as part of their jobs should have formal accountability for making certain that data are produced following the business rules, hopefully recorded, for these data. Or perhaps they should have accountability for making certain that the data they produce are entered into the system or wherever in a timely manner. Or they should have accountability for making certain that appropriate people are notified when data are updated, when data accuracy provides low levels of confidence, or when data haven’t been received. This individual can be a data entry person, a data integrator, a data analyst, a report generator, or a person involved in any of the efforts described in the above paragraph. The Non-Invasive Data Governance approach calls for data production stewards to become formally accountable for the production of data.
And this leaves the data usage stewards. Everyone who uses data in a job should be held accountable for how he or she uses that data. This means that the data governance program should focus early on recording and making available the rules—regulatory, compliance, classification, and any risk management effort—associated with data usage.
The data usage steward should be held formally accountable for individuals with whom data are shared. The data usage steward should be accountable for securing and protecting the data according to the recorded and available rules. This person could be anybody in the organization who uses data for his or her job. This can be anyone.
Does this mean we need to physically record every single individual in the organization who has a relationship to data? Well, probably not. Do we need to know every division, department, and group that defines, produces, and uses the data? Probably so. Please see in Chapter 11 a copy of a Common Data Matrix spreadsheet tool I developed and have used repeatedly with organizations to help them formally record who does what with specific data across their organizations.
Being a data steward (whether as a definer, producer, or user of data) and the formal accountabilities inherent with being a data steward all comes down to each individual’s relationship to data. A data steward may have two or three of the three relationships to data and may then have greater levels of formal accountability. Again, anybody can be a data steward.
A Data Steward Is Not Hired To Be a Data Steward
I’ve seen organizations post full-time-equivalent (FTE) jobs for data stewards. I think this is a mistake for most organizations. As you can tell from my rules thus far, I think that data stewards already exist in your organization and they can be anybody.
I make this a rule because the people in your environment are already the stewards of data even though they may not formally consider themselves as such. Stewards are not hired unless you are hiring into other positions, and the mere fact is that any position probably defines, produces, or uses data as part of its responsibilities.
In my Operating Model of Roles & Responsibilities, I differentiate between operational data stewards, described in the previous rule, and data domain stewards at the tactical level. The data domain steward typically has a level of formal accountability, or sometimes authority, to make decisions for a specific domain or subject area of data for an entire organization or whatever part of the organization falls under the auspices of the data governance program.
Some organizations designate the data domain stewards through formal guidelines and policies. A Big Ten University I recently worked with focused on data classification as the primary driver of its data governance program. The classification policy spelled out that the registrar was the data trustee—another name for data domain steward—of student data, that the controller was the trustee of financial data, and the vice president of human resources was the trustee of employee (staff) data. This way of doing things is becoming more typical then we may think.
It makes sense for organizations to spell out, by position in the organization, the persons who hold the responsibilities of the data domain steward. In some organizations, this position is not the know-all and be-all authority on that subject matter of data. Yet this person is held in high enough regard across the organization to make certain that the data in his or her subject matter is governed properly.
In a situation where the data domain steward is not the authority or person who can make decisions for the organization, it becomes the responsibility of the Data Governance Council at the strategic level to make these decisions. It’s been my experience that decisions about data are rarely escalated above the council level to the executive level.
A Data Steward Doesn’t Need the Title of Data Steward
If everybody is a steward of data, then there’s no reason to change people’s job titles. Wouldn’t doing so get confusing? As I stated earlier, any person with any title may be a steward of data. Therefore, and to stay less invasive, we should allow individuals to retain their original titles and educate them on the formal accountabilities that accompany their relationships to data. In most cases, this won’t mean a major work shift for data stewards. This doesn’t mean there’ll be no work shift, only that it won’t be a redefinition of their position or what they do.
The same probably holds true for the data domain steward. A controller need not be called the Finance Data Domain Steward and a registrar doesn’t have to be called the Student Data Domain Steward. It’s most important that these individuals are recognized as the persons filling the role of the data domain steward.
A Data Steward Doesn’t Have To Be Told How To Do His or Her Job
A great debate is going on over whether or not data stewards need to be told how to be data stewards and whether or not data stewards can be certified as data stewards. The answer to both considerations is that it depends. Well, what does it depend on?
In my experience, data stewards don’t have to be taught how to be data stewards. Rather, data stewards can be educated on the formalities of their existing relationships to data. A person who uses data must be educated on what data mean, where data came from, how data may and may not be used, how data may or may not be shared, etc. A person who produces data must be educated on the impact of how data are entered and the guidelines for the production of those data. I think you get my point.
In some ways, you could say that data stewards need to be told what this formality means and how to be the best data stewards they can be. Then the question becomes, “Does this mean we need to tell data stewards how to do their jobs?” And to that, I say a resounding “No!” We don’t have to teach data stewards how to do their jobs.
Public or Industry Data Steward Certification Is a Load of Bunk
This is the second half of the answer to the questions raised by the previous rule. I firmly believe that data stewards can’t be certified. Every data steward has a different relationship with data and, therefore, a different responsibility, some with formal accountability and some without.
I know some industry organizations focus on coming up with the credentials to become a certified data steward. But I’m against this idea.
I’m not against a practitioner organization or a company setting up credentials and training internally for their stewards to certify them in their positions as a steward of the specific data that define, produce, and use. Please understand this distinction. Organization certification, yes. There are well-documented cases of organizations certifying their own data stewards. Industry certification, no.
To have an industry group certify data stewards would be like telling them how to do their jobs. And you already know that this subject is covered by the previous rule.
You may tell me that data stewards could be educated but not certified on the types of activities that go with their relationship to their organization’s data. This may include everything from how to access metadata and business rules about data to the formal processes that must be followed to the method of getting something approved, changed, communicated, or retired. I just have a hard time understanding how someone outside an organization and culture can provide this level of industry data steward certification.
To summarize these points, let me state again that data stewards need to be educated on the formal accountabilities that go with their relationship to data. This education may include information security and operational data rules, compliance and regulatory rules, standards and processes that have been defined—if not, they need to be—for their relationship to data.
So therefore I say “bah humbug” to industry-level data steward certification. And I make it one of my rules for being a data steward.
More Than One Data Steward Exists for Each Type of Data
I can’t tell you how many times I’ve begun working with an organization where a number of people point their fingers at individuals and say, “Jim, he is our Customer Data Steward.” And “Mary, over there, she’s our Product Data Steward.” And “Mike is our Employee Data Steward.”
Identifying people this way is not right. At least not if you follow any of the rules I’ve outlined above. Please remember that in the Non-Invasive Data Governance approach, the idea that only one data steward per type or category or subject matter is invalid. That is, unless you are talking about data domain stewards who could be given the role of the Customer Data Domain Steward, Product Data Domain Steward and so on. These people have accountability across business areas. Do not forget to insert the word domain or subject area into the role title, just to define more clearly the responsibilities of the role.
The truth is that there are many data stewards for practically every type of data that exist in your organization, if you include each person who has a relationship with data. Do we need to know exactly who all these people are and call them data stewards? No. Do we need to know that there are people with a relationship to a particular type of data within a certain part of an organizational? Yes. How else will we be able to communicate with them about these data? We need to know where data stewards exist.
Data Steward Training Should Focus on Formalizing Accountability
Rather than certifying individuals as data stewards, a data governance program should focus on educating data stewards in your specific organization about the formal accountabilities of their specific relationships to data. Definers get education on the accountabilities that go with defining data. Producers are educated on accountabilities that go with data production. Perhaps most important, users receive education on accountabilities related to using data. And individuals who actively have two of the three relationships or three of the three relationships receive data governance education on all relationships that apply to them.
And not just general education about what data stewards do. I’m talking about education that specifically pertains to the definition, production, and use of data they use or data they steward as part of their everyday jobs.
This may be scary for some organizations since they may not have the accountabilities of each relationship for each type of data defined in a way that can be shared with their data stewards. Well, this gives you a place to start with your data governance program.
If you, as the data governance program definer, haven’t defined what these relationships mean, the formal accountabilities that go with the relationships, or the specific rules associated with how data domains can be defined, produced and used, how do you expect data stewards to know what to do? Again, this gives you a good place to start.
|
Key Points
|