Blog: Mike Ferguson Subscribe to this blog's RSS feed!

Mike Ferguson

Welcome to my blog on the UK Business Intelligence Network. I hope to help you stay in touch with hot topics and reality on the ground in the UK and European business intelligence markets and to provide content, opinion and expertise on business intelligence (BI) and its related technologies. I also would relish it if you too can share your own valuable experiences. Let's hear what's going on in BI in the UK.

About the author >

Mike Ferguson is Managing Director of Intelligent Business Strategies Limited, a leading information technology analyst and consulting company. As lead analyst and consultant, he specializes in enterprise business intelligence, enterprise business integration, and enterprise portals. He can be contacted at +44 1625 520700 or via e-mail at

January 2007 Archives

This blog entry is co-authored by Mike Ferguson and William McKnight (link) and is being cross-posted on our blogs.
When you’ve decided the appropriate forays into EII (staying away from the times NOT to use EII) and you’ve selected your product, you will need to architect it into your information management environment.

The process of getting the EII tool to learn about a data source is called mapping. From this exposure to the underlying sources, you can use the EII tool to create a virtual schema, which will be used on data access. All EII applications will then see and use the single virtual schema.

The technical base of the data sources can be relational databases, packaged applications, file servers, web services and potentially numerous other data stores – operational and decision support e.g. data warehouses. Indeed, this will be a major criterion of your tool selection. EII platforms differ somewhat in the data source types supported.

Generally, one of these EII instances per environment with multiple data sources is all that is necessary. If your users already use a portal to access information systems, the EII platform can become another of the underlying data stores accessed from the portal.
Applications built on the EII platform can support SQL, XQuery for XML, ODBC, JDBC, and other APIs to access the heterogeneous data sources hidden by virtual view(s) defined in the EII platform.

The implementation of EII in an environment is often the first time that an organization will be capable of providing users with access to an integrated view of both their operational and the post-operational environments. A big decision in your EII architecture will be if you want to expose this fact to the user and for what kind of use should you make such views available. Many organizations start out by leveraging their EII investment to rapidly produce operational and regulatory reports that require data from heterogeneous sources. More mature implementations of EII, in environments that have already been able to shield users from underlying architecture elsewhere in the data access environment, should successfully be able to continue this practice.

Posted January 25, 2007 9:50 PM
Permalink | No Comments |

Earlier today, Cognos announced that they had acquired operational BI and performance management vendor Celequest in a non-disclosed deal. This is the first of the large independent BI vendors to step into the world of Business Activity Monitoring and Operational Performance Management. All I can say is that it is about time! This acquisition may well trigger similar acquisitions or announcements by other large BI vendors competing with Cognos to allow them to push into this fast growing market. The acquisition shows that Operational BI is beginning to become a mainstream issue pushing BI to the center of the enterprise plugged into core business operations and processes. This is signalling the shift from business intelligence to intelligent business

Posted January 17, 2007 5:09 PM
Permalink | No Comments |

This blog entry is co-authored by Mike Ferguson and William McKnight (link) and is being cross-posted on our blogs.

Many questions arise about what vendors supply solutions in the market place for enterprise information integration (EII).

There are two main types of EII vendors in the marketplace:
1. Model driven federated query EII vendors
2. ETL tool vendors providing EII via data integration services built using traditional graphical data flows and published as web services

In the first category the vendors with federated query EII products include
• Business Objects Data Federator
• BEA AcquaLogic Data Services
• Composite Software Information Server
• Denodo
• IBM WebSphere Federation Server (formerly WebSphere Information Integrator) and IBM Information Server
• Ipedo XIP
• Metamatrix
• Sybase Avaki
• XAware

It is also the case that several ETL data integration vendors have extended their data integration tools to support EII. These vendors include:
• Ab Initio
• Business Objects - Data Integrator
• IBM - WebSphere DataStage SOA Edition
• Informatica - PowerCenter
• Microsoft - SQL Server Integration Services
• Oracle - Warehouse Builder
• SAS - Data Integration Studio

Posted January 17, 2007 1:29 PM
Permalink | No Comments |

This blog entry is co-authored by Mike Ferguson and William McKnight (link) and is being cross-posted on our blogs.

Much discussion abounds about when not to use enterprise information integration (EII). This blog looks at some situations that are not particularly well-suited to the use of EII technology as a solution. Please note that these criteria should be taken only as guidelines.

Generally speaking EII is NOT suited for

• Complex transformations, fuzzy matching and integrating high volumes of data

• A replacement for data warehousing

• Business process management

• Frequent federated query processing with single federated queries integrating data across a large number of data sources. Performance may become an issue as more and more data sources are added to a data integration server. Several vendors do support caching in order to counteract this problem but nevertheless if you plan to integrate data from a wide range of data sources in a single query you would be well advised to benchmark products and compare results before making any purchase

• High volume transaction processing (insert, update and delete) is required to update virtual EII views of data in multiple underlying systems. This is because update processing via EII is still in its infancy and can be subject to product specific restrictions. Also concurrent access to EII servers may cause problems as workload management is missing from many tools. It is recommended that you investigate carefully how well EII vendors support transaction processing and if they support 2-phase commit distributed transaction processing.

• Transaction processing when integrity constraints across data sources are complex and could cause update processing to fail

• A complete solution to enterprise master data management. EII products can potentially provide a virtual view of integrated master data IF EII tools support global unique identifiers (and the mapping of disparate keys to the global one) and also the matching process to integrate data from multiple master data systems of entry does not require complex fuzzy matching. EII may be offered up as a component technology in an MDM solution but it will not provide everything needed for a full complete solution

Posted January 11, 2007 7:30 PM
Permalink | No Comments |

This blog entry is co-authored by Mike Ferguson and William McKnight (link) and is being cross-posted on our blogs. This is the first in a series of entries on Enterprise Information Integration (EII). EII is gaining traction for enabling data integration without the need for the physical instantiation of the integration. In other words, EII adds integrated reporting capabilities while minimizing impact on existing systems. We have been selectively adding EII to our data warehouse architectures. Today, we’ll look at those situations when EII makes sense for data integration requirements.

1. Connecting structured (as in data in a data warehouse) data in particular with unstructured data takes advantage of EII’s strength of leaving data in place that could dramatically increase overall storage requirements if duplicated

2. When immediate data change in response to the data view is desired (changing a copy of the data would not suffice)

3. When data transformation is relatively light or nonexistent and just getting the data together for integrated query is the biggest challenge

4. When the relatively worse query performance of EII query is acceptable (versus the obvious advantages of physically cohabitating all data for the query)

5. Some operational and regulatory reporting where the data needed is not completely integrated in one place

6. Integration of Performance Management software with multiple underlying line of business BI systems to allow a company to see performance management at the enterprise level (across line of business BI systems) using LOB metrics to calculate enterprise KPIs

EII is changing and some of the disadvantages and restrictions will lessen over time but it’s a chicken-and-egg situation. More end clients will need to incorporate small adaptations of EII in their decisioning environment to spur the growth. There may be opportunities and TCO propositions to federate your data acquisition requirements now using EII. Small sized, relatively smaller transformations, unstructured and interactive situations provide those opportunities.

Posted January 6, 2007 4:59 PM
Permalink | No Comments |