3.2 Execute

< Day Day Up >

The purpose of this phase is to create an architecture that translates business requirements into a solution. As with any software application, the solution architecture should address both the functional and operational domains.

The functional domain addresses the business functionality of the solution. It describes the structure and modularity of the software components that will be used to realize the business functions, the interactions between the components, and the interfaces between them.

The operational domain describes the system organization (such as hardware platforms, connections, locations, and topology), the placement of software and data components, the NFRs (such as performance, availability, and security), and system management (capacity planning, software distribution, and backup and recovery).

Remember that the architecture needs to align with the overall business strategy and provide a roadmap for its implementation.

The Execute phase begins with the establishment of a project within which a solution will be developed. There are three steps in designing the solution:

Establish system requirements through defined use cases.
Design a solution that meets these requirements. The logical design of this system is defined primarily through an Architecture Overview Diagram. The associated key decisions are captured in the Architecture Decisions work product.
The logical design is transformed into an operational physical design by defining the components that make up the logical system and the packaging of these components into applications that run on a physical infrastructure of servers, storage, and networking. The physical design is primarily modeled using the Component and Operational Models.

Task: Develop high-level Project Description and System Context Diagram

The Project Description establishes the scope of the project. It describes what is to be accomplished and identifies the high-level functions that must be taken into account by the solution. The Envisioned Goals and Issues document should be used as input to the Project Description. You need to know where the customer is heading and what is its vision for the long term. Otherwise, you might be creating a solution that is valid only for the short term. It's also important to list the business and IT drivers for the project. These will be used to drive and validate your choices during the logical and physical design steps.

For our e-government case study, the Project Description is as follows:

This Incident Management project addresses the need for government agencies to work together to manage low security threat incidents (for example, a contamination of a food shipment). Agencies that participate in some aspect of the incident have information pertinent to that incident and subject matter experts who can resolve it. These experts are required to participate in a collaborative environment, working together to resolve the incident effectively and efficiently. The following define the major functional areas for managing the incidents:
- Function—Vehicle/Vessel Enters Port
  - Vessel requests Port Authority permission to dock, sending manifest and crew list
  - Assess risk by integrating information from multiple agencies
  - Trigger Customs inspection (if needed)
- Function—Proliferation and Tracking
  - Determine if cargo may be contaminated
  - Alert subscribing government agencies
  - Correlate information across agencies to track extent of problem and assign lead agency
- Function—Collaboration
  - Identify experts and create cross-agency incident response team
  - Set up collaborative environment for team
- Function—Interception/Treatment
  - Disseminate information to regional emergency teams and businesses
  - Determine public communication strategy
  - Approve and publish bulletins

The following scenarios show a typical end-to-end use of the Incident Management System functionality described above:

Scenario 1—Vessel Enters Port. A large foreign commercial container ship submits a request to the Coast Guard "Master of the Port" for permission to dock at the port. The request includes a manifest and crew list. A risk assessment is performed on the ship's cargo and the crew list, integrating information results from across agencies. The risk factor is determined to be high, and it is determined that a close inspection of the ship's cargo is required.
Scenario 2—Proliferation and Tracking. The Customs Agency is called in to perform the inspection, during which the Inspector finds the contents of one of the containers to be contaminated. Due to the serious nature of the inspection failure, an alert is sent to interested (subscribing) government organizations.
Scenario 3—Collaboration. An emergency response team is created, composed of selected experts. A collaborative environment for the team is set up. Intensive analysis is performed on data in a variety of agencies to find relevant information for this incident. Investigation determines that additional shipments with the same lot number were scheduled to enter the country from other ports around the country. The Department of Agriculture and the US Customs Service discover that some shipments have cleared customs and are either in transit to grocery stores or already on the shelves. It is decided that a Health Alert Bulletin must be created and disseminated immediately.
Scenario 4—Interception and Treatment. A document is created on the CDC (or other associated response team's) Alert Content Management/Publishing System and published to the inter-agency Alert System. The document is then published and disseminated to the public, where a person who works in the food industry sees the news flash on her company's portal. She realizes that her company sells this product and immediately informs her store managers and warehouses to pull the product from the shelves, thereby preventing an occurrence of someone becoming ill from consuming a contaminated substance.

Business drivers for the case study

Need to integrate "stovepipes" and decrease redundancy
Need to streamline processes and improve data analysis
Need to facilitate effective decision-making

IT drivers for the case study

Better internal use of information
Secure data sharing
Effective incident management through automated processes
Support for new security demands
Interface to new and existing databases

The System Context Diagram is intended to exhibit the relationships, interactions, and information flow into and out of enterprise systems. These diagrams also serve as a discussion aid in determining project scope. Figure 3-5 on page 84 represents the System Context Diagram for our case study. This diagram shows the disparate government organizations, the customers, and the outside sources of information, coupled with the relationships that comprise the solution. Any interaction between the agencies is via telephone, fax, etc. The vision is to enable and enhance electronic communication and collaboration.

<
Figure 3-5: System Context Diagram for e-government

Note?/td>

The outputs of this task are the Project Description and System Context Diagram work products.

3.2.1 Step 1: Develop solution requirements

The goal of this step is to define the solution requirements and to understand their complexity and scope.

The process of outlining solution requirements involves identifying both the Functional and Non-Functional Requirements and then documenting the architectural principles that will drive the solution. The process begins by creating a description of the project in order to develop the solution outlining the major functionality that is needed. A System Context Diagram shows the current system environment in which the solution will exist. Using the Project Description and Current System Context, the Functional Requirements are derived and documented in a Use Case Model.

The following reiterates the best practice process for leveraging large reusable assets to develop solution requirements:

Step 1A: List users/existing systems and Functional Requirements
Step 1B: Derive actors and use cases required to create the Use Case Model
Step 1C: Inventory large reusable assets
Step 1D: Match solution use cases with generic use cases of the large reusable asset candidates
Step 1E: Identify delta use cases to handle requirements that are not handled by the matched large reusable asset and classify into Business and Integration patterns
Step 1F: Document Non-Functional Requirements
Step 1G: Validate requirements with customer

Each of these process steps will be explained in its respective section below.

Step 1A: List users/existing systems and Functional Requirements

From the High-Level Description and System Context Diagram we will glean the actors, high-level business functions, and high-level interactions between these actors and functions. The first step in this identification process is to list the users and existing systems from these work products and to identify the major functionality required by the system.

Based on the Project Description and the System Context Diagram, we derive the following list of actors and existing systems as well as the major functionality needed:

Users and existing systems:
- Vehicle/vessel/ship
- Captain
- Agency
- Port Authority
- Customs
- Inspector
- Emergency Management (Homeland Security)
- Agent
- Health agency
- Incident response team
- Lead agency
Functionality required:
- Request permission to dock
- Assess risk
- Integrate information from multiple agencies
- Trigger inspection
- Inspect manifest
- Alert agencies
- Assess problem scope
- Assign lead agency
- Identify experts
- Create incident response team
- Setup collaborative team environment
- Disseminate information
- Approve and publish bulletins

Step 1B: Derive actors and use cases required to create the Use Case Model

A Use Case describes the flow or sequence of events when an actor ^[2] interacts with the system, and is used to establish the most important scenarios for using the application or system under consideration. It helps determine the required functionality and user interfaces. Use cases don't describe how the system works internally. Figure 3-6 on page 87 depicts the use cases that were derived from our list of users and existing systems as well as the functionality required

<
Figure 3-6: e-Government Use Case Model

Table 3-2 provides short descriptions of each use case:

Table 3-2: e-Government Use Case descriptions
Use Case	Description
Authenticate and Authorize User	All users authenticate with the system, establishing a distinct role for interaction with it.
Author and Approve Bulletins	The X-Agency incident management team puts together a bulletin to handle the incident, which must be approved to be published. For example, the incident management team creates a health alert bulletin explaining that there is a product recall on a contaminated item.
Resolve Incident	The X-Agency team—comprising experts from various agencies—performs tasks, shares information, and collaborates to manage the incident.
Inspect Cargo	The inspector checks the cargo for potential hazardous materials and contamination. Usually, this individual uses a handheld device to enter inspection results.
Publish Bulletin	The X-Agency team publishes an approved bulletin as the result of managing the incident.
Manage and Track Incident	The incident leader establishes an X-Agency team of experts to resolve the incident. To facilitate the team, the leader establishes a collaborative environment for it and populates this environment with relevant information from various sources/agencies. The leader also tracks the incident to ensure that it is being handled effectively and in a timely fashion.
Request Entry	The operator of a vehicle or vessel requests entry into a port. Typically, the request for entry requires a crew list and manifest information.
Register with Agency	Operators of vehicles or vessels register with the agency to use its services.
User Provisioning	The system administrator manages user accounts, including assigning roles.
Assess Risk	The system assesses the risk of a request through an established process that uses each agency's information and services to determine any potential problems.
Generate Alert	The system generates an alert based on its assessment of the request. Typically the alert is an indicator for an inspection.
Generate Incident	An incident is generated when an inspection determines that a problem exists.
Find SMEs	An X-Agency team requires the identification of experts in different fields to tackle an incident. Finding subject matter experts facilitates the generation of a list of potential candidates from the various agencies.
Find Agency Information	Each agency has information that could be pertinent to handling the incident and assessing risk. Finding agency information is required to facilitate the X-Agency team to resolve the incident.
Establish Team and Environment	An integral part of setting up a X-Agency team is to establish the team and collaborative environment.

Note?/td>

The output of this task is the Use Case Model work product.

Step 1C: Inventory large reusable assets ^[3]

Here we determine if there are any large reusable asset candidates—including Composite patterns for e-business, reference architectures, industry solutions, and other solution architectures, implementations, engagements, etc. If so, we investigate them to see how close the business requirements match. To be useful, these large reusable assets must have a complete set of work products that can be leveraged through the best practice process. For this step, the large reusable asset must describe the business and IT drivers and a set of generic use cases.

Since by matching the needed functionality to the characteristics of portal solutions outlined in Chapter 2, "Portal solutions" on page 39 we know that the intended project is a portal solution, we can consider leveraging the Portal composite pattern. The business and IT drivers for the Portal composite pattern shown in Figure 3-7 on page 90 indicates a potential match to the intended project:

<
Figure 3-7: Portal composite pattern generic use cases

Business drivers

Deep customer knowledge and mindshare
Achieve leadership from a quality and/or marketplace mindshare perspective
Transactional and process efficiency

IT drivers

Information and data aggregation
Information targeted to specific user and group types
Identification of user and group types
Content management (including workflow)
Search and indexing of static and dynamic database content
Single sign-on
Centralized business rules definition
Centralized security mechanism (covering single sign-on functionality)

The generic Use Case Model for the Portal composite pattern (see Figure 3-7 on page 90) highlights the Business and Integration patterns associated with the use cases.

Note?/td>

The Use Case Model above matches very well with the requirements, making the Portal composite pattern a strong asset candidate that can be leveraged for the solution.

Step 1D: Match solution use cases with generic use cases of the large reusable asset candidates

Now that you have identified asset candidates to leverage, compare the intended solution use cases to the generic use cases of the large reusable assets. In this section, we will focus on matching the intended solution's use cases to the generic use cases of the Portal composite pattern.

Table 3-3 on page 91 describes these Portal composite use cases.

Table 3-3: Portal composite pattern generic use case descriptions
Generic Use Case	Description
Register New User	Registering users to the portal system
Authenticate	Validating the user to the portal system
Authorize	Determining the user's access privileges once authenticated
Customize Home Page	Allowing users to personalize their home page content
Display Home Page	Displaying a home page based on the user's role, displaying only the information pertinent to that role
Access Enterprise Applications	The system accesses an enterprise application, providing data and functionality
Visit TeamRoom	Providing an asynchronous area for user collaboration
Create Content	Allowing users to author, edit, and (through workflow with other users) collaborate on content from within the portal system
Synchronous Chat	Allowing users to send instant messages to other online users
Participate in e-meeting	Facilitating real-time communication for user access to various types of media content (for example, presentation files, applications, or streaming media) through the portal
Search for People	Providing the ability to search for other portal system users
Search for Content	Providing the ability to search for various content in the portal system
Publish Content	From the portal interface, allowing users to publish content to the portal system

Matching the intended solution to the Portal composite pattern's use cases yields the mapping depicted by Table 3-4.

Table 3-4: Solution use cases that match Portal composite pattern generic use cases
Solution Use Cases	Matched PCP Use Cases
Register with Agency	Register new user (SS)
Authorize and Authenticate User	Authenticate (AccI) Authorize (AccI)
Establish Team and Environment	Visit TeamRoom (C)
Manage and Track Incident and Resolve Incident	Create content (C) Synchronous chat (C) Participate in e-meeting (C)
Find SMEs	Search for people (IA)
Request Entry	Access remote applications (SS)
Author and Approve Bulletin	Content creation and management (C)
Publish Bulletin	Publish content (IA)

Note?/td>

We have indicated to which Business (SS = Self Service, C = Collaboration, IA = Information Aggregation) or Integration (AccI = Access Integration) pattern the use case belongs.

Step 1E: Identify delta use cases to handle requirements that are not handled by the matched large reusable asset and classify into Business and Integration patterns

The following use cases do not directly match any generic use cases associated with the Portal composite pattern:

Generate Alert
User Provisioning
Inspect Cargo
Assess Risk
Find Agency Information ^[4]

Next, we classify the remaining use cases into business and integration patterns to show how these "deltas" will be integrated into the initial solution that can be leveraged from the reusable asset.

Figure 3-8 on page 94 maps the remaining use cases into the primary Business patterns, and (where appropriate) to an Integration pattern that could potentially be used to integrate the functionality into the baseline solution:

<
Figure 3-8: Classifying delta use cases

Looking at the details, each of Generate Alert (Apia), Generate Incident (Apia), Find Agency Information (EE), and Assess Risk (EE) include a Business or Integration pattern that is not part of the Portal composite pattern. Inspect Cargo includes an optional Application pattern for Access Integration (Pervasive Device Access).

Step 1F: Document Non-Functional Requirements

Non-Functional Requirements (NFRs) are those technically oriented requirements against an IT infrastructure that are necessary to support the business-oriented requirements but oriented to the IT community only. Since NFRs indirectly support use cases through functional requirements, they are closely related to the Use Case work product addressed previously in this chapter (see Step 1B: Derive actors and use cases required to create the Use Case Model). NFRs demand IT infrastructure function as opposed to application function, and define what the system must do from an infrastructure viewpoint. Since they frequently define key features, characteristics, and constraints on the proposed IT system, NFRs are among the most important requirements affecting the ultimate architectural decisions. The easiest way to remember them is that they represent the "ilities"—usability, manageability, scalability, portability, reliability, availability, and maintainability. Other key items addressed by NFRs are performance and security. They are frequently the first sign of potential software product requirements.

NFRs are used as a basis for early system sizing and cost estimates, as well as to assess the viability of the proposed IT system and to define requirements and constraints upon it. Clear requirements are necessary for a successful project because they define the project's goals, clarifying what is needed in the end solution. They also drive the design of the operational models, architectural decisions (since they frequently define key features, characteristics and constraints on the proposed system), and component design. Many system constraints having significant impacts on the ultimate system architecture are uncovered while discovering the NFRs. Constraints might include the use of specific hardware or software, which in themselves may have associated constraints such as operating system prerequisites or release levels. There may be physical constraints such as the physical location of hardware, technology or standards constraints (such as the use of Java or Linux), operational constraints (such as wireless capability), or configuration constraints (such as using an existing network infrastructure). Non-Functional Requirements are frequently the most important determining factor of the architecture. Two systems with the same use cases but with very different Non-Functional Requirements need very different architectures.

The NFRs for the e-government case study follow.:

Performance

Concurrent accesses from multiple users to be supported
Expect 20,000 agency users plus the external users registered with agencies

Availability

Configurable to achieve 24x7 but not required in the first installation
Data access limited by legacy system availability

Maintainability

Variable data should be maintained as metadata in properties files so that changes can be made without recoding.
Presentation, business logic, and data abstraction must be enforced to reduce the potential impact of changes.

Security

Authentication—The following to be provided:
- Access validation by user ID/password
- Usage of passwords for supervisor functions
- System administrator authority to set up and maintain application security for functions and data
- An interface to authenticate clients (for use by server software)
Authorization:
- Validation of authorized clients to be provided by server components
Other:
- Passwords to be masked (not printed) at entry
- Passwords to be stored in encrypted format
- PKI or Basic authentication/authorization
- LDAP-based

Manageability

Change control information:
- Change control for this solution should adhere to current practices within the agency.
System administration—The following to be provided:
- The ability to start and stop software components
- The ability to display alarms and events from software components
- The ability to set up and maintain user profiles (for example, roles)
Installation and distribution—The following to be provided:
- Installation of client and server software components
- The ability to distribute/push files
- Following installation:
  - Procedures to perform system verification
  - Tools to perform system verification
- Support—both on demand and by scheduled distribution

System Usability

User interface designed for non-technical users
Robust capabilities to execute business rules during data entry and transaction processing
Strategic trend toward integrated business operations, driving requirements for back-end enterprise data integration
Strategic trend toward e-government services, driving tactical trend toward front-end Web enablement or enterprise portal with CRM functionality and e-services models

Data Integrity

Delivery of messages regardless of the state of the network or applications
Logic for retry and system alert if problems exist in completing a transaction

Note?/td>

The output of this task is the NFRs work product.

Step 1G: Validate requirements with customer ^[5]

The final task is to validate the requirements with the users of the systems, usually by walking through the intended functionality using storyboards. Since this task is difficult to show in a book format, we will skip this step in the narrative.

3.2.2 Step 2: Develop the logical design

The logical system design is driven by the Architecture Overview Diagram (AOD), which takes into account the NFRs, the architectural decisions, and the IBM Patterns for e-business Composite, Business, Integration, and Application pattern mappings. From these, the Runtime patterns are derived.

We already have the NFRs and the Architectural Decisions document from the step we just completed (see 3.2.1, "Step 1: Develop solution requirements" on page 84). We will continue the formulation of the logical solution by creating the AOD.

The AOD will go through two stages.

The first will identify the subsystems of the solution. We will refer to this as the Architecture Overview Diagram (Subsystem). This version of the AOD is most compatible with the notation used in working with Business, Integration, Composite, and Application patterns.
The second will denote the logical nodes within the solution. We will call this the Architecture Overview Diagram (Logical Nodes). This logical nodes version of the AOD is aligned with the notation used by the Runtime patterns and is compatible with the typical work product used by most architects.

Steps required to develop the logical design

Step 2A: Derive the initial Architecture Overview Diagram
Step 2B: Seed the AOD with large reusable assets
Step 2B1: Validate the AOD from matched large reusable asset matches requirements

Note?/td>
When using a Composite pattern, validate Application patterns.
- Step 2B2: Capture decisions for chosen patterns into the Architecture Decisions document
Step 2C: Identify and apply patterns for each delta requirement in the AOD
- Step 2C1: Identify delta requirements that need to be addressed in the AOD
- Step 2C2: Identify and apply Business and Integration patterns for the delta requirements
- Step 2C3: Identify and apply Application patterns for delta Business and Integration patterns
- Step 2C4: Capture decisions for chosen patterns into the Architecture Decisions document
Step 2D: Transition the AOD from Subsystem view to Logical Node view
- Step 2D1: Seed the AOD (Logical Nodes) with logical system architecture from large reusable asset
- Step 2D2: Identify and apply Runtime patterns for the delta Application patterns
- Step 2D3: Integrate the Runtime pattern for the Application patterns into the AOD (Logical Nodes)
- Step 2D4: Capture decisions for chosen patterns into the Architecture Decisions document
Step 2E: Review and apply logical design guidelines to the AOD (Logical Nodes)
Step 2F: Conduct technical walkthroughs to ensure that functional requirements are met

We will explain each of these steps in this section.

Step 2A: Derive the initial Architecture Overview Diagram

An Architecture Overview Diagram (AOD) is a graphical representation of the business description. It illustrates the basic ideas of the proposed architecture. Keep in mind that the objective is to keep the diagram simple, yet informative. Typically, the diagram will evolve with a greater level of detail as the architecture is better understood. The diagram serves as means of confirming an architectural understanding between the IT Architect and the client. It also serves as a basis for more detailed work products such as the Component Model and the Operational Model, as we will see later on.

The development of the AOD begins with depicting the functional blocks (Subsystems) of the solution. Functional blocks represent a logical grouping of use cases. Table 3-5 on page 99 displays the functional blocks that were identified from the case study's use cases, which we identified earlier in this chapter. Keep this table available for reference as you continue through the process. It is important to ensure that you know what use cases are rolled into a functional block. As you continue forward, you will be applying patterns to the functional subsystem blocks (defined in the first column).

Table 3-5: Functional blocks that were identified after grouping similar use cases
Functional Subsystems	Associated Use Cases
User Management	Register with Agency (SS) User Provisioning (SS) Authenticate and Authorize User (AccI)
Entry Management	Request Entry (SS)
Risk Management	Assess Risk (EE) Generate Alert (Apia)
Inspection	Inspect Cargo (SS) Generate Incident (AppI)
Cross-Agency Collaboration	Establish Team and Environment (C) Manage and Track Incident (C) Resolve Incident (C)
Cross-Agency Information	Find SMEs (IA) Find Agency Information (IA)
Cross-Agency Document Management	Author and Approve Bulletin (C) Publish Bulletins (C)

The User Management functional block was created by combining the Register With Agency, User Provisioning, and Authenticate and Authorize User use cases. Key points to keep in mind when laying out the AOD are:

Identify business functions required, split into front-end (user-facing), middle (logistical), and back-end (core systems)
Make central business functions central to the picture
Leave gaps for connections and pattern boundaries
Put shared business functions near the middle of the picture
Use a dotted rectangle to aggregate related business functions together in a visual aggregation
Expect to iterate—This is only the beginning. The diagram will be modified as the patterns are applied

Figure 3-9 on page 100 is the AOD (Subsystem) that was developed for the case study depicting the functional blocks that were identified above.

<
Figure 3-9: The AOD (Subsystem) begins with a display of the major business functions

Figure 3-9 depicts a preliminary AOD (Subsystem) with the major business functions identified and connected to illustrate their interactions. This will be updated as we apply the patterns in the next step. This is a good opportunity to review with the customer, confirming that you have identified all of the major business functions of the proposed system.

Note?/td>

The output of this task is the Architecture Overview Diagram work product.

Step 2B: Seed the AOD with large reusable assets ^[6]

Figure 3-10 shows the case study's AOD (Subsystem) after the Portal composite pattern has been applied.

<
Figure 3-10: Architecture Overview Diagram (subsystem) after the Composite pattern is applied

Note?/td>

The dashed lines represent pattern boxes that are subsumed by the Composite pattern.

Table 3-6 shows the functional subsystems and associated use cases that are handled by the Portal composite pattern.

Table 3-6: Subsystems/Use Cases handled by the Composite pattern
Functional Subsystems	Associated Use Cases
User Management	Register with Agency (SS) User Provisioning (SS) Authenticate and Authorize User (AccI)
Entry Management	Request Entry (SS)
Risk Management	Assess Risk (EE) Generate Alert (AppI)
Inspection	Inspect Cargo (SS) Generate Incident (AppI)
Cross-Agency Collaboration	Establish Team and Environment (C) Manage and Track Incident (C) Resolve Incident (C)
Cross-Agency Information	Find SMEs (IA) Find Agency Information (IA)
Cross-Agency Document Management	Author and Approve Bulletin (C) Publish Bulletins (C)

Sidebar: The process used to conclude Portal composite pattern applicability

The following section provides additional details on how the individual Business and Integration patterns were identified for the case study. This section is for those readers who might not be comfortable with the apparent leap to the AOD (Subsystem) shown in Figure 3-10 on page 101. Others should skip ahead to the next step in our solution development process (Step 2B1: Validate the AOD from matched large reusable asset matches requirements).

Business patterns

Business patterns are used to describe the key business purpose of a solution. These patterns describe the objectives of the solution, the high-level participants that interact in the solution, and the nature of the interactions between those participants. Structurally, these patterns are made up of at least two of the following three entities that occur in e-business solutions:

Users of the solution—This can include customers, investors, partners, vendors, and so on.
Enterprise or organization with which the users interact—This "business" entity can be used to represent the organization itself, or systems (applications or software programs) that exist within the organization
Data that exists within the organization—Data is distinguished from applications because the nature of interactions between these entities is very different.

As mentioned in Chapter 2, "Portal solutions" on page 39, there are business and IT drivers that influence the selection of a pattern for a given application. You should review these drivers along with the general guidelines to help you assess if patterns are applicable. Let's go through this process now.

Identify the Business pattern

Throughout the process of applying patterns, you will use the AOD (Subsystem). Remember to keep the functional block's use cases in mind as you review each Business pattern. Let's go through an example using the Self-Service business pattern.

From the Patterns for e-business Web site, review the Self-Service business pattern. Review the pattern overview and then follow the "Guidelines" link to:

Analyze the business and IT drivers
Understand the general context
Identify the major components of the pattern
Review real-life situations where the pattern can be observed

Note?/td>

The IBM Patterns for e-business Web site can be found at http://www.ibm.com/developerworks/patterns/

Self-Service business pattern

The Self-Service business pattern (also known as the User-to-Business or U2B pattern) captures the essence of direct interactions between interested parties and a business. Interested parties include customers, business partners, stakeholders, employees, and all other individuals with whom the business intends to interact. For simplicity, these interested parties are referred to as users. In this definition, the term business represents various types of organizations, including large enterprises, small and medium businesses, and government agencies.

The following are general characteristics that this pattern satisfies (in other words, the business and IT drivers):

End-users and customers must directly interact with business processes.
The business process must be integrated with existing business systems and information.
The business process must be reachable in a common, consistent, and simplified manner through multiple delivery channels.

Now let's look at the case study and identify a Business pattern.

Look at the Entry Management System functional block on the AOD (Subsystem). Recall which use case was encapsulated into this block. Reference Table 3-7 on page 105 to keep the use case in mind as you identify the patterns.

Table 3-7: Excerpt of the Functional block table ^[a]
Functional Subsystems	Associated Use Cases
Entry Management	Request Entry (SS)
^[a](focusing on the "Entry Management" functional block)

Begin with Self-Service business pattern that we reviewed earlier. Keep in mind the use cases that the functional block satisfies. In this example, does the Request Entry use case share some of the characteristics of the Self-Service business pattern? For this functional block, Self-Service is the appropriate pattern.

If the functional block does not fit the characteristics of this Business pattern, move on to another functional block, making note to compare the functional block to a different pattern later.

Apply the Business pattern

As you identify an appropriate Business pattern, draw pattern boxes on the AOD (Subsystem) to depict the Business pattern within the solution. Continue reviewing each functional block of the AOD (Subsystem) in order to identify which Business pattern is appropriate for each functional block until all of the blocks have been categorized.

Figure 3-11 on page 106 is the complete e-government AOD (Subsystem) after all Business patterns have been applied.

<
Figure 3-11: The AOD (Subsystem) after Business patterns have been applied

In Figure 3-11 each pattern box uses the notation BusinessPatternAbbr (Use Case Name)—for example, SS (Request Entry). This notation ties together the use case, a functional subsystem, and the pattern used to provide that functional behavior. Most of Figure 3-11 shows Business patterns that exist independently of one another and do not interact or interface with one another. However, IA (Find Agency Info) is an example of a pattern that does interact with other Business patterns. The next task, applying Integration patterns, will help you better understand this example.

Identify and apply Integration patterns

Integration patterns allow for more complex solutions to be built by combining multiple Business patterns. These patterns allow the integration of multiple applications, modes of access, and sources of information to build one seamless application. Integration patterns are differentiated from Business patterns in that they do not themselves automate specific business problems. Rather, they are used within Business patterns to support more advanced functions, or to make Composite patterns feasible by allowing the integration of two or more Business patterns. (Composite patterns are discussed further in the next task.)

Whenever more than one Business pattern is needed to solve a business problem, an Integration pattern must be included so that the solution can be simplified or made seamless to the user or application requiring the solution. Therefore, Integration patterns assist in implementing the full solution by integrating Business patterns to satisfy the full e-business requirements.

Reliable integration of applications—whether legacy "stovepipe" applications, packaged software applications, or custom applications—requires the use of proven replicable patterns. At its highest level, application integration can be divided into two essentially different approaches:

Process integration—The integration of the functional flow of processing between applications.
Data integration—The integration of the information used by applications.

Neither approach is necessarily better than the other. Rather, specific integration requirements dictate which approach best solves a given business problem. For example, the integration of an e-commerce application with an Enterprise Resource Planning (ERP) system for a newly created sales order would most definitely be a process integration activity. However, in the same solution, the master data synchronization of the product catalog between the ERP system and the e-commerce system would be a data integration activity.

Business and IT Drivers

Businesses developing a solution needing the following characteristics should consider using the Application Integration business pattern:

The business process must be integrated with existing business systems and information.
The business processes should integrate with processes and information that exist at partner organizations.
The business activity should aggregate, organize, and present information from various sources both within and outside of the organization.

Reference the AOD (Subsystem) again. First, look at each of the lines between the functional blocks and determine how the integration should be accomplished. You should understand the relationships between the Business patterns that have been identified within the solution. Functions that should be tied together to provide a consistent experience to the user indicate the occurrence of an Integration pattern.

Let's look at the case study and identify an Integration pattern. For the next example, we'll focus on the integration point (or connection) between the Entry Management and Risk Management functional blocks.

Remember from the use cases that the operator requests permission to dock at the port. Once that request is received, the system must assess the risk of the cargo/crew to determine if an inspection is needed.

Table 3-8 shows the use cases that are represented on the AOD (Subsystem) by the Entry Management System and Risk Management functional blocks. This is an example of business process integration, which helps to identify that it is an Application Integration pattern.

Table 3-8: Excerpt of the Functional block table ^[a]
Functional Subsystems	Associated Use Cases
Entry Management	Request Entry (SS)
Risk Management	Assess Risk (EE) Generate Alert (AppI)
^[a](focusing on the "Entry and Risk Management" functional blocks)

Next, you can extend the AOD (Subsystem) by drawing ellipses to indicate applicable Integration patterns as they are identified. Figure 3-12 shows the case study's AOD (Subsystem) after all the Business and Integration patterns have been applied. This diagram will be refined later by further identifying appropriate Application patterns.

<
Figure 3-12: AOD (Subsystem) after integration patterns have been applied

Use the Composite pattern to identify Application patterns

The following steps outline how to use the mandatory Application patterns from a Composite pattern to identify both the Application patterns for your solution and the functional blocks that are covered by the application of the corresponding Composite pattern:

Review each pattern box on the AOD (Subsystem).
1. Focus on the use cases that are satisfied by this functional block.
If you have identified a pattern box (around the functional block) as a Business pattern, review that Composite pattern's mandatory Application pattern(s).

In the case study, the Entry Management System functional block was identified as a Self-Service business pattern. The Portal composite pattern indicates that Directly Integrated Single Channel is a mandatory Business pattern::Application pattern.
1. For each mandatory Application pattern, assess the:
  1. Business and IT drivers
  2. Guidelines for use
  3. Benefits and limitations
  4. Examples of where this Application pattern exists
  Note?/td>
  The items listed above (i. through iv.) are all available on the IBM Patterns for e-business Web site.
2. Does this Application pattern apply to this functional block? Does it address the use cases?

Indicate on the AOD (Subsystem) which functional blocks are absorbed by the mandatory Application patterns by checking off the pattern block. For our case study, we have now generated the AOD (subsystem) shown in Figure 3-13 on page 111.

<
Figure 3-13: AOD (Subsystem) after the Composite pattern have been applied. Solid lines denote patterns which are not absorbed by the Composite pattern.

Step 2B1: Validate the AOD from matched large reusable asset matches requirements

Review the AOD (Subsystem) after the Composite pattern has been applied. Because they require one of the mandatory Business/Integration pattern::Application patterns, all of the functional blocks that have been checked off are absorbed by the Composite pattern.

In the case study, most of the AOD (Subsystem) is subsumed by the Portal composite pattern. Only some of the Access Integration patterns, Application Integration patterns, and the Extended Enterprise business patterns fall outside the Portal composite pattern's scope.

To further validate that you have chosen the correct Composite pattern, confirm that the Application patterns associated with the selected Composite patterns are valid to your solution. To validate, review the set of mandatory and optional Application patterns associated with the Composite pattern to ensure they apply. Figure 3-14 shows the AOD (Subsystem) from the case study after all of the Application patterns have been validated.

<
Figure 3-14: The AOD (Subsystem) after the chosen Composite pattern's Application patterns have been validated

Table 3-9: Validation of Application Patterns covered by Composite pattern for e-government case study
Application Pattern	Discussion
AccI::Web Single Sign-on	Authenticate and Authorize User requires a common portal-style SSO environment.
AccI::Personalized Delivery	Requirement for role-based presentation (not directly linked to a particular use case)
SS::Directly Integrated Single Channel	Single delivery channel for all SS applications (the presentation server). UI to be adapted for environment (in other words, not As-is Host). Included use cases: Register with Agency Request Entry User Provisioning Inspect Cargo
C::Store and Retrieve	This covers e-mail, SMS messaging, simple chat via IRC, and document-sharing via TeamRooms. Included use cases: Manage and Track Incident Resolve Incident Author and Approve Bulletins
IA::Population Crawl and Discovery	Many documents (unstructured data) needed to be searched to populate TeamRoom. No summarization needed. Included use case is Find Agency Info.
IA::Population Single Step	No data needs to be transformed or restructured. Included use cases are Find SMEs (structured data) and Publish Bulletin (unstructured data)

It is important that you go through these steps to assess if your solution truly resembles the Composite pattern you assumed. Looking at Figure 3-15 on page 114, you might think that the Portal composite pattern could be applied. It has the necessary Self-Service, Collaboration, and Information Aggregation business patterns, as well as the required Access Integration pattern, and it has some of the optional patterns as well. Simply looking at this AOD (Subsystem), you might think it's a variation of the Portal composite pattern.

<
Figure 3-15: Example of an AOD (Subsystem) that could be deceiving, leading you to select a Portal composite pattern instead of the Electronic Commerce composite pattern

However, the following illustrates the importance of paying close attention to the use cases as you go through this process. If you examine the use cases in Table 3-10 on page 115 that go along with the following solution, you will clearly see it is not a Portal composite pattern, even though the AOD (Subsystem) diagram in Figure 3-15 on page 114 might lead you to that conclusion. Rather, this is an example of the Electronic Commerce composite pattern.

Table 3-10: Use cases for commerce case study
Use Case	Description
Register with Company	Customers register their names, locations, shipping addresses, preferred financial institutions, and other relevant information with the system
Perform Account Maintenance Functions (user provisioning)	Maintaining account information (addresses, etc.), managing passwords, and setting user interface parameters
Browse and Select from Catalog	Allow users to search and select components from the product catalog
Access Forum Information	Allows users to learn more about the experiences of other manufacturers, structured content providing the key design specifications, assembly advice, and reliability and desirable service strategies appropriate for their line of finished products for particular product lines
Place Order	Users will be able to place orders from the product catalog
Query Inventory	The system will verify that the component is available by querying the in-house inventory control application
Choose Financing Option	Select from several financing options provided by different financial institutions
Access Customer Preferences	Access the customer's preferences and other profile information from the customer registration database to complete the details of the order
Notify Customer	Once the order is placed, customers will be notified electronically via e-mail or pager
Send Order to Warehouse	The completed order is then forwarded via e-mail to the warehouse to be filled and shipped to the customer

Step 2B2: Capture decisions for chosen patterns into the Architecture Decisions document

We have reminded you at various points in this process of the need to document the architectural decisions you have made. As a formal process task, we have called it out to ensure that the Architecture Decisions document is updated.

Here is an example of the Architecture Decisions document for the case study. Table 3-11 on page 116 is an excerpt of the Architecture Decisions document that focuses on the decisions made when choosing the Information Aggregation for the Find SMEs functional block of the case study.

Table 3-11: Excerpt of the Architecture Decisions document
Subject Area	Expertise Operational Datastore
Architectural Decision	Access to a logical (read-only) operational data store is required to support Find SMEs.
Issue or Problem	Provide information aggregation to quickly and efficiently locate SMEs to participate on the X-Agency Response Team.
Assumptions	Requirement for Find SMEs is a read-only access to LDAP information.
Motivation	Minimize network traffic and latency when setting up a new incident team.
Alternatives	Could make multiple queries (crawl and discover) at team creation time.
Decision	Choose Population Single Step (application pattern) to generate a composite "inter-agency" SME ODS.
Justification	Low volatility in ODS records. Only require read-only access to data.
Implications	?/td>
Derived Requirements	?/td>
Related Decisions	?/td>

This document will continue to be updated as you make other decisions throughout this process. The format shown in Table 3-11 is an example of how to document such decisions

Step 2C: Identify and apply patterns for each delta requirement in the AOD

Consists of the following sub-steps:

Step 2C1: Identify delta requirements that need to be addressed in the AOD
Step 2C2: Identify and apply Business and Integration patterns for the delta requirements
Step 2C3: Identify and apply Application patterns for delta Business and Integration patterns
Step 2C4: Capture decisions for chosen patterns into the Architecture Decisions document

Step 2C1: Identify delta requirements that need to be addressed in the AOD

Review the AOD, this time focusing on the pattern boxes/integration points that were unabsorbed by the Portal composite pattern.

In the e-government case study's AOD (Subsystem), look at the Risk Management System pattern box. This is an example of a Business pattern that falls outside the Portal composite pattern because it is an Extended Enterprise business pattern. This Business pattern is an optional pattern within the Portal composite pattern. Its pattern box is thus identified as a delta requirement.

Similarly, the line between Entry Management System and Inspection System functional blocks was identified as an Application Integration pattern. The Portal composite pattern does not mandate that the Application Integration pattern be used, so that this pattern is identified as a delta requirement. Make a mental note of this as we continue through these steps.

After reviewing all of the delta requirements, we can identify the delta Business and Integration patterns (as illustrated by Figure 3-16).

<
Figure 3-16: AOD (Subsystem) after delta requirements have been highlighted

Delta requirements will be our primary focus throughout the remainder of the solution design process.

Step 2C2: Identify and apply Business and Integration patterns for the delta requirements

Depending on the analysis performed thus far in Step 2, you may have already identified Business and Integration patterns associated with delta requirements. For example in the case study illustrated by Figure 3-16 on page 117, all of the deltas have been classified into the appropriate Business or Integration pattern.

This formal task has been defined to address the situation where your large reusable asset has not yet identified patterns. In order to continue to the next step of the process, it is important that you have these patterns identified. The process applied here is the standard process identified in A Portal Composite Pattern Using WebSphere V4.1. ^[7]

Step 2C3: Identify and apply Application patterns for delta Business and Integration patterns

The next step involves identifying the Application patterns associated with each of the delta Business and Integration patterns. You should use the standard approach of reviewing the business and IT drivers associated with each potential Application pattern and comparing these to your solution requirements.

For the case study, the following are the deltas that were captured in the AOD (Subsystem):

Access Integration (Inspect Cargo)
Application Integration (Assess Risk)
Application Integration (Generate Alert)
Application Integration (Generate Incident)
Extended Enterprise (Assess Risk)
Extended Enterprise (Find Agency Information)

As an example, let's focus on the Extended Enterprise (Assess Risk) delta. The general problem addressed by this pattern is illustrated by Figure 3-17 on page 119.

<
Figure 3-17: Illustration of the general problem addressed by the Extended Enterprise pattern

Interactions between partners form a public process (or potentially multiple distinct public processes). Each of these must be integrated into the private business process flows implemented by each partner. This separation of public and private processes provides the benefit of flexibility and autonomy for the trading partners.

In order to identify the appropriate Application pattern, you need to assess the business and IT drivers of the solution to the Extended Enterprise::Application patterns.

Let's recall the business and IT drivers for the case study again:

Business drivers

Need to integrate "stovepipes" and decrease redundancy
Need to streamline processes and improve data analysis
Need to facilitate effective decision-making

IT drivers

Better internal use of information
Secure data sharing
Effective incident management through automated processes
Support new security demands
Interface to new and existing databases

With these in mind, we'll review the business and IT drivers associated with the various Extended Enterprise business pattern's Application patterns, looking for the Application patterns that satisfy most of the case study's needs. First, let's review the business drivers of the Extended Enterprise in Table 3-12.

Table 3-12: The Business Drivers for the Extended Enterprise::Application patterns
Business Drivers	Document Exchange	Exposed Application	Exposed Business Services	Managed Public Processes	Managed Public and Privage Processes
Improve the organizational efficiency	√	√	√	√	√
Reduce the latency of business events	√	√	√	√	√
Support a structured exchange with business partners	√	√	√	√	√
Support partner real-time access to/from applications	?/td>	√	√	√	√
Support partner real-time access to/from business services	?/td>	?/td>	√	√	√
Support for shared public process flows with partners	?/td>	?/td>	?/td>	√	√
Support for internal private and shared public process flows	?/td>	?/td>	?/td>	?/td>	√

It is important to assess which of these drivers will address your needs. Table 3-13 shows how we have tied the pattern's drivers back to the case study's in order to identify which Application pattern is most appropriate.

Table 3-13: Side-by-side look at the pattern's business drivers as opposed to the case study's
Pattern's Business Drivers	Applicable Case Study's Business Drivers
Improve organizational efficiency	Need to integrate "stovepipes" and decrease redundancy Need to streamline processes and improve data analysis Need to facilitate effective decision-making
Reduce the latency of business events	Need to streamline processes and improve data analysis Need to facilitate effective decision-making
Support a structured exchange with business partners	Need to integrate "stovepipes" and decrease redundancy
Support partner real-time access to and from applications	Need to streamline processes and improve data analysis
Support partner real-time access to and from business services	Need to streamline processes and improve data analysis
Support shared public process flows with partners	None apply
Support internal private and shared public process flows	None apply

Table 3-14 on page 122 highlights the applicable business and IT drivers associated with Assess Risk. Note that neither Document Exchange nor Exposed Application can satisfy the solution requirements.

Table 3-14: Highlighting the pattern's applicable business drivers
<

Similarly, Table 3-15 on page 123 illustrates the applicable IT drivers.

Table 3-15: Highlighting the pattern's applicable IT drivers
<

Looking at these two diagrams that highlight the applicable drivers, you can deduce which Application patterns satisfy the case study. Only three Application patterns address all of its requirements. Figure 3-18 on page 124 is a graphical representation of all five Application patterns, highlighting the best candidates.

<
Figure 3-18: The five Extended Enterprise——Application patterns, highlighting the three that are applicable

Table 3-16 highlights more information that will help us determine the most appropriate Application pattern.

Table 3-16: Description of the various Application patterns ^[a]
Application Pattern	Issues
Document Exchange	This is the ideal Application pattern to choose if your current business needs would be satisfied by the batched exchange of electronic documents. (EDI is a good example)
Exposed Application	Typically supported by asynchronous communication mechanism. Requires security features such as authentication, authorization, confidentiality, integrity and logging for non-repudiation purposes. Limitation—common middleware between all partners.
Exposed Business Services	This application pattern is ideal when there is need to hide the back-end application details from trading partners to gain flexibility and improve maintainability.
Managed Public Process	Trading partner agreements. The primary reason for choosing this application pattern is to support different business protocols with different trading partners. This provides greater flexibility.
Managed Public and Private Process	This Application pattern accommodates long-running transactions across organizational boundaries.
^[a](highlighting the most appropriate one for the case study)

Table 3-16 on page 125 helped us drill down to the Exposed Business Services application pattern. We chose the Application pattern that is the best choice for the case study, but that does not over-complicate the solution. Because there is no public, well-defined process, the Managed Public Process and the Managed Public and Private processes would be inappropriate. Thus, the simpler of the three candidate Application patterns is the Exposed Business Services. If a well-defined trading partner agreement was later obtained, this may need to be re-evaluated.

This process should be applied for all deltas. Figure 3-19 on page 126 is the AOD of the case study showing the applied Applications patterns, while Table 3-17 on page 126 summarizes the Application patterns selected for the delta Business and Integration patterns

Table 3-17: Summary of Application patterns for delta Business and Integration patterns
Delta requirements in the AOD (Subsystem)	Applied Pattern
Application Integration (Assess Risk)	Application Integration::Broker
Access Integration (Inspect Cargo)	Access Integration::Pervasive Device Access
Extended Enterprise (Find Agency Information)	Extended Enterprise::Exposed Business Service
Application Integration (Generate Alert) Application Integration (Generate Incident)	Application Integration::Direct Connection

<
Figure 3-19: Application patterns for delta requirements

Step 2C4: Capture decisions for chosen patterns into the Architecture Decisions document

Again we have created a formal process task to remind you of the importance of documenting your architectural decisions. Table 3-18 is an excerpt of the Architecture Decisions document that focuses on the decisions made when choosing the Information Aggregation for the Find SMEs functional block of the case study.

Table 3-18: An excerpt of the Architecture Decisions document
Subject Area	Inter-Agency Business Services
Architectural Decision	Application Integration (Assess Risk)
Issue or Problem	This is a process (rather than data) integration activity
Assumptions	The integration involves multiple systems
Motivation	Application pattern choices are: Direct Connection ^[a] Transactional ^[b] Broker Managed Process ^[c]
Alternatives	?/td>
Decision	Applications are provided via the Broker application pattern.
Justification	?/td>
Implications	?/td>
Derived Requirements	?/td>
Related Decisions	?/td>
^[a] Since the integration involves multiple systems, Direct Connection is inappropriate ^[b]Since there are no updates to any of the contributing applications, the integration isn't Transactional. ^[c]Managed Process (BPM) is typically associated with long running processes. This is short-term.

This document will continue to be updated as you make other decisions throughout this process. The above format is an example of how to document such decisions.

Step 2D: Transition the AOD from Subsystem view to Logical Node view

From a Patterns approach, the next step in our solution design process is to move to the Runtime pattern level. Unfortunately, the Subsystem view of our AOD is not consistent with the Logical Node view associated with Runtime patterns. This step transitions the AOD from a Subsystem view to a Logical Node view. This is a logical progression leading to physical design and the development of the Component and Operation models.

Step 2D1: Seed the AOD (Logical Nodes) with logical system architecture from large reusable asset ^[8]

The next step is to transition the AOD to work with the Logical Node view. The large reusable asset should have a similar work product with which you can seed, building out the AOD (Logical Nodes). When working with the Portal composite pattern, the corresponding Runtime pattern can be used. Remember that if there is a portion of the matched large reusable asset that is not applicable to the current solution being developed (a delta that will not be included in the solution), the corresponding logical nodes should not be included in the seeded AOD (Logical Nodes).

Definition:?/td>

Runtime patterns are used to define the logical middleware—in other words, to support the Application patterns. They describe the logical architecture needed to implement the Application patterns by exposing the major middleware nodes, their roles, and the interfaces among them. These logical nodes can then drive the physical model through Best Practices, Usage Guidelines, Reference Implementations, and Personal Experience.

Following Application pattern validation in the case study, we verified that the Portal composite pattern is a good starting point. Since it absorbed a major portion of our solution, it's appropriate to use the Portal composite's Runtime pattern to seed the AOD (Logical Nodes). Figure 3-20 on page 129 is the Portal composite pattern's Runtime pattern. We will use it to seed the AOD (Logical Nodes) for the case study.

<
Figure 3-20: The Portal composite pattern's Runtime pattern

Note?/td>

For an explanation of each of the nodes, refer to section 5.2.1 of the redbook A Portal Composite Pattern Using WebSphere 4.1, SG24-6869.

The Portal composite Runtime pattern is a combination of a number of different Runtime patterns. The characteristics of the Runtime patterns and the addition of portal-specific nodes is what comprise the Portal composite Runtime pattern. During the seeding process, you may want to customize the logical nodes to better represent the domain of your solution.

Customizing the Portal composite Runtime pattern results in an initial AOD (Logical Nodes) for our solution. Figure 3-21 on page 130 represents the customized AOD (Logical Nodes) for the case study that was seeded from the reusable asset.

<
Figure 3-21: The AOD (Logical Nodes) as seeded from the customized Portal composite pattern's Runtime pattern

This customization consisted of renaming the logical nodes to be more applicable to the case study. The User Management node was also identified as a separate functional node in order to highlight the user registration, authentication, and authorization.

Step 2D2: Identify and apply Runtime patterns for the delta Application patterns

In order to design a complete solution, you will need to update the AOD (Logical Nodes) to include the delta Application patterns. Starting with the Application patterns for each delta requirement, you should identify the appropriate Runtime pattern to be used in the solution.

You should then review the business and IT drivers, benefits, and limitations, pulling the pattern-to-use sections from the patterns Web site in order to identify the most applicable pattern. Be sure to review all of the Runtime patterns in order to make the best choice.

Once you have chosen Exposed Business Services as the Application pattern used to handle Assess Risk, you must choose the corresponding Runtime pattern. Note there may be several "variations"—which will lead to alternative designs. You may be able to dismiss some alternatives immediately, while at others the alternatives must be "considered" until later in the design process.

Figure 3-22 shows the specific business functionality supported by the Extended Enterprise business pattern ^[9] that we have chosen.

<
Figure 3-22: Detail of the Exposed Business Services application pattern

There are various topologies available for the Application patterns that vary from one industry to another. A survey of such applications in multiple industries, however, reveals certain common approaches that have been successful. The diagrams are used to describe these successful approaches for the Application patterns.

For Exposed Business Services, the resulting runtime pattern illustrated by Figure 3-23 on page 132 will result in adding the Message Broker node and the VPN end point to the current AOD (Logical Nodes). Figure 3-23 on page 132 is the Runtime pattern for the Exposed Business Services application pattern obtained from the Patterns for e-business Web site.

<
Figure 3-23: Exposed Business Services application pattern—— Runtime pattern

The Exposed Business Services Runtime pattern supports message-oriented interactions using a Message Broker. This broker handles enterprise application integration and communicates over a Virtual Private Network (VPN). The VPN is terminated behind the domain firewall for greater security.

Repeat this process, identifying the appropriate Runtime pattern for each delta pattern by identifying the logical nodes that are needed to support each Runtime pattern.

Step 2D3: Integrate the Runtime pattern for the Application patterns into the AOD (Logical Nodes)

Once you have identified the Application pattern and the most appropriate Runtime pattern, you will need to ensure that the solution's AOD (Logical Nodes) reflects those decisions. Review the AOD (Logical Nodes) and validate that the solution contains the logical nodes required by the chosen Runtime pattern.

The original AOD (Logical Nodes) that we created for the case study did not have the necessary logical nodes required by this Runtime pattern. Figure 3-24 illustrates the updates made to the AOD (Logical Nodes) once the Extended Enterprise Application pattern has been applied for the Assess Risk function.

<
Figure 3-24: AOD (logical nodes) after the Runtime patterns were updated for the delta "Assess Risk"

Continue through the process described above to address the other deltas, updating the AOD (Logical Nodes) to reflect your choices. Figure 3-25 is the final AOD (Logical Nodes) after all deltas have been addressed.

<
Figure 3-25: AOD (Logical Nodes) after all deltas have been addressed and the appropriate Runtime patterns incorporated

Table 3-19 details the updates that were made to the AOD (Logical Nodes) to address each of these deltas shown in Figure 3-25 on page 134.

Table 3-19: Description of how the deltas were addressed in the AOD (Logical Nodes)
Deltas identified in the AOD (subsystem	Addressed by
Application Integration (Assess Risk)	Applied Pattern: Application Integration::Broker Added the Message Repository to address the Runtime pattern.
Access Integration (Inspect Cargo)	Applied Pattern: Access Integration::Pervasive Device Access Added the gateway and the non-IP network to address the Runtime pattern.
Extended Enterprise (Find Agency Information)	Applied Pattern: Extended Enterprise::Exposed Business Service Added the connection from the Message Broker to the Cross-Agency Collaboration Server to address the Runtime pattern. The reverse proxy, VPN end point, and Message Broker had already been applied when the Extended Enterprise (Assess Risk) delta was addressed in detail earlier.
Application Integration (Generate Alert) Application Integration (Generate Incident)	Applied Pattern: Application Integration::Direct Connection No nodes/connections were added

Step 2D4: Capture decisions for chosen patterns into the Architecture Decisions document

Again, this formal task has been added to ensure that you understand the importance of documenting the decisions you have made during this process in the Architecture Decisions document. The tables below summarize the decisions that were made when the deltas were addressed in the preceding tasks above.

Subject Area	Inter-Agency Business Services
Architectural Decision	Extended Enterprise (Assess Risk)
Issue or Problem	Agencies need to protect their ability to maintain applications while preserving a consistent interface for consumption by partner agencies.
Assumptions	Since agencies will define their own private processes, support for a public process is not required
Motivation	Support good decoupling between agency systems and applications that should integrate.
Alternatives	?/td>
Decision	Applications are provided via the Exposed Business Service application pattern and will exploit Web services standards to manage the interface.
Justification	?/td>
Implications	Extensive use of Web services throughout e-government.
Derived Requirements	?/td>
Related Decisions	?/td>

Subject Area	Inter-Agency Business Services
Architectural Decision	Application Integration (Assess Risk)
Issue or Problem	This is a process (as opposed to data) integration activity.
Assumptions	The integration involves multiple systems.
Motivation	Application pattern choices are: Direct Connection ^[a] Transactional ^[b] Broker Managed Process ^[c]
Alternatives	?/td>
Decision	Applications are provided via the Broker application pattern.
Justification	?/td>
Implications	?/td>
Derived Requirements	?/td>
Related Decisions	?/td>
^[a] Since the integration involves multiple systems, Direct Connection is inappropriate ^[b]Since there are no updates to any of the contributing applications, the integration isn't Transactional. ^[c]Managed Process (BPM) is typically associated with long running processes. This is short-term.

Subject Area	Inter-Agency Business Services
Architectural Decision	Access Integration (Inspect Cargo)
Issue or Problem	Pervasive access to the system
Assumptions	?/td>
Motivation	This is an optional Portal composite pattern Application pattern driven by the input device characteristic.
Alternatives	?/td>
Decision	Applications are provided via the Pervasive Device Access application pattern.
Justification	?/td>
Implications	?/td>
Derived Requirements	?/td>
Related Decisions	?/td>

Subject Area	Inter-Agency Business Services
Architectural Decision	Extended Enterprise (Find Agency Information)
Issue or Problem	Similar issues to other Extended Enterprise patterns (detailed above)
Assumptions	?/td>
Motivation	Leverage existing Message Hub from other requirements.
Alternatives	?/td>
Decision	Applications are provided via the Exposed Business Process application pattern.
Justification	?/td>
Implications	?/td>
Derived Requirements	?/td>
Related Decisions	?/td>

Subject Area	Inter-Agency Business Services
Architectural Decision	Application Integration (Generate Alert) Application Integration (Generate Incident)
Issue or Problem	Providing simple, non-transactional integration to peer applications
Assumptions	?/td>
Motivation	These are Information Request (data integration). Options are Direct Connection or Aggregator. Aggregator requires multiple source applications/data sources. Upon further decision/realization that each application will be deployed on the same Application Server, we are easily able to provide direct communication.
Alternatives	?/td>
Decision	Applications are provided via the Exposed Business Process application pattern.
Justification	?/td>
Implications	?/td>
Derived Requirements	?/td>
Related Decisions	?/td>

Step 2E: Review and apply logical design guidelines to the AOD (Logical Nodes)

Throughout the solution development process, you should ensure that known guidelines and best practices are being followed. An excellent source for these guidelines is the appropriate patterns redbook. What you want to do at this step is review the current solution architecture to determine if it is consistent with these known guidelines and best practices.

For example, in A Portal Composite Pattern Using WebSphere V4.1 ^[10] you will find the following portal solution guidelines:

Leverage a central user directory.
Provide a single mechanism for intercepting user requests and passing security credentials to various applications and data sources.
Provide a session or authentication time-out for a user's logged-in session.

The Directory and Security Services node provides a central user directory. A single authentication point for user interactions can be provided by the Presentation Server, or later by a Security Proxy in the DMZ. Similarly, the Presentation Server or Security Proxy can provide the session time-out.

Here's one other guideline gained from field experience:

Needing user provisioning means the likelihood of needing an enterprise security manager.

We have a requirement for user provisioning and have factored out User Management as a separate logical node in the AOD. We strongly suggest that you seriously consider an enterprise security manager within the solution and review this during physical design.

Step 2F: Conduct technical walkthroughs to ensure that functional requirements are met

Now that the AOD (Logical Node) has been developed, you should account for all functional requirements before continuing to the physical model. Using the AOD (Logical Nodes), you can conduct technical walkthroughs with the customer to validate that the functional requirements are met. Figure 3-26 on page 141 is a mockup of the AOD (Logical Nodes), detailing the functional flow of the use case Request Entry.

<
Figure 3-26: Mocked-up AOD (Logical Nodes) to be used in a technical walkthrough

The following details the steps highlighted in Figure 3-26.

Step 0

Ship's captain logs into (authenticates with) the Port Authority portal.

Step 1

Ship's captain navigates to the Entry Request Form via the portal and submits manifest and crew documents.
The Presentation Server invokes the Entry Management application.
The Entry Management application triggers the Assess Risk process in the integration hub.

Step 2

The Assess Risk process accesses each remote business service via the Message Broker and VPN.
The Assess Risk process determines that a alert must be generated.

Step 3

The Assess Risk process sends an Alert via the integration hub and message repository to the Customs Agency.

Once you have verified that the logical solution you have prepared addresses all functional requirements, you can continue on to develop the physical solution.

3.2.3 Step 3: Develop the physical solution

At this point, you have finished designing the logical representation of your solution. You have (long ago) worked with the customer to determine the business model it was originally using. You have investigated its use cases, determined NFRs, made some architectural decisions, and determined which Business, Integration, Composite, and Application patterns were applicable to your design. Now it's time to develop the physical solution.

The physical system design is driven by the logical solution, developed using both the Component (optional) and Operational models, and serves to determine the actual product mappings for the solution.

Steps required to develop the Physical Solution

Step 3A [optional]: Develop high-level component model
Step 3B [optional]: Apply Design Guidelines (Application Level) from large reusable assets (including redbooks and best practice white papers)
Step 3C [optional]: Perform a technical walkthrough of the component interactions
Step 3D: Develop the Operational Model
Step 3E: Seed the Operational Model by applying the Product mappings from the matched large reusable assets
Step 3F: Address "operational" NFRs in the Operational Model
Step 3G: Conduct technical walkthroughs to ensure that Non-Functional Requirements are met

This section addresses each of these steps.

Step 3A: [optional]: Develop high-level component model

The Component Model describes the high-level logical structure of the system's components. It depicts major subsystems and boundaries (interfaces) of the overall system and:

Shows and defines the components (nodes) that comprise the solution and are to be placed on the operational model
Exhibits the responsibilities, relationship boundaries, and interactions of the components
Documents how functional/technical parts of the system are related

A component can be a software subsystem, a program module, a collection of classes (for example, all the classes dealing with registration), a program (for example, one that performs alert notification), a part of a product (for example, DB2?, or a hardware device (for example, a computer).

The Component Model encompasses a number of diagrams. At the highest level, it identifies the components or nodes that make up the solution and shows how they interact. There may be a description of each of the components involved. Relationship diagrams show how the functions work together, and sequence diagrams exhibit what happens when, so that the process or data flow can be established.

Note?/td>

This work product can be considered optional if the solution is not complex enough to warrant its necessity.

Table 3-20 shows the pertinent components in the e-government case study, organized by associated logical node.

Table 3-20: e-government case study components
Logical Node	Associated System Components
Presentation Server	Health Department Portal Port Authority Portal
Cross-Agency Document Management	Content Management System Remote Document Search Service
Application Server, Entry Management, and Inspection System	Entry Management Customs Inspection System
Message Broker and Integration Hub	Alert Management Integration Hub Risk Assessment System
Cross-Agency Collaboration Server	Emergency Response Team Environment
Existing Agency Servers	Lookout Operational Data Store (ODS) Service Import Bill of Lading (BOL) Service Threat Level Service
Component added for performance purposes	Subject Matter Expert ODS

Figure 3-27 illustrates the relationship between the components that comprise your solution. Cardinality ^[11] can be noted if desired. The intent is to show which components interact with others.

<
Figure 3-27: e-government case study Component Model Relationship Diagram

Note?/td>

The output of this step is the Component Model Relationship Diagram work product.

Component Interaction Diagram for the case study using the Risk Assessment scenario

Component Interaction diagrams serve to validate your design in scenario context. They allow you to walk through the scenario and ensure that the use cases and components previously identified are correct with respect to their interactions.

Note?/td>

In the Risk Assessment and Inspection diagrams that follow (Scenarios 1–4), the wireless entity isn't really a component but is included in the diagram to enhance readability and understanding. Also note that although no actual storage is shown, a record is created and stored for the Risk Assessment scenario. This record can be referenced later for the inspection.

<
Figure 3-28: e-government case study Component Interaction diagram—Scenario 1

<
Figure 3-29: e-government case study Component Interaction diagram—Scenario 2

<
Figure 3-30: e-government case study Component Interaction diagram—Scenario 3

<
Figure 3-31: e-government case study Component Interaction diagram—Scenario 4

Step 3B: [optional]: Apply Design Guidelines (Application Level) from large reusable assets (including redbooks and best practice white papers)

Guidelines help establish the required service levels needed to support functional responsibilities. Their use helps ensure that these responsibilities are covered by the set of components representing the solution architecture. Refer to the guidelines published in relevant patterns redbooks. For example, review Chapter 8, "Application Design," from A Portal Composite Pattern Using WebSphere V4.1. ^[12] There you will find guidelines on topics such as single-versus multi-tier Portal server design, content management, MVC, SSO, collaboration, and Web services guidelines. Chapters 7–10 provide a set of guidelines organized by technology, application design, application development, and systems management.

Content Management guidelines included in this redbook:

Define content types and location/source
Define the process by which content will be contributed and eventually published
Define the content versioning and expiration schemes

SSO usage guidelines and best practices from this redbook

Leverage a central user directory
Provide a single mechanism for intercepting user requests and passing security credentials to various applications and data sources
Provide a session or authentication timeout for a user's logged-in session
Provide a variation of the SSO interface for various client device types
Identify the various user types and link them with the business rules engine
Enable encryption of the data packets as authentication is being performed
Update security policies to enhance the physical security of the SSO mechanism that intercepts authentication requests for existing applications and data sources
Agree to a common format for user names and passwords
Agree to a process for updating SSO account information for user names and passwords ^[13]

In addition to the redbook guidelines, be sure to leverage physical mappings from known solutions and field experience, both for core components and for key component interactions.

Once the guidelines have been found and identified, the question is how to apply them for practical use. For example, the Content Management guidelines previously specified imply a need for an Authoring server with workflow. Also, a decision can be made as to how the content will be delivered (in other words, Runtime server). These may be new, additional components, or additional details for existing components, and they will be reflected in the Operational Model.

Step 3C: [optional]: Perform a technical walkthrough of the component interactions

The main idea is to verify that the component interactions and sequences apply to the use cases. This is to insure that the operational flow is correct and that all components are accounted for, and should be very detailed. The Component Interaction and System Sequence diagrams are used to document and validate system behavior. The walkthrough should ensure coverage of all system scenarios (detailed use cases) by interaction or system sequence diagrams.

Develop test case scenarios from the use cases to ensure that all are correct. Read the text insert example in the Component Interaction diagram used for our case study and verify that it validates the use (and test) case.

Step 3D: Develop the Operational Model

After reviewing the AOD, the next logical step is to translate the logical nodes into physical servers and then apply the products needed to complete the physical model. This is accomplished by starting with the AOD to seed the Operational Model (which is a graphical representation of a network of computer systems, their associated peripherals, and the systems software, middleware, and application software that they run). It answers such questions as how many servers and where components reside within them.

The Operational Model serves to:

Provide a physical view of the system
Depict major elements of the IT system
Facilitate analysis of NFRs
Provide a walkthroughs mechanism
Enable product evaluation and selection
Enable early cost estimates

It may contain:

System Topology Diagram
Node descriptions
Network view
Software view
Physical hardware view
Walkthrough description

As previously stated, certain work products are referenced when creating others. When creating the Operational Model, be sure to refer to the NFRs, Architectural Decisions, Architecture Overview Diagram (Logical Nodes), and Component Model (which gets deployed onto the Operational Model). These work products will assist you in developing your Operational Model. Also see if there are any design guidelines from associated redbooks that are applicable. Use field expertise when considering clustering, etc.

The process of creating the Operational Model is illustrated in Figure 3-32.

<
Figure 3-32: Operational Model development process

The Conceptual Operational Model references project requirements. The Specified Operational Model references the logical components, and the Physical Operational Model references the physical components. Generally, an Operational Model develops from conceptual to specified to physical. Depending on the complexity of the problem and your starting point, it may not be necessary to go through all three stages. For example, an architecture may be heavily constrained by physical platform decisions that have already been made, or by an existing specification-level known solution. Remember to address the NFRs (for example, clustering or high-availability) and any product dependencies in your Operational Model.

First we start with the AOD for our case study (as shown in Figure 3-33 on page 153). Note the additional documentation of the software services provided by the logical nodes. This will help provide a foundation for establishing the product mappings that follow directly afterward.

<
Figure 3-33: AOD for the e-government case study

Step 3E: Seed the Operational Model by applying the Product mappings from the matched large reusable assets

Apply product mappings for the delta requirements—Unfortunately, solutions architects often jump right into this step without carefully considering all the previous steps and work products that we have discussed so far in this chapter. The problem with this approach is that it makes it harder to maintain and scale the proposed solution. It becomes more of a "standalone" architecture that may work for now, but probably not last for the long term. Or it may not integrate easily into the customer's existing IT infrastructure.

To properly perform product mapping, it's essential to go through the method outlined in this chapter—to go through the steps and create all of the associated work products. It's a best practice to identify the Business, Integration, Composite, Application, and Runtime patterns in order to arrive at the point where product mappings can occur. From the Runtime patterns identified in your solution, you can map the products, technologies, and platforms that provide a "best fit" for your solution. Realize, of course, that you should also leverage any existing assets. Use your collection of assets ^[14] to identify the best implementation approach for your components.

In addition to business drivers, consider the following when deciding on a product and technology mix:

Existing systems and platform investments—Leverage these as much as possible unless there is a reason to change.
Customer choices—The customer might have experience and satisfaction with certain products and operating systems and thus want to stay with them.
Planned future functional enhancements—Try to obtain a "long-range" vision based on the customer's goals. Look at the Envisioned Goals and Issues document. Is there anything in there suggesting that certain topologies or products should be adopted at this time? Maybe the customer has plans to scale up at a later time. You must consider this so as not to inhibit scalability at a later date with a product set that limits this capability.

The products and technologies chosen should fit into the target environment and ensure quality of service (such as scalability and reliability) so that the solution can grow along with the e-business.

The goal in product mapping is to choose a set of products and technologies that will minimize any necessary customization. Refer to any known solutions that are applicable and show products and versions that are known to work well together. Realize, however, that product updates may have occurred since that architecture was deployed. Be sure to check the product release notes ^[15] for compatibility listings before making any final decisions. There might be version dependencies that must be observed. For example, when integrating TAM V4.1 and WebSphere Portal Server V4.2, there is a portal server patch (PQ70837) that must be applied—a patch that isn't needed when using WebSphere Portal Server 4.2.1.

Unless this is a stand-alone solution or there is no current target environment, there may be an existing set of products and technologies that have already been implemented for specific functionalities. In this situation, the integration of products and technologies from various vendors (for example, IBM, Microsoft, Sun, and Oracle) is not only required but can be successfully implemented if the products communicate—for example, by using Web services. If you need to use existing product sets, this will affect your architectural decisions. Be sure to document these.

The Patterns for e-business Web site ^[16] shows each Runtime pattern with the products that have already been tested in that capacity. It may be beneficial to reference these because they have already been proven to be successful. Note, however that this should be used as a starting point, that it is not exhaustive and may not always represent the product versions that are appropriate for your particular engagement. A more successful approach might be to leverage existing known architectures. In addition, be sure to review Chapter 8 of A Portal Composite Pattern Using WebSphere V4.1. ^[17] This chapter includes guidelines for SSO, collaboration, Web services, and portal solutions, all of which should be considered before any product mapping occurs.

From this, we derived the product mappings. In other words, we "filled in" or listed the products that provided the necessary functions for each node, resulting in the design shown in Figure 3-34 on page 156.

<
Figure 3-34: AOD for e-government case study with product mapping

From this diagram we derived the Operational Model illustrated by Figure 3-35 on page 157.

<
Figure 3-35: e-government case study Operational Model

This gave us the base model. Then—by referring to the NFRs to see what performance, scaling, and high-availability requirements were needed—we added additional servers to address these requirements (as discussed in the next task).

Note?/td>

The output of this step is the Operational Model work product.

Step 3F: Address "operational" NFRs in the Operational Model

At this point, you have a first pass at your physical model. You have applied the product mappings, taking advantage of any available known solutions, redbooks, and other guidelines and best practices. Now it's time to address the NFRs in your physical model to ensure that they are all accounted for. NFRs are used to assess the viability of the proposed IT system. NFRs are frequently the most important determining factor of the architectures.

IBMers should realize that this is another opportunity to use redbook guidelines, physical mappings from known solutions, and field experience. If you have any other engagements that concerned themselves with these issues, you should examine what was done to address these concerns. You might be able to leverage these assets. Also leverage the IBM High Volume Web Site (HVWS ^[18]). The HVWS team focuses on high scalability tests and measurements, end-to-end performance management, and collaboration with key product groups for high-scale testing in customer environments. From this site you can find best practices, actual design and implementation experiences, and presentations on scalability and performance that might assist you in your solution. These were generated from actual customer engagements. There are many guidelines and white papers dealing with scalability and performance. Following is an example for addressing high availability, security, and performance concerns from the HVWS:

Cluster the portal server (implies clustering the underlying applications server).
Cluster the Web server to enhance delivery of static content.
Use WebSEAL as a reverse proxy to keep security mapping (LTPA tokens) in the DMZ. Replicate/cluster the WebSEAL server to enhance throughput.
Cluster/replicate other key-service intensive servers based on expected traffic (for example, various collaboration servers such as Lotus?Instant Messaging and Team Workplace?. ^[19]

Using these clustering guidelines, our Operational Model from Figure 3-35 on page 157 evolves into Figure 3-36.

<
Figure 3-36: Operational Model with clustering

Another example highlights best practices for achieving application scalability.

Ten techniques for achieving scalability

Faster machines

The goal is to increase the ability to do more work in a unit of time by processing tasks more rapidly. A faster machine can be achieved by upgrading its hardware or software.
Replicated machines

The primary goal is to service more client requests. Parallelism in machine clusters typically leads to improvements in response time. Moreover, system availability is improved due to failover safety in replicas.
Specialized machines

The goal is to improve the efficiency of a specific component by using a special-purpose machine to perform a required action. These are usually dedicated machines that are very fast and optimized for a specific function. Examples are network appliances and routers with cache, such as the IBM WebSphere Edge Server.
Segmented workloads

The goal is to split up the workload into manageable chunks, thereby obtaining more consistent and predictable response time. The technique also makes it easier to manage workload distribution on individual servers. Combining segmentation with replication frequently offers the added benefits of providing an easy mechanism for redistributing work and scaling selectively as business needs dictate.
Request batching

The goal is to reduce the number of requests sent between requesters and responders (such as between tiers or processes). This is accomplished by defining new requests that combine multiple requests.
User data aggregation

The goal is to allow rapid access to large customer data controlled by existing system applications and to support personalization based on customer-specific data. The technique calls for aggregating customer data into a Customer Information Service (CIS). A CIS that is kept current can provide rapid access to customer data for a very large number of customers, thereby providing the required scalability.
Connection management

The goal is to minimize the number of connections needed for an end-to-end system, as well as to eliminate the overhead of setting up the connections. This is accomplished by maintaining and sharing a pool of preestablished connections that can be reused. In WebSphere, this is referred to as connection pooling. Reusing existing database connections conserves resources and reduces latency for application requests, thereby helping to increase the number of concurrent requests that can be processed. Managing connections properly can improve scalability and response time.
Caching

Caching is a key technique to reduce hardware and administrative costs and to improve response time. The goal is to improve performance and scalability by reducing the length of the path traversed by a request and the resulting response, and by reducing the consumption of resources by components when the same content is requested multiple times or by multiple users.
Content delivery services

The goal is to guarantee that mission-critical content (video, audio, data, or text) gets from its source to its destination in a timely and reliable fashion. One method is to distribute the servers in multiple localities, thereby ensuring that content can be provided even if one server is down, for load balancing, and for delivering from the best possible location for enhanced performance.
Local distribution across sites

The goal is to distribute network traffic across multiple sites, thereby reducing the load and bottleneck at any one site. Locally distributing the application across multiple sites enhances scalability.

Table 3-21: How scaling techniques relate to scaling objectives
Technique #	Scaling Technique	Increase Capacity/Speed	Improve Efficiency	Shift/Reduce Load
1	Use faster machine	X	?/td>	?/td>
2	Create machine cluster	X	?/td>	?/td>
3	Use a special machine	X	X	?/td>
4	Segment the workload	?/td>	X	X
5	Batch requests	?/td>	X	?/td>
6	Aggregate user data	?/td>	X	?/td>
7	Minimize connections	?/td>	X	?/td>
8	Cache data and requests	?/td>	X	X
9	Content Delivery Services	X	?/td>	X
10	Local distribution across sites	?/td>	X	X

Figure 3-37 illustrates where you might take advantage of the preceding scalability guideline techniques.

<
Figure 3-37: Where performance, scalability, and availability can be implemented

It's important to note that a detailed understanding of the application is key to the successful implementation of these best practices in an architecture.

Note?/td>

The IBM High Volume Web Site is http://www.ibm.com/websphere/developer/zones/hvws/

Step 3G: Conduct technical walkthroughs to ensure that Non-Functional Requirements are met

Technical walkthroughs need to consider all applicable NFRs to ensure that availability and performance are covered. You should also consider maintenance requirements (for example, can regular maintenance be applied within the availability guidelines?).

For our first walkthrough, we'll use the high-availability NFR that was addressed in Step 1F: Document Non-Functional Requirements.
- Configurable to achieve 24x7 but not required in the first installation
Refer to Figure 3-38 on page 162. Let's assume that the requirement is that any user must be able to connect to the portal server at any time (in other words, that it's always available).

<
Figure 3-38: e-government case study Operational Model with high-availability NFR walkthrough

Detailed below are the walkthrough steps that are highlighted in Figure 3-38 to ensure that this requirement is met.

Note?/td>
The colored lines and numbered circles correspond to users, not the step numbers.
- Step 1:
  
  User "1" logs into the portal server (blue path)
- Step 2:
  
  User "2" logs into the portal server (red path)
- Step 3:
  
  The portal server that User "1" is logged into fails over to another in the cluster (yellow path). User "1" continues uninterrupted.
For our next walkthrough, we'll use the performance-related NFR that was addressed in Step 1F: Document Non-Functional Requirements (see Figure 3-38).
- Concurrent access from multiple users to be supported. ^[20]
Again using Figure 3-38, you can see that the security servers between the two left-most firewalls are redundant. This is for failover as well as for load balancing to increase performance. Notice that the portal server as well as the Lotus Instant Messaging and Team Workplace servers are all redundant—which addresses this particular NFR as well. We can use a similar walkthrough as the one above.
- Step 1:
  
  User "1" logs into the portal server (blue path)
- Step 2:
  
  User "2" logs into the portal server (red path)
Additional users that log in will be load-balanced among all available redundant servers.
For our next walkthrough, we'll use the security-related NFRs that were addressed in Step 1F: Document Non-Functional Requirements. These are handled by the WebSEAL and Tivoli servers and products. As a reminder, the following NFRs address security.
- Authentication
  - NFR 1. Access validation by user ID/password will be provided.
  - NFR 2. Usage of passwords for supervisor functions will be provided.
  - NFR 3. System administrator authority to set up and maintain application security for functions and data will be provided.
  - NFR 4. An interface for use by server software to authenticate clients will be provided.
- Authorization
  - NFR 5. Validation of authorized clients will be provided by server components.
- Other
  - NFR 6. Passwords will be masked/not printed at entry.
  - NFR 7. Passwords will be stored in encrypted format.
  - NFR 8. PKI or Basic authentication/authorization
  - NFR 9. LDAP based
The walkthrough is as follows:
- Step 1:
  
  User attempts login to the WebSEAL server (NFR 4) through a browser. The user is challenged to provide user name and password (NFR 1). Passwords are masked as they are typed (NFR 6).
- Step 2:
  
  WebSEAL authenticates the user (NFR 5). This is performed by passing the user credentials to Tivoli Access Manager (TAM), which checks the credentials and encrypted password (NFR 7) against the LDAP user registry (NFR 9) and returns to WebSEAL.
- Step 3:
  
  If authentication is validated, WebSEAL forwards the HTTP request and authentication credentials into the trusted network to the portal server.
- Step 4:
  
  The portal server uses the Trusted Association Interceptor (TAI) to communicate with Tivoli Access Manager (TAM) to verify that the user is authenticated. TAM then verifies user authorization.
- Step 5:
  
  If authorized, the portal server displays the requested URL.
- Step 6:
  
  The portal session is started and an LTPA token created and cached in WebSEAL's memory so that at the next user request, WebSEAL determines that the token already exists and passes the request to the portal server without repeating the authentication. The portal server checks the TAI and displays the page.
  
  For SSO, the token is passed to the other servers when they are accessed so that the user will not be challenged a second time.

Assumptions:?/td>

WebSphere Portal Server is configured to use an external authentication proxy. WebSphere Portal Server has deferred ACL to TAM. Authentication is HTTP Basic Authentication (NFR 8).

For brevity, we will not address each of the NFRs in this chapter, but this is something you will need to do to ensure that your solution takes them all into account. Should you find that you overlooked one of the NFRs, this is the time to address that. For instance, if you see that there's an NFR for high availability and you haven't already designed, this is the time to add it to your physical model.

^[2]An actor can be a class of users, roles users play, or other systems.

^[3]For example, Composite patterns, reference architectures, and industry solutions

^[4]Part of this use case matches Search for content. However, this doesn't take into consideration the external systems that must be accessed as part of this search.

^[5]For example, walkthrough storyboard(s)

^[6]For example, Composite patterns, reference architectures, and industry solutions

^[7]IBM Redbook SG24-6869-00 (ISBN 0738427446)

^[8]For example, Composite pattern's runtime pattern

^[9]Also known as the Business to Business or B2B business pattern

^[10]Redbook SG24-6869-00, ISBN 0738427446

^[11]The number of cardinal (basic) members in a set. In tables, the number of rows is called the cardinality

^[12]Redbook SG24-6869-00, ISBN 0738427446

^[13]For example, passwords cannot be retrieved if lost, but must be reset

^[14]Known solutions, Composite patterns, field deployments, etc.

^[15]http://www.ibm.com/software/support

^[16]http://www.ibm.com/developerworks/patterns/

^[17]Redbook SG24-6869-00 (ISBN 0738427446)

^[18]http://www7b.software.ibm.com/wsdd/zones/hvws/

^[19]Formerly known as Sametime and QuickPlace

^[20]Expect 20,000 agency users in addition the list of external registered users.

< Day Day Up >

3.2 Execute

3.2 Execute

Task: Develop high-level Project Description and System Context Diagram

Business drivers for the case study

IT drivers for the case study

3.2.1 Step 1: Develop solution requirements

Step 1A: List users/existing systems and Functional Requirements

Step 1B: Derive actors and use cases required to create the Use Case Model

Step 1C: Inventory large reusable assets [3]

Business drivers

IT drivers

Step 1D: Match solution use cases with generic use cases of the large reusable asset candidates

Step 1E: Identify delta use cases to handle requirements that are not handled by the matched large reusable asset and classify into Business and Integration patterns

Step 1F: Document Non-Functional Requirements

Performance

Availability

Maintainability

Security

Manageability

System Usability

Data Integrity

Step 1G: Validate requirements with customer [5]

3.2.2 Step 2: Develop the logical design

Steps required to develop the logical design

Step 2A: Derive the initial Architecture Overview Diagram

Step 2B: Seed the AOD with large reusable assets [6]

Step 2B1: Validate the AOD from matched large reusable asset matches requirements

Step 2B2: Capture decisions for chosen patterns into the Architecture Decisions document

Step 2C: Identify and apply patterns for each delta requirement in the AOD

Step 2C1: Identify delta requirements that need to be addressed in the AOD

Step 2C2: Identify and apply Business and Integration patterns for the delta requirements

Step 2C3: Identify and apply Application patterns for delta Business and Integration patterns

Business drivers

IT drivers

Step 2C4: Capture decisions for chosen patterns into the Architecture Decisions document

Step 2D: Transition the AOD from Subsystem view to Logical Node view

Step 2D1: Seed the AOD (Logical Nodes) with logical system architecture from large reusable asset [8]

Step 2D2: Identify and apply Runtime patterns for the delta Application patterns

Step 2D3: Integrate the Runtime pattern for the Application patterns into the AOD (Logical Nodes)

Step 2D4: Capture decisions for chosen patterns into the Architecture Decisions document

Step 2E: Review and apply logical design guidelines to the AOD (Logical Nodes)

Step 2F: Conduct technical walkthroughs to ensure that functional requirements are met

Step 0

Step 1

Step 2

Step 3

3.2.3 Step 3: Develop the physical solution

Steps required to develop the Physical Solution

Step 3A: [optional]: Develop high-level component model

Component Interaction Diagram for the case study using the Risk Assessment scenario

Step 3B: [optional]: Apply Design Guidelines (Application Level) from large reusable assets (including redbooks and best practice white papers)

Content Management guidelines included in this redbook:

SSO usage guidelines and best practices from this redbook

Step 3C: [optional]: Perform a technical walkthrough of the component interactions

Step 3D: Develop the Operational Model

Step 3E: Seed the Operational Model by applying the Product mappings from the matched large reusable assets

Step 3F: Address "operational" NFRs in the Operational Model

Ten techniques for achieving scalability

Step 3G: Conduct technical walkthroughs to ensure that Non-Functional Requirements are met

Step 1C: Inventory large reusable assets ^[3]

Step 1G: Validate requirements with customer ^[5]

Step 2B: Seed the AOD with large reusable assets ^[6]

Step 2D1: Seed the AOD (Logical Nodes) with logical system architecture from large reusable asset ^[8]