Note that unlike other data warehousing and general DBA books, I've placed the software architecture chapter prior to the chapter on hardware architecture. That's because I see this as a fundamental problem with the other offerings. If you'll indulge me for a simple analogy: Why buy a gas stove if you're attempting to cook microwave dinners? You need a destination before you set out. You need a goal before you try to achieve. That's just how it's done.
Remember the following old adage: Don't put the cart before the horse? Well, far too often, that's what happens with Oracle database applications, including data warehouses. That is, technical management succumbs to both hardware and software vendor recommendations before the application's true software architecture has been adequately defined. Often, the rationale is that the hardware must be ordered prior to the project so that it's available for the team to work on; otherwise, they'd be sitting around idle. Hogwash! One of the initial team's jobs should be to define both the software and hardware architectures. A common mistake is to assume that the project proposal has adequate insight into what's truly needed.
For example, our initial hardware selection for the 7-Eleven data warehouse was a Hewlett-Packard (HP) K-class server with a small EMC disk array. Oracle and HP sold our technical management on the idea of using Oracle Parallel Server (OPS) and adding 4?6 small central processing unit (CPU) servers as needed. To our management, this seemed like a reasonable recommendation. As for the vendors, knowing the information they were given, this was probably quite fitting. Less than a year later, both the K-class server and EMC disk array were donated to another OLTP project. We had outgrown that hardware. But more importantly, it did not fit into our software architecture. We had to buy all new hardware to continue. Plus, we never used OPS, and we switched from the raw files required by OPS to the Veritas file system with Quick IO. In short, we switched just about everything possible.
So what happened? In short, management went to the vendors and said we're building a data warehouse and we've got this much to spend?what should we buy? What do other people like us buy? Don't get me wrong, though. Those vendors were doing us a great service by making such recommendations. But, their recommendations should have been viewed as defining the universe of products for consideration. Ultimately, the data warehouse DBA must be the one who defines the software architecture. Then, he or she must go to the vendors of choice, show them the proposed software architecture, and ask what hardware they have that fits your requirements. You'll find at least two things to be true. First, they'll recommend fewer solutions as possibilities. And second, with more insight, their recommendations will be much better. Hence, you should not have to change everything (as we did) a year later.
Another way to view the software architecture is to treat it like a logical data model for your hardware needs. Thus, the software architecture defines the database and application design concepts that you're embracing. The hardware architecture represents a particular instantiation of the equipment necessary to fulfill those needs. And, like data modeling, there may be more than one way to physically implement your logical model. In other words, you may have more than one hardware solution that can get the job done.
As with many endeavors, it helps to know your options. In other words, to pick a solution, it helps to know the available possibilities. You still have to pick the correct one from among the choices available, but at least you won't have missed possible good choices by not knowing of their existence. So, we must examine an eclectic collection of software architecture options. Some are related; others are not. But it's the sum of the selections that will help you define your ultimate software architecture. Armed with that information, you can proceed on to the next chapter and correctly select your hardware architecture.