Download (direct link):
The managed evolution of an IT infrastructure would be very difficult without the development model. What, for instance, would happen if developers unilaterally changed fundamental design and development structures in individual projects? When things such as component models, techniques, and tools are defined unilaterally in individual projects, ad hoc architecture is the inevitable result.
Chapter 1: IT-Architectural Styel
Without the development model, such changes occur automatically and unintentionally. There is no effective way for project managers or developers to synchronize themselves across projects without a common development model.
The only way ad hoc dilution of an architecture can be avoided is to provide the lead designers of projects with a development model. If fundamental structural changes do need to be made, for instance, then they are made relative to the common model as used by all projects. Experts can then properly assess the impact on all designs, systems, and organizations, both present and future. At this point, a solid basis for a decision founded on dependable information exists. In addition, once decisions to modify the architecture are made, the migration of every aspect of the architectural style can be planned and coordinated properly. Above all, such decisions are not made in an ad hoc manner by, perhaps, the wrong persons. This is the most important step toward managed system evolution.
The development model is very different from generalized design methodologies in that it is concerned only with aspects specific to the particular IT-architectural style, not with generalized advice. For example, it should not present a discourse comparing various pattern approaches, development process alternatives, or component models. It should be as specific as possible, telling the developers which processes, patterns, and components to use and, concisely, why this choice was made. Whenever design options are provided, then precise decision criteria should be available as to when a given option applies. This is so because the probability of ad hoc and incompatible constellations increases with the number of unclear or competing alternatives.
To ensure adequate coverage (depth and breadth), the following three fundamental themes should be addressed by the development model:
■ The development structures theme. This describes the concrete resources used to design, implement, and deliver the system. The focus here is on describing the structures to be built and the structures required along the design and development path. These include such things as layers of the architecture, component stereotypes with their models and their diagrams, and other artifacts used to construct and deploy systems. The ownership of these structures and how they are derived are described in the IT organization and development process, respectively. The full-coverage tool suite layer, presented in this chapter, outlines how these structures are manipulated and managed with the help of specific tools as part of the process.
■ The development process theme. This describes the specific development tasks. These tasks focus on the creation and evolution of the development artifacts and are specifically supported by the tools and organization of the style. Its process should at least cover the entire critical development path, which must be defined by the style, including the repeat cycles necessary to address the change and evolution of the system properly. However, defining the process is not enough; it must be coordinated properly by an IT organization.
■ The IT-organization structure theme. This defines how responsibilities, roles, and persons are best coordinated to simplify and support the specific development process. Often, methodologies neglect the intimate relationship between the process and organization, assuming that the process is complete. However, no matter how complete and well-thought out the process is, there is no way to cover
Chapter 1: IT-Architectural Styel
everything that can possibly occur during a development effort. An organization must be prepared to handle everything that happens in between and around well-defined tasks, both the everyday things and the surprises. In addition, not everything can or should be defined as a specific task. For example, attempting to define the activities of an IT architect as a series of tasks would be fruitless. The tasks are too complex and intertwined to be able to be described in an appropriate way. On the other hand, establishing an architecture organization with specific responsibilities and tools is extremely useful. Thus, the IT-organization structure both complements and supports the development process.
How each of these themes is presented is left up to the IT-architectural style itself. In any case, this entire development model will evolve with time, just as any other layer in the style. Things will be added, removed, modified, and refined in the spirit of an evolutionary approach.