Chapter 8 Roles and Responsibilities – Tactical Layer

During consulting engagements, classes, or conference presentations, I often refer to the tactical layer as the biggest hurdle for organizations to get over while implementing data governance programs.

Non-Invasive Operating Model of Roles & Responsibilities with Tactical Layer Highlighted

Many organizations have become accustomed to operating in silos even though they recognize that this lies at the root of their data problems. The switch to a tactical and cross line of business (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 this 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. 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 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 the cross-LOB data. Therefore, it’s important to separate data that cross 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 data in their domain are managed. This can be an important responsibility depending on the domain of data.

From my experience, there are three primary ways to spell out 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 isn’t a simple question to answer. The answer depends on the complexity of the data and the ability to associate responsibilities with sets of data elements. Some organizations start at a higher, less granular level and break domains into subdomains or even sub-subdomains if the need arises. The lower the level of granularity, the more domain stewards. This can be a simple rule of thumb, but it doesn’t necessarily mean that all domains are of the same granularity or that a data domain steward can’t 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’s unavoidable.
2. By Level-1 and Level-2 Data Resources. This is the second-most common approach. Level 1 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 desktop 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 marts, Master Data Management (MDM) solutions, Enterprise Resource Planning (ERP) or package integrated data sets—anyplace where data are shared across business units or functional areas. The issue with defining domains by Level-2 data resources is that doing so often results in data falling into numerous data domains, thereby adding complexity to the data governance program.
3. By Organizational Unit. This approach 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.

The 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 Steward

A data domain steward may or may not be a decision maker for a 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 domains.

Organizations on the other side of the spectrum have taken volunteers to represent the domains of data as facilitators to resolve issues around the data in that domain. There is no right or wrong answer, but one thing is certain: Organizations recognize the need to move toward the enterprise or data domain perspective.

An Authority or Facilitator?

Since there’s not a single, specific level of the organization that’s associated with all data domain stewards, it’s difficult to state that 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. At other times, data domain stewards have less authority and become facilitators in setting standards and resolving issues with the intention of resolution across business units without escalating decision-making up to the Data Governance Council at the strategic level.

How Do You Identify a Data Domain Steward?

Data domain stewards typically fall within a specific line of business or business unit, and have an existing title that’s something other than data domain steward. When the data domain steward acts in the domain steward role, allegiance to his or her business unit needs to be placed on the back burner. A data domain steward should have the ability to focus on the enterprise perspective rather than just the specific interests of a business unit.

The inability to act in an enterprise capacity will lead to the inability to gain the trust and support of the enterprise for decisions made or recommendations for decisions to be made coming from that position.

Data domain stewards are typically determined in one of a few ways:

• A data domain steward is 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 this 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 more or less 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 subdomains that would bring with it the need for their own domain stewards.
• The domain stewards may be designated by the Data Governance Council. 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 may appear to be contrary to the non-invasive approach to data governance I’ve mentioned before. Perhaps, but recognizing such a person as a domain steward, because of his or her level of knowledge or accountability for a specific domain or subject area of data, may carry a positive connotation of increased responsibility to the organization. By assigning or recognizing someone for this role, there must be consideration for the existing work load carried by the individual selected. Giving someone responsibility who lacks the bandwidth to carry out the position can lead to an inability to manage domains of data from an enterprise perspective.
• Domain stewards may be identified by policy. I’ve 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. In any case, the existing workload of the person selected becomes important.
• Data domain stewards may volunteer for the role. I’ve seen individuals step forward and volunteer to be domain stewards for described domains of data. I overheard one gentleman state, “I may not know everything that’s 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.”

As you can see, there’s no single way to identify the position that should be associated with managing a domain of data.

Traits of a Data Domain Steward

Here is a list of personality and human traits I’ve found useful in identifying individuals who are appropriate data domain stewards:

• Data domain stewards should have a vision of what the future of data integration within the department can be, 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 are managed. They continually look for ways to improve the status quo of how data are managed and continually strive for improvements in how data are defined, produced, and used.
• Data domain stewards should have the ability to motivate the organization to achieve data integration by including all parties 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 have 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, to look to others as resources, and to 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 differ from one another, and situations are frequently ambiguous where values may differ. An inability to come to grips with conflict seriously limits a team player. Data stewards must have the personal interest, intuitive ability, and communication skills to facilitate issue resolution to achieve a win-win result.

What do data domain stewards do, and when do they get involved?

These two questions are perhaps the most important questions to be answered. Here are some examples of what data domain stewards do and when they get involved:

• A data domain steward gets involved when standards are being developed for data elements in the steward’s data domain. This definition of standards occurs when integrating data or developing a new go-to data resource such as an enterprise data warehouse, a master data management solution, and package implementations like Enterprise Resource Planning (ERP) solutions. Getting people to agree on what data should look like moving forward is a responsibility of a data domain steward.
• A data domain steward becomes involved when resolving issues pertaining to data in his or her 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 in 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 when the same or similar data are 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 are 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 his or her domain. The data domain steward, or a designee, is the appropriate position to have the responsibility of documenting how the data in a domain are classified—open, sensitive, restricted, secured—and how the business rules around the data in a domain are 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 the data. It’s no longer acceptable for a company or an employee to say, “I didn’t know the rules.” The government has taken care of this for us, and severe penalties and levels of risk are associated with not knowing.
• A data domain steward gets involved in new projects where data in the steward’s domain is defined, produced, and used. Often these projects may take place over long periods of time. 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 activities that focus on the definition of standards and resolving cross-business unit issues pertaining to the data in his or her domain. The balance of the stewarding activities is typically left to the operational data stewards, 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 in the development of a data governance program.

Data Steward Coordinator

To manage or monitor the activities of the numerous operational data stewards in each unit or area, a best practice in data governance dictates that someone have the responsibility of coordinating the stewards’ activities. Most often, operational data stewards won’t govern themselves. As the name suggests, the data steward coordinator is a business unit or functional area responsibility for coordinating the activities of the data stewards in their units or areas.

This responsibility makes certain that stewards who define, produce, and use data are involved when they need to be in promoting healthy data activities and addressing data quality issues including:

1. Identifying data stewards in their business units/functional areas.
2. Coordinating data steward involvement in proactive and reactive data governance activities.
3. Communicating changes to data policy, regulations, and rules to the affected data stewards in their units/areas.

A data steward coordinator is often in the middle of data governance communications and data governance activities. One of the most important aspects of responsibility goes beyond traditional coordination or management of personnel activities. At several, critical points, communications tend to break down across organizations, putting the organization at unnecessary risk. The formalization of the data domain steward discussed earlier involves identifying a person or persons with responsibility for documenting, knowing, and communicating the rules around the data that are a part of their domains.

Data Domain

Stewards are responsible for recording and sharing information about changes to the data in their domains. This information may include:

• Policy – Description of and change to formal and approved manners to define, produce, and use data.
• Regulation – Description of and change to how an external entity dictates how data may be defined, produced, and used.
• Rules – Internal business specifications for how data may be defined, produced, and used.

While the data domain steward has responsibility for documenting and communicating these types of changes to the coordinator, the data steward coordinator has the responsibility for communicating the types of changes mentioned above to the data stewards in their units/areas affected by changes. This closes the loop of the communications process. The coordinator has the responsibility for communicating with the impacted people in their areas.

Assigning Data Steward Coordinators

Data steward coordinators are typically effective when their responsibilities are associated with the data stewards of their specific business units and functional areas. Therefore, the first step in identifying coordinators involves identifying the units/areas they’ll represent. The responsibility of describing the units/areas for data governance purposes typically falls into the hands of the team of individuals responsible for establishing the data governance program.

The units/areas are often gathered from an organizational chart, or they can be determined by documenting the companies, divisions, departments, teams, and so on, that make up your organization. If the units/areas are defined at a company level, the company determines how granular it wants to get with defining units/areas. For example, it’s not uncommon for units/areas to focus on different levels, some at units/areas at a departmental level and some at a division level.

Once the definition of units/areas has been completed, the most senior level manager of that lowest granularity group often identifies or assigns a logical person—sometimes, but not always, by position—to help coordinate the activities of the stewards in his or her group and to act as the point person for data-oriented communications.

Data Steward Coordinator Responsibilities

The data steward coordinator may be responsible for one, several, or all of the following responsibilities:

• Identifying the operational stewards of data per domain for their units/areas. This typically requires research and inventory time for the data steward coordinator.
• Acting as the point communications person for distributing rules and regulations per domain of data to the operational stewards in their business units and making certain that the operational data stewards understand the rules and risks.
• Acting as the point communications person for his or her business unit to document and communicate issues pertaining to specific domains of data to the proper data domain steward.
• Acting as the point person in the Common Data Matrix, or data steward repository, according to a regular change control process. A regular change control process takes place on a scheduled basis to assure that all changes that require a change to the Common Data Matrix are entered in a timely manner and on a regular basis.
• Working alongside the data domain stewards and operational data stewards on specific tactical data steward teams set up for the duration of issue resolution or project focused tasks.
• Researching exactly how and what data are defined, produced, and used in their units/areas and by whom.

Key Points The data steward coordinator typically has no decision-making authority but plays a pivotal role in data governance and data stewardship success. A data domain steward is the logical position or person considering the domain of data. 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. Data domain stewards should have the ability to motivate the organization to achieve data integration by including all parties interested or mandated to integrate their data. A data domain steward gets involved when standards are being developed for data elements in a steward’s data domain. Responsibilities of data steward coordinators include identifying data stewards in their business unit/functional areas, coordinating data steward involvement in proactive and reactive data governance activities, and communicating changes to data policy, regulations, and rules to the affected data stewards in their units/areas.