Data Management Strategies

Database Consolidation: Understanding the process

Blogger: Marcus Collins

The ever-changing business environment is forcing organizations to continually reevaluate their existing IT landscape. Consolidation is one approach that many organizations are adopting to improve efficiency. Databases are a major component of the operational IT budget both in terms of manpower (e.g., database administrators or system administrators) and hardware (e.g., database servers). Therefore, the consolidation of databases and database servers is a priority for CIOs. But databases are also core to the business processes and informational needs of the enterprise, so consolidation should be approached in a methodical way. Therefore, organizations should adopt a more structured approach when undertaking database consolidation to assist with the analysis phase of the initiative.
Database consolidation should not be thought of as a purely technical activity concerned with database migrations or virtualizing database servers. There are a number of other factors that should be considered as the consolidation activity is planned:

• An application-decommissioning initiative should be conducted alongside the database consolidation initiative. Applications are sticky—they are far easier to create than to decommission; this drives up operational complexity, business risk, and cost. The cheapest and most straightforward consolidation approach is decommissioning!
• A comprehensive application portfolio should be developed and should include:
• • Business context: The relationship between database, application, and business process, and the service level required by the business process
  • Technical context: The relationship between database and the supporting hardware; internal database structures, version, and feature usage
  • Operational context: Both current and historical workload and usage statistics and forward-looking capacity planning data.
• Database consolidation is a continuous process because it is driven by the hardware refresh cycle and the evolving nature of businesses (e.g., entering new markets, mergers, and acquisitions). The supporting processes (e.g., application portfolio management and technology refresh) should be an integral part of the IT processes.
• The key to any consolidation initiative is standardization at all levels of the technology stack and within the associated IT processes. Standardization reduces operational costs, reduces business risk, and enables business agility. The standardization should be defined in concert with a strategy of tiered service levels.
• Consolidation is a series of tradeoffs and compromises with no correct answer. The degree to which a consolidation initiative will be successful is directly related to the understanding of the organization’s priorities for cost reduction, service levels, and risk acceptance. A tiered set of service levels, with each specifying detailed availability and performance constraints and scalability requirements, will simplify the tradeoff analysis and improve the chances of success of the standardization initiative.

In a recently published document - Structured Approach to Database Consolidation, Burton Group Senior Analyst Marcus Collins explores the various approaches to database consolidation. Each approach has its benefits and drawbacks and the document details theses. Adopting the approaches outlined in the document will allow organizations to develop a roadmap for the successful reduction in operational complexity.

The Data vs. Process Debate

Blogger: Lyn Robison

When I speak about the importance of data, a few IT professionals will usually feel compelled to bring up the importance of business process automation. They make the point that information systems automate business processes, and they don’t want me to neglect that important IT topic in my zeal for data. In fact, they kind of imply that data is not really what enterprise IT does -- business process automation is the real work of IT.

While I can appreciate the value of business process automation, from what I can see, data is more fundamental than process. I am not saying that data is more important than process -– they are both vital in the work of IT –- but data is more fundamental. The reason is simple. Processes require data as input. If you do not have good data, you cannot have good processes. Good data is the prerequisite for good business processes.

Of course, the process folks might counter by saying that good business processes are what produce good data, so process is the prerequisite to data –- kind of a chicken and egg argument. I don’t agree with that. Data does not necessarily spring from business processes. Data can and will exist independent of any business processes. Good data is a picture of reality. Good data is a record of those aspects of reality that the business deems important. If you don’t have good data, you have no picture of reality, and you are in La La Land. Any business processes that businesspeople perform that are not based on reality will be unproductive.

So, if you want good business processes, make sure you have good data. You can improve your data by becoming proficient at measuring and tracking data quality in your enterprise. If the data gets better, everything else that the business does will get better along with it. A rising tide (of data quality) will raise all ships.

What do you think?

Quality doesn’t matter, until it suddenly does

Blogger: Lyn Robison

My colleague Jack Santos wrote in a blog post today, “Lyn Robison (from our Data Management group) loves to rant about how business people put up with bad information from their IT departments.  No doubt. The sad thing is businesses want more.” I think Jack’s observation is true that businesspeople always seem to ask for more information even though its quality is shoddy, but I also think that this situation won’t last forever.

During the 60’s and 70’s, the American auto industry assumed that American consumers would always ask for more cars, even though the quality was shoddy. That observation was true, but it did not last forever. Quality didn’t matter, until suddenly it did.

As soon as someone (the Japanese automakers in this case) demonstrated to American consumers that they no longer had to settle for shoddy vehicle quality, vehicle quality became paramount. Likewise, as soon as a few IT shops demonstrate to businesspeople that they no longer have to settle for shoddy information quality, information quality will become paramount. IOW, if word gets out that the information coming from IT systems need not be garbage, look out. Businesspeople will demand high quality information from IT systems all of the time. And those IT people who cannot deliver it will find themselves in the same situation as the American automakers.

Those IT shops that do not want to end up looking like Detroit (see my "A Crystal Ball shows the Future of IT, and it is … Detroit?!" blog post for background on this) will adopt the approach of the Japanese automakers and start focusing on information quality today. These visionary IT shops will put themselves ahead of the curve and will find their prospects for the future bright and secure.

ROI on Data Quality and/or Data Management

Blogger: Lyn Robison

We’ve had several clients ask us for help in defining the return-on-investment for data quality and/or data management for the benefit of their CIO. I struggle with that ROI calculation because it is so basic and obvious to me that I almost can’t articulate the value proposition. It is as though I am being asked, “Can you give me the ROI on doing regular oil changes on our company-owned vehicles?” I am afraid that I would find it difficult to come up with an ROI calculation for that one too.

The value of any information system can be determined by measuring the value of the information that that system provides to the business. If you neglect to do data quality and data management on any information system, the information within that system will eventually deteriorate into a worthless, indistinguishable blob of goo. If the information within an information system becomes worthless, then the information system itself becomes worthless too. Any information system that provides useless information is useless. Like an airplane that can’t fly, it is unfit for its intended purpose.

What is the ROI on not letting a corporation’s valuable assets, such as its information systems, deteriorate? I guess you show that if you neglect any valuable asset, its value will deteriorate to nothing. So, the inputs are the value of the asset today (Vi), and the value of the asset after one year of neglect (Vf).  Then to calculate the ROI, (or in this case the yield, effective interest rate, effective annual rate, or annual percentage yield) you take (Vf – Vi)/Vi. As you can see, if Vf is higher than Vi, you will get a positive yield. If Vf is less than Vi (if the asset’s value is deteriorating) you will get a negative yield.

To do this calculation, you have to be able to quantify Vf and Vi. Coming up with precise, defensible numbers for Vf and Vi can be difficult. And as a result, many CIOs have thought (consciously or unconsciously), “Hmmm, there is no ROI for data quality or data management.” As a result, those CIOs have not prioritized data quality or data management work. Instead, they are passively letting the value of their existing information systems deteriorate to nothing. That approach does not make a lot of sense to me.

This is where information quality metrics come in handy. If an enterprise were to measure the quality (a.k.a. "the usefulness to the business") of the information coming from their information systems over a one-year period, they could calculate the yield (positive or negative) in the value of their information systems. If the IT organization can keep the yield positive, I guarantee that the business will be pleased with the IT organization’s efforts. I also guarantee that if the yield is negative (whether it is actually measured or not), the business will not be pleased with their IT people and will look for any opportunity to outsource or replace them.

Fix What Ails Your IT Group: Focus on Information

Blogger: Lyn Robison

Something is not right in enterprise IT. Corporations spend piles of money on enterprise IT, but business leaders do not seem satisfied with the work of their IT groups. There is a simple antidote. A focus on information will fix what ails enterprise IT. Businesses pay for IT systems not because they want technology, but because they want information. If enterprise IT groups would focus on delivering information (instead of just delivering systems and technology), the business would at last be pleased with IT’s work.

Sound too simple? Let’s examine the alternatives.

Without a focus on information, IT’s work on services and architecture turns into activities that benefit IT instead of the business.

Without a focus on information, IT’s business process automation efforts turn into rigid silos that often don’t fit the business processes.

Without a focus on information, the BI systems that IT builds turn into Business Stupidity (BS) that cannot answer businesspeople’s questions.

Without a focus on information, IT agility turns into yet more useless IT systems delivered faster and cheaper.

Without a focus on information, IT’s focus on business outcomes heightens the risk of unemployment for IT people.

The simple fact is that if an IT group does not focus on delivering useful information to businesspeople, nothing else that the IT group does will work.

The place to start is IT metrics. The first step in focusing on information is to establish information quality metrics as the primary metrics by which an IT department measures its work. For guidance on information quality metrics, click here.

Enterprise Trends driving Data Management

Blogger: Lyn Robison

Three data management trends seem to be driving enterprise data management to higher levels of attention and importance. Those trends are:

1. Regulatory and compliance requirements
2. Enterprises’ desire to do more with the systems they already have
3. Information management as a differentiator.

1. Regulatory and compliance requirements are forcing enterprises to exercise a modicum of competence in data management. The traditional view is that applications own their data. This view results in fragmented, duplicated, balkanized data. When IT people concentrate on managing applications and letting those applications manage their data, they are not performing competent data management. Enterprises face regulatory requirements to manage their data as a whole, and thus the discipline of data management is becoming important.

2. During this economic recession, enterprises are being forced to make do with what they have. There is not a lot of money for new information systems and IT infrastructure. Companies are generally trying to spend less on IT, not more. Smart enterprises are realizing that the best way to get more out of information systems is to do a better job of managing the data inside those systems so that those systems produce better information. This realization is elevating the status of data management.

3. Enterprises are finding that information management is a differentiator. Every large enterprise has an IT department and a bunch of systems. Having an IT department and IT systems does not differentiate an enterprise, but managing the information inside those systems does. Any enterprise that does a better job of managing its information than its competitors do will differentiate itself in the marketplace. This fact will make data management all the more important during this economic recession.

2010 Planning Guide, Data Management Strategies

Blogger: Lyn Robison

I recently recorded a presentation about our 2010 Planning Guide for Data Management Strategies. The Planning Guide and the presentation about it are intended to assist IT leadership in setting priorities in enterprise IT planning for the coming year. The entire Planning Guide is published (here) on the Burton Group web site for Burton Group clients. The presentation outlines the enterprise IT planning considerations for data management in 2010. You can view the presentation below:

To see how trends are driving enterprise IT groups to adopt a new model for their work, see slide 3 of the presentation.

To learn about the importance of data management in a cloud computing environment, you can go to slides 7, 11, and 12.

To get a fresh perspective on data silos, jump to slide 9.

To gain insight into the pattern of diminishing returns that enterprise IT is delivering to the business, go to slide 10.

To hear a Burton Group analyst say that Information Lifecycle Management (ILM) tools are “frankly, garbage”, even as the need for ILM grows to near crisis proportions, skip to slide 14.

To learn why Moore’s Law won’t save us, jump to slide 17.

To encounter the unvarnished truth about Business Intelligence (“Gee, it’s not working for some reason…”), skip to slide 18.

To listen to me hammer the big three DBMS vendors for neglecting to provide a platform on which enterprises can actually manage all of their information , skip to slides 19 - 23.

And to hear three things that an enterprise IT department can do in 2010 that are basically free and that will generate hard-dollar benefits for the business, jump to slides 24 and 25.

Here are the links to the resources that I point to in the presentation:

• A Data Management Freebie
• Foundations for Data Governance
• IT Metrics: Measuring IT’s Business Value
• Information Lifecycle Management and Data Management: The Chicken or the Egg?
• The Data Management Organization: Key to Effective Data Management
• Master Data Management (MDM): A Pivotal Process
• The Methodology for Overcoming Data Silos (MODS): Using the New XQuery Development Stack
• Delivering Integrated Information from Data Silos Using MODS

So you want good data - do you know what it cost?

By Noreen Kendle

No one ever says they want bad data, everyone wants good data. The poor state of the data and lack of formal data management in most organizations is well known. Improving the state of data has been on most C-level radar for at least ten years. So what‘s the problem?  Am I missing something here?  If most organizations are aware of their data problems and they know they need good data, then why hasn’t data management been given the spotlight and funding it needs. Many of my data management colleagues say that they continually struggle to sell a data management function.  Try as they will, they cannot convince management to spend the money and resources; same folks who want good data.

I believe there is a fact that is often overlooked. If you have data, then you manage it, weather it’s recognized or not – data will get managed, proactively or reactively.  Most organizations manage their data reactively. The cost of reactive data management typically goes unrecognized and unaccounted for. I was talking to a fried the other day about data quality problems. She had been the head of a large vendor support/management department (126 employees) for a fortune 100 company. She calculated that on average 60% of their time was spent chasing and correcting bad vendor and product data. It was just considered to be part of the job, and one of the main reasons for such a large department. I have been told and witnessed similar situations across many organizations. Reactive type data management is never accounted for in a data management budget.

Request for funds for a formal “proactive” data management function is viewed as a new expenditure that requires extensive justification and is rarely approved because the organization is functioning "fine" without it. The irony is that the expenditure for a formal data management function is a drop in the bucket to what is being wasted in reactive data management.  

The case for formal data management needs to be presented as a cost-cutting initiative with an accounting and comparison to the cost for reactive data management. Proactively managing data is the key to having good data and will cost much less than most organizations are spending today. If the true cost of reactive data management were recognized,I believe formal data management would quickly take center stage in most organizations.

Enterprise Databases: Multiply and It's Tough to Prosper

Blogger: Marcus Collins
 
As a follow up to my blog post Comparing Enterprise Databases and recently published research - I was interviewed by Ann All of IT Business Edge at the Burton Group Catalyst conference in San Diego. We discussed the issues organizations experience when they try to control the growth of different databases in their application portfolios. Here's a link to the interview Enterprise Databases: Multiply and It's Tough to Prosper.

Is Data Integration Working?

 By Noreen Kendle

The typically approach to data integration has been a bottom-up, data systems, tools/technology approach where a data integration tool is used to merge data columns form various database systems.  This approach has been around for many years.  If it worked, then we would not be in the data disparity mess we are in today. 

The data integration tools and the automation they offer are not the point of failure; the issue is the methodology, how the tools are applied. The tools move and merge the data as directed. It is how they are directed. The decisions on what gets “merged” or “pasted” together are typically based on data field names, content and sometimes relationships within the existing data systems.  Anyone who has worked in the guts of data knows how misleading a column name or even its content is to its meaning. Add to that the fact that most legacy data systems are riddled with data issues and idiosyncrasies.  When they are integrated in this manner, the data abnormalities multiply.

There is also the dimension of time that plays a role in data meaning and integration.  Often data can change its meaning over time as can the business it represents. Even when two data items appear the same, they may be representations of the same thing at different points in time and therefore, not really the same thing. This is a challenge for data systems tool based integration.

Another challenge with this data integration methodology is capturing the data relationships. Data meaning is dependent on it relationships with other data, where the meaning of a data item, a column in a database, is relative to its relationship within the table it resides, as well as its relationship/dependencies to other attributes and tables. When data is looked at individually, as a single column or attribute, void of its relationships, there is a high risk of losing its full meaning, thus compromising its integrity. Many organization’s database systems today, even if they have the capability, do not implement referential integrity (RI) within the database or compensate for the RI.  Much of the data, even well named and defined data has lost its relative meaning. 

Data is not something that can be disassembled and treated linearly, without the risk of compromising its integrity. There is a very good reason why relational logic for data structures works well – data, as is the real world it represents is inter-related. Hierarchies are simple parent-child relationships. This does not necessarily mean data has to be stored or moved in a relational structure; rather its relational or relative meaning must be preserved in some manner in order to maintain its integrity.

Data integration tools can only take a “best guess” in an attempt to derive a data field’s meaning, even if the guess is based on a good quality name, content, and structure/relationships. The real meaning/understanding of data comes from its intended business meaning, how it represents the business.  Without the real business meaning, where the physical data is mapped/justified to a business data model and then used to drive the data integration, it can only ever be a best guess, with or without a tool.