This article originally appeared on the BeyeNETWORK.
A long time ago, there were only OLTP (online transaction processing) transaction-based systems. And in these systems, performance was everything. If you did not get good online transaction performance, then nothing else mattered. Furthermore, these transaction-based systems were complex and most of the designers/developers did not know that performance had to be built into the systems from the outset. As a consequence, there were many OLTP systems that failed because of poor performance or poor availability. Or at least the initial design failed.
Shops soon discovered that it was a very expensive matter to go back into the OLTP system and retrofit performance. The adage, “build it quick now, and we will go back and tune performance into the system later,” simply was a tempting mirage in a very dry desert.
After a quick start of building transaction-based systems that yielded poor performance, shops discovered that the way to put performance into the system was to build it in from the beginning.
Thus born was the practice of design review. In a design review, all the developers and designers were gathered together, and for a week or so the details of the system were discussed. In many cases, an outside expert was brought in to lead the design review effort.
The design review consisted of a thorough review of every aspect of the system, including:
- Database design
- Transaction design
- Configuration analysis
- Capacity planning
- Implementation planning
- End-user interface
- Workload analysis
In a word, every aspect of the system was open to disclosure and discussion.
At the end of the design review, a report was issued by the party conducting the review. The report contained a collection of suggestions and recommendations for the purpose of improving the design of the system – for performance, availability and other reasons important to the operation of the system. Through design review, the world quickly learned how to build performance into the design of their OLTP systems.
Where is design review today in the world of data warehousing and decision support systems (DSSs)? Only very, very infrequently are design reviews conducted in data warehousing and DSSs. In almost every case, the organization simply builds the data warehouse and starts to build analytical processing on the data warehouse. If mistakes are made, the mistakes are corrected and a new iteration of DSS development ensues. In data warehousing, design review simply is not an established practice.
So why don’t we see design review in data warehousing? Perhaps for the following reasons (among others):
- Performance is not an issue in most data warehouse environments.
- Data warehouse DSS systems tend to be self-contained. If a mistake is made, the mistake does not affect every other program and database.
- DSS systems are built in an iterative manner where it is known that the system will not be perfect.
The requirements for DSS processing are in a constant state of flux. There is no such thing as having a static set of requirements in a DSS data warehouse environment.
Bill Inmon is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations.