ABSTRACT
You can design the best architecture in the universe, but it is impossible to realize it if it cannot be communicated to stakeholders. You can design the best architecture in the universe, but it is worthless if it is not used to guide the creation of the system. This means that software design is an intimate part of the system or product development process. Unfortunately, having a development process or using a process framework does not automatically mean that you have a design process. Design should be part of the entire life cycle of software-intensive systems. The product or system life cycle is often thought of as a continuum of activities from requirements to design, implementation, maintenance, and decommissioning. However, an organization’s development is not a series of seamless, sequential steps, but rather a set of individual processes, each addressing different needs, such as requirements, planning, tracking, configuration management, and so forth. Although many of these process areas have enjoyed a great deal of attention by researchers and practitioners, the least served of these is the process of architectural design. Although certain aspects of architectural design have received a lot of attention over the last decade or so, practitioners still struggle with fundamental practical matters, such as how and when to design, how to turn requirements into architectural designs, how to know when design is done, how to evaluate designs, and how to use designs throughout the life cycle. Architectural design is not exclusively a technical activity performed in isolation by architects. It is not an artifact. It is not just a milestone on a schedule. Design is a first-class member of the set of processes that comprise an organization’s development and life cycle processes. An ad hoc design process is as dangerous as an ad hoc configuration management process-or any other process critical to project success and organizational well-being. Organizations are constantly bombarded with emerging methods, tools, and techniques, and they must figure out:
If they are useful n How to transition and use them n How to make them fit with other processes and methods n The estimated costs for adoption n The return on investment n
In other words, the not-so-trivial transition and implementation details of the method or process are left to the organization to interpret and work through. Since 1995, when architecture design concepts were first introduced, a few industrial-strength architectural methods have emerged that address specific aspects of architectural design, such as architectural requirements gathering and prioritization, design representation, design evaluation, and so forth. Some of these methods have provided great value to practitioners. However, adopting new processes, methods, and techniques can be a tough sell in many organizations. Just as elements of design can have mismatch, so can processes, methods, and tools when we try to bring them together in a project context. Similarly, many of these methods suffer from two key problems. First, they are intervention oriented; that is, they were designed to be applied in isolation from the design process or the overall development process. Organizations employing these methods must decide when and how to apply various architectural methods during the project-or weave together various (sometimes incompatible) architectural methods and processes within a project. Using these methods can be disruptive to the development life cycle without significant tailoring to fit the specific needs of the organization and project. Significant tailoring of the method (or methods) or development processes is often required to successfully use them. Unfortunately, very little guidance is available for tailoring architectural methods or the development processes. Less is available when it comes to weaving together technical methods and processes-sometimes brute force experience is the only teacher. Transitioning methods and changing organizational development processes is expensive, time-consuming, and risky. To most efficiently use architectural methods and organizational development processes, someone in the organization has to know a great deal about architectural design, the proposed method (or methods), and the organization’s development processes. This can be a tall order to fill, time-consuming, and problematic. A second but related problem with these methods is that many of them were designed to be applied by a third party-usually a consultant. Some of these methods even have proprietary elements that require special training, tools, and expertise, much of which must be purchased at a premium. These hurdles have prevented many organizations in industry from adopting the best architectural design practices. Software development teams could benefit greatly from specific guidance about how to instantiate the architectural design process and how to weave it into an organization’s existing development and life cycle processes.
