Chapter 7. Deployment Architecture

Enterprise-class software systems have seen many phases of evolution. Centralized mainframe systems evolved into client/server systems, client/server systems evolved into distributed systems, and distributed systems, still in their infancy, are now being recast as reconfigurable Web services. Each of these deployment architectures spawned many variants. Emerging Web architectures extend these ideas and add new ones, bringing alleged new benefits for users and keeping both marketects and tarchitects busy. Not surprisingly, we are also carrying each of these major architectural styles into the future, as much for the unique advantages they offer as for the legacy systems they've left behind.

The wide variety of deployment architectures for enterprise-class software is starting to more strongly influence deployment architectures for common packaged software applications ("shrink wrapped" applications that usually cost less than $500). We're now seeing traditional applications offered as services. As bandwidth continues to increase and hardware devices become more sophisticated, the number of deployment choices increases .

I use the term deployment architecture to describe the manner in which a customer deploys a system. This is related to the UML definition of deployment architecture but my focus is more on the strategic implications of a deployment choice and less on the lower-level decisions such as how to allocate work in a multiprocessor computer system. Emerging Web technologies and business models present tarchitects and marketects with considerable creative flexibility. This chapter will help you sort through some of the business and technical issues associated with choosing a deployment architecture so that your customer will see your choice as a winning solution.