Step 3: Identifying business patterns

Looking closely at the solution overview diagram (Figure 1), you can observe the following business patterns in the solution:

• Gamers interact with the game themselves. Out of the available options, this is best represented as a Self-Service pattern. (Also known as User-to-Business, this pattern addresses the general case of internal and external users interacting with enterprise transactions and data.)
• Buyers may search and select items from the catalog and may place orders for selected items. These functions involve direct interaction between users, back-end systems, and databases (the catalog). This is indicative of a Self-Service business pattern.
• The users may use chat and e-mail to communicate with each other and with customer service representatives. This is a Collaboration business pattern. (Also known as User-to-User, this pattern addresses the interactions and collaborations between users.)
• The company accepts credit cards online from both account administration (for renewal of access to the game and from order management to pay for purchases). This could be counted as an Extended Enterprise business pattern. The usage of online credit cards is well-understood and the function is integrated into many products, but include this pattern for now and see what changes or additions it leads to. (Also known as Business-to-Business, this pattern addresses the interactions and collaborations between business processes in separate enterprises.)
• The fulfillment function is at a boundary between the organization and other organizations; in this case, most likely a shipment house such as FedEx. In some cases, the entire fulfillment function may be outsourced, perhaps using an alliance with a company such as Amazon.

Step 4: Identifying integration patterns

How will you integrate between these functions? In general, use the Access Integration pattern; in fact, this seems to be a good fit here also. This integration pattern describes those recurring designs that enable access to one or more business patterns. In particular, this pattern enables access from multiple channels (or devices) and integrates the common services required to support a consistent user interface.

Access Integration is also a good fit for the customer service personnel too, since they need to access a number of different applications in support of resolving customer issues.

Figure 2 shows the revised solution architecture diagram, including the integration patterns.

Step 5: Identifying composite patterns

Now that you have identified the integration patterns, look for composite patterns. These are common, recurring combinations of integration and business patterns.

Look at the list of patterns included in the solution overview and then check them against the patterns covered by the composite patterns. Note that several of the composite patterns seem to apply: the Electronic Commerce, the Portal, and the Account Access composite patterns all cover part of what you need.

However, the Portal pattern -- which typically aggregates multiple information sources and applications to provide single, seamless, and personalized access to users -- seems to offer the most coverage. It lists the following mandatory building blocks, all of which are in your solution overview:

• Access Integration pattern
• Self-Service pattern
• Collaboration pattern
• Information Aggregation business pattern (also known as User-to-Data, allows users to access and manipulate data that is aggregated from multiple sources)

The pattern description further underscores this belief. To quote Adams from Patterns for e-business: A Strategy for Reuse:

A portal is typically designed to aggregate multiple information sources and applications to provide uniform, seamless, and personalized access for its users. . . . 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, plus at least one other Business pattern.

This exactly describes your situation.

Figure 3 is a pictorial representation of the Portal composite pattern, taken directly from the book.

Figure 3. The Portal composite pattern is composed of the mandatory and optional patterns required for a portal

By comparison, the Electronic Commerce composite pattern notes Information Aggregation, Application Integration (which brings together multiple applications and information sources without the user directly invoking them), and Self-Service as the mandatory patterns, with the others as optional pattern variations. You already understand that Collaboration is a requirement.

Extended Enterprise is listed as an optional pattern variation for both composite patterns. You clearly need Extended Enterprise-like functions for billing, order management, and fulfillment.

The application pattern choices for the Electronic Commerce composite business pattern are either web-up (used to quickly enable a Web-based buying site without any close integration with back-end systems) or enterprise-out (extends an existing order processing system to a new Web-based buying channel and includes close integration with and reuse of existing back-end systems), depending on the existence of legacy applications. Since you are building this infrastructure from scratch, the web-up pattern is the better fit.

Keep an eye on the Electronic Commerce pattern and take a look at the Runtime pattern as you move forward, to see if you can use any implementation suggestions.