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.
Heres 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 dont 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 youve 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 its 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 isnt 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 youre 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.
Its 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 Ive been looking for an example of this kind of deep business-level consolidation, and every time Ive scratched the surface of a database consolidation project what Ive come up with is something far short of far enough.