Business Intelligence applications are often based on a denormalized version of transactional data. This is done mainly to:
- keep analytical processing from slowing down the transaction systems
- create "reporting friendly" databases that lend themselves to analysis
Traditionally, both transactional and analytical databases reside on hardware inside the company's firewall and when necessary, a BI report and/or chart can drill down from one system to another transparently.
With Cloud Computing, this model gets more complicated. The current trend of moving to the Software as a Service (SaaS) model is centered on transaction processing. For example, Salesforce.com is a transactional system that allows users to access a Customer Relationship Management system in a cloud. In the old days, because of the total cost of ownership, smaller organizations could ill afford to acquire these systems, and instead, resorted to maintaining their data in home grown and/or Excel-based databases. The SaaS model allows an organization of any size to access and benefit from very sophisticated systems through subscribing to them on a named user basis. Therefore, whether an organization has 10 or 1,000 sales reps, it can maintain a robust set of metrics at a very reasonable cost.
However, since these metrics are maintained in a cloud, how will the owners of the data slice and dice them in order to find trends and create meaningful Key Performance Indicators? Currently, there are two ways of addressing this issue:
- depend on query tools provided in the outsourced application to extract the data into a local database
- use Data Warehouses created to support the transactional system in the cloud
The former is cumbersome and prone to errors while the latter is a lot more expensive and not necessarily a simple do-it-yourself endeavor. In my next article I'll discuss this dichotomy in more detail.