THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

The Data Stewardship Approach to Data Governance: Chapter 7

The Tactical Layer – The Data Domain Steward

Published: October 1, 2007

This is the seventh article in a series of articles by Robert S. Seiner. The past few chapters have discussed the KIK Data Governance Framework© that is demonstrated in the diagram below.Part 6 of this series focused on the Data Governance Council. The discussion continues with the middle section (darker yellow) of the pyramid structure – the one that I label as the tactical layer. The tactical layer typically consists of two pivotal roles that I refer to as the Data Domain Stewards and the Data Steward Coordinators. This article focuses on the Data Domain Steward. The articles in the coming months will address each level of the pyramid as well as the side-bars and the tower sticking out of the top. Please address all comments and questions to Mr. Seiner.

 

During consulting engagements, classes or conference presentations, I often refer to the tactical layer as being the biggest hurdle for organizations to get over while implementing Data Governance programs. Many organizations have become accustomed to operating in silos even though they recognize that this is at the root of their data problems. The switch to a tactical and cross LOB (often called the “enterprise”) perspective most often brings with it pain, political battles, differences of opinion and loads of work. It’s no wonder people don’t want to stand in front of that train.

Identifying a position (or positions) that have the responsibility for the enterprise perspective for a subset of the enterprise’s data can also present a challenge. In the KIK Data Governance Framework, the tactical layer represents this cross-LOB perspective at a tactical level. If you recall, the last article of this series focused on the top section of the Framework as the cross-LOB strategic perspective. To satisfy the need of managing data tactically across lines of business requires that a person in a specific position have the responsibility for that cross-LOB vision at a tactical (managed cross-operational) level. This person is the Data Domain Steward.

Enterprise Data Perspective through Domains

It should be obvious that a single person cannot manage ALL of the cross-LOB data. Therefore it is important to separate the data that crosses business units or functional areas into subsets or buckets (so to speak) of enterprise data. I refer to these buckets as domains of data. The primary responsibility of the Data Domain Steward is to be accountable for how the data in their domain is managed. This can be a very important responsibility depending on the domain of data.

From my experience, there are three primary ways to spell out the domains of data for an organization:

1. By Subject Area – This is the most common approach. The question always arises as to the appropriate level of granularity to define the domains. “Customer” may be too large and complex while “Customer Mailing Address” may be too granular. I was recently asked “how many domains of data will I need and what is the typical number of domains identified in other organizations?” This is not a simple question to answer. It depends on the complexity of the data and ability to associate responsibilities to sets of data elements. Some organizations start at a higher less granular level and break domains into sub-domains or even sub-sub-domains if the need arises. The lower the level of granularity, the more domain stewards. That can be a simple rule of thumb but it does not necessarily mean that all domains are the same granularity or that a Data Domain Steward cannot be responsible for more than one domain of data. Sometimes, when data doesn’t perfectly slot into one subject area or another, data can be associated with more than one domain. This is not a recommended approach but sometimes it is unavoidable.
   
   
2. By Level-1 and Level-2 Data Resources – This is the second most common approach. Level one data resources are defined (in this context) as operational systems or data resources that address the needs of a single business unit or functional area. Data in Level-1 address specific operational needs and are typically referred to as “self contained” within a business unit. Sometimes Level-1 data can be managed locally or even at the desk top or unit server level. Level-2 systems or data resources occur when data is fed from multiple Level-1 data resources into data warehouses, data mart, MDM solution, ERP or package, integrated data sets – anyplace where data is shared across business units or functional areas. The issue with defining domains by Level-2 Data Resources is that it often results in data falling in numerous data domains, thus adding complexity to the data governance program.
   
   
3. By Organizational Unit – This is seldom, if ever, used. Many organizations have tried and failed to define domains by organizational units because this approach promotes the silo and vertical view and management of the data.
   This person with the enterprise perspective of a ‘domain’ (typically a subject area) of data holds a pivotal role in the execution of the program. I refer to this person as the Data Domain Steward.

Data Domain Stewards

A Data Domain Steward may or may not be a decision maker for their domain of data (or in general). Whether or not the Data Domain Steward is a decision maker often depends on the position identified to be the domain steward and the responsibilities typically associated with that position. Some organizations identify Data Domain Stewards through approved policy and anoint the defined position to be the decision makers for their domain. Other organizations on the other side of the spectrum have taken volunteers to represent the domains of data as facilitators toward resolution of issues around the data in that domain. There is no right or wrong answer but one thing is for certain. Organizations recognize the need to move toward the enterprise or data domain perspective.

Is the Data Domain Steward an Authority or Facilitator?

Since there is not a single specific level of the organization that is associated with all Data Domain Stewards it is difficult to state that the Data Domain Stewards are always THE authoritative decision makers. Sometimes Data Domain Stewards are in a position of authority or have the ability to break the ties between operational units. Other times, the domain stewards have less authority and become facilitators in setting standards and resolving issues with the intention of resolution cross business units without the need to escalate decision making up to the Data Governance Council (at the strategic level). If you recall, in the last chapter of this series I state that organizations often try to severely limit the number of escalations to the strategic level (often less than 10% or 5%).

How are Data Domain Stewards Identified?

Data domain stewards typically fall within a specific line of business or business unit, and have an existing title (something other than Data Domain Steward). However, when the Data Domain Steward is acting in the Domain Steward role, their allegiance to their business unit needs to be placed on the back burner as they should have the ability to focus on the enterprise perspective rather than just the specific interests of their business unit. The inability to act in an enterprise capacity will lead to inability to gain the trust and support of the enterprise for decisions that are made or recommendations for decision to be made coming from that position (see traits of data domain stewards in the next section).

Data Domain Stewards are typically determined in one of a few ways:

• The domain stewards are the logical position (or person) considering the domain of data. For a university, the domain steward for student registration information may be the Registrar. The Director of Human Resources (or a designee of that position) may be a logical choice as the domain steward of HR data. The Director of Marketing could be the domain steward of Marketing Data, and so on. The ability to make the logical decision of the position associated with becoming the data domain steward may be easy or more difficult based on how you select your domains. If it becomes difficult to identify a logical position to be the domain steward, an organization may consider breaking the domain of data into multiple sub-domains that would bring with it the need for their own domain stewards.
  
  
• Or … The domain stewards are designated by the Data Governance Council. The Data Governance Council was addressed in the previous chapter of this series. Sometimes the Council names the data domain stewards. This works a percentage of the time as the Council looks for logical people to play the domain steward role. The selection of domain stewards appear contrary to the Non-Invasive Approach© to Data Governance that I have mentioned in previous chapters. By assigning someone the role, there must be consideration for the existing work load that is carried by the individual selected. Giving someone responsibility that does not have the bandwidth to carry out the position can lead to an inability to manage domains of data from an enterprise perspective.
  
  
• Or … The domain stewards are identified by policy. From my experience I have seen organizations identify their domain stewards through verbiage in the data operations, data classification, data security and privacy policies. Again, the authors of the policy do their best to select the logical position to carry out the data domain steward role. Again, the existing workload of the selectee becomes very important.
  
  
• Or … The domain stewards volunteer for the role. From my experience I have seen individuals step forward and volunteer to be the domain steward for a described domain of data. I overheard one gentleman state, “I may not know everything that is needed to be known about the domain of data, but I will do my best to facilitate acceptable standards of data within my domain and facilitate acceptable resolution of data issues pertaining to the data in my domain.”

There is not a single way to identify the position that should be associated with managing to a domain of data.

Traits of a Data Domain Steward

Here is a list of personality and human traits that I have found useful in identifying people that are appropriate Data Domain Stewards:

• Data Domain Stewards should have a vision of what the future of data integration within the department can be and have the ability to get others to see the vision and align all data-related activities with achieving the goals of the organization.
  
  
• Data Domain Stewards are rarely satisfied with the way data is managed. They should constantly be looking for ways to improve the status quo of how data is managed and as a result, constantly strive for improvements in how data is defined, produced, and used.
  
  
• Data Domain Stewards should have the ability to motivate the organization to achieve data integration by including all parties that are interested (or mandated) to integrate their data.
  
  
• Data Domain Stewards should set an example of data-related behavior for the department. They should exhibit the data-related behavior they want from the department every day and in everything they do.
  
  
• Data Domain Stewards should be team players. They must develop and help achieve common goals and a shared sense of purpose regarding their specific subject matter and its linkages with organizational goals. They should be able to draw on their own strengths and look to others as a resource, and hold one another accountable where they are interdependent.
  
  
• Data Domain Stewards should be diplomatic when dealing with other Stewards. Conflict is an inevitable part of teamwork, as people are different from one another and situations are frequently ambiguous where values may differ. An inability to come to grips with conflict is a serious limitation to a team player. Data Stewards must have the personal interest, intuitive ability and communication skills to facilitate issue resolution to achieve a “win-win.”

These traits were initially developed while working with a gentleman by the name of Terry Drent (at that point he worked for Keane) several years ago while we were both on an engagement working for a state department in Florida. Terry made a strong point that “not all people have the tools to be a Data Domain Steward.”

What Does the Data Domain Steward Do? When Does a Data Domain Steward Get Involved?

These two questions are perhaps the most important questions that need to be answered. I will answer these questions through a series of bullet points that highlight some of the most important tasks of the Data Domain Steward.

Here are a few examples of when Data Domain Stewards get involved and what they do:

• A Data Domain Steward gets involved when standards are being developed for data elements within their data domain. This definition of standards occurs when integrating data or developing a new “go-to” data resources such as an enterprise data warehouse, master data management solution, package implementations such as ERP solutions. Getting people to agree on what the data should “look like” moving forward is a responsibility of a Data Domain Steward.
  
  
• A Data Domain Steward gets involved when resolving issues pertaining to data in their domain. This is often an add-on to the previous bullet. Differences of opinion are inevitable when the development of data resources in the past have been marked by autonomy whether on purpose (mergers and acquisitions), or by lack of management over how data has been defined, produced and used in the past. The effort of pulling disparate data together is typically difficult with the same (or similar) data being defined numerous ways. The Data Domain Steward is often in the middle of deciding how the data in the integrated data set should look and how data from the disparate sources is mapped to the integrated data set.
  
  
• A Data Domain Steward gets involved when it becomes important to document and communicate the rules and regulations around the data in their domain. The Data Domain Steward (or a designee) is the appropriate position to have the responsibility of documenting how the data in their domain is classified (open, sensitive, restricted), secured, the business rules around the data in their domain, audited, and regulated. The Data Domain Steward has the responsibility to make certain that this documentation is collected, recorded, communicated and shared among all stakeholders in their data. It is no longer acceptable for a company or an individual in a company to state “I didn’t know the rules.” The government has taken care of this for us and there are severe penalties and levels of risk associated with “not knowing.”
  
  
• A Data Domain Steward gets involved in new projects where data in their domain is defined, produced and used. Often these projects may take place over large periods of time and this is not to suggest that the domain steward participates in every step of these projects. Typically the domain steward is asked to participate in the activities that focus on the definition of standards and resolving cross-business unit issues pertaining to the data in their domain. The balance of the stewarding activities is typically left to the operational data stewards (to be discussed in a future issue) who are the daily definers, producers and users of data within their business units and functional areas.

The Data Domain Steward plays a pivotal role in a successful data governance program. Identifying the data domains, identifying the Data Domain Stewards and enabling the domain stewards to successfully manage data across the enterprise is an early step addressed in the development of a Data Governance Program.

The next article in the series will detail the responsibilities of the other tactical role of the KIK Data Governance Platform, the role of the Data Steward Coordinator. 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.