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 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.

What exactly happens when those distributed queries make their way through to the source systems? For a start, the unpredictable nature of queries will upset the careful load balancing done by operations departments to optimize on-line throughput. Or rather, it won’t, because no systems managers are going to allow this technology anywhere near their delicately balanced systems, at least not after the first time it brings the ordering system to a grinding halt.

The next problem with the EII approach is that there is no history. For transaction systems, you want to archive data quickly in order to maintain high performance (there is no need to worry about what your account balance was last year, just what it is now; last year’s balance can be archived). However for an inquiry like “show me the trend in account withdrawals over the last year in the south-east region” then this does require historical data.

Next, do these vendors really think that all the analysis hierarchies needed are embedded within the ERP systems? To take the example of marketing, there are normally complex segmentation hierarchies for analysis purposes that are usually held in entirely separate places from the core transaction systems, and are not stored along with each order or invoice.

Just as importantly, the EII tools entirely ignore the tedious problem of data quality. It may be news to vendors who have more experience producing Powerpoint slides than production code, but the quality of data lurking in the transaction systems is not what it might be. This is why there is an industry of products to assist with improving data quality, and why a significant chunk of any data warehouse project budget is associated with data quality. Oh that’s right; you don’t need a data warehouse any more, so I guess you may as well ignore that pesky data quality problem as well.