This article is the third in the series on Financing the BI Solution and follows from “BI Project Decisions: Ready Made Database Options” and “Financing the Business Intelligence Project“.

The decisions we make about the solutions we buy, which must all be made at the start of any new implementation do require analysis of a wide range of factors. In the case of the BI solution these must consider the existing infrastructure and any proposed imminent changes to it. This does complicate the decision making, but it is an essential part of BI project success.

Within any Business Intelligence implementation it is necessary to understand the impact of the corporate IT architecture. The complexity of the architecture can be a key factor in identifying any plausible ready-made solution. Many organisations have a veritable spiders-web of systems and inter-relationships some of which will defy logic, yet exist they do. Whilst it is primarily the operational applications that will be providing data to the Data Warehouse that must be considered to support the solution must take a more holistic view. Any system may hold key pieces of information and is thus capable of providing data to the Warehouse.

If we examine any two companies we will become immediately aware of architectural differences between them (and these are based on real solutions provided in the past).

In one organisation there may be an evolutionary mix of systems of varying ages and types; with few systems integrated together; there are many overnight batch jobs that transfer data between systems, but no integrated approach. How the organisation was formed may have an impact on the solution needed: here acquisition has meant there are separate systems in each of 17 different countries, some are packaged solutions, but most are bespoke. For the global corporate headquarters to gather worldwide information it has to contend with a complex mix of old and new systems using different data storage standards; all potentially making this a complex solution.

Conversely a second corporations is more integrated: all applications use pre-built solutions, based on relational databases; bringing an integrated architecture, that is well documented, and has been at the foundation of its IT platforms. It should be clear to the reader that this company’s architecture is unlikely to be very complex.

It is essential as a part of the financial decision making process to grade both the business and technical complexity of the solution.

Integration of existing systems is always an essential step especially assessing the corporate legacy application architecture. Integration of systems is almost always ranked as one of the most important architectural factor when deciding whether a pre-built Data Warehouse can be implemented. Highly integrated systems can be an enabler for a ready-made database. They are not the sole reason to implement a pre-built solution.

It is necessary to add a word of warning before diving headlong into such an implementation. When companies introduce new ERP, or CRM systems there is immense pressure to introduce analytics at the same time. This can also be true for SaaS, or Cloud Computing solutions. Often this is the integrated ‘Business Warehouse’. When the new ERP or CRM is introduced it is unproven (from the business viewpoint) and there is an assumption that results taken from the out-of-the-can Analytical Application are valid and correct. This is not always the case. An assessment of data quality is as essential to the ready-made solution as it is to the custom built Warehouse. Generally a new system cannot have its data quality assessed until it is in production and has had the wrinkles ironed out of it.

Next article in this series “What Makes Our Business Unique?”

If you built an office block without an architect’s plans, and all of the relevant city/state approvals. Sure you can put-up a building without plans, but if it collapses with loss of life then you will be facing serious repercussions (and probably criminal proceedings).

When it comes to the corporate IT structure then there seems to be a general acceptance that it is OK to simply plug-in a new component without adequate planning. On top of this corporate mergers add other unplanned systems into the mix. The problem is that we end up with a mess.

The purpose of building an enterprise architecture is to ensure that all components deployed are compatible and function in a planned manner. The other effect of implementing a consistent architecture is that there should be a $ saving for the corporation.

I have previously worked with an organisation that had to implement a consistent architecture after a corporate merger brought in 5 different systems covering the same business area. The net effect of consolidating these various systems into a single architecture was a saving of $20 million of licensing fees over a 5 year period – at an integration cost of approximately $1 million. That is where a consistent architecture reaps benefits.

Not every case will have tangible financial benefits to show, but even a CEO will understand benefits if you can demonstrate performance improvements even where there is a $ cost for the upgrade, provided the benefits bring an demonstrable advantage.

Planning is the key to success

By Peter B. Giblett