The Biggest Reason Why Business Intelligence Fails For Many Applications


Many Projects put so much resources in terms of time, effort and money to collect and process business data.  The developers put 80% of the project time into developing the project with little thought into reporting.  The real question is if the developer captures the data then why is reporting still failing?  Why is it so hard to get the data back out and tell valuable business stories?

The mind set of a good developer using Domain Driven Design techniques is to start coding at the business services layer. This means they are thinking about the business process and how to wrap the code around that flow.  The end user see the UX and so that too get lots of upfront attention.  The user sends immediate feedback on how to use the application and how easy it is to use.  This will slant the development attention in favor of the UX and business process.

“Begin with the end in Mind” – Bill Inman

Corporate Information Factory

The end user maybe sees in the short term that the end is a working application.  That is certainly not the end game.  It is really only the first step in development.  There is very little strategy given to the persistent data model or the database model.  The end user never sees it and who cares how its is stored as long at the application can easily read and write to the database.  The BI engine is then asked to report on in most cases a very normalized and silo data model.

There is really only way real way to fix this issue and that is to have a data architect who thinks about both development and BI to design the model that the developer must use. The developer at first will not like this because reading and writing to the database is often harder than they would like to do but it is a small price to pay for getting on the super highway of BI once the data becomes big data.

The most common pitfalls when designing

  1. We do not need to data model; we will just copy the source system tables
  2. We do not have a data modeler so we will just do without
  3. We built the data model already; we just need reports now (if the data model does not reflect the report specificaitons and the general business requirements then you did not design a model for your reporting)
  4. We will use stored procedures, this is extremely limited and brittle and will lead to much greater costs over time.
  5. We can just get someone who knows the tools for the job, a talented new hire.  This will rarely work unless the designer is a data modeler and business analyst.

Stephen Choo Quan

Stephen is a double threat holding both SAP business objects certified architect as well as being a certified IBM DB2 Database Developer. read More…