In the Field with our Experts

A Data Governance Primer (Part 3 of 3)

By Carol Newcomb, Senior Consultant

Diamond in the Rough: Data Quality

The third part of my summertime primer addresses Data Quality Analysis.  Don’t even start a data quality analysis until you have completed the first two steps of your Root Cause Analysis--investigate & prioritize any potential causative factors, and start your metadata assessment.  Otherwise, you may be misled by your findings.

Data quality is defined as complete and accurate data that is ready for business consumption.  Sources of poor data quality may include lack of data entry rules, unclear data element definitions, inconsistent metadata definitions for field type, format or intent, or breakdowns in data transformation processes as data flow between systems or applications.  Poor data quality results in bad business decisions; it contributes to major problems in using data effectively, and costs companies millions of dollars/year in terms of rework and inefficiency.  Data quality, in combination with robust metadata definitions, is part of the foundation of good data governance.

Data Quality Analysis

A Data Quality Management process should be designed to enable an area to start with a simple approach and over time to mature to one that is more proactive and comprehensive.  Initially, investigation may be focused on single data elements or events.  As patterns, data commonalities and other relationships appear, the data quality management process will grow to support complete business processes.   A mature data quality management process will not just resolve individual issues; it will also track relationships between data elements, ensure that business rules are consistent and generate statistical analyses to monitor previously addressed issues to ensure that data quality is stable and that an early warning system is in place as part of the data governance program.  The goal is to design a data quality management lifecycle, as shown in this diagram:

Initial Data Quality Analysis Process

I. Define data scope

• Determine data elements that are associated with or are direct results of the reported issue
• Check that all metadata definitions are present and current
• Enlist the involvement of the Data SME or Data Stewards
• Identify all source systems where the data originates, is  entered or derived

II. Extract and profile the data

• Extract the relevant data from all key source systems.
• Design the profile.  A profile will consist, at a minimum, of total record counts, min/max values, frequency of unique values, and frequency of invalid values (if defined) for each data element profiled. 
• Profile the data to determine key characteristics that are contributing to the issue, such as:
• 1. Wrong values
  2. Missing values
  3. Corrupt transformation processes
  4. Incorrect business rules
  5. Incorrect usage rules

III. Analyze Data Profile Results

• Summarize the key findings from the profile detail
• Determine what key drivers are contributing to the impact
• Determine accountability for the data quality issue
• Involve other Data Stewards in troubleshooting and designing the data quality solution

IV. Design the Corrective Action Plan

Two types of plans should be developed to address known data quality issues: a corrective action plan to fix the immediate source of the problem identified, and an ongoing monitoring plan, where thresholds have been determined and metrics are routinely collected and reported to data stakeholders.  This monitoring process should be scalable based on the number of data elements being tracked.

1. Corrective Action Plan
2. • Does scope of problem warrant change in metadata definitions, business practices or data entry rules?
   • Does scope of problem warrant a data governance standard?
   • Does the corrective action plan include details on how to fix the source of the problem as well as ways to correct historical data in the system?
3. Preventive Action Plan
4. • This plan will be designed to minimize the probability of data quality issues from recurring
   • Determine ‘early warning triggers’ based on designated thresholds.  These thresholds should reflect the business tolerance for inaccurate data (is 95% acceptable?)
   • If data latency is the source of a data quality issue, then latency thresholds should be included in the monitoring plan
   • Determine how frequently results of the monitoring plan will be reported to data stakeholders or governance oversight committees

So, now that summer is officially here, this wraps up my Data Governance Primer series.  Time for some iced tea and my favorite beach towel.  Come August, these little refreshers might be just the thing!

photo by Swamibu via Flickr (Creative Commons License)

---

Carol Newcomb is a Senior Consultant with Baseline Consulting. She specializes in developing BI and data governance programs to drive competitive advantage and fact-based decision making. Carol has consulted for a variety of health care organizations, including Rush Health Associates, Kaiser Permanente, OSF Healthcare, the Blue Cross Blue Shield Association and more. While working at the Joint Commission and Northwestern Memorial Hospital, she designed and conducted scientific research projects and contributed to statistical analyses.

The Metadata ROI Series: Episode 2: Software Development

By Stephen Putman, Senior Consultant

This posting is the second in a series discussing various aspects of the financial justification of a metadata management system implementation that are not obvious in many existing analyses. Today, we will discuss the time and effort saved by software development staff in system implementation projects.

In Part 1 of this series, we examined the value of a metadata management system in regard to the gathering and documenting of business requirements. In this installment, we will take a look at the next phase of a system implementation - software design and development. A metadata management system can help you save money and time in these areas as well.

For new system development, the system designers and developers can use the data stored in the business requirements process as a basis for their designs. Properly documented requirements leave little question as to the intent of the system, and reduce (or even eliminate) the need for follow-up meetings between the engineering staff and the business analysts. Measuring this saved time by the assigned resources is your first source of return for the investment.

Two other major areas of development that benefit greatly from metadata are Extract-Transform-Load (ETL) development and report development. Both functions need to know where data is located on various systems, which is something a metadata system does well. For ETL development, the location and mapping of source data elements is also available. Developers contribute specific information related to their activities to the metadata system to demonstrate fidelity in design to requirements and design considerations introduced to the system.

The major return on investment of a metadata system in the software development area is primarily related to the time saved by staff in information discovery and application. It is important to measure both pre-metadata-system and post-metadata-system metrics on developer and analyst time to accurately determine the money saved by implementing the metadata system.

In Part 3, we will tackle the potential cost saving to end-user reporting groups in your organization.

Photo, "physical metadata," by Nadya Peek (via Flickr)

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.

Finding the Gold in Enterprise Data

By Adam White, Senior Consultant

Without control of their data corporations can no longer compete. The emphasis on globalization, new competitive pressures, and the widespread adoption of the Internet have introduced a new sense of urgency around data integration and management.  These days a company must not only have control of its physical data, the actual information that it has captured, it must have the ability to derive information from that data, interpreting it accurately and leveraging it for operational efficiencies and strategic advantage. And it must be able to deploy enterprise data across business users, including call center agents, point of sale staff, sales representatives, managers, directors, and executives. The data may also be required for direct use by customers and/or prospects.

Corporate control of data extends beyond just using data. Data management is also an emerging discipline in most companies. Data must be protected. There are regulatory requirements, customer privacy expectations, and the need to securethe customer base from competitors.  The unforeseen forces of a global economy mean that companies must be able to work with data that is not English. And, of course, the need to integrate the data across various external and internal silos means that point-to-point interfaces must be phased out in favor of a single version of the truth.

Indeed, many of your company’s databases are replicated to provide access to various constituencies. But the point-to-point interfaces they use to exchange data are costly both development and maintenance-wise. Control over heterogeneous data—not to mention sustained management and integration of that data—is next to impossible.  Application upgrades and data enhancements mean large, expensive projects that come with a high risk of failure. A deliberate approach to enterprise data integration can help IT save time, headcount, and rework, as well as launching efficiencies that can not only drive down costs—ensuring responsiveness, repeatable development practices, and data reuse—but, more importantly, delivering value to the business.

So what are the approaches that will give you control over your data and provide the functionality that you need to support your business?  There are different options for integration (the sharing of data and services), including: Extract, Transformation, and Loading (ETL); Enterprise Application Integration (EAI); Enterprise Information Integration (EII); and Customer Data Integration (CDI). The optimal solution at your company may be one of these, or a combination of all four. The point is that decisions about data integration remedies should involve a complete understanding of the differences of data integration solutions, and a deliberate technology selection process.  Also, the implementation of the solution means that you will have to have a robust data governance and data management framework in place so that data integration supports your needs going forward, and doesn’t over time revert back into the original legacy architecture, losing the capabilities that are instrumental in implementing the solution in the first place.

Note: Baseline Partner Evan Levy will be teaching a class at the TDWI World Conference in Las Vegas next month, titled Architectural Options for Data Integration, in which he will outline the differences in these and other integration approaches, compare the strengths and weaknesses of each, and offer lists of vendors in each category. I strongly recommend attending!

---

Adam White is an expert in Customer Data Integration (CDI), Services Oriented Architecture (SOA), Systems Development Life Cycle Methodology, Project Management, IT Governance, and establishing IT Process and Organization. Since joining Baseline, Adam has been responsible for conducting enterprise CDI assessments, implementing CDI, implementing SOA architecture, and implementing development methodologies.

SOA and Enterprise Applications

By Adam White, Senior Consultant

It’s frustrating to see the consistent mistakes enterprise and solution architects make when implementing and supporting Service Oriented Architecture (SOA).  The most common one is co-opting functionality that comes with a packaged product as an enterprise solution.  

One example is using CRM workflow as enterprise workflow.  Most products nowadays  come packaged with workflow capabilities.  This means that events can trigger a process and that processes can interface outside of the application to activate other events. The first inclination of many enterprise architects is to utilize that functionality to support the enterprise-class business needs.  The problem is that the functionality that comes with the product is designed to support the product, not the overall enterprise. 

However, there are workflow products that support the entire enterprise. The easiest way to tell is by applying two trusted rules of thumb.  The first is by mapping your functional requirements.  You will see that by using this yardstick, product level functionality is different than enterprise level functionality.  And the second simple rule is if you replace your packaged application (say, your CRM application) do you also have to replace or rebuild your workflow?  The answer should be no.  If it’s yes, then you have incorrectly repurposed the product’s workflow functionality. 

This also occurs in the integration world.  Just because an ETL solution provides integration and can call a web service does not mean it’s the product to use for your core applications. After all, these are systems that support business operations, the systems that you use to process your day to day customer transactions.  In the end, it all comes down to fleshing out your requirements, and using the right tool for  the right job.

---

Adam White is an expert in Customer Data Integration (CDI), Services Oriented Architecture (SOA), Systems Development Life Cycle Methodology, Project Management, IT Governance, and establishing IT Process and Organization. Since joining Baseline, Adam has been responsible for conducting enterprise CDI assessments, implementing CDI, implementing SOA architecture, and implementing development methodologies.