Download (direct link):
■ System project manager. In addition to being a project manager, this is a specialist in system development projects, as defined in the following section, and is specifically responsible for the following:
o Bootstrapping and accompanying a system development
project as defined in the following section according to the development process model as presented in Chapter 6. This includes initial project analysis and planning and managing project iterations according to the project management workflow (see Chapter 6).
Chapter 5: The IT-Organization Model
o Building and supporting assembly development teams and
their component development teams (discussed later).
o Convergent Architecture-specific instance of the following
RUP worker role: project manager.
■ Change sets (artifacts): System project plan (long-term development strategy, current iteration plan with work orders for both assembly and component development projects), but no predefined specialized technologies.
■ Specialized technologies: None pre-defined.
■ Developer. A collective term denoting any developer in the system development organization. This includes the lead developers, assembly developers, component developers, and accessor developers, covered in this chapter.
The System Development Project
A system development project is something specific in the Convergent Architecture. Just as in most organizations, the IT organization sets up explicit projects to create valuable processes and resources. The processes and resources produced by a project are then used by organizations in ongoing processes or as building blocks in other projects. Thus, projects are the central driver in an infinite cycle of progress and change. Although projects in all organizations share common features, my focus here is on the development of IT systems—on system development projects.
I speak of system development instead of software development because the resulting systems are not limited to pure software. Although my focus here is on IT, these projects also include aspects of business organization that have little to do with technology. A system development project also addresses the infrastructure and operational elements of systems that have more to do with the configuration and maintenance of hardware, packaged-software, and human infrastructure than they do with software development. The consolidation of these various aspects helps us produce more effective systems, not just a piece of software.
System development projects in the IT context are the raison d'être of the system development organization, regardless of whether the system is actually developed in-house, is outsourced, or, as is most often the case, is a mixture of both.
Although still called development projects, these projects also address the longterm aspects of the system life cycle. To achieve this, the structure and focus of these projects must deal explicitly with the dichotomy of short-term deliverables versus long-term returns.
The short- and long-term perspectives of system development form two competing poles in any development organization. Whereas the clients of development projects normally are interested only in their short-term, immediately tangible deliverables, IT architects are also concerned with the long-term, often hidden qualities of systems. Most clients have an acute problem. They only want to pay for the minimum effort required to solve their particular problem. On the other hand, the IT architect realizes that a purely short-term focus to system development will cause significant long-term problems. Ironically, the costs to rectify these problems eventually are borne by the client, so professional IT architecture also is in the client's interest. The IT architect determines how longterm planning and investment can significantly reduce the costs of each client over time. On the other hand, a purely long-term focus to system development often
Chapter 5: The IT-Organization Model
ends up in an unchecked academic exercise, which, sooner or later, will be condemned by clients as "utopist"—usually with good reason.
Although a modern iterative development approach helps a project deal with these poles within a single project, it is not very specific about how they should be dealt with across multiple projects and across multiple generations of systems. The system development organization emphasizes the following specific short- and long-term aspects of development to help projects and project teams improve the equilibrium between these two poles.
Long-Term: Deliver Business-Centric OPRs
When a convergent component is identified as significant during the business-modeling workflow, particular attention is paid not to refine it into an accessor-specific component that meets only the punctual requirements of a particular application. Instead, care is taken to also represent the inherent features of the business domain, regardless of the particular application. To achieve this, domain experts and the lead developers do not focus only on the accessor use cases associated with a particular accessor component. They know that the OPR components of the business may be used by any number of accessors, many of these accessors being currently undefined. Thus, the business use case scenarios are employed to help the domain experts and designers identify more business-centric, in contrast with problem-centric, OPRs. These OPRs result in crossapplication convergent components that can be reused and evolved over time more easily from the long-term perspective, according to the requirements of the business at large. However, to prevent this from becoming an academic exercise, this evolution takes place in the context of individual system development projects, each driven by the needs of a particular assembly component. This approach is compatible with the short-term aspect discussed later.