Chapter 3: A Recommended Approach to Architecting Portal Solutions

---

Overview

This chapter is a detailed guide on how to architect and design portal solutions for customers in a wide range of industries by leveraging large reusable assets, best practices, and experiences . In order to make this apply to real projects, we have embedded these practices and experiences into an industrial-strength methodology, including a step-by-step process for asset deployment. This guide weaves the process into the appropriate phases, tasks, and activities required to develop all required work products.

Our methodology focuses primarily on where and how to leverage these assets. As we lead you through our solution development lifecycle, we spend relatively little time on implementation, since the assets utilized there tend to be smaller and more focused, ^[1] and this phase generally much better understood and documented than the others. Also, please note that even though our intention was to provide enough details about our design to be able to cover both functional and non-functional requirements, we stopped short of selecting operating systems or product versions, since frequent upgrades there would soon render any book obsolete.

Important: 

This guide is essentially methodology-independent and can be woven into any existing industrial-strength methodology.

The methodology we have chosen is used by IBM Software architects to design solutions for a wide range of customer requirements. It includes three distinct phases—Plan, Execute, and Implement. Each of these phases has a well-defined set of tasks and activities that produce associated work products for helping the architect uncover and document system requirements and then to design a solution capable of meeting them. The execute phase is where reusable assets, best practices, and experiences can best be leveraged. Here requirements come to light and a solution is developed. We thread our step-by-step best practice process into the appropriate tasks and activities of this phase to show how reusable assets can be employed to seed work products and then customized to design a solution that meets unique customer requirements.

Note 

These work products should be familiar to the architects and designers of modern e-business systems, and their notation is consistent with the Unified Modeling Language.

To better illustrate how to use this guide in actual practice, we have developed interrelated scenarios built around a complex customer case study. Here we chose a "typical" situation requiring modernization of disparate government agencies needing collaboration and integration. The business scenarios that comprise this study target the need for governments to collaborate across countries, agencies, regions, states, local governments, and the private sector in order to identify and more effectivly control the sources of potential problems.

Table 3-1 on page 67 summarizes our best practice guide and sets the stage for the rest of the chapter. The first column shows the tasks, activities, and resulting work products in each phase of our solution development methodology . The second column shows the known solutions and assets that can be leveraged within a given part of that methodology, as well as the impact of reusing these assets. The final column shows the step-by-step best practice process that we recommend you follow to ensure that assets are leveraged effectively.

Table 3-1: Best practice process & its relationship to development methodology & large reusable assets

Solution Development Methodology	Known Assets and Solutions	Best Practice Process for Leveraging Large Reusable Assets
Phase: Plan
Activity: Evaluate Customer's Environment
Tasks: Define Business Context Identify Business Issues and Goals
Task: Describe Current Organization
Activity: Develop Plan Linked to Customer's Business Initiatives
Task: Document IT Standards
Task: Analyze Current IT Infrastructure
Phase: Execute
Activity: Develop Customer Interest; Establish Buying Vision with the Customer	Consider the catalog of IBM Patterns for e-business. Reference solutions, targeting the customers' industry and solutions that have been successfully developed for similar customers as potential sources of assets that can be leveraged for building the solutions to address the customers' needs.	Survey the catalog of large reusable assets, including the IBM Patterns for e-business, reference architectures, reference solutions targeting the customer's industry, and known solutions from customer engagements to build a set of candidate assets that can be leveraged to build your solution.
Task: Obtain or Develop Business Roadmap
Task: Gain Sponsorship Work Products: Project Description System Context Diagram		Develop High Level Project Description and System Context Diagram
Activity: Demonstrate Business Benefits and Capabilities; Qualify Opportunity
Task: Outline Solution Requirements Work Products: Non-Functional Requirements (NFRs) Use Case Model	The reusable assets must be matched against the customer's requirements to validate that they can be effectively leveraged. When there is a match, the assets can be leveraged by showing which parts of these requirements are handled directly by the assets and the delta requirements that have to be custom-built.	Step 1: Develop the Solution Requirements: Step 1A: List users/existing systems and functional requirements Step 1B: Derive actors and use cases; create Use Case Model Step 1C: Inventory large reusable assets (for example, Composite patterns, reference architectures, and industry solutions) Step 1D: Match solution use cases with generic use cases of the large reusable asset candidates to identify the matched large reusable asset. Step 1E: Identify delta use cases (additions or subtractions) to handle requirements that are not handled by matched large reusable assets and classify into business and integration patterns Step 1F: Identify and document NFRs Step 1G: Validate requirements with customer (for example, walkthrough storyboards).
Task: Assess Initial Viability
Activity: Develop Solution with Customer
Task: Develop Solution Architecture Work Products: Architecture Overview Diagram (AOD) Architecture Decisions.	Given the requirements gathered thus far, we want to develop the AOD. Known industry and customer solutions can also be leveraged by validating that the solution at least partially matches the requirements, and by using the known solution to seed the AOD. It is important to highlight which parts of the solution are not tackled by the asset, and then to work on designing and integrating these delta Business and Integration patterns to arrive at a complete solution	Step 2: Develop the Logical Design: Step 2A: Derive Initial AOD (Subsystems), showing major functional subsystems by grouping use cases. Step 2B: Seed the AOD with matched large reusable asset (for example, Composite patterns, reference architectures, and industry solutions): Step 2B1: Validate the AOD from matched large reusable asset matching requirements When using a Composite pattern, validate Application patterns. Step 2B2: Capture chosen patterns into Architecture Decisions Step 2C: Identify and apply patterns for each AOD delta requirement Step 2C1: Identify delta requirements that need to be addressed in the AOD Step 2C2: Identify and apply Business and Integration patterns to address delta requirements Step 2C3: Identify and apply Application patterns for delta Business and Integration patterns Step 2C4: Capture chosen patterns into Architecture Decisions Step 2D: Transition the AOD from subsystem view to a logical node view Step 2D1: Seed the AOD (Logical Nodes) with logical system architecture from matched large reusable asset (for example, the Composite pattern's Runtime patterns) Step 2D2: Identify and apply Runtime patterns for the delta Application patterns Step 2D3: Integrate Runtime pattern for the Application patterns into the AOD Step 2D4: Capture chosen patterns into Architecture Decisions 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
Conduct technical walkthrough
Task: Develop High-level Component Model (Optional) Work Product: Component Model	The Component Model includes both functional and technical component interaction models. Existing Patterns for e-business redbooks might help in the development of these Component Models. For the identified Business, Integration, and Application patterns, select the appropriate Patterns redbook and review its design guidelines chapter. This chapter will outline the technical component interactions for a given solution, based on the patterns identified earlier in this process. The information gathered from the design guideline chapters in the Patterns for e-business redbooks should be used as a baseline for component interactions. The component model for known solutions and the established best practice guidelines for the type of solution can be leveraged to seed the Component Model.	Step 3: Develop the Physical Design: Step 3A [optional]: Build the Component Model, showing software component nodes (required to support functional subsystems). Step 3B [optional]: Apply design guidelines (application level) from matched large reusable assets, including redbooks and best practice white papers. Step 3C [optional]: Conduct technical walkthrough of component interactions
Conduct technical walkthrough
Task: Develop Operational Model Work Product: Operational Model	When leveraging patterns: Finalize the Application patterns to be used, again based on the Business, Integration, and Composite patterns selected earlier. Here you can select the Runtime pattern for each of the identified Application patterns based on Non-Functional Requirements (NFRs). If multiple Runtime patterns are selected, combine to get a first draft of the Operational Model. You might need to develop several runtime architectural options. When leveraging known solutions: Use runtime product mappings that are known to work together. Leverage scalable architecture techniques to apply NFRs to the operational model, especially to address high availability. Leverage known operational configurations to address system management issues. Note  The Component and Operational Model tasks can be developed simultaneously. In some cases, the information from the Operational Model will be needed to evaluate the technical component interactions in the Component Model.	Step 3D: Seed the Operational Model by applying product mappings from the matched large reusable asset. Apply product mappings for the delta requirements. Step 3E: Address "operational" NFRs in the Operational Model Step 3F: Conduct technical walkthroughs to ensure that the NFRs are met
	As such, the architect or individual completing these tasks in the method should not assume that the Component Model must be completed before beginning the Operational Model.
Task: Refine Viability Assessment
Conduct technical walkthrough
Activity: Refine Solution, Resolve Concerns, Close Sale
Task: Assess Business Impact
Task: Ensure Client Commitment
Task: Evaluate Integrated Solution
Phase: Implement
Activity: Monitor Solution Implementation and Ensure That Expectations Are Met
Task: Monitor Pilot
Task: Evaluate Success
Task: Harvest Assets

Note 

The rows highlighted in yellow define our primary focus in writing this chapter.

Note 

All of the best practices are primarily applicable to the Execute phase and support the development of the work products used to model the solution. Figure 3-1 on page 74 illustrates the dependencies between the primary work products.

Figure 3-1: Work product dependencies

As promised, some of these work products will be examined within this chapter to assist you in understanding how they contribute to the design of your solution.

Note 

We have assumed that the reader is familiar with work products and the Patterns for e-business. This redbook is not intended to cover those patterns or work products other than to show how they are used in architecting a portal solution. For further information on the IBM Patterns for e-business, go to http://www.ibm.com/developerworks/patterns/.

Since this redbook is about developing a portal solution, we have focused on the Portal composite pattern. The next section consists of a "sidebar" providing further details about the Portal composite pattern. Readers familiar with this can skip to 3.1, "Plan" on page 77.

Sidebar: Portal composite pattern

This pattern is designed to facilitate many variations of similar functionality. A portal solution typically aggregates multiple information sources and applications to provide a single, seamless, personalized access to users.

As shown in Figure 3-2, the Composite pattern for portal applications is made up of an Access Integration pattern that facilitates functions such as single sign-on, multiple device support, and personalization—and integrates the common Business patterns for portal applications, including Self-Service, Information Aggregation, and Collaboration.

Figure 3-2: Portal composite pattern

Benefits

Once an organization has determined that it needs to aggregate information, target that information to specific users, analyze the usage of information, and collect and manage information, it can use a portal to meet these requirements. Creating a portal architecture can provide the following benefits:

• A single aggregated view of content targeted to specific user types

• Ability to analyze usage patterns to make marketing efforts more efficient

• Ability to tailor the user interface to specific groups, thereby enabling a focus on cultural, language, or nationality-based differences

• Single sign-on, allowing the user to save time and have access to information while decreasing the requirements for direct interaction with the organization, thereby saving money

Application patterns of the Portal composite pattern

An Application pattern shows the principal layout of the application, focusing on its shape, logic, and associated data. It identifies the high-level logical components needed to implement the key functions of the chosen Business patterns.

The selection of an Application pattern is based on the selected Business, Integration, and Composite patterns. Application patterns use logical tiers to illustrate the various ways to configure the interaction between users, applications, and data.

Each Application pattern has associated business and IT drivers. Review each of the business and IT drivers with the associated Application pattern to determine the best fit for the requirements.

Figure 3-3 on page 77 shows the specific Application patterns (within the associated Business and Integration patterns) that can be used to enable the various types of functionality found in each Business and Integration pattern. Note that some of these Application patterns are mandatory (shown in blue text) for a properly functioning portal, while others are optional (indicated by red text).

Figure 3-3: Application patterns in the Portal composite pattern

^[1]For example, design patterns and coding guidelines

---