Using IBM Patterns for e-business during inception
Key goals of the RUP inception phase are:
- A vision that establishes the key needs
- A business case that justifies the investment
- Initial budget and schedule for the project for moving forward
Table 1 on page 9 gives an overview of how IBM Patterns for e-business apply to
RUP during the inception 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 1 Inception and IBM Patterns for e-business
| RUP elements: Disciplines, workflow details (WFDs), activities, and artifacts | Added value of IBM Patterns for e-business |
| Discipline: Environment WFD: Prepare environment for project Activity: Prepare guidelines for the project Artifact: Project specific guidelines | Patterns for e-business are one of the intellectual assets that should be considered during the initial identification of useful project guidelines. |
| Discipline: Business modeling WFD: Explore process automation Artifact: Business vision | Patterns for e-business can be used as inspiration for identifying and characterizing business processes. Also, analyzing the business goals and business processes for the business as a whole provides valuable input to deciding how and what to automate. |
| Discipline: Requirements WFD: Define the system Activity: Develop vision Artifact: Vision | The need to collect the necessary information for navigating the asset catalog creates an opportunity for a focused analysis of the requirements. The navigation of the Patterns for e-business asset catalog starts from a broad categorization of business requirements. Not only do these guide the asset selection process, but they also offer additional insights into the overall business area and the main business drivers. |
| Discipline: Analysis and design WFD: Perform architectural synthesis Activity: Architectural analysis Artifact: Architectural proof-of-concept Artifact: Software architecture document (inception draft) | Reference architectures, of which Patterns for e-business are an example, contribute significantly to the definition of an architectural proof-of-concept. |
| Discipline: Project management WFD: Evaluate project scope and risk WFD: Plan the project Artifact: Business case Artifact: Software development plan | The architectural proof-of-concept, created using Patterns for e-business, provides valuable input to the business case and project plans. |
We now discuss each of the elements outlined in Table 1 in the context of the
First Financial case study. First Financial, a fictional company used for this
example, is a large financial services company, seeking to deliver better services
to their customers and to do so more efficiently.
Business modeling
Business modeling is an optional discipline in RUP that looks at the broader
scope of the business. It is used to understand the current business processes
and determine how they can be improved. Identifying opportunities for
automation is one way in which business processes can be improved.
Business modeling can be performed as part of a project, to better understand
the business context, or can be performed as a separate project and result in the
spawning of multiple software development projects.
Figure 6 Business modeling discipline
In the case of First Financial, business modeling can be used to describe how
services are currently provided to customers and identify opportunities for
improvement. One way of identifying possible improvements is to look for
opportunities where particular Business patterns (from the Patterns for
e-business repository) are applicable.
For example, after modeling some key business processes of First Financial, we
could look for where the Self-Service business pattern might be applied. The
Self-Service business pattern addresses direct interactions between interested
parties and a business. We recognize that the business processes involved in
applying for, approving, and managing credit card accounts fit this pattern and
that automation in this area would be in line with the business goals of providing
better services with more efficiency.
We decide that Web enablement of the existing credit card system is a first step
toward giving customers access to some of First Financial's core applications
across multiple access channels. These core applications are supported by
IBM Eserver® zSeries® mainframes and maintained by First Financial's
predominantly CICS® skilled staff.
Environment
Patterns for e-business are one of the assets that should be considered during
the initial tailoring of process for an e-business project. Process tailoring is
performed as part of the workflow detail: prepare environment for project.
At this stage, Patterns for e-business are evaluated for relevance to the project
and process. The recommendation to use Patterns for e-business, and any
additional guidance related to using the patterns, can be incorporated into a RUP
configuration as additional guidelines associated to the workflow details identified
in the Redpaper. See the RUP activity: prepare guidelines for the project, for
more details.
Figure 7 Environment discipline
Because First Financial is embarking on an e-business project, we decide to use
Patterns for e-business for a fast path definition to a suitable and proven solution.
Note that patterns are rarely a perfect fit; some customization is usually needed
to address the unique requirements of each project. Patterns, even when they fit,
are only part of the solution. The specific functionality for the project still needs to
be defined, designed, and delivered.
Requirements
A key goal for the requirements discipline during the inception phase is to
baseline a vision for the project.
The RUP workflow details of analyze the problem, understand stakeholder needs,
and define the system describe how to describe the problem to be solved, identify
the key stakeholder needs, and capture the key functional and non-functional
requirements of the system.
Figure 8 Requirements discipline
First Financial's goal is to open up the existing enterprise transactions and data
to external customers. The first step to be taken toward this goal is the Web
enablement of their existing credit card system.
The vision identifies the top business issues, challenges, or priorities for the
enterprise and provides an insight into the trade-offs made and priorities set by
the client. These drivers and priorities are an important input to the Application pattern selection process (described later in this paper), which is based, among
other things, on an analysis of the key business and IT drivers.
First Financial's business objectives that flow down from the business modeling
efforts are:
- Reduction of time to market
- Tactical focus on only supporting the Web channel
- Strategic focus on supporting multiple access channels such as call center
and telephone access
- Leverage legacy investments and the existing CICS skill base
The use cases and actors for First Financial are summarized in the system
context diagram shown in Figure 9.
Figure 9 System context diagram: First Financial
Supplementary specifications include:
- A requirement to access an existing CICS-based application
- A strong emphasis on the privacy of the exchanges between the front end
and the existing applications and the authentication of a client before any
access to an existing application is allowed
- A preference for Microsoft® Windows® 2000/xSeries® servers to host the
Web infrastructure, because there is a current installed base of Windows
2000/xSeries and zSeries servers
In the case of First Financial, we identified the opportunity for automation from
the Self-Service business pattern. However, it is equally valid and common to
start with requirements and determine what pattern or patterns fit already
specified software requirements. In this case, an analysis of the high-level
business requirements described earlier and captured in the vision suggests that
the Self-Service business pattern is applicable. First Financial is interested in
extending an existing credit card legacy application through a Web channel to its
customer/user base. The Self-Service business pattern is applicable, because
users need to interact directly with legacy data. See Figure 10.
Figure 10 Self-Service, User-to-Multiple Applications
Analysis and design
In the inception phase, analysis and design is optionally performed, as
necessary, to convince stakeholders that the project is worth investing in.
Specifically, the workflow detail: perform architectural synthesis can be
performed to create an architectural proof-of-concept.
Patterns for e-business can contribute significantly to creating an architectural
proof-of-concept. The navigation of the Patterns for e-business asset catalog is
guided by the requirements collected as part of requirements discipline.
Figure 11 Analysis and design discipline
Note that the architectural proof-of-concept is elaborated to the extent required to
convince stakeholders that the project should proceed to the next phase. For
many systems, it will be sufficient to demonstrate that there are one or more
suitable solution patterns that match the Business pattern identified from the
requirements. In other cases, there might be particular feasibility risks that
require more design exploration, such as:
- A list of additional technologies (frameworks, patterns, executable
architectures) that seem appropriate to the solution
- A sketch of a conceptual model of a solution using a notation such as UML
- A simulation of a solution
- An executable prototype to address design beyond what the Application
patterns express, produce a simulation of a solution, or create an executable
prototype
It is not uncommon to find that multiple patterns and assets are relevant to the
proposed solution. In this case, additional work will be required to integrate the
different patterns and assets in order to arrive at a coherent proof-of-concept.
The software architect steps through the activity: architectural analysis. The first
step is to develop an architecture overview, ideally based on an existing
reference architecture. Patterns for e-business are immediately applicable. The
architect goes to the Patterns for e-business Web site
(http://www.ibm.com/developerworks/patterns) and is guided through the
following steps.
Step 1: Selection of a Business pattern
In the case of First Financial, the Self-Service business pattern has already been
identified as applicable.
Step 2: Selection of an Application pattern or patterns
The Application pattern focuses on the application-level functionality required to
support the identified Business pattern or patterns.
Figure 12 on page 18 presents the Application patterns (shown as column
headers) for the Self-Service business pattern and the typical business and IT
drivers (shown as row headers) that drive the Application pattern selection.
First Financial plans to provide access to its existing back-end systems through
different channels (initially only a Web channel, but the call center and telephone
have been identified as future extensions).
The software architect selects the Router application pattern, because it provides
a structure for applications that require intelligent routing of requests from
multiple delivery channels to one of multiple back-end applications.
Figure 12 Business and IT drivers of the Self-Service business pattern
The Router application pattern supports multiple delivery channels connecting to
one or more back-end legacy applications through a router tier. This router tier
can route a single message to one or more applications within the same
business process. This is in line with First Financial's requirements as noted in
Figure 12. The router tier can process a single request and access the required
legacy systems to produce a response, in this case, the rating and underwriting
systems. Refer to Figure 13 for an example of the Router application pattern.
Figure 13 Self-Service::Router application pattern
The selection of an Application pattern leads to a set of specific Runtime
patterns.
Step 3: Selection of a Runtime pattern or patterns
The Runtime pattern focuses on the technical functionality needed to support an
Application pattern.
The software architect selects the basic Router runtime pattern, because the
combined presentation and application server is judged to be sufficient. This will
be validated in the elaboration phase.
In the Router application pattern, the router tier serves as an integration point for
delivery channels in the presentation tier, allowing access to individual back-end
applications. In the following Runtime pattern, which supports the Router
application pattern, the functions of the router tier are performed by an
integration server. Figure 14 shows a Runtime pattern for Self-Service::Router.
Figure 14 Self-Service::Router runtime pattern
Each of the nodes identified in this diagram is described in more detail on the
Patterns for e-business Web site. Refer to the following URL for more
information:
http://www.ibm.com/developerworks/patterns/u2b/at5-runtime.html
Note: Runtime patterns indicate the zones where the execution of certain
specified implementation components will take place and where data will be
made available. The precise determination of the involved locations (given
that a zone can span several locations) as well as the specification of the
nodes that will support the following will have to be determined as part of the
definition of the specified deployment model:
- The execution of these components
- The storage of data
Step 4: Obtaining a Product mapping
Given the existing base of Windows 2000/xSeries servers, the software architect
selects a Product mapping based on Windows 2000/xSeries servers.
This Product mapping immediately gives us an overview of the recommended
products and their relationships. See Figure 15.
Figure 15 Self-Service::Router Product mapping
Note: The source for all Product mapping information can be found on the
Patterns for e-business Web site at the following URL:
http://www.ibm.com/developerworks/patterns/u2b/at5-product-nt-was4-mb.html
Follow-on steps
The software architect continues through the steps of the activity: architectural
analysis. This includes creating an architecture overview diagram, as shown in
Figure 16.
Figure 16 First Financial architecture overview diagram
The software architect completes the remaining steps of the activity: architectural
analysis, documenting the results in an early draft of a software architecture
document:
-Survey available assets: Identify other relevant assets that might be
applicable to this project.
- Define the high-level organization of subsystems: Influenced by the selected
patterns, because you will typically define subsystems that don't span
processing nodes.
- Identify key abstractions: These will be specific to the functionality to be
delivered and are not provided by the patterns.
- Identify stereotypical interactions: Indirectly influenced by the patterns, insofar
as subsystems have been influenced.
- Develop deployment overview: This mirrors the Product mapping diagram
shown in Figure 15 on page 20. The difference is that hardware and software
specific to First Financial will appear on the diagram, such as specific legacy
systems. You can choose to use standard UML notation, rather than the
free-form notation used by the patterns.
- Identify analysis mechanisms: The patterns have already identified
implementation mechanisms that suit this application, such as messaging.
The architect should determine what other mechanisms are required by this
application, such as security or transactions. It is likely that many of the
required mechanisms are already supported by the selected product
mapping.
The architect then performs additional modeling and prototyping as necessary to
prove the feasibility of the project. This is described in the activity: construct
architectural proof-of-concept. In the case of First Financial, the architectural
analysis done so far, and the good fit of the patterns to the problem at hand,
provide a sufficient proof-of-concept, convincing the stakeholders that the project
can proceed to the elaboration phase.
Project management
The analysis and design work was performed to confirm technical feasibility. It
also serves as input to the business case and project plans, specifically:
- Estimating the software budget, taking into account, among other elements,
the costs of suggested products
- Specifying the staffing resources required to deliver the solution (among
others derived from selected products)
Summary
This section describes how Patterns for e-business can be used effectively to
help reach the goals of the inception phase.
Patterns for e-business allow us to arrive very quickly at a proof-of-concept.
However, Patterns for e-business are not complete architectures by themselves.
They provide a basis for the architecture, which must be elaborated to include the
specific requirements and software components required for a specific system.
The use of the Patterns for e-business' assets typically increases the overall
technical quality of an architectural proof-of-concept, because the patterns are
based on proven software and hardware product combinations.