19.4 The Impact of Commercial Components

As we said in Chapter 18, the capabilities and availability of commercial components are growing rapidly. So too are the availability of domain-specific architectures and the frameworks to support them, including the J2EE for information technology architectures. The day is coming when domain-specific architectures and frameworks will be available for many of today's common domains. As a result, architects will be concerned as much with constraints caused by the chosen framework as by green-field design.

Not even the availability of components with extensive functionality will free the architect from the problems of design, however. The first thing the architect must do is determine the properties of the used components. Components reflect architectural assumptions, and it becomes the job of the architect to identify them and assess their impact on the system being designed. This requires either a rich collection of attribute models or extensive laboratory work, or both. Consumers of components will want a trusted validation agency, such as Underwriters Laboratories, to stand behind the predictions.

Determination of the quality characteristics of components and the associated framework is important for design using externally constructed components. We discussed a number of options with J2EE/EJB in Chapter 16 and the performance impact of each. How will the architect know the effect of options that the framework provides, and, even more difficult, the qualities achieved when the architect has no options? We need a method of enumerating the architectural assumptions of components and understanding the consequences of a particular choice.

Software Architecture in Education In this chapter, we focused on the technical future of software architecture and how we believe it is going to evolve. But what about the future of architecture in software engineering education? The discerning reader will have noticed that three members of the Bass family contributed to this book. I received a BA in mathematics in 1964, Tanya received a BS in computer science in 1991, and Matt received a BS in computer science in 2000. I will use our experiences to draw some general conclusions. When I received my degree, I had seen one computer (we took a tour just to see it) and had absolutely no knowledge of programming or how computers worked. Of course, I was immediately hired as a programmer. The world was different then. Given that you are going to spend thirty or forty years in your career, the clear message is that what you learn in school ages quickly and you need to keep current in order to remain on the leading edge of the field. Tanya graduated having learned a variety of programming languages, including C but not C++, without being exposed to object-oriented concepts. Matt graduated having learned a different set of programming languages, including C++ and Java. He also learned about object-oriented design. Within nine years, curricula evolved to include object-oriented languages and techniques. Although Matt did not take a course in architecture, by the time he graduated software architecture courses were common in graduate programs and in existence in undergraduate programs. The education that Matt received included more elements of abstraction and design than the education that Tanya received, and this trend is only going to continue. Thus, my prediction for the year 2010 is that undergraduate curricula will routinely include courses in software architecture with some universities offering more than one course at that level. At the graduate level, software architecture as an area of specialization should be common. We hope that this book foreshadows what will be in curricula in 2010 and that it leads the way for the other courses in software architecture that will be appearing. - LJB

Finally, components and their associated frameworks must be produced and the production must be designed to achieve desired qualities. Their designers must consider an industry-wide set of stakeholders rather than those for a single company. Furthermore, the quality attribute requirements that come from the many stakeholders in an industry will likely vary more widely than the requirements that come from the stakeholders of a single company.