Intelligent Enterprise

Editor's Note: This month, we present opposing views of the "EII for business intelligence" issue from the vendor community. In the following article, Andy Hayler, founder and chief strategist at Kalido, makes the case that using EII as a business intelligence tool is ill advised. To learn about the opposing point of view, read "A New View on Intelligence," by Tim Matthews, co-founder at Ipedo Inc., who contends that EII provides the perfect foundation for "on-demand intelligence."

The computer industry loves its buzzwords, and one that has cropped up in recent years is "enterprise information integration" (EII). The idea behind this is that everyone knows that companies have their data locked up in multiple, incompatible IT systems: ERP, CRM, supply chain, etc. At present, the only way to make sense of this data is to extract it from these systems, try and resolve inconsistencies and data quality issues, and then load the result into a data warehouse, from which you can report on the data in a common form. Unfortunately this approach is hard: you discover that the data quality in even the shiniest new ERP systems is not what it might be, you have to unravel the differences between the way that various business units classify products, channels, and customers, then you have to design and build a data warehouse and the subset "data marts" from which you can report using one of the many well-established reporting tools around (such as BusinessObjects).

EII vendors' technology has genuine application in trying to answer questions that involve access to current data, such as "give me a view of the all the data we have on customer x" — what some term "lightweight BI." However, they have recently been peddling their products for more general business intelligence applications. After all, why go to all the trouble of building a data warehouse when someone can come along with a technological magic wand? Vendors with "EII" solutions have whitepapers that scorn today's approach to business intelligence, promising that their technology can merely look at all those inconsistent source systems and somehow run queries that will give the answers without having to go through all that dull work of building and populating a data warehouse.

Well, in that case, what were we all thinking? The data was there all the time in the source systems, and for over a decade people have unaccountably been copying it somewhere else in order to report on it; what a bunch of dopes they were! How much simpler just to access the data directly in real-time from the sources — how very "real time enterprise."

Some people who should know better have swallowed this EII mirage hook, line, and sinker, and a number of start-up companies have been funded flaunting "EII for business intelligence" messages. The only problem with this new futurist approach is that it is absolutely and utterly flawed.

Let's consider the problem again. You have data in dozens of incompatibly structured source systems. Your new EII software is somehow going to build a presumably fairly complex set of distributed queries that will zip off to the source transaction systems, interrogate them and bring back a result set that will somehow produce a consistent answer.

The first problem is: how exactly does the EII software know what the linkages are between the differently coded source system structures? Somewhere it is going to have a catalogue which will translate the differences, rather like a dictionary to translate words from one language to another. This sounds suspiciously like a metadata dictionary of the type that data warehouses have to construct, but let's leave that aside for the moment.