Studies show that the vast majority of large organizations across industries are embracing the concept of data governance as a mechanism to coordinate how shared data is defined, maintained and leveraged across the organization. Yet when consultants work with clients, we often encounter challenges in aligning a cross-system and cross-functional data governance concept with an existing system ownership model, where clear ownership for everything in a particular system – including the data – is already defined and placed with a businessperson. The problem is that many data elements are used in and synchronized between multiple systems, a fact the system-centric ownership model often fails to address. To solve this dilemma, it’s critical that an alliance is forged between your system ownership organization and your data governance organization, where clear boundaries for decisions and responsibilities are defined.

The Challenge with System Ownership from a Data Perspective

Consider a company with a strong and mature culture of system ownership anchored in the business, so that each business application (like a customer or supplier relationship management system) is owned by a manager who is responsible for the functionality delivered by that particular application. This concept has been implemented to ensure that all changes to a system are approved by the owner and to establish one person as the final escalation path. The system owners in the business have IT counterparts that own the technical aspects of the various applications.

The company has acquired countless business application systems over the years, which has made it increasingly more difficult to keep the systems aligned. Each system owner is responsible for the data in his or her respective system, and it’s a constant challenge to keep shared data aligned across different systems.

Key challenges related to managing shared data include:

  • The decision-making process around data-related business rules (e.g., list of valid industry codes or product types, or proper formatting of a customer address).
  • Implementation of data-related business rules as validations to ensure compliance.
  • Accountability for the quality of data.
  • Ownership of the data maintenance process.

These challenges may manifest themselves as material numbers in one system that doesn’t align with another. One system may use 0 or 1 for its flags where others use “Y” or “N.” Two system owners working in separate business functions may have conflicting views of product groupings or the importance of capturing correct telephone numbers. The more the data is passed around, the more the challenges proliferate.

Enter Data Governance

But help is at hand: A data governance model seems to be a concept that answers the challenges around data coordination. Data governance is the cross-functional framework of alignment, quality management and decision-making around data and its definitions. A data governance program is initiated at the company, data owners and data stewards are appointed, and data governance forums are established. The data owners and data stewards have the responsibility of making common data definitions, keeping the master data aligned across systems and improving the quality of data.

However, during the implementation phase of the data governance program, the project team encounters a major challenge: The systems owners and the data governance forum have an unclear overlap and differing agendas. On one hand, the system owners have a clear focus on delivering a set of functionalities (typically for a single business function) and ensuring process efficiency in the system, and on the other hand, the data governance forums are trying to coordinate across systems over which they really have limited decision authority. The two main battlegrounds are likely to be the master data maintenance processes and the data definition processes.

Data maintenance is typically considered a key control area under data governance, because this is where both good and bad data quality get started. To ensure common definitions for shared data across systems, the data governance project has defined new decision-making data governance forums that include representatives (data stewards) from various business functions. This is the optimal way to ensure alignment and an enterprise focus. These forums will meet and decide how data is defined and how it should be validated.

However, if changes to system validation rules and field configurations are controlled by the individual systems owners, there is a potential conflict here, since it is the job of the systems owner to ensure optimal effectiveness of their respective system, so they may not see data in the same enterprise focus as the data governance people.

Defining the Boundaries

There are good arguments for both strong system ownership and for cross-system data governance, so the solution to the dilemma is to forge an alliance where the two concepts can coexist and complement each other. For this alliance to work, explicit boundaries are required so it is always clear with which group the responsibility for a particular issue lies. System owners from the business often are obvious candidates for the data owner roles, which simplifies the potential conflicts.

So how should you divide the responsibilities when introducing a data governance model in a company where a strong system owner culture exists? Follow these general recommendations: 

1.   Ownership of the data maintenance process.

System owners should be responsible for everything that happens within the boundaries of their systems. This includes the data maintenance process and any system-specific documentation. There are really only a few occasions when there is a clear case for the data governance organization to own and manage the end-to-end master data maintenance process:

  • If nobody currently has ownership of the data maintenance process, then anything is better than nothing.
  • If the data maintenance process can be separated from the system operation as some form of service.
  • If a business process ownership concept is already implemented (business-anchored ownership of processes that may span multiple systems and departments), the data governance organization can easily become the process owner for the data maintenance process.

In all of these cases, you will only get an effective setup if the data governance organization takes responsibility for the whole of the data maintenance process. If only certain fields on a particular screen are considered global and part of the process owned by the data governance organization, then splitting responsibility for what happens on that particular screen isn’t ever going to work. This means that the scope of data under data governance needs to cover all fields that appear together on a maintainer’s screen. That’s never an issue when you only have system ownership, but data governance doesn’t have such clearly defined boundaries.
When data is maintained across several systems with some attributes being entered in one system and others in another, data owners should take responsibility for the cross-system workflows, which act as a container for the individual system maintenance processes.

2.   Common data definitions.

Data owners (along with the various business-based data stewards) should be responsible for defining the cross-system data model, which includes the business and validation rules for the data. System owners should provide input on common definitions and assist with impact and benefit analysis. Even though an organization should strive to implement common data standards across systems, the consequence of doing so is not always acceptable. For instance, it may be desirable to standardize units of measure across systems, but the cost of physically changing all the codes in a system (as opposed to mapping the values) may outweigh the benefits.

3.   Compliance with common data definitions.

System owners should be responsible for managing changes to their systems to bring them into compliance with the common data model, and system owners should be responsible for ensuring that changes to their system comply with the common data model.

4.   Data quality.

Data owners should be responsible for defining quality requirements for data and for auditing the data for compliance. If a system is in non-compliance, then the data owner will raise an issue. System owners should be required to respond to data quality issues in the same manner in which they would respond to any other issue.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access