Database Consolidation and ROI: The State of the Art

PDFPrintE-mail

The problems that drive companies towards database consolidation of any kind are well known, and span a range of business and technical problems. (See Figure 1.) It is clear that the business risks that companies encounter by relying on multiple, highly disparate, and unconsolidated data sources are endemic to all industries and company types. It is also clear that there are business events, such as mergers or acquisitions, as well as regulatory requirements and other drivers, that in many cases make consolidation an absolute necessity, independent of a specific return on investment (ROI) case.

State of the Art

Against this backdrop of opportunity and necessity, examples of database consolidation projects abound, all promising a robust business case, and an equally robust ROI. A review of most publicly available examples of consolidation, as well as EAC’s own research, reveal that the overwhelming majority of examples of database consolidation are fundamentally technical consolidations, and not higher-value business consolidations.

The value of technical consolidation has nonetheless been amply proven by a number of different research organizations. Forrester Research has estimated that companies that have undergone consolidation to a single instance have spent well below the industry average on their total IT budget. Whereas a broad swath of companies spend an average of 3.8 percent of revenues on IT, according to Forrester, companies that have undertaken single-instance consolidation spend on average 2.5 percent of revenues on IT, with one company reporting a 1.6 percent spend rate.

A look at some published results from technical consolidation projects shows how some of this ROI is achieved, and in particular how these types of projects focus on resolving problems of IT complexity, rather than presenting a means to improve business operations. Hewlett-Packard, IBM, Microsoft, and Williams-Sonoma have all recently engaged in data center consolidation projects, yielding some impressive cost savings. In Hewlett Packard’s case, the company was able to reduce its number of data centers from 85 to three, with an additional three centers acting as disaster recovery sites. IBM’s consolidation efforts reduced a 3900-server system to 30 mainframes, in the process reducing data center energy use by 80 percent. Microsoft’s efforts at data consolidation produced a $23.2 million savings, while retailer Williams-Sonoma consolidated 100 servers down to five, and in the process was able to cancel plans to add 50 more servers at its data center.

While these projects all showed significant ROI, they were focused exclusively on the technical aspects of consolidation, which meant that the resulting environment still had a large degree of complexity, and therefore was poorly positioned to deliver the benefits that a business consolidation delivers.

Not all technical consolidations are without business value, however. Toronto-based Longo Brothers, an on-premise and on-line grocery chain, undertook a technical upgrade and consolidation effort that was in part targeted at reducing the IT department’s enormous spend on data integration, estimated at 30 percent of the total IT budget. Longo was able to measure a distinct return on its investment for this project in a critical area of its business: warehouse management. The consolidation yielded a 1.5 percent improvement in its warehouse management processes relating to its on-hand stock. That improvement allowed the company to stock an additional 300 items in its stores, an improvement that translated into significant revenue upside for the company.

Like many technical consolidations, however, Longo retained many of the disparate systems that contributed to its complexity problems, including multiple point-of-sale (POS) systems and a homegrown employee scheduling system, among others. Mediating all this complexity is a service- oriented architecture that by its very nature advances business functionality, but imposes its own considerable costs, and also limits potential return on investment and optimal business value. Similarly, limited returns on investment can be seen in master data management projects, which are typically expensive, multi-year engagements that add more complexity and promise high on-going maintenance costs.

>>> Download the White Paper In Full (PDF)

 

© 2009 EAC

Joshua Greenbaum has over 25 years of experience in the industry as a computer programmer, systems analyst, author, consultant, and industry analyst. He spent three years in Europe as an industry analyst and as European correspondent for Information Week and other industry publications.

In his role as an industry analyst, Josh regularly consults with leading public and private enterprise software, database, and infrastructure companies, and advises end-users on technology infrastructure and applications selection, development, and implementation issues.

An award-winning columnist, Josh is widely quoted in the trade and business press, blogs on ZDNet, and is a regular columnist for Managing Automation, Datamation.com, NetWeaver Magazine, and Redmond Channel Partner magazine. Other opinions by Josh may be found on his blog at http://ematters.wordpress.com/ or on his website http://www.eaconsult.com/.

Add comment


Security code
Refresh

Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Enter your email address to sign up for our Newsletter

Sign up now

captcha
TEChanges - Agility by Design

May Puzzle

David is often referred to as Rainman due to his peculiar ability to effortlessly figure out a certain date's day of the week. He recently displayed this talent when I asked him if there was a conflict with the upcoming Fuzzy Dice Conference and our weekly court-ordered community service. He asked the date of the convention. It was April 20th, 2012.

"Oh, that’s a Friday," he said, effortlessly. "And your sentences have you committed for the next few dozen Wednesdays so you'll be able to go." And of course he was right.

One day a few weeks ago I asked out loud in the office about the date June 5th. And of all people, my brother Tommy piped up and said "Oh, that's a Tuesday."

"That's right," said David.

Well how about Otcober 3rd?

"That's a Wednesday," said Tommy. Then I asked about Christmas Day 2012.

"Oh, that's a Tuesday." David nodded in agreement.

Do we now have two rainmen? Or had Tommy figured something out?

Show solution...

Solution

Here's what was going on. Tommy was using something called anchor dates. And these dates apply to each and every year. April 4th, or 4/4 we’ll call it from now on, June 6th or 6/6, 8/8, 10/10, 12/12, are all the same day of the week, each and every year.

So too are 5/9 and 9/5, May 9th and September 5th. So too are 7/11 and 11/7, and all the above dates are the same day of the week, as is the last day in February, Leap Year or not. And they’re all the same day as January 4th, it would otherwise be January 3rd, but this was a leap year, and that’s changes the anchor day from January 3rd to January 4th.

Tommy also knew that New Year's Day was a Sunday. He was sobered up by then. And he knew it was a Sunday because Christmas was a Sunday in 2011, so New Year's Day is a Sunday, so the Anchor Day for 2012, January 4th, has to be a Wednesday!

So if that's a Wednesday, then 4/4, 6/6, 8/8, 10/10, 12/12, 5/9, 9/5, 7/11, 11/7, and February 29th are all the same day of the week, and they're all Wednesdays. So when I ask for example, about October 3rd, he knew October 10th was a Wednesday, 10/10. So 10/3 must also be a Wednesday. 12/12 is a Wednesday in 2012, so it’s 12/26, which is two weeks later. So 12/25, or Christmas Day, must be a Tuesday.

Success Tips for Oracle Project Management

  • Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
  • Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
  • If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
  • Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
  • Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
  • Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
  • Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
  • Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
  • Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
  • Include governance, risk, and compliance management as part of the project plan.
  • Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.

The Analyst Corner

John Van Decker, Research VP of Gartner, states:

"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."