This article originally appeared on the BeyeNETWORK.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Key data entities are the fundamental information objects that are employed by the business applications to execute the operations of the business while simultaneously providing the basis for analyzing the performance of the lines of business. While my description casts the concept of a key data entity (or KDE) in terms of its business use, a typical explanation will characterize the KDE in its technical sense. For example, in a dimensional database such as those used by a data warehouse, the key data entities will be reflected as dimensions. In a master data management environment, those data objects that are designated as candidates for consolidation into the master repository are likely to be the key data entities.
Managing unique copies of key data entities is a core driver for master data management (MDM), especially due to their inadvertent replication across multiple business applications. However, we have addressed the topic of divergent definitions and fragmented formats numerous times. Instead, let’s consider two challenging aspects of enterprise information management: KDE ownership and data quality management.
The ownership question is the stickier of the two. In fact, data ownership itself is always a challenge, but when data sets are associated with a specific application, there is a reasonable expectation that someone associated with the line of business using the application will (when push comes to shove) at least take on the responsibilities of ownership. But as key data entities are merged together into an enterprise resource, how are the ownership responsibilities reallocated?
There are two possible trains of thought. The first says that as an enterprise resource, KDEs stored as master data objects are owned by the organization, and therefore the responsibilities of ownership are assigned to an enterprise resource. There are some benefits to this approach. For example, instead of numerous agents responsible for different versions of the same objects, each is assigned to a single individual. In general, management and oversight is simplified because the number of data objects is reduced, with a corresponding reduction in resource needs (e.g., storage, back-ups, metadata). One major drawback to centralizing ownership is political, since the reassignment of ownership, by definition, removes responsibilities from individuals, some of whom are bound to feel threatened by the transition. The other is logistic, focusing on the process of migrating the responsibilities for data sets from a collection of individuals to a central authority.
A second approach is to assign ownership of a KDE to representatives from one of the lines of business that contributed to the consolidated representation. In other words, ownership is assigned (or retained?) based on some subjective criteria in a distributed manner. One benefit of this approach is that it does not create new work for the limited resources at the enterprise level. In addition, there is a reduced risk of a gap in support, as the selected owner will already have stewardship processes in place. One drawback is that the overall management and oversight is much more complicated, as the absence of a centralized process for oversight may increase risks of uncontrolled activity.
So which is the better approach? Let’s look at the question from a different angle by asking about the expected goals of transitioning to a centralized master repository for KDEs. For the most part, any enterprise initiative like master data management (MDM) or enterprise resource planning (ERP) is based on strategic drivers with the intention of adjusting the way the organization works. Master KDE consolidation is meant to provide a high quality, synchronized asset that can streamline application sharing of important data objects. ERP implementations reduce business complexity because the system is engineered to support the interactions between business applications, instead of setting up the barriers common in siloed operations. In essence, the goals of these strategic activities are to change the way that people work, increase collaboration and transparency, and transition from being tactically driven by short-term goals into a knowledge-directed organization working toward continuous performance improvement objectives.
Therefore, any implementation or operational decisions made in deploying a strategic enterprise solution should lead to increased collaboration and decreased distributed management. This suggests that our first approach of centralized ownership of key data entities by agents for the entire organization is more aligned with the strategic nature of an MDM or ERP program.
What about the drawbacks? Actually, the pain incurred through the transition process may be a blessing in disguise. Turf protection and blockading are symptomatic of socio-political intrigues at the group or division level, but actually may hide more troublesome issues such as hidden incompetence or deliberate violations of policy. Exposing the issues allows the organization to flush out violators and “clean house.”
Our other significant pain point is the effort to migrate the responsibilities from a collection of individuals to a collective for the organization. Again, a potential blessing: the processes by which we identify the key data entities provide a forum for interaction in standardizing business meanings, definitions and metadata across the variant representations. A successful execution of these processes requires knowledge sharing, collaboration and consensus, which are some of our strategic objectives. So in other words, the transition of responsibility and accountability for the quality of key enterprise data entities not only achieves the tactical goal of centralized consolidation, it instills in the staff the good practices necessary to make the enterprise activity a success.