Many years ago, when CASE tools were touted as the solution to everything, ERwin was just hitting the market, and web-based application development was still in its infancy, I participated in a two-hour governance meeting with 24 people – business experts, IT project managers, data architects, and data managers – to determine whether or not to add a new Type Code to the Nasdaq Market Parent Model in CoolGen.
Now if you have ever had the privilege of modifying a Parent model on the CoolGen mainframe and re-subsetting Business Area (BA) and Project models from same, you know that any changes to the base model are a Big Deal – especially if procedures have already been written against Project models (subsets from BA models, which in turn are subsets from the Parent model). This is one of the (many) reasons why, despite very useful features for capture and control of metadata and standardization of data assets, most organizations abandoned CASE tools. The price of enforced process and force-feeding for a streamlined data layer seemed too high – especially for developers, who fretted under the restrictions imposed by the processes embedded within the tools.
In this case, since “Organizations” was a central subject area, the change would affect two BA models, potentially causing downstream consequences to multiple projects. The Directors of Data Administration and Information Engineering opened the meeting: ‘the purpose of this meeting is to discuss the impact of adding an Organization Type Code.’ We were off and running – what was a reasonable definition, what were the impacts to existing business rules, existing projects, etc. The timbre of voices soon became tense, incited by the project managers under strict deadlines. Before five minutes had passed, the room was charged with tension, and soon the shouting began.
That unpleasant meeting left a sharp impression; it could be an example in a book which might be titled “The Pitfalls of Data Governance” in the chapter “Never, Never Do This.” It illustrates the necessity for: identifying high impact data changes early; communicating changes to stakeholders in time for them to adapt; and above all, establishing collaborative data governance that works and holds up in stressful circumstances.
Through cumulative governance activities, and in evaluating data management program capabilities for organizations, I’ve realized that to implement a successful, collective, organization-wide approach to building, sustaining, and controlling the data assets, it is vital to win the hearts and minds of everyone involved – data stewards, custodians, executives, and business knowledge experts. If individuals aren’t convinced that their efforts will lead to something of value, governance will not deliver on its promise.
The term “culture change,” in this context, means ‘educating stakeholders so that each understands the importance of his/her effort and is willing to take it on.’ This implies accepting responsibility for shared data assets (or appropriate portion(s) thereof) on behalf of the enterprise, as well as being willing to work together on decisions and approvals.
To find an activity-based fulcrum for launching or revitalizing a data governance program, we’re looking for an initiative that fulfills a business need, and meets the following criteria: inspires an individual’s sense of purpose and responsibility; cannot succeed without collaborative agreements; and facilitates developing a collective sense of mission and achievement. And there’s a very good option close to hand. The most naturally-focusing endeavor for participating stakeholders, to prove to themselves the value of collaborative governance, is mutually crafting approved business terms for the Business Glossary. Why? Because capturing metadata is the Great Synthesizer mechanism for all parts of the organization, because business terms are the core of the organization’s metadata, and because line of business experts are essential in order to define them.
The Business Glossary is the fundamental mechanism to manage data as meaning.
A common understanding of the meaning of terms is key to mutual understanding of shared data by multiple business lines, both for basic and derived (calculated or aggregated) data elements. There are so many possible problems associated with divergent use of terms – for example, incorrect financial statements, inaccurate regulatory reports, and inadequate analytics results – leading to poor decisions, negative compliance findings, lost revenue, etc.
This is essentially a business problem that all organizations encounter. It is the result of sub-optimal organizational design and a siloed approach to data. However, it also offers an opportunity for the data management professional to provide valuable assistance in the roles of diplomat, facilitator, and healer.
At a Federal agency, there was confusion about a shared term – “Case.” The parent Department had informed the organization that it should implement a unified case management system, since the Department kept encountering the term used in multiple contexts. However, when the business areas engaged with each other, they immediately understood that the term was used by four key business processes which were quite distinct from each other. They developed and approved qualifying name components added to “Case,” with appropriate definitions to clarify the intent and use of each term. These approved and well-defined terms put to rest the concerns of the Department, and were embedded in the enterprise data model for forward engineering; a high-value outcome.
The Business Glossary is central to many fundamental data management practices and work products. The diagram below highlights some key relationships, and a summary follows (clockwise from top):
- The data management function depends on governance participants to resolve discrepancies in use of business terms; it also often serves as the facilitator to help this happen.
- Governance groups need to be structured to include individuals and roles with a sound knowledge of the terms within their business lines.
- Business terms are the core of an organization’s metadata resources, mapped to logical and physical data models, data stores, and interfaces.
- Data quality rules are set by lines of business for business-specific, as well as shared terms. For shared terms, quality rules should be defined across multiple lines of business to support shared data stores and the target data architecture.
- Data profiling frequently reveals divergent use of terms and their defined values and ranges. These discoveries should be resolved through data governance, and metadata should be updated if warranted.
- Data cleansing can be expensive; shared business terms with defined quality rules can reduce the need for overlapping cleansing activities, especially when performed at or close to the originating source.
- Data requirements should employ approved shared business terms as available; conversely, data requirements definition efforts frequently provide new business terms for agreement and approval.
- Key to the success of data lineage efforts are approved, standardized business terms with definitions and values; they are the backbone of mapping from end to end across the data life-cycle.
- Business term formulation requires approved standards and corresponding metadata, to ensure that all suppliers and consumers are capturing information in a repeatable manner with appropriate ownership and change controls.
- The need to integrate data underscores the critical importance of approved business terms. For example, a self-regulatory organization held frequent governance meetings with business knowledge experts from inspections, examinations, and enforcement to name, define and approve, term by term, thousands of data elements in over 300 incoming interfaces, for transformation and inclusion in the new enterprise data warehouse.
Their approach was quite a refreshing change compared to my first example. These meetings were calm, rational, and very productive – the result of knowledge, within each individual, that their shared aspiration and mission – to ensure the correctness and accuracy of their regulatory reports and enforcement actions – would be achieved only if their data was defensible and of high quality.
Engaging in developing or building out the Business Glossary is typically not a hard sell for an organization, because executives have frequently encountered complaints from the business lines, e.g., ‘Why can’t the X division define Calculation 23 the way I define it? The data from their system is messing up my reports!” When the phased development of an organization-wide Business Glossary is linked to an important initiative, such as implementing a metadata repository, or consolidating major operational systems following a merger, it can be justified on its business merits – and as a wonderful side benefit, is a powerful activity to energize and solidify data governance.
