The Worst Mistake

07/21/2006

The Worst Mistake

I recently undergo the worst mistake that can be done in a business intelligence project. Of the large number of pitfalls there is one that must be avoided at all costs.It spoils developers’ and consultants’ lives, it makes the client terribly unhappy and helpless, it automatically makes the project go late.So never, never, never, never, never, never, never…
…build a business intelligence system (or a part of it) before the source system is fully deployed.
It is such obvious evidence that it should not be necessary to explain this further, but I keep seeing projects where the main transactional system starts together with the BI system. Along with this I keep seeing stressed consultants and disappointed customers.So, what are, once and for all, the reasons that prevent a BI system from going live right together with its transactional source?
If there’s no data to analyze there’s no way to analyze them.It seems too obvious but a system with only a handful of test data is not representative at all of the entire cruising situation.
Migrated/Imported data are not suited for developing.Maybe the new system is filled with migrated data. They are not suited for BI development as well. They are not because, often, systems work well with different patterns that are not the patterns produced by the operational system itself. That is, some test data fields may be filled while, in new transactions after go live, they’ll be empty, or will contain a different value. Some lookups may work only before, on migrated data and not after. Some phenomena may actually take place only after the go live. To build a consistent ETL process, to cleanse and rearrange data, all the data patterns and all the phenomena must be in place. Each early try is doomed to failure as unnecessary transformations will be put in place and necessary ones will be left.
Business Intelligence is related to bulk data analysis. Business Intelligence queries normally sweep large amount of data to extract aggregations, averages, metrics of any sort etc. This means that testing those operations on fake data is by no mean a sensible way to develop data. True values can be figured out only from true data.
Many Business Rules are implicit. Not all the business rules that are meaningful to the analysis are explicitly stated. Many are embed in the transactional system functioning. Often they are taken for granted by users and ignored in the requirements collection step. The database builder and the report builder will be called to a detailed work to carefully analyze those rules and transform them to the reporting/dashboard expected behaviour. Usually these rules do not apply to the generality but to particular cases. Test data cannot catch up these cases.
So, I hope you’ll think to this short article the next time you’ll find yourself in an “everything now” situation.