Free Newsletters :

Should You Consolidate Your Database?

Database consolidation can have a huge impact on IT budgets by lowering hardware and database license costs. But the perils are numerous.
(Page 1 of 2)

I recently did one of those things that analysts are supposed to do, which is to test the accepted wisdom about a concept that’s been kicking around so long no one seems to even question its veracity. The concept is database consolidation, and the accepted wisdom is that database consolidation lowers IT budgets and raises business effectiveness and efficiency while providing a high degree of ROI and value.

Unfortunately, that statement is only half true. Database consolidation can have a huge impact on IT budgets by lowering hardware and database license costs, and in doing so database consolidation can even help on the business side as well. But it turns out that most database consolidation projects miss an enormous opportunity to have a dramatic effect on the business side, and in fact often leave business users out on a limb when it comes to regulatory compliance, business continuity, and plain old business success.

Once again the accepted wisdom proves to be more accepted than is merited and a lot less wise than expected.

Here’s the problem. Database consolidation is easy if you leave out one important element: the maintenance of an accurate, usable, and extensive history of past transactions and results that spans the different data types, formats, and standards that have been used in your different source databases over time.

In other words, as long as you don’t try to maintain anything but the most cursory history of your chart of accounts, your customer records, your product offerings and prices, your manufacturing records, and everything else you’ve store in databases lo these many years, consolidation is easy. And cost-effective, and relatively useful, and a key component in IT simplification.

But if you want to maintain some historical perspective on your business, and be able to access the data that you need to meet regulatory requirements, analyze historical trends, maintain customer and business continuity, and otherwise run a successful business following a merger, divestiture, or other major consolidating event, it turns out that database consolidation only gets you so far. And it’s usually not far enough.

Far enough means being able to meet your business obligations, like providing the FDA with an historical record of the clinical trials for a new drug that isn’t working right or the processing records for a food product that is suspected of poisoning consumers. Far enough means being able to accurately balance your books and, if necessary, restate your earnings without worrying whether you’re about to break the law. Far enough means being able to truly optimize your cross-sell and up-sell opportunities by maintaining a single version of the “truth” about your customers and prospects. Far enough means making sure your business is up and running on day one post merger or divestiture, absent that chaos and uncertainty that an incomplete data environment would guarantee.

It’s true that there are other ways of meeting these business needs other than through a classic database consolidation. You can undertake a major master data management initiative, and keep everything you need in its original database, which solves your data history problem but kills any attempt to reduce the complexity and cost of your IT environment. Similarly, you can build an enterprise SOA infrastructure, and hide the complexity of data reconciliation behind a wall of Web services interfaces. Once again, say farewell to simplification and budget savings.

Or, you can try to actually do a business-level consolidation, which up until recently would have involved a massive, brute-force effort to reconcile an enormous set of complexities that typically exist between different database instances. That brute force effort is so brutal, and requires so much force, that – guess what – virtually no one has ever tried it.

I say virtually because I leave open the possibility that it has been done on a small scale, or in some benighted corner of the IT universe. But I’ve been looking for an example of this kind of deep business-level consolidation, and every time I’ve scratched the surface of a database consolidation project what I’ve come up with is something far short of “far enough.”

Page 1 of 2

1 2
Next Page

Tags: database, services, management, IT, Enterprise

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.