In the Field with our Experts

Does Data Governance Equal Data Quality?

By Frank Dravis, Senior Consultant

I was working with a client collecting stakeholder inputs in preparation for a proposed data governance program. One of the questions I asked the interviewees was “How do you expect data governance to help you?” The responses varied by the person’s role in the organization, but universally, all of the managers, be they in field marketing, global marketing, sales ops, or other areas answered the question in roughly the same way: they expected data governance to improve data quality.

Yes, data governance will indeed improve data quality over time through the implementation of policies and better processes, but the respondents expected data governance to directly affect data cleansing operations.

Suffice it to say there is a whole chain of activities that need to take place between the formation of a data governance program and the point where a data analyst connects a data quality solution to the data and begins the standardizing and de-duping. However, it was encouraging for me to see the value proposition of the two concepts, governance and quality, inextricably intertwined, no attempts to separate or isolate them. Our client’s business people fervently believed that taken together data governance and data quality were the solution to the myriad of problems exacerbated by silo-ed, fractured, and unreliable data.

My guess is that this client’s adoption curve for data governance will be shorter and can piggy-back off the successes of data quality. I’ll let you know if I’m right.

---

Frank Dravis is a senior consultant with 21 years of experience in enterprise information management (EIM) and data quality solutions design, implementation, and consulting. He specializes in data integration, data quality, and data governance solutions, advising key clients and industry vendors.

Vendor SLAs: A BI Best Practice

By Alex Vilensky, Senior Consultant

Frequently on client engagements I noticed that even sophisticated BI and data warehouse development teams omit Service Level Agreements (SLAs).  Comments like “... Why should I bother amending my company’s service levels into the contract when the vendor should be handling that task...?” or, “Shouldn’t the vendor be telling US what the SLAs are?” underscore the point that development teams don’t consider SLAs a core responsibility.

Meanwhile your vendor is protecting its own interests. A down-the-road realization of a weak agreement with the vendor will likely occur once it’s too late for a “win-win.” The risk is cost overruns, low staff morale, and eroded vendor goodwill. Here is a list of some actual SLAs for BI vendors according to three different categories:  system performance, organization/people support, and application quality categories.

 System Performance

• BI application design screen refresh SLA’s (of 1 second, 6 seconds and 15 seconds) must be consistent with client’s refresh SLA’s of 2 to 7 seconds.  Vendor is expected to meet refresh SLA’s with additional hardware and/or application tuning.
• Data Warehouse daily batch runs are not must occur within the established 2-hour window. 

Organization/People Support

• Vendor ‘s support staff must have at least two client references per staff member.
• Vendor must be able to articulate changes from prior to current release in writing prior to installing the subsequent release.

Application Quality

• Code quality must be demonstrated (test cases) to be better than in the previous release prior to the release.
• Patch quality issues – ensure all patches are well tested without cause of problems elsewhere in the code.  For every iterative patch needed to solve a single issue, vendor must reimburse support credit dollars.

SLAs help to manage expectations and drive consensus.  They form a partnership bond with clear definition of the level of product and service support and escalation procedures when something goes awry.  In a mature production environment, clear service levels drive the long-term client/vendor relationship with concise expectations and clarity about the role and responsibility of each party.

---

Alex Vilensky has over 20 years experience in significant areas of information systems design and development including business requirements definition, logical and physical design, application development, technical leadership, project management, disaster recovery, systems programming, and database administration.

BI Development: Wrong Processes and Best Practices

By Bob Newell, Senior Consultant

One phenomenon I’m seeing with clients’ business intelligence development groups is IT relying on a one-size fits all development method. And the end results never seem to satisfy the business users, who are likely funding the project in the first place.

Any experienced developer asks the questions: “Who is my customer, and what’s the end product I’m expected to deliver to that customer?”

For a Software Development Life Cycle (SDLC), you’re trying to support a business process or a business operation. Whether it’s an application for data entry, a call center, or a network application that’s moving data from one part of the company to another, it’s all about the business processes and operations.

In the case of BI, you’re really trying to build an analytical environment. You need to understand what business initiatives need analytics, what questions your business users are asking, and what data is needed to support the answers to those questions. These types of issues are very different than those in standard application development, where the resulting functionality is much more straightforward and easy to articulate.

At a simple level, developers of both operational and analytical systems should understand the same concept when choosing a development method. Are you automating a business process? Then perhaps a standard SDLC is fitting. But if you’re building an analytical environment, a specific BI development lifecycle is the likely ticket to success.

---

Bob Newell is a senior consultant at Baseline. He has spent his career bridging technical and business disciplines, focusing on the effective utilization of data to advance strategic business objectives. This includes domain expertise in many technical disciplines such as database architecture, data presentation, CDI and ETL strategies, and enterprise architecture. Bob also manages the development of BI Application Portfolios and Business Requirements.