Using a Single Business Pattern with the RUP -part4

Using Patterns for e-business during elaboration

A key goal of the elaboration phase is to baseline the architecture of the system.
In the inception phase, architectural analysis was optional. The architectural
proof-of-concept produced in the inception phase could be anything from a
documented analysis to a set of throw-away prototypes. In the elaboration phase,
the goal is to baseline the architecture, including a working subset of the system
(not throwaway) that demonstrates that architecture.

Table 2 gives an overview of how IBM Patterns for e-business apply to RUP
during the elaboration phase. We focus on those parts of RUP to which the
assets of Patterns for e-business are of most value by accelerating the
development of the associated artifacts. This is only a small subset of a complete
RUP-based software development process.

Table 2 Elaboration and IBM Patterns for e-business

Elaboration disciplines	Added value of IBM Patterns for e-business
Discipline: Requirements WFD: Refine the system definition Artifacts: Vision (updated), use cases, supplementary specifications	By the end of the elaboration phase, the vision and requirements should be stable. There must be enough detail to define a stable architecture and mitigate all major technical risks. Patterns for e-business, which might have been used for proof-of-concept work in inception, are revisited in the elaboration phase. As requirements are better understood, the applicability of the particular Business patterns can be confirmed or adjusted.
Discipline: Analysis and design WFD: Define a candidate architecture WFD: Refine the architecture Artifact: Software architecture document	As the architecturally significant requirements are detailed, Patterns for e-Business are revisited to confirm that any choices made during proof-of-concept work are still applicable. Fit-gap analysis determines how much additional work is needed to flesh out a complete architecture.

Requirements
Additional requirement details obtained in the elaboration phase can result in
discovering additional Business patterns, or in confirming or rejecting the
applicability of other Business patterns.
More typically, however, the greater availability of more detailed requirements
enables the architect to make better decisions for selecting applicable solution
patterns.

In the case of First Financial, we reexamine the customer's requirements in more
detail and update the artifacts (vision, use cases, and supplementary
specifications) created during the inception phase. In addition, requirements are
prioritized in terms of risk and architectural significance, so the highest priority,
architecturally significant requirements can be implemented first.
In the case of First Financial, the Self-Service business pattern remains as the
only Business pattern applicable to this solution. The following additional
non-functional requirements are obtained and documented in the supplementary
specifications:
－The application must support multiple languages.
－ Performance must be enhanced over existing Web-based applications.
－ Capacity/logon (500 logons and fifty transactions every minute).
－ Scalability (10,000 users in two years).
－ Security (secure transaction support, strong encryption, and only
authenticated connections to CICS are allowed).
－ Technology constraints (front-end access is Netscape and Microsoft Internet
Explorer browser-based, CICS Version 4.1 for legacy).

Analysis and design
A key goal of the elaboration phase is to create a stable software architecture,
documented by the artifact: software architecture document.
Any initial work done in the inception phase is used as a starting point, but as
more information is available, the assumptions made in the inception phase are
backed up, modified, or elaborated.
The workflow detail: define a candidate architecture includes the same activity,
architectural analysis, that was described for the inception phase. However, in
the elaboration phase, the activity is focused on defining the architecture that will
be the basis for designing and implementing the system and is no longer an
optional activity.

In addition, the workflow detail: refine the architecture includes activities to
elaborate all aspects of the architecture. These activities, along with a description
of some of the impacts of Patterns for e-business, are:
－ Identify design mechanisms. This involves categorizing analysis mechanisms,
making an inventory of available implementation mechanisms, and making
build and buy decisions. In this activity, the architect considers the costs of
acquisition and considers alternatives. The Product mappings provided by
Patterns for e-business are a good starting point, but this activity confirms that
the selected products are the right solution. These might have been identified
by earlier analysis, but it is not likely that many of the required mechanisms
are already supported by the selected Product mapping. If any gaps are
detected at the level of the Application patterns, it becomes very likely that
both the Application and Runtime patterns will need to be enhanced in order
to cater to the additional functionality to be delivered by the application.
－ Identify design elements. The patterns only provide part of the solution. The
architect (in collaboration with designers) must identify the subsystems and
their interfaces for the new software to be developed. However, the selected
products also influence the design options. For example, if the underlying
product set is IBM WebSphere® Application Server, the design will likely be
composed of J2EE components, such as servlets and EJBs.
－ Describe the runtime architecture and describe distribution. These activities
describe how the functionality of the system is composed of concurrent
inter-communicating elements distributed across physical nodes. At this point,
an initial deployment model already exists that reflects the selected Runtime
pattern and Product mapping. It describes both the major concurrent
elements and the mechanisms for communication. However, the architect
now does a much deeper analysis, evaluating memory, disk and computing
capacity, communication bandwidth, response and throughput requirements,
and so forth, to decide on specific hardware and software configurations.
Also, any new design elements identified need to allocated to processing
nodes, nodes that might or might not already have been identified by the
Runtime pattern.
－Incorporate existing design elements. “Existing design elements” include any
legacy systems with which you want to integrate, commercial software
products to be integrated into the system, and any other software that you
want to incorporate and adapt to the needs of this specific project. This
activity describes how to incorporate these elements into the design of the
system.

Note: In some situations, it might be useful to document the way the
products and technology will be used with use case realizations. The
Patterns for e-business series of Redbooks™ can provide direct input
toward creating such models by the detailed descriptions they provide of
the interactions between the various components that characterize the
adopted products and technology.

－ Structure the implementation model. This activity establishes the structure in
which the implementation will reside. The implementation model is influenced
by the design model, which in turn, is influenced by the selected patterns.

Note: In the Patterns for e-business series of Redbooks, additional
guidance is given for performing product and technology selections. After
making the high-level decisions, the relevant Redbooks can be consulted
for a discussion about the more detailed trade-offs involved in deciding
how to best use the selected products, technology, or both.

In the case of First Financial, the pattern selections and Product mappings made
in inception continue to hold true, despite new and more detailed requirements
identified in this phase and a detailed analysis of procurement costs and required
capacity.
It should be noted that this is not always the case. Many more factors can enter
the process during the elaboration phase, such as:
－ The client decides to standardize on a particular product or series of products.
－ New requirements cause another product to be preferable (for example, a
need to support audit trailing facilities that are compliant with specific legal
requirements).
－ An evaluation of the performance shows that the initial hardware/software
configuration will not be sufficient.
－There are alternative products with which the staff is familiar.
Related work in elaboration
In addition to defining and refining the software architecture document, there is
related work in the elaboration phase:
－ Design and implementation proceeds on the highest priority use cases.
－ Hardware and software defined by the Product mapping is acquired, installed,
and configured.
－ An executable subset of the system is built and tested that demonstrates the
selected architecture.
－ The architecture is assessed based on both the software architecture
document and experience with the executable system.
As in the inception phase, the architectural decisions, including hardware and
software product decisions accelerated by Patterns for e-business, affect all the
other disciplines. In addition to affecting project management (in the same way
as described in the inception phase), these decisions affect test planning (test
discipline), deployment planning (deployment discipline), and the development
environment (environment discipline). See the RUP for more details.
One responsibility of the environment discipline is to put hardware and software
in place to support the development activities. The Patterns for e-business
Redbooks can be leveraged in building this development environment. For each
of the involved products, identified through the physical-level technical
component model (which takes part of its input from the Product mappings), the
system administrators and tool specialists should refer to the product installation
instruction chapters in the related Patterns for e-business series Redbooks.