Mergers, Acquisition & Data Aggravation: M&A Hell

You go to work with the architecture you have – not the one you designed.

With – ahem — apologies to Donald Rumsfeld, the above is many a CIO’s problem. Either through mergers & acquisition (M&A), new job, or legacy systems predating tenure, infrastructures are less an issue of design and more an issue of inheritance. And much like the treasures Aunt Shirley bequeathed to you – they can be less than desired too.

Nothing kills the thrill of an acquisition faster than finding out post-deal that you can’t integrate systems in order to achieve the synergies you expected. In fact, depending on who is counting, M&A failures are between 40-80 percent — with an inability to integrate systems one of the leading causes. And while failures alone are bad, 50-70 percent of them, according to Orit Gadiesh, chairman of Bain & Company, “actually destroy shareholder value.”

The M&A Gift: Inherited Infrastructures

Solving this problem of inheritance, or infrastructure sprawl in general, has been made easier of late with schema-agnostic database platforms that allow data and metadata to be stored and queried. Planned growth in most enterprises results in a mosaic of “purpose-built” systems that must be integrated. Ignoring all the issues surrounding rationalizing technologies and duplication of technology teams, the real crux is to get to the point where you are sharing information – be it related to customers, payment systems, product SKUs – whatever, fast!

Adding new infrastructure through acquisition is just a matter of more data from more silos in need of aggregation. Because really, at the end of the day, unifying data from newly acquired systems is no different than integrating any and all enterprise operational systems like ERP, CRM, OLTP – or any other type of system.

My colleague Ken Krupa, Enterprise CTO at MarkLogic and resident pragmatist, concurred. “Inherited data systems, mainframes, disparate databases, even the same database with different schemas create a heterogenous mess,” he told me. “If you are going to have to do all that ETL to make things communicate – you will never realize intended benefits, be in compliance or whatever it is you need to do. In short, you’re very likely to fail.”

Operationalizing this acquired data means beyond a relational paradigm which has proven to be very limiting. New-generation NoSQL (“Not Only SQL”) databases have gained popularity because they are ideally suited to deal with the volume, velocity and variety of data that businesses and governments handle today.

NoSQL for M&A

“Companies are using Enterprise NoSQL to create a unifying information hub – either ingesting free-text, modeling data with XML, RDF triples, JSON, or combinations of the above,” explained Krupa. “Having all of the data in one place, and in a place that can actually make sense of the data is what allows stakeholders to do discovery inside of a comprehensive business context, as opposed to dealing with the friction of asking different styles of questions depending on the type of database in which the data is stored. If you think about it, it’s hugely inefficient to parse a discovery task into the ‘structured part’ of the question, the ‘unstructured part,’ the ‘semantic part’ and so on. It’s more natural (and effective) to do discovery across all of these dimensions instead of creating artificial technical boundaries that ultimately result in diminishing the overall quality of the entire process.”

Less Operational Overhead

Aside from discovery, there are huge operational gains too, with regard to data management. “Not being bound to a rigid prerequisite modeling process in order to achieve tangible business results is a huge enabler,” Ken said, who has been under the hood at many a Fortune 100 company. “It’s not that models aren’t important, it’s just that relational models force us into a mode of making sure they’re ‘perfectly defined’ before we ask a single query, let alone write a single line of code. I truly believe that the origin of the cliché phrase of ‘analysis paralysis’ has its roots in the constraints of RDBMS modeling.”

I agree with Ken. Conforming to a single schema takes time, people and resources. Analysis paralysis is very real, even if it is a cliché phrase. And as long as another cliché phrase – “the only thing constant is change” – remains true, there will be an ever-increasing need for technology that manages change more elegantly.

And nothing says change more than an acquisition.