One of the powerful features of OBIEE is the possibility of federated query's. Sadly in most sales pitches we tend to emphases the technical part instead of the practical part. Every now and then there is a BI-manager in the audience who really knows his stuff and starts asking the wright/wrong questions. In this article I want to show you some of the pitfalls when trying to "sell" federated query's.
The most common demo is we get all the data up to last night from our DWH and add today's data from the OLTP system.
Pitfall #1: Creating unstable reports.
Most managers tend to bring paper printouts of there reports to the meeting. This means that the printout for manager 1 at 09:10 will different from the printout for manager 2 at 09:15. This leads to useless discussing of the numbers on the report.
Pitfall #2: Wasted energy
A DWH generally contains data over a long period of time. For strategic or tactical discussions today's unstable data is not significant compared to the amount of historical data. A federated query would be a unnecessary claim of recourses of the OLTP system.
Pitfall #3: Uncleansed data
The ETL process which loads the DWH often cleanses the data from the OLTP system. (FI: Don't count invoices from department '999'). If these rules aren't covered in the RPD it will lead to the wrong numbers.
Does this mean you should use federated query's against an OLTP system at all? Of course not! Just think about the result your are trying to get. Try confining the federated query to a specific level. (FI: Use in only when a day to day comparison is made.)
Till Next Time