People often expect that all reports should be generated from the data warehouse. Operational applications do the heavy lifting for the needs of the business. Analytical systems, constructed of data warehouses or data marts, serve up reporting needs. The original drive for creating a data warehouse arose from load balancing the work against the operational systems.
“Uncontrolled” reporting frequently burned cycles, and tied up space in an ungainly feast or famine way that abused any single integrated data source. When certain reports ran, the operational systems stopped working properly, response slowed to a crawl, and things that should have worked efficiently simply didn’t. Eventually it became apparent that the operational database and applications running the business were actually harmed by folks doing a “deeper dive” in their desire to make sense of organizational data. Therefore, a split emerged: one database became two, one optimized for the work of keeping business operation moving ahead, and a secondary version of things optimized for analysis.
Following this split is the point where the confusion emerged. Some people got the impression that all reporting, for every possible use, must come from the data warehouse, or associated data marts. And not a single report, ever, should be allowed to run against the operational application. While drawing such a straight line down the room makes for a nice division of tasks, the flaw in those thoughts is in the implied belief that all reports are created equal. That narrow-minded harsh view doesn’t allow for a report to be wholly operational in nature. Under these lines of demarcation, reports must occur only downstream and the very existence of reports makes them analytical. In fact, circumstances do exist where current data is needed for a report, and where there are needs for operational decisions about how to treat a customer right now that must be based on current data. In order to support these needs and provide for immediate usage of current data, either one requires a real time data warehouse or some level of reporting must be allowed to run against the operational applications.
Executing certain reports against operational systems can be viewed less negatively. Very little difference exists between displaying a screen full of information within an operational online and displaying a report. This is not to say that just any reporting should be executed anywhere; but with prudent consideration, some reports can be executed easily and harmlessly against the operational environment. Such operational reports should access current values, and be scoped and optimized so that they can run effectively without causing bottlenecks and delays to the rest of the application. This does mean that ad hoc reporting and lengthy trending are probably not good choices for this style of reporting. Business questions are business questions; some questions can be narrowed to a quick running query, and other questions require a larger breadth of input to provide useful answers. Even under meager circumstances, simple questions can be answered operationally.
The shades of gray between analytical and operational requirements have been growing. Things no longer fall easily into one category or the other–if they ever really did truly fit with ease at all. Initiatives involving customer relationship management and master data management applications have shown a vital need to jump between the operational and analytical arenas. Some pieces of information should be integrated and available to everyone immediately. Architectures such as DW 2.0 show a much greater need for having everything integrate gracefully with everything else. Some questions asked in an operational environment may require waiting until a fully integrated real-time data warehousing environment is built, while other things–the low hanging reporting fruit–may be addressed more readily. Real-time data warehousing will prove unavoidable at some point. Until such a time arrives, downstream, post-operational mode reporting will continue to stumble upon circumstances where tasks are awkward, difficult, and less-than-responsive. The encountered difficulties will establish the arguments and motivations for building towards that future real time data warehousing environment.