Project Notebook

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Integration Patterns

June 2004

Summary: This chapter takes a broader view of the Global Bank scenario by showing the link between business and technology viewpoints. It starts with an overview of the Global Bank business environment, and then describes the viewpoints of five key business stakeholders. The chapter then presents a series of models that the Global Bank team produced as they designed the baseline architecture based on business requirements. These models trace a path from the Chief Executive Officer to the technical solution and show how the team used patterns during the design process.

Contents

Interpreting the Artifacts

Global Bank Business Context

Stakeholder Viewpoints

From Business Scenario to Technical Solution

Going Forward

"A business architecture is just an instruction set for extracting value. To extract value, a business must first create value for its customers; then extract some of the customer transaction value for itself."—Richard Sears, engineer and entrepreneur

While constructing the baseline architecture for Global Bank, the architecture team created numerous artifacts ranging in scope from business process models to executable bits. The team created these artifacts so that they could understand the business with sufficient clarity to create a technical architecture that would meet the needs of the business.

As they designed the technical architecture for Global Bank, they wanted to take advantage of reusable design elements (patterns) to mitigate technical risk and make the project more predictable. In addition, they knew that these patterns embodied design principles that would make it easier to evolve the architecture as the needs of the business changed over time. They wanted to take advantage of this extensibility after the system was delivered to lower the cost of new application development in the future.

This chapter presents some of the artifacts that the team produces while designing the baseline architecture. It starts with an overview of Global Bank's business environment, and then describes the viewpoints of five key business stakeholders. These viewpoints are captured in a set of models, which trace a path from business requirements to the technical solution. The chapter also presents some pattern-driven design models that capture the team's use of patterns during the process.

Interpreting the Artifacts

This chapter presents Global Bank team artifacts in a logical top-down progression, by starting with the high-level organizational processes and then disassembling these processes in progressive levels of detail. The order in which the chapter presents these artifacts does not, however, reflect the order in which the team produced them. The team produced the artifacts through an iterative process—building first cut approximations and then progressively refining them in subsequent iterations. They are presented here in logical order only to enhance readability.

The scenario presented in this book is intentionally incomplete. And although the artifacts presented here were used to build out an actual running system, it is important to remember that both Global Bank and the scenario portrayed are fictitious. They are intended only to demonstrate the application of patterns to the problems of integration within a representative enterprise scenario.

Let's examine the overall business context in more detail.

Global Bank Business Context

Global Bank is a midsize, traditional bank that has acquired a complete range of financial services capabilities through a series of acquisitions. The bank currently has a limited online presence that is fragmented across its various divisions. As part of its expansion strategy, Global Bank has decided to innovate in the online banking market by providing a host of value-added services on top of a fully integrated financial management capability. Some banks currently offer, or are developing the capability to offer, integrated online banking across all accounts (such as savings, checking, and credit cards). But no other bank offers a full range of value-added services such as financial advice, financial analysis and planning, and tax planning and filing. In addition, Global Bank has not seen the synergies it anticipated from offering a complete line of products. This lack of synergy is caused by its inability to effectively cross-sell based upon existing relationships and customer knowledge.

Convergence in the Banking Industry

In the late 1990s, the United States Congress began the process of deregulating the financial services industry. The Depression-era regulations restricted what services could be provided by specific types of financial services companies. Banking could only provide banking products and insurance companies could only provide insurance products. The deregulation of the industry had the effect of removing the legal barriers between various product types and between the companies that provided them. This triggered a mergers and acquisitions frenzy to broaden service offering portfolios.

Because he is familiar with the notion of profit patterns, the CEO of Global Bank quickly recognizes a particular pattern unfolding within his industry. He strongly believes that this Convergence pattern [Slywotsky99] will not only impact the global and national banks, but the whole industry.

The Convergence pattern describes the phenomenon in which businesses expand their offerings to related products and services along the value chain. Customers may forsake traditional suppliers in search of higher value, if not lower price (for example, the modern financial services industry). This complicates the market and presents a challenge because you must meet the new market by expanding your deliveries, which takes you outside your expertise. Convergence occurs when suppliers do one or more of the following:

• Expand up or down the value chain
• Substitute new products in place of existing ones
• Bundle products together

To apply the supplier Convergence pattern, you must do three things: first, successfully promote your product offerings; second, emphasize the portions of the chain which command the highest perceived value and; third, upgrade your delivery of the lower value products. Convergence requires gaining access to the other aspects of the bundled product. This usually involves mergers and acquisitions. It is wise to jump into mergers and acquisition activity early, when the choice of business combinations is best.

Bundling products together also increases efficiency due to economies of scope. That is, the cost of performing multiple business functions simultaneously should prove to be more efficient than performing each business function independently, and therefore drive down overall costs.

Applying the strategy of convergence, the CEO convinces the board of Global Bank to embark on a series of financial service acquisitions, which in effect creates a midsize, full-service financial company. To turn this strategy into concrete action, the CEO needs to charter several projects. For each one of these projects, there are key stakeholders, each with a unique viewpoint.

One of the key initiatives involves strengthening the bank's online presence. The online channel is an effective means of adding new services at relatively low cost. With many customers using online checking and savings today, it will be easy to move them to other value-added services if the bank can make the online services work better together. A key new service is the addition of an online bill payment feature. Let's take a closer look at the stakeholders in this initiative.

Stakeholder Viewpoints

There are five key stakeholders for the online bill payment initiative: the Board of Directors, the Chief Executive Officer (CEO), the General Manager of Banking Services, the Director of Electronic Bill Presentment and Payment (EBPP), and the Supervisor of EBPP.

Board of Directors Viewpoint

There are five members of the Board of Directors for Global Bank. One member is an experienced executive within the financial services industry and the others come from other industries. Members of the board are elected by shareholders to oversee management of the company. In this capacity, the board meets every six weeks with Global Bank's executive team to review operations and make critical decisions that affect the future direction of the firm.

The board is primarily concerned with the overall assets within the bank, and how these assets are used to create wealth. They want to understand what drives the return on capital invested and what the investment risks are.

The board is very interested in understanding how current and potential customers benefit by doing business with Global Bank. They know that satisfied customers are a key ingredient for any sustainable enterprise. For clarity and operational effectiveness, Global Bank's value to customers is clearly stated in a series of value propositions, one of which is for online services.

Value Proposition for Online Services

Global Bank's value proposition for online services is to provide an integrated, online financial portal for affluent clients that will enable them to view all of their financial assets at once. From this integrated view, clients will be able to seamlessly execute all of their financial transactions including those associated with savings and checking accounts, loans, stock trading, domestic and international bill payment and funds transfer. Clients will use this portal to save their most precious commodity: time. Through efficient operations, the bank will be able to offer this capability to clients without irritating service fees for each transaction.

In addition to serving affluent clients, the bank will also serve mass market customers with simplified services such as checking, savings, and mortgage origination. Customers will benefit from the intuitive user experience and integration with home mortgage loans and credit cards.

Providing this integrated service to customers will allow the bank to provide a higher rate of return on assets than other banks. Focusing on high-net-worth individuals means that the bank can manage more assets with fewer transactions. Fewer transactions result in lower total operations cost. Providing an integrated portal to customers enables effective cross selling from low margin service offerings (such as savings accounts) to high margin service offerings (such as loan and portfolio management services).

A compelling online user experience will drive adoption and attract new customers, including high-net-worth individuals and lower income, mass market accounts. Although the mass market accounts are less profitable, they will more than cover costs; the higher margins, however, will come from the wealthy individual segment. After the user experience is developed for high-end customers, it will be easy to offer a reduced-service version for the mass market.

Capital Expenditure

Delivering on this value proposition requires significant capital investment in new capabilities. In the past, technology investments have represented a high percentage of the bank's capital expenses. The Board also considers technology investments to be somewhat risky, due to the difficulty in predicting cost and schedule for both custom software development and system integration projects.

The Board wants better visibility into these projects at a high level. Recently, the Chief Technical Officer (CTO) briefed the board on a major project and visually presented a set of decision points related to the proposed technical architecture. The decisions points he presented (shown later in this chapter in Figure 16) reflected a set of choices containing proven design elements assembled together in a cohesive set. These elements were considered proven because they were harvested from other software engineering projects and had withstood scrutiny from the software design community. Creating a design based on these elements would mitigate some of the project's risk, making it more predictable. Of course, he explained, just using these design elements (patterns) was no guarantee of success—the real success would depend on the skill and experience of the team and how they implemented the actual system.

As the CTO presented, he talked through some of the design elements such as gateways to credit bureaus and message brokers. Although the board was not particularly technical, they got a sense of how the capabilities they were investing in were realized with technology at a high level. This understanding, and the vocabulary that went with it, allowed them to ask clarifying questions about the approach without getting bogged down with lower-level details. It also helped them to see the connection between the firm's value propositions and technical investments, and they expected this alignment to occur at various levels within the organization. The primary person they held accountable for driving this alignment throughout the organization is the CEO.

Chief Executive Officer

The CEO perspective focuses on defining the strategy and formulating a strategic portfolio of initiatives to take advantage of, or defend against, the opportunities and threats in the marketplace. The CEO of Global Bank defines a strategy and a set of initiatives that reflects his firm's approach in the financial services sector—a sector that is currently experiencing significant growth.

Evaluating the Current Situation

Driven by the explosive growth in home refinancing activity and the improved margins of full-service financial institutions, the banking industry is one of the few bright spots in this slow-growth economy. The CEO of Global Bank, however, has been frustrated by his company's lackluster profit margins and anemic growth in revenues. If the bank doesn't correct these trends quickly, its shareholders may miss out on the impressive returns of the rest of the industry.

Global Bank has been suffering from the growth in customer churn, which is defined as the loss of old customers and the acquisition of new customers where the net change in number of customers is close to zero. Customer churn has raised the bank's customer acquisition cost by 3 percent, which is a substantial increase. The loss in customers is believed to be caused by the lack of awareness and the inconvenient access to the firm's full suite of services offerings. Especially troubling is the loss of high-net-worth individuals. Many studies show that this particular market segment is the most likely to use fully integrated financial services; this segment also creates, on average, a 6 percent higher rate of profitability than other market segments.

Figure 1 correlates the bank's current portfolio allocation against average growth and profitability rates for the industry.

Figure 1. Initial allocation of Global Bank portfolio, according to service type

The bubbles in Figure 1 represent the share of the bank's portfolio. Current portfolio allocation shows that more than two-thirds of the bank's portfolio is invested into savings, the lowest-growth and lowest-profit of all service offerings based on current industry average growth and returns. Only 20 percent of the bank's portfolio is allocated to consumer lending, which is a high growth/high profit category. Table 1 shows the specific numbers associated with Figure 1.

Table 1: Global Bank Portfolio Compared to Average Profitability and Growth Rates for the Industry Segment

Services	Average profitability for the industry segment	Average growth rate for the industry	Share of Global Bank portfolio
Savings	1%	2%	40%
Commercial lending	3%	8%	20%
Consumer lending	4%	12%	20%
Brokerage	7%	3%	10%
Financial planning	9%	7%	10%

Formulating a Strategy

The CEO wants to change the bank's portfolio mix so that a higher percentage of the portfolio is in high growth and high profit categories. Specifically, the CEO believes that the bank could increase deposits, reduce churn, and dramatically increase loan origination by offering an integrated savings, checking, and mortgage solution.

There are four critical success factors for this initiative:

• Make the bank's complete suite of services easily accessible, both online and offline.
• Make the online services work better together to provide a richer, more integrated experience between offerings.
• Build awareness of the suite of services, both online and offline.
• Attract and retain high-net-worth individuals.

The CEO believes that the first two measures could reduce churn costs by 2 percent and increase loan origination to 40 percent of their business portfolio. The multiple entry points and the exposure of the bank's services to a wider array of customers will help drive the growth in these segments of the portfolio. Based on estimated customer value and acquisition costs, he projects that focusing on attracting and retaining high-net-worth individuals will affect profit margins by as much as 10 percent.

The overall strategy will be to bundle higher-profit services such as consumer lending (also known as mortgage) together with the basics (savings) to change the portfolio mix to things that are more profitable industry wide. By doing so, the CEO believes that he can increase customer loyalty and increase the cost the customer would incur to switch banks (switching costs). He also believes this integrated approach has the potential to increase the very profitable financial planning offering to 20 percent of the bank's portfolio. Figure 2 shows the CEO's projected portfolio allocation after the successful execution of these key initiatives.

Figure 2. Projected allocation of Global Bank portfolio, after convergence

Table 2 compares Global Bank's projected portfolio to average industry segment growth rates and profitability after the successful execution of the consolidation initiative.

Table 2: Global Bank Projected Portfolio Compared to Average Profitability and Growth Rates for the Industry Segment

Services	Average profitability for the industry segment	Average growth rate for the industry	Share of Global Bank portfolio
Savings	1%	2%	10%
Commercial lending	3%	8%	20%
Consumer lending	4%	12%	40%
Brokerage	7%	3%	10%
Financial planning	9%	7%	20%

The CEO realizes that the firm needs to bundle together services that may never have been previously integrated. Given his convergence strategy, he also knows that the firm must aggressively and quickly acquire new capabilities. He expects to pursue partnering agreements, mergers, and acquisitions as soon as possible, but knows from past experience how challenging the integration issues could be. He is also aware of high-level service-oriented-architecture concepts that he's learned from his CTO and wonders if they might be applicable here. If so, they may have an impact on the execution of his strategy.

To move forward with this initiative, the CEO calls a two-day working session with bank executives who report directly to him. The session includes both general and administrative executive leadership. The CEO knows that this initiative requires significant capital investment and that the organization must focus on delivering as much customer value as possible for each dollar invested. To start, he will work with the General Manager of Banking to shape a more detailed customer value proposition.

General Manager of Banking

During the working session, the CEO briefs the service-line general managers, including the General Manager (GM) of Banking about his plan for dealing with convergence. To act on this plan, two teams are formed: banking services and financial planning services. The teams are organized as follows:

• Bankingservices. The GM of Banking will lead a team to create a service bundle that will integrate checking, savings, bill payment, and mortgage loan origination.
• Financial planningservices. The GM of Financial Planning Services will lead a team to focus on creating a service bundle that will integrate financial planning, non-mortgage lending, investing, and insurance.

Other executives, including the CTO, and the Chief Financial Officer (CFO), are expected to support and report into each team. Each team is expected to find areas of synergy between service lines to enable cross-selling convenience and compatibility. The teams must also identify and support all real competitive differentiators.

The rest of the Global Bank scenario described here and earlier in Chapter 2, "Using Patterns to Design the Baseline Architecture," focuses on the effort to create the banking services bundle.

Banking Services Bundle

The GM for Banking Services is excited about the prospect of offering a more robust set of services to the general public. She believes the direct impact of the integrated service bundle will be a doubling of the consumer loan portfolio.

Zeroing in on the changes she wants to affect, the GM creates two visual models to communicate with her team. Figure 3 shows the current "as-is" situation with 40 percent of the firm's service offerings in savings, which is a low growth and low profit category.

Figure 3. Current portfolio allocation of services in the banking services bundle

Figure 4 shows the desired "to-be" situation after changes have been implemented. Notice that the portfolio has shifted, moving the majority of the service offerings to high growth and high profit categories.

Figure 4. Projected portfolio allocation of services in the banking services bundle, after changes

The GM believes that the critical success factor to attracting and retaining new customers rests chiefly on the success of their bill payment service. Studies show that as customers successfully use online bill payment (which is the next logical service after online savings and checking services) they are much more likely to explore and use additional value-added services. From there, the GM believes that customers will naturally turn to Global Bank for loans.

The GM knows she must collaborate with two key members of the team. First, she must work with the CTO to smoothly integrate the value-added services with online bill payment. Next, she knows the online bill payment feature would require high level involvement of the electronic bill presentment and payment department. She would need to work closely with the director of that department.

Director of Electronic Bill Presentment and Payment

The Director of Electronic Bill Presentment and Payment (EBPP) is very excited about the prospect of the bank investing strongly in his area. Currently, only 3 percent of the bank's customers use online banking services. He believes that with a similar look and feel to the checking and savings offering, the online bill payment service will help increase the use of the online banking services to over 20 percent of the bank's customers.

To reach this 20 percent usage target, the director has identified the following requirements that are critical to the success of the system:

• Similar user experience to the current checking and savings site. More specifically, the number of key strokes required to complete a bill payment transaction must be less than or equal to the number required to complete a checking and savings transaction.
• The time required to add a new payee to the system must be minimized. The time needed to add payees (known as billers) to the system was expected to be a key barrier to adoption. Making this experience quick and painless would make the service very compelling for customers to use.
• Bill payment must be prominent on the Global Bank portal page. The bill payment service must be in an inviting and logical location on the portal main page (in relation to the checking and savings page).

To achieve these requirements, he would have to collaborate closely with the architects, designers, and analysts from the CTO's team. He would also have to work closely with the supervisor of electronic bill presentment and payment operations. Behind the user interface, it is the supervisor who has detailed knowledge of the processes and systems needed to make this system operational.

Electronic Bill Presentment and Payment Supervisor

The Supervisor of Electronic Bill Presentment and Payment Operations has just learned of the new strategic focus on EBPP as a key capability in the overall bank strategy and he is a bit concerned. The EBPP capability must be enhanced in several ways to meet the bank's growth objectives.

The focus of the Director of EBPP is primarily on the user experience and how the presentation and navigation of the EBPP functions should be similar to the existing checking and savings functionality. The main underlying issue for EBPP operations, however, is how to integrate the existing systems to provide a seamless experience without tightly coupling all of the systems together. In the past, the Supervisor of EBPP has been frustrated by systems that could not be replaced or changed because of tight interdependencies between systems. He wants to avoid that frustration in the future.

To meet its objective, the EBPP implementation must also streamline the addition of new billers and simplify the integration and processing for existing billers. This simplification will help control the operations costs of the EBPP system. One of the supervisor's goals is to automate the entire EBPP process, including the subscription management of EBPP users. The current manual subscription management process can take as long as 30 days to enroll a new EBPP participant. The manager considers this 30-day process to be a loss in revenue, as well as a barrier to adoption.

From Business Scenario to Technical Solution

The technical team at Global Bank now has enough business context to start their technical planning sessions. Now they need a way to organize their thinking about the overall enterprise. Although there are many valid models that they could use, the team started with an enterprise architecture stack as shown in Figure 5.

Figure 5. Enterprise architecture stack used by the Global Bank technical team

At the top of the stack is the business architecture, which captures the resources, processes, goals, and rules that the enterprise uses to generate revenue and profit. Underneath the business architecture are several levels of technical architecture that together enable the enterprise to realize its business architecture.

After business architecture, the next level on the stack is the integration architecture. This architecture describes an integrated portfolio of applications that support the business architecture. Underneath the integration architecture is the application architecture. For each application described in the integration architecture, there is a detailed description of the application in the application architecture. This includes (but is not limited to) platform infrastructure components such as application servers, Web servers, and databases.

After an instance of an application is built, it must be deployed into production, operated, and maintained. These concerns are described in the operational architecture. Finally, the development architecture describes how teams build instances of applications and integrations. This development level includes (but is not limited to) developer and lifecycle tools, build environments, and processes.

As teams make decisions within each level of architecture, they should verify whether they directly support the enterprise's value proposition. To make very detailed decisions about architecture, it is helpful to have a more granular perspective than architectural levels provide—such as a perspective based on viewpoints.

Viewpoints Within the Enterprise Architecture

Although the enterprise architecture stack in Figure 5 is useful to organize and classify initial architectural concerns, the team needed a more granular classification scheme. The team realized that the artifacts they produced to describe their systems would differ according to discrete viewpoints. A viewpoint is really just a lens into the enterprise, and from the perspective of these lenses, many snapshots, or pictures might be taken. They decided to organize these viewpoints from the perspective of various roles within the enterprise. Figure 6 shows three layers of the resulting model, which added some of the roles identified for the business, integration, and application architecture levels.

Figure 6. Levels and viewpoints within the architecture stack

Figure 6 concentrates on the three layers of the architecture stack that are the focus of this guide. The business architecture includes the views of key stakeholders as well those involved with business processes. The focus on process is important, because processes are key interfaces between people and systems. Processes also enable the enterprise to complete the work from which it derives revenue.

In the areas of application and integration, viewpoints are organized according to traditional information technology roles. These viewpoints reflect the different concerns of various roles. For example, as a team builds an application an architect's concerns will be different from a developer's concerns.

Now that the team had a model with which to organize their approach, they built more detailed visual models that captured their stakeholder concerns.

Business Architecture Views

To model the business architecture views, they used the Erikkson/Penker Business Extensions to the Unified Modeling Language (UML) [Erikkson2000]. These extensions to the UML provide stereotypes for business concepts such as processes, events, resources (including people), goals, and rules.

To draw these models, they used the Microsoft Office Visio® Professional 2003 drawing and diagramming software as their tool of choice. They used a template created by Pavel Hruby (available at http://softwarestencils.com/) that contains more of the UML stereotypes than the standard Visio templates. Using these tools, the team created a series of views of enterprise processes.

CEO's View

The first model they created was the highest-level enterprise view, which reflected the CEO's viewpoint. Figure 7 shows this CEO view of the business architecture.

Figure 7. CEO's view of the high-level enterprise processes

In Figure 7, resources on the left are inputs into the bank. The elements on the top guide and constrain the activities of the bank, while the center contains groups of processes needed to run the bank. Beneath the Global Bank box are the entities with which the bank collaborates. The bank's output is modeled on the right.

Notice the core process groups within the bank include basic banking, insuring, lending, investing, and sales, general, and administrative (SGA). The processes of interest to the online bank initiative are in the basic banking group, headed by the General Manager of Banking. Let's now look into this group (shown in gray) in more detail.

General Manager's View

For the basic banking group of processes, the team created a model that describes the bank from the GM of Banking's view, as shown in Figure 8.

Figure 8. General Manager of Banking's high-level view of processes

Similar to the CEO's view, this view shows resource inputs on the left, guidelines and constraints on the top, outputs on the right, and entities (collaborators) on the bottom. Notice that basic banking includes both consumer (foreground) and commercial (background). Within consumer, there are processes related to consumer banking and consumer lending. Consumer Banking is highlighted in Figure 8 because the online application is oriented towards consumers. Figure 9 narrows the focus further to EBPP.

Figure 9. General Manager's view of Consumer Banking

Similar to the basic banking model, this view shows resource inputs on the left, guidelines and constraints on the top, outputs on the right, and entities (collaborators) on the bottom. Notice that there are six groups of processes within consumer banking: payment processing, account management, electronic funds transfer, electronic bill presentment and payment, cash management and card services. Because the online application involves electronic bill presentment and payment (shown in gray), this group of processes requires a closer examination. The individual responsible for this area is the Director of Electronic Bill Presentment and Payment.

Process Owner's View

The technical team is very interested in the business processes within the enterprise because they are key inputs into technical design. The team uses the role of process owner to indicate the individual directly responsible for the successful execution of a specific process within any given enterprise. With respect to electronic bill presentment and payment (EBPP) within Global Bank, this individual is the Director of Electronic Bill Presentment and Payment. The model representing this view is shown in Figure 10.

Figure 10. Director of EBPP's view of high-level processes

The Director of EBPP's view further refines the higher level process diagrams showing the subprocesses that the Director of Electronic Bill Presentment and Payment (EBPP) is responsible for. Like previous diagrams, this view shows resource inputs on the left, guidelines and constraints on the top, outputs on the right, and entities (collaborators) on the bottom.

This view provides a way to tie the specific unit's mission, vision, guiding principles, resources, and goals to the specific processes in the department. This linkage allows both the business owner and the technical architects to evaluate specific cost-benefit tradeoffs for the design and implementation based on the business value and goals while maintaining traceability to the organizational guidelines and goals.

This view is helpful because it breaks down processes to granular subprocesses, and approaches the level needed for detailed technical analysis. However, subprocesses are not granular enough. The team needs to identify the level at which a person or system (actor) interacts directly with another system. This actor/system boundary is the level which use cases describe, and the person who interacts directly with the system to perform part or all of a business process is called a process worker. One important process worker in Global Bank is the EBPP Supervisor.

Process Worker's View

The EBPP Supervisor works with his team to review the Director of EBPP's view (shown in Figure 10) and identify all of the related use cases as shown in Figure 11. For each use case, a description is created that includes preconditions, post-conditions and the steps involved in the use case. Steps are included for normal and exception scenarios.

Figure 11. Significant EBPP use cases

The use cases outlined in gray are key parts of the online bill payment application. To further define these use cases, the team creates activity diagrams that show the details needed to realize the use case, such as conditional branching, transitions, forks, and joins.

Integration Architecture Views

Although architects were involved in understanding and modeling the previous views, more analysis is needed before the team can design a technical solution that meets the needs of the bank. Before the team spends time designing a technical solution, they want to make sure that the business processes that they want to automate will add as much value as possible to the enterprise. To determine this value, the architects work with business analysts to examine the business processes in more detail.

Process Value Analysis

Before rushing into defining requirements for the technical solution, the team wants to make sure that the processes they are automating are aligned with the enterprise's overall value proposition. To do so, they analyze each significant use case and business process according to the value it adds to the enterprise. To quantify value, they estimate the number of full-time employees and the cycle time needed for each step of the most important processes. They categorize each step as a value-add for the customer, a value-add for the business, or not a value-add.

The team tunes their processes to be as efficient as possible given the enterprise's value proposition. Working with the executive team where necessary, they are able to improve the firm's overall business process design and thereby avoid automating inefficient processes with technology. Also, during this analysis process they identify use cases that greatly enable the customer value proposition yet are inexpensive to implement. These items become high priority work items in early iterations. After they create a set of prioritized and well-designed processes expressed as use cases, they consider how to realize these use cases. A key step in the realization of these use cases is to identify the appropriate logical services.

Logical Services

The team reviews the EBPP process groups and identifies use cases for each process group. They step through each use case and design a collaboration of services that allows them to realize each use case. As they see multiple use cases using a particular service, they factor the service interface to make it as flat and stable as possible. They know that once they create these published interfaces, they will be much more difficult to change in the future. Therefore, time spent factoring these interfaces now will pay off with fewer versioning headaches later and allow them to support more use cases with each service. To communicate these relationships, they create the assembly line drawing in Figure 12.

Figure 12. Assembly line drawing showing a candidate set of logical services for Global Bank

At the top of the assembly line diagram are the groups of processes within EBPP and their associated use cases. On the left side of the diagram are candidate logical services that will play a role in realizing the intersecting use cases. By identifying sets of use cases that must interact with a specific service, it is easier to design services that eliminate duplication and are more extensible.

With a set of prioritized use cases and an initial set of logical services needed to realize those use cases, the team then spends time deciding how to allocate these logical services to physical servers.

Technical Architecture

To allocate logical services to physical servers, the team starts by reviewing the enterprise's existing technical architecture. They want to use these existing investments as much as possible, and extend them to take advantage of commercial infrastructure platform components such as Web servers, databases, and integration servers.

Taking all of these factors and constraints into consideration, they arrive at a technical architecture as shown in Figure 13.

Figure 13. Global Bank's initial technical architecture

Given the system use cases and a first cut technical architecture, the team is able to identify some areas that represent high technical risks for the project. They want to make sure and tackle these areas first so they can "retire" these risks early in the project life cycle. To exercise these areas, they identify a set of architecturally significant use cases.

Architecturally Significant Use Cases

As described in Chapter 2, "Using Patterns to Design the Baseline Architecture," the architecturally significant use cases for Global Bank include the following:

• Schedule Payments
• View Scheduled Payments
• Execute Scheduled Payment
• Receive Payment Response
• Add Payee

For each one of these use cases, the team identifies how a set of server processes and nodes collaborate to realize each use case. They capture this high-level interaction with collaboration diagrams. In addition to collaboration diagrams, the team also creates a "port and wire" style model that shows service encapsulation and communication through ports, as shown in Chapter 2.

With high-level collaborations defined for server processes and nodes, the team needs to refine these collaborations down to more detailed design elements.

Integration Patterns

At this point, the team has a set of use cases that describe how users will interact with the system and how the system will respond. These use cases are prioritized so they represent the riskiest part of the technical implementation. Now the team has to consider various design alternatives and make a series of technical decisions and tradeoffs to design an integration architecture.

As the team considers the technical challenges and problems they must solve during the design process, their discussion naturally leads to patterns. Patterns contain concise, reusable elements of design knowledge and are organized as problem-solution pairs. The team uses patterns because they know reusable design elements can mitigate risk and make a project more predictable.

To think about their design alternatives for a given challenge, the team uses the visual model shown in Figure 14. This model shows a related set of patterns in the area of integration. These patterns are represented in the model as circles; the lines between circles indicate associations between the patterns.

Figure 14. Integration patterns and their relationships

Row one (1) in the model shows patterns that represent three types of integrating layers:, , and (for more information, see Chapter 3, "Integrating Layer"). As in many other areas of computer science, adding another level of indirection solves many problems in the integration space. These patterns describe specific integration problems and how the introduction of very specific new layers would solve these kinds of problems.

For each of these integrating layers to work, they must make one or more individual connections to target systems. Row two (2) in the model shows three logical levels at which these system connections could be made: data, functional (business logic), and presentation; each logical connection type represents a pattern. For and, there are several pattern variations that further refine each pattern. These refinement relationships are shown as triangles.

Integrating at the logical data level, for example, has three variations: Shared Database, Maintain Data Copies, and File Transfer. Integrating at the functional (business logic) layer has three other distinct variations: Distributed Object Integration, Message-Oriented-Middleware Integration and. These patterns are discussed in more depth in Chapter 4, "System Connections."

As you decide about integrating layers and the various kinds of system connections you will need to make, you inherently must also determine a topology with which to connect these elements. Row three (3) in Figure 14 shows patterns (and their variations) that represent three different integration topologies: Point-To-Point Connection, , and. Any time two or more systems are connected, a topology decision must be made. The result may be a single topology or a combination of topologies depending upon requirements.

After systems are connected using a particular topology, it is possible to use a publish/subscribe mechanism to synchronize systems. The pattern is shown at the bottom of Figure 14, along with three patterns that refine the basic Publish/Subscribe pattern: List-Based Publish/Subscribe, Broadcast-Based Publish/Subscribe, and Content-Based Publish/Subscribe. Chapter 5, "Integration Topologies," discusses these patterns in detail.

Pattern Types

Until now, this chapter has discussed patterns conversationally as is often done during typical whiteboard design sessions. To be a bit more precise about how the team uses patterns to explain their application, it is necessary to make a distinction between pattern types and pattern instances.

In object-oriented programming, the common example of type and instance is class and object. That is, a class defines a type of abstraction and an object is an instance of that abstraction. Because design patterns have been associated traditionally with objects, the distinction has not been important for patterns. For example, the Singleton [Gamma95] pattern contains advice that tells you how to create a singleton object.

In the integration space, patterns often provide advice that is much broader than classes and objects. To apply these patterns, it is helpful to clarify when you are talking about types and when you are talking about instances. Unlike typical design patterns, these pattern instances occur at several levels of abstraction, including objects, processes, and subsystems. Think of the pattern narrative as providing information about a type of compositional design element. When you choose to include some finite number of these compositional design elements in your specific design, think of these as instances.

Note   Because patterns contain a wide variety of design knowledge, not all patterns are about compositional elements of design. Thus the type/instance distinction will not apply to all patterns. Other authors have referred to similar categories of patterns as constructional design patterns [Yacoub04]. All patterns contained in this guide, however, are compositional elements of design.

Taken together, Figure 14 shows the patterns and their relationships as pattern types used in the integration space. These are types of patterns because they contain advice about a particular kind of integration problem. For this kind of problem, the patterns contain generative advice that tells you what to do, along with the pros and cons associated with following that advice.

For example, as the Global Bank team discusses their particular design problems, they know they need a portal integration layer that connects with multiple back-end systems. For each target system, they need an individual system connection. As they consider which type of connection they will use, they use the model in Figure 14 to narrow their choices down to three possibilities for where to make the connection: at the logical data layer, at the functional layer, or at the presentation layer. The team prefers to integrate directly to the functional layer whenever possible to present the most up-to-date information as directly as possible.

As they consider the types of Functional Integration they might use, they evaluate as alternatives Distributed Object Integration, proprietary Message-Oriented Middleware Integration, and Service-Oriented Integration. Because interoperability between platforms is important to them, they prefer to use Service-Oriented Integration whenever practical.

After deciding on the type of system connection to use for each system, they realize that they need a topology with which to connect these elements. A set of Point-to-Point Connections is the simplest to consider initially, but upon further reflection they realize they will have to connect with an unreliably connected data center and external trading partners. These different locations will use different systems and different data formats.

They could implement a Message Bus, but that would require defining a canonical data model and command messages between trading partners and acquired banks. This seems an unwieldy alternative when compared to a approach.

In the end, they decide on a Message Broker topology and a Publish/Subscribe mechanism. The specific Publish/Subscribe mechanism they use is Content-Based Publish/Subscribe. All of these choices are shown in Figure 15.

Figure 15. Types of patterns chosen by the Global Bank team

During the design sessions, the team uses the model in Figure 15 to help them think through the range of potential design alternatives that might apply to a particular design challenge that they are experiencing at the time. However, during the process of designing the architecture for Global Bank, they need more than design options. They need to make a set of specific design decisions that reflect instances of design elements.

Patterns Instances

Now that the team has identified the types of patterns that apply to their design, they need to decide which (and how many) specific instances of these patterns they will actually use. For example, the team decides that the pattern (from Chapter 5) is a good choice for Global Bank because it solves the problems involved in integrating applications that do not have a common interface. The Message Broker pattern narrative describes how to solve this particular type of problem, but it does not specify if or where to place it in a specific design. These kinds of decisions are the responsibility of the Global Bank architecture team.

After careful consideration, the team decides to use two instances of Message Broker in their design; both instances are implemented with BizTalk Server 2004. One Message Broker instance integrates applications between their local and remote data centers for loan applications. The other Message Broker instance integrates applications between their payment system and external payment gateways.

These two Message Broker instances are shown in Figure 16 along with all of the other instances of design elements that the team identifies for their integration architecture. This pattern-based design model shows the architecture at a higher level of abstraction than conventional models. With each design element representing a named pattern, this model provides a rich set of abstractions and a vocabulary with which the team can reason about their system. It also allows them to have a high-level design dialog with other project stakeholders, without debating extraneous technical detail. Should these other stakeholders not understand a particular element, the team can point them to pattern catalogs that define these terms in more detail.

Figure 16. Pattern-based design model of the Global Bank bill payment system

With an initial set of high-level design decisions made, the team then needs to bind these decisions to specific implementation platforms. Although this binding may seem to be a top-down approach, it is actually an iterative process that requires full team involvement. For key design elements, platform infrastructure components are evaluated in terms of how well specific patterns can be implemented. Although this mapping from high-level design to technology often is quite straightforward, it is often not. Difficult cases require the team to either change their design to optimize a particular platform or choose an alternative platform that better fits their architecture. When the team is finished, they produce the diagram shown in Figure 17.

Figure 17. Mapping the patterns to implementation technologies

Figure 17 shows Global Bank's integration architecture to be composed of numerous pattern-based design elements implemented on the Microsoft platform. To trace the implementation of these elements down to running bits, refer to the appropriate implementation pattern in previous chapters. For example, to understand how to implement the gateway to the mainframe, refer to in Chapter 5, "Integration Topologies." This pattern includes the details of connecting Global Bank's .NET Framework–based portal application with their existing COBOL-based CICS transactions.

Going Forward

The last few pages of this chapter focused on distinctions between pattern types and instances that may not be important for many design conversations. In conversations that require a precise distinction, it is helpful to clarify how you are using patterns. In these cases, using a pattern type model to enumerate design options and a pattern instance model to articulate specific design elements can be a very effective communication tool. Even if you are not interested in types and instances, however, patterns are a useful vehicle for communication among different levels of the enterprise.

This communication aspect of patterns is the main message of this chapter. The progression of pattern models discussed here will become increasingly important in the future as developers, architects, and business leaders increasingly use patterns to build technology that meets business requirements.

Start | Previous | Next

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.