Download (direct link):
Architectural Evolution Workflow
An instance of the Convergent Architecture defines the way the entire IT organization operates, including how it designs and delivers convergent systems. Clearly, this is a long-term approach that must take changes and the passage of time into account to be successful. The architectural style workflow makes sure that changes relevant to the architectural style take place in a proactive, constructive manner as part of the normal, self-optimizing activities in the IT organization. Through this workflow, the architectural style embraces change as part of its own design and ensures that it does not begin to impede its own goals with the passage of time. This activity starts with the creation of the very first instance of the Convergent Architecture.
Activity. Architectural evolution.
Activity owner, principal participants. Chief architect, steering
Artifacts produced or refined. Convergent Architecture style reference.
Guidelines and artifact/tool usage:
As outlined in Chapter 5, the Convergent Architecture style reference describes an organization-specific instance of the Convergent Architecture as defined in this book. The instance may be a one-to-one application of the entire style book or a documented variant that remains compatible with the architectural and development models, both described in this book. The chief architect allocates adequate time to maintain the Convergent Architecture style reference and to ensure that changes are understood and implemented throughout the IT organization. The extent of this effort will depend on how far the variant instance of the Convergent Architecture deviates from mainstream evolution of the architectural style. Although one of the principal goals of the style is to reduce the invasive
Chapter 6: The Development Process
effects due to change, change will occur. For example, even a stable, fundamental standard such as UML will evolve. Many, if not most, changes to the architectural style will have a minor impact so long as they are introduced incrementally. The trick is to handle this steadily and step by step. The best strategy an organization can take to avoid problems due to change while at the same time benefiting from new developments is this ongoing activity of observation and incremental change—that is, evolution.
This allocation of the chief architect's time is a wise investment in constructive foresight to ensure that changes take place at the best time and at the right place.
In addition to continuous investments by the chief architect, this activity will involve efforts from other members of the IT organization.
For example, the architectural IDE may need to be adapted by the toolsmiths who are responsible for its usage in individual projects.
However, timely adaptations to the reference IDE will help avoid costly problems in active projects down the road.
Project Management Workflow
The project management workflow applies the RUP phases, its milestones, and its concepts on incremental development. This begins with a canonical iteration planning and tracking activity that applies an optimizing four-pass approach. This planning activity is canonical in the sense already used in the IT-organizational model. It is applied equally to every iteration with slight variations relative to the current life-cycle phase of a project. This canonical planning activity in conjunction with conceptual proximity of the IT organization and the architectural IDE enables a simple, highly effective project management workflow.
The project management workflow coordinates and drives all other canonical project workflows. It also interacts with the cross-project workflows, in particular with the T-bar business analysis activity as described previously. This interaction is intentional along the lines of the T-technique: The project management workflow handles the lower levels of the T, as denoted by the vertical strut of the T, whereas the T-bar business analysis activity absorbs and consolidates information at the upper level of the T, the T-bar. This relationship is illustrated in Figure 6.4.
Figure 6.4: The flow and scope of an iteration.
The figure also illustrates the logical orientation of the other canonical project workflows, from top to bottom, along the critical path of each iteration in a system development project. The project management workflow initiates and terminates each iteration, as indicated by the innermost arrow in the figure returning from the
Chapter 6: The Development Process
review and termination of an iteration at the bottom, back to the top of the workflow, where the next iteration is planned. Clearly, the project management workflow brackets the other critical-path workflows into the context of planned iterations of a project. As emphasized in the RUP, the workload distribution among the workflows is highly dependent on the current phase (and state) of the project. The intended distribution of workload across the iterations of a project is signified by the scales to the right of the figure. Lastly, the vertical positioning of two supporting workflows, the development environment workflow and the configuration and change management (CCM) workflow, indicate that, although important, they do not lie directly in the critical path of each iteration. These supporting workflows are ongoing in the context of a project with a peak load for workers from the IT support organization toward the beginning of the project.