This article originally appeared on the BeyeNETWORK
Those enterprises that have a clean, consistent model of their business in a data warehouse representing customers, products, markets and other critical business relationships are in a much better position to weather challenging economic dynamics than those that are flying blind. The allocation of limited resources can be done in an optimal way; tough decisions can be made based on facts, not fancy; requests for support and extensions can be done in a way that builds credibility and integrity rather than saps it. As a rule of thumb, knowing what you don’t know results in fewer surprises than not knowing what you don’t know. Businesspeople hate surprises, and a data warehouse is one way of avoiding them.
For those enterprises that have been lax or casual about building the data warehouse, it will not be simple, but by no means impossible, even in a down economy. Challenging economic times can make it easier to overcome local politics, turf wars, finger pointing, being right, and personal egos in the interest of furthering and sustaining an enterprise point of view. Bill Inmon tells the famous cautionary tale of the project manager who got back to his desk after successfully implementing a data warehousing system only to receive a call that he was fired. The name of the company? Enron. Not too much information – but information of the wrong kind – about what wasn’t working. If leaders do not want visibility and transparency, then that itself should be a worrisome sign. But what about the enterprise point of view when the enterprise has just been acquired by another firm or, just as scary, has acquired another firm whose business and assets are supposed to represent future growth areas?
The Consolidated Enterprise
Ideally, an inventory of information assets should be conducted prior to the acquisition, whether takeover or merger. Major incompatibilities can put the benefits of the consolidation at risk. If one of the benefits is supposed be greater operational efficiency by closing or consolidating IT operations, etc., it is especially unpleasant to learn that platforms and business processes dependent on them do not mesh well. Assessment of compatibility of information technology systems is often a part of the due diligence that precedes the merger or combination of the larger firms. However, this is sometimes performed superficially, making surprises inevitable. If such an overview is not possible because it is a “shotgun” wedding, driven by regulators, a bankruptcy judge or unbending market imperatives, then it is likely this will be done on a crash basis soon after the acquisition is formalized. If that’s the case, fasten your seat belt!
Even prior to an acquisition, heterogeneous data is often the state of the average IT organization. The consolidation of two separate enterprises presents a quantitatively greater and more complex data integration problem, but not one essentially different in kind. The data warehousing group will have cross-functional technical and organizational skills to offer to the entire merged, consolidated enterprise. These skills can be exploited for the good of the new, larger whole.
The merger of two firms presents challenges and will require strong executive leadership to reduce the risks of marching and counter-marching. If the executives of the firms believe they are merging to provide complementary operations and IT is working at consolidation (or vice versa), then serious misalignment will result. As a part of the IT infrastructure, the data warehouses will be subject to the same prioritization, triage and consolidation as the other parts of the IT organization. However, the one significant difference immediately evident is that the cross-functional data warehousing team will now include members from both of the organizations. In the instance where some systems (and people) are being eliminated, the utmost tact and professionalism are required to obtain detailed background on data warehousing design, technology and operations from those in a sunset situation.
Leveraging the Data Warehouses
Benefits to be obtained from leveraging a data warehouse in an acquisition are directly proportional to the overlap between the customer and product lists of the two enterprises. If the customer lists were complete duplicates, one system could be eliminated or greatly consolidated; and the products from company X's list could be cross-marketed to the customers at the combined firm. If the customer lists were mostly different, then an opportunity for seizing additional market share is represented by the data warehouse that, in turn, will make possible such a marketing initiative. That is reportedly the case with Bank of America’s acquisition of Merrill Lynch where little overlap existed between retail banking and the thundering herd of wealth management brokers. Notwithstanding the “shotgun” wedding – and at risk of mixing the metaphor – Merrill is the tail wagging the dog. If the merged firms were in service businesses (e.g., consulting, transportation or healthcare), the extra capacity would be represented in the data warehouse insofar as it represents the merged enterprise as a whole. This does not represent a benefit in itself, except that an accurate model of the enterprise is a powerful tool for management when making decisions and identifying marketing and revenue trade-offs. The benefits of data warehousing for firms that are merging are similar to those undertaken by a single enterprise (a single fact is still worth a thousand opinions in a recession): managing by the numbers, tracking trends, revenue and profitability, cross-selling and up-selling. In other words, substituting information for inventory thanks to a consistent, unified view of customers, products and services.
Of course, this is a simplification. Two firms being merged rarely have normalized their customer, product and service data structures against a single, canonical, unified, rule-governed representation of the information. Even if the data types are the same, the information is often grouped differently or described in overlapping and partially inconsistent ways or displays different levels of granularity. Much data engineering lies between the existing systems and the reconciliation of the two disparate data stores. In the likely event that such data engineering has not yet happened upon formalization of the acquisition, such a design task (building a consistent view of customer, products, etc.) can be expected to lie on the critical path just downstream from a readiness assessment and a prioritization of projects in the IT portfolio.
In the context of an acquisition, the existing data warehouse systems are just another group of systems to be inventoried. If the merged enterprises were already operating enterprise data warehouses, they would be able to compare customers, products, services, etc. across the board and perform an assessment of overlap and cross-sell opportunities. The list of standard databases in the infrastructure has grown over the past few years, extending beyond the stalwart usual suspects (IBM, Microsoft, Oracle, Teradata) to include a slew of data warehousing appliance offerings (Balanced Warehouse – IBM, DATAllegro – Microsoft), Dataupia, Greenplum, HP Oracle Exabyte – not to be mistaken for HP Neoview), Netezza, prototype and production instances of open source (MySQL, Postgres), and new-fangled column-oriented data stores (Alterian, ParAccel, Nucleus (Sand), Sybase IQ, Vertica), which, of course, are not really new. Even then, it will be necessary to employ "workarounds" such as sequential extracts of customers and products, followed by transformation and load to a rule-governed format that represents the logically unified view of the data. This is doable using of one of many extract, transform and load (ETL) tools. If the merged enterprises do not have such data warehousing systems or have ones that are mostly incomplete, building one should be a priority. Such a project can serve as a focal point for constellating combined efforts to match and merge overlapping or inconsistent systems. However, before jumping blind into such an undertaking, a readiness assessment and a prioritization of requirements should be completed.
Design for the Long Term
Even before the economic bubble burst, data warehousing and especially data mart consolidation was an ongoing trend. The pendulum had swung in the direction of smaller, more self-contained data mart class implementations where they could have a quicker impact on marketing and revenue operations. The current corporate dynamics around “shotgun” mergers of shaky financial, home building, manufacturing, and retailing will accelerate those trends. With that in mind, a final word of caution and recommendation. Do not be like the firm that implemented its data warehouse but forgot to design it. One result was a lot of rework – by a new and different team. The more intense becomes the shouting for a quick fix, the more important become quality (high), integrity and professionalism. That means design for the long term and enterprise context even if the system is a limited and local one. Work fast by documenting issues and escalating, making for political cover. This will enable the data mart to be rolled up into an enterprise perspective when the focus shifts back to expansion and growth as it inevitably will. If someone asks what you are going to give them, be sure to offer and express appreciation. And if you’re invited to a “shotgun” wedding, don’t forget your bulletproof vest!
Lou Agosta is an independent industry analyst, specializing in data warehousing, data mining and data quality. A former industry analyst at Giga Information Group, Agosta has published extensively on industry trends in data warehousing, business and information technology. He is currently focusing on the challenge of transforming America’s healthcare system using information technology (HIT). He can be reached at LAgosta@acm.org.
Editor's Note: More articles, resources, news and events are available in Lou's BeyeNETWORK Expert Channel. Be sure to visit today!