Every organization has a business strategy that reflects both the business management and the risk and compliance management objectives, and the success of the organization depends on the ability to manage how all operations conform to the business strategy. This is true for information technology, but because of its centrality in the application infrastructure, it is particularly true in the area of data management. It is important to communicate the business strategy and to engineer the oversight of information in a way that aligns the business strategy with the information architecture. This alignment is twofold – it must demonstrate how the organization understands and uses its information asset as well as how the asset is managed.

Many organizational applications are created in a virtual vacuum, engineered to support functional requirements for a specific line of business without considering whether there is any overlap with other line of business applications. This tactical approach may be sufficient to support ongoing operations; but not only does it limit the enterprise analytic capability, it hampers any attempt at organizational oversight. Before a data governance framework can be instituted, the management must understand and document the de facto information architecture, suggesting that a preliminary phase to governance is assessment. In other words, a prelude to governance involves taking inventory to understand what data assets exist, how they are managed and used, how they support the existing application architecture, and evaluating where existing inefficiencies or redundancies create roadblocks to proper oversight.

The inventory grows organically from the ground up – initially, the process involves identifying the data sets used by each application and enumerating the data attributes within each data set. Each data element must have a name, a structural format, and a definition, which must be documented within a core metadata repository. Each data set models a relevant business concept, and each data element provides insight into that business concept – all within the context of the “owning” application. In turn, each definition must be subjected to review to ensure that it is correct, defensible, and is grounded by an authoritative source.

This collection of data elements does not an architecture make, though. A team of subject matter experts and data analysts must look at the physical components and recast it into a logical view that is consistent across the enterprise. This requires harmonization of the data elements to look for similarity (or distinction) in meaning. While this activity overlaps with the technical aspects of master data object analysis, its importance to governance lies in the identification and registration of the organization’s critical data elements and their composed information structures, along with the application functions associated with the data element life cycle.

Every activity that creates, modifies, or retires a data element must somehow support a business activity contributing to the organization’s overall business objectives. In turn, the success or failure of the business activity is related to the appropriate and correct execution of all the information functions that support that activity. For example, many Web site privacy policies specify that data about children below a specified age will not be shared without permission of the child’s parent. A data element may be used to document each party’s birth date and parent’s permission, and there will also be functions to verify the party’s age and parental permission before the information is shared with another organization.

When assessing the information architecture, one must document each information function and how it maps to achieving business objectives. A standardized approach for functional description will help in assessing functional overlap, which may be subject for review as the core master data objects are identified and consolidated. However, in all situations, the application functionality essentially represents the ways that information policies are implemented across the enterprise.

The goal of the bottom-up assessment is to understand how the information architecture and its associated functionality support the implementation of information policy. But in reality, the process should be reversed – information policy should be defined first, and then the data objects and their associated services should be architected to both implement and document compliance with that policy. Ultimately, as critical data objects and their associated attributes are absorbed under centralized management, it creates the ability to map the functional service layer to the deployment of information policy, which in turn enables the embedding of monitoring probes that collectively (and reliably) report on compliance.

And isn’t this the beginning of data governance? The ability to define an information policy, to articulate which data elements are involved in complying with that policy, and to monitor conformance are all pieces of the puzzle. The next step is to map the way that the information policy is represented as a set of data quality rules and how those rules are validated.

Recent articles by David Loshin

• Social Media, Content, Structure and Wagging the Long Tail
• Customer Analytics
• Entity and Identification
• Master Data Management Checklist #5: Data Quality Mechanics