Download (direct link):
Once prepared, the architecture organization kicks off the T-bar business modeling and requirements workflow (discussed later), which, through the identification of system development projects, influences the speed and extent of the IT-environment workflow.
With the establishment of the steering team and the kickoff of this first T-bar workflow, the self-regulating cycle of operational workflows has commenced. As stated in the IT-organization model, the active, operational workflows are owned as a whole by the IT-organization manager. This sounds like more work than it really is. Since each instance of an activity within a workflow has its own owner, the IT-organization
Chapter 6: The Development Process
manager is more a proactive monitoring and escalation point than anything else. It simply confirms the IT-organization manager as the top-level owner of the operational development process. This should not be confused with the owner of workflow definitions—the definition of the process. It is the chief architect who maintains these definitions as part of the Convergent Architecture-style reference.
T-Bar Business Modeling and Requirements Workflow
This workflow and the ABD workflow detailed here exercise different hierarchical levels of the T-technique as described in convergent engineering (Taylor 1995) and unanimously endorsed by Microsoft (Ambler 1997) and RUP (Kruchten 2000). In addition, both workflows and their respective tools in the architectural IDE constitute a style-specific application of the responsibility-driven design (RDD) concepts formulated by convergent engineering (Taylor 1995) and RUP's "Work Guidelines: Role Playing" (Rational 2000). Complementing the T-technique, techniques such as class responsibility collaboration cards (CRC) and walk-through, as described in convergent engineering and RUP, are used to derive and validate requirements and to ensure a high-fidelity business model.
The T-bar business modeling and requirements workflow (or simply T-bar workflow) derives its name from its focus on the highest level of business modeling as represented by the bar of the T—the crossbar of the T—in the T-technique. It serves to identify business requirements and business partitioning as a prerequisite to defining system development projects. This workflow initiates system development projects and, as such, initiates the project management workflow. It also serves as the top-level consolidator of feedback and requirements arising from the sum of all system development projects.
Effective global optimization of the business and its IT infrastructure is achieved by consolidating the feedback and requirements at this level, according to the T-technique. This is also where the non-IT-related organizational impact of system development projects is assessed, communicated, and coordinated with the entire business and its projects.
This workflow comprises the following ordered activities:
T-bar business analysis. This produces the top-level OPR business model, including scenarios and analyses of contexts, constraints, and urgency, and it produces project proposals.
Project initiation and tracking. This initiates system development projects or other projects in the IT organization.
Global requirements management. This provides uniform prioritization, coordination, dispatching, and the tracking of requirements, including change requests from diverse sources and levels.
Activity. T-bar business analysis.
Activity owner, principal participants. Chief architect, business managers (sponsoring clients or their representatives) and domain experts, IT-organization manager, requirements manager, lead developers.
Artifacts produced or refined. Top-level business object model, context diagrams, project proposals.
Guidelines and artifact/tool usage:
Chapter 6: The Development Process
The chief architect or an appropriately experienced convergent architect heads up this activity to ensure effective information modeling and requirements gathering. The architect defines and mediates T-bar business analysis sessions. Another architect or lead developer may assist during modeling and results processing. The IT-organization manager coordinates and administers participation of the appropriate mixture of business managers and domain experts.
The sessions normally last two to four days; the business managers and domain experts are only involved half-days. There are a maximum of three active business managers or domain experts per session plus the architect and, optionally, one lead developer. This constitutes a T-bar business analysis team (or T-bar team). During the morning, the joint requirements gathering and modeling activity proceed according to the convergent engineering schema shown in Figure 6.2. In the afternoon, the business managers and domain experts are freed up to carry out their daily business. During this time, the architect and lead developer work on consolidating, documenting, and generally improving the model. Above all, they advance into the invention phase shown at the right of the figure. The results of the consolidated business model and the tentative invention results are then the basis for discussion when the session resumes together with the business managers and domain experts on the next morning.