Architecting Portal Solutions: Applications Development

3.2 Execute

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:

1. Establish system requirements through defined use cases.

2. 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.

3. 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

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:

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.

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.

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

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

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.

1. 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.

2. 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).

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:

1. Identify business functions required, split into front-end (user-facing), middle (logistical), and back-end (core systems)

2. Make central business functions central to the picture

3. Leave gaps for connections and pattern boundaries

4. Put shared business functions near the middle of the picture

5. Use a dotted rectangle to aggregate related business functions together in a visual aggregation

6. 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.

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

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

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

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.

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.

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:

1. Review each pattern box on the AOD (Subsystem).

   1. Focus on the use cases that are satisfied by this functional block.

2. 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

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.

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.

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):

1. Access Integration (Inspect Cargo)

2. Application Integration (Assess Risk)

3. Application Integration (Generate Alert)

4. Application Integration (Generate Incident)

5. Extended Enterprise (Assess Risk)

6. 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.

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-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.

Similarly, Table 3-15 on page 123 illustrates the 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 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

< 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.

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).

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

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.

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.

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.

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

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

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.

< 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).

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

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.

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?).

1. 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.

2. 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.

3. 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.

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.