Business Intelligence - What is it really?
The last few years I have been working with developing BI solutions, and people I talk to have a challenge to understand what BI means. When you say "BI", some would think of it as something complex and maybe unnecessary, so they might rather just create some reporting for their solutions. Well…. BI is reporting!
Written by Christian Dalen, BI Solution Architect in Frontica
What is a Data Warehouse (DWH)?
Normally you would build a Data Warehouse (DWH) to host the data from several systems in one common source. This is, normally, a database with data in normal database tables. You have special editions of databases which are optimized for hosting a DWH, but that does not mean you necessarily need to invest in them if you wish to build a DWH. Just think of the data warehouse as a database with tables which are built to be easy to make reports from.
What is a Dimensional Model?
There are several ways to model the data, but the most common way is to model the data based on a Dimensional model. You might say that BI evolves around two terms:
- Things you want to count, sum or run an average of (A "number")
- This might be number of employees, total income, average age or a percentage of a total
- Things you wish to either filter or group by
- This could be department, country or status on something.
What is a Cube?
Cubes are built on top of the DWH and their main purpose is to make sure you get data within an acceptable time. E.g. if you want to find financial data per customer, then it could be up to millions of rows that need to be analyzed. A cube makes sure that all the data you expect to report on is already calculated, so the cube will show you the already processed data. This is more responsive process when working with the data. The cube also makes it easier to limit access to data through roles in a way that might be more difficult if you were to read the data straight from the database (DWH).
Front end – “Seeing is believing”!
Ok - so now, we have all the data put nicely into a database and all the data has been related neatly to each other and is ready to be used. So far, no users has seen anything, and seeing is believing, right? Depending on the purpose of the report and the nature of the reporting tool, you would connect either to the cube or directly to the DWH.
I have found that there are mainly three different purposes for reports:
- Standard reports that are intended to look the same every time
- Fancy dashboards that give you a quick overview at a high level with analytic capabilities
- Reports that are intended to be used for investigation and analysis
It is not easy to find a reporting tool that is good for all purposes, so you might be better of choosing different tools for different purposes. The main job is to build the DWH, and this DWH can be used across reporting tools ensuring they are based on the same data so the reports are consistent independent on the tool used for the actual reporting.
Begin with the end
I think I should mention one more thing regarding the front end. I actually find it best to start a BI Project with the front end – not make the actual reports, but visualize the data in a dummy report or a “quick and dirty” proof of concept. Then the end users, which are the ones with the requirements, can quickly visualize the final result. This is something most people can relate to and it becomes easier to identify which numbers that are important to see (measure), and how data should be grouped or filtered (dimensions). It is also important to help the end user identify which data he or she would need to analyze/find root causes, if the data for some reason seem off. For example, if the sales numbers seem to be too high or low, you might want to look closer at which region the sales are coming from. This will help identify which dimensions that should be included in the BI Solution.
Considerations when you decide to invest in BI
Being able to build a data model that reflects what you want to report on could be challenging, especially as many who require a BI Solution (Reports) are not BI architects who know how to create a functional specification. They also might not know what is considered important for building a solid BI Solution. You need the right resources to develop good functional requirements that your BI resources can relate to.
Very often, a big issue would be that you bump into data inconsistency across the systems and lacking data quality. It is often first when you decide to make a report that aggregates numbers at a higher level - across systems - that the inconsistencies tend to pop up. Many companies do not have a clear strategy in terms of Master Data Management. Consequently, it becomes difficult to relate and analyze data across systems (e.g. conflicting company names). If you are lucky, you have consistent data across your systems, which relate to the same values and you are fortunate to have good data quality. Are you that lucky? If so, then you have a very good foundation for building BI Solutions without major issues.
All that is left is my good luck to you on your BI Projects. I hope that you feel that you now know a bit more of what all this is about, and if not, please give me a call!