Monday, July 13 2009
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.
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/.
| < Prev | Next > |
|---|
Related Articles
Related Pages
Enter your email address to sign up for our Newsletter
January Puzzle
A traveler gets lost on a deserted island and finds himself surrounded by a group of n cannibals.
Each cannibal wants to eat the traveler but, as each knows, there is a risk. A cannibal that attacks and eats the traveler would become tired and defenseless. After he eats, he would become an easy target for another cannibal (who would also become tired and defenseless after eating).
The cannibals are all hungry, but they cannot trust each other to cooperate. The cannibals happen to be well versed in game theory, so they will think before making a move.
Does the nearest cannibal, or any cannibal in the group, devour the lost traveler?
Solution
The short answer is the traveler’s fate depends on the parity of the group. If there is an odd number of canibals, the traveler will be eaten, but if there is an even number, the traveler will survive.
To prove this, we will consider small groups and use mathematical induction to explain the solution for larger groups.
Case n = 1: this is an obvious case. If there is one cannibal, the traveler will be eaten. It doesn’t matter that the cannibal will get tired because there are no other cannibals around as a threat.
Case n = 2: this is a more interesting case. Each cannibal wishes to each the traveler, but each knows he cannot. If either cannibal eats the traveler, then he will become defenseless and the other one will eat him. So each cannibal uses backwards induction to realize that the only strategy is to not eat the traveler. The hapless traveler finds a bit of luck, therefore, and actually survives.
Case n = 3: this is where the problem gets interesting. The best strategy is for the closest cannibal to make a move and eat the traveler. The cannibal will be defenseless after eating, but ultimately he will be safe. Why is that? The reasoning is due to induction: once the cannibal eats the traveler, the resulting situation has 2 unfed cannibals and the 1 defenseless cannibal. But as we just showed above, when there are 2 unfed cannibals, neither will make a move for fear of being eaten by the other! Thus the first cannibal to make a move will be safe as the remaining 2 cannibals block each other.
We can prove the higher cases using mathematical induction. If the number n is odd, then the closest cannibal can safely eat the traveler because the remaining number of unfed cannibals is even (and by induction, with an even number of unfed cannibals no one makes a move). If the number n is even, then no cannibal will eat the traveler, for if he did, the remaining number of cannibals would be odd, meaning he will get eaten by the induction hypothesis.
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."
