This article originally appeared on the BeyeNETWORK.
Part 1 of this series discussed some basic reasons why a bus architecture is no substitute for integration of data and why it does not meet the needs of decision support analysts for the access and analysis of data. A lot of vendors have sought to solve the problem of integrating data and forming a basis for analytical processing by integrating the data inside the bus at the moment of access. By doing the integration of data inside the bus, the vendor doesn’t have to go back into the application and integrate the data. Or so the theory goes. However, the reality in this case is 180 degrees different than the theory.
While the previous article discussed some very fundamental reasons why doing integration “on the fly” through a bus architecture is no substitute for actual integration, there are some other, even more profound reasons why that method is not a substitute for a properly integrated, robustly and properly structured foundation of data.
The most basic reason is that the bus architecture assumes that the applications that will be accessed have in place a proper supply of data. This is a very invalid assumption. In order to understand why, see Figure 1.
Figure 1: Illustration of the Differences in Three Applications
In Figure 1, there are three applications. Each of the applications has data about revenue. In one application, there is weekly revenue data for one quarter. In another application, there is monthly revenue data for a year, and the third application has daily revenue data for a month. Each of these applications makes its data open and available to the bus.
Now suppose the analyst wants to look at revenue by transaction – i.e., revenue generated by each sale. The problem is that each of the applications has summarized data. There is no data that can be broken down by sale. The most intelligent bus in the world cannot solve this problem of the need for deeper granularity of data.
Now suppose that the analyst wants to look at data for the past two years. None of the applications have that amount of data. It simply isn’t there. The smartest bus in the world cannot solve the problem of finding data that is not there. The bus architecture is limited by the applications it accesses. Assuming that the applications have a rich and robust historical supply of data is not a valid assumption.
The issues of granularity and history are at the heart of conducting proper analysis and decision support. The bus architecture simply does not address either of these issues.
A proper data architecture is necessary. In addition to integration, the data architecture must address the issues of granularity and the need for history. Whether the data architecture is built around a data warehouse or an operational data store (ODS) – or both – is a moot point. The panacea to the problem of analysis and decision support is not a fast and clever bus.