The patterns approach

Patterns are groups of reusable assets that can help speed the process of developing e-business applications. IBM, for example, classifies these reusable assets into the following elements:

• Business patterns identify the interaction between users, businesses, and data, and are used to build simple, end-to-end e-business applications.
• Integration patterns bind other business patterns together to create applications with advanced functionality.
• Composite patterns are combinations of business and integration patterns that have themselves become commonly used types of e-business applications.
• Custom designs are similar to composite patterns (as they combine business and integration patterns to form an advanced, end-to-end solution), but they have not been implemented to the extent of composite patterns; they are instead developed to solve the e-business problems of one specific company.
• Application patterns and Runtime patterns: Driven by customer requirements, these patterns describe the shape of applications and the supporting runtime needed to build the e-business application.

With architectural patterns, developers create solutions more quickly, regardless of the scale of the business.

Borrowing from the book Patterns for e-business: A Strategy for Reuse, I'll describe the steps involved in identifying and selecting the appropriate architectural pattern that best represents the functions required to solve a business problem:

• Step 1: Develop a high-level business description that illustrates the major business functions of the proposed solution.
• Step 2: Develop a solution overview diagram to translate the textual description into a pictorial representation.
• Step 3: Identify business patterns that apply to the solution from a catalog of existing patterns.
• Step 4: Identify integration patterns from the catalog. Integration patterns are commonly found, like recurring combinations of business patterns.
• Step 5: Identify composite patterns to use in identifying major collections of the business functions.
• Step 6: Identify application patterns from the catalog.
• Step 7: Summarize all the application patterns required.
• Step 8: Integrate the patterns and any packages selected into the solution.

I'll lay the groundwork next by offering a simple scenario and discussing issues involving the first six steps. (In the next article, I refocus on the game itself, talk about scale as an infrastructure issue, cover the final two steps, and discuss whether or not to build or buy, using off-the-shelf components.)

Step 1: Developing a high-level business description

Let's describe a potential interaction between a member of the target audience and the system you plan to build. Use this initial interaction for a guide as you design the architecture for the functions that the system needs to provide. Call this interaction Scenario 1: Purchase, then Play.

A potential gamer, Ken, saw an advertisement listing the Web address for your newest PC-based MMOG, HAL 2010: Universe On Demand, in the latest issue of The Hip Gamer's Magazine. He surfs to your public Web site. A banner advertises the game and offers the chance to purchase it.

Ken selects the "buy now!" button. He is asked to provide registration information: A unique user ID and password. He is then redirected to a shopping cart containing the game. Your Web site asks if he would like to add a poster of the game, a T-shirt, cap with a logo, or coffee mug to his purchase -- for an additional fee, of course. He chooses the poster. The site offers him a choice of delivery mechanisms for the game and the poster. He can choose to download them or he can have them snail-mailed (the game on CD-ROM, the poster as, well, a poster). Items with no digital option (coffee mug) and items for which he selects physical delivery are physically shipped after giving him a choice of delivery times and associated costs.

Then the Web site offers the option to browse your catalog, look through new player recommendations, or join a hosted chat session.

As part of the purchase, Ken is afforded a certain amount of free usage. Since he purchased the game from you, you have updated the directory record entry created when he registered with an indicator of the free usage he's entitled to. You can also add to his entry either the registration number of the downloaded game instance you're delivering or the registration code of the CD-ROM that you ship him.

Once Ken begins playing, you can grab information about his game play. Some information is captured in the database that maintains game persistence; other data is added into the directory that contains his profile or the game statistics database.

Your site also offers the option to open a chat session to customer service, if Ken is unable to answer his questions using the FAQ or tutorial information provided.

Once Ken has used up his initial free time, the site automatically generates an e-mail to his designated address with a link to allow him to update his subscription. With this link, he can choose between a number of supported subscription packages (such as unlimited usage per month at one price or a specific number of usage hours at a lower one-time charge). When he selects a particular package, your site presents the credit card information that he used previously, gains his approval, and immediately processes the charge.

Wow! This potential interaction seems straightforward from a user's perspective, but you can already sense that it will be non-trivial to build.

Step 2: Developing an overview of a solution

In developing an outline or overview of a potential solution, what functions are mentioned or implied from the scenario? Here's my list:

The game

It goes without saying, that the game itself is the main content -- the reason the gamer comes to your site. It is likely that you will need to integrate the game with other components; for example, to keep each person's game state intact between game sessions.

Registration

During registration, you ask the gamer to provide a unique user ID and associated password. You also ask him to provide an e-mail address to receive subscription renewals, newsletters, relevant advertising, and other information.

Directory

You need to store basic information identifying the user. This is also a convenient mechanism to store other person-specific information such as game-playing preferences or billing information.

Account administration

For any game that is not free, the gamer should be able to see how much time or money remains in his account and be able to update his account information.

Search and select

While finding access to the game is likely to be easy (in this case through a banner on the site listed in the ad), you also offer the chance to select game-related paraphernalia and to search your catalog of other products. You also mention that a player can search player recommendations; no doubt you will offer other information.

The catalog

This will contain the purchasable game, mugs, posters, T-shirts, books, maybe even telephone ring-tone versions of game sounds.

Order management

Thanks to FedEx and UPS, customers want to track their orders. Many people who purchase over the Internet expect functions such as a link to a shipping site with a delivery number.

Fulfillment

You might deliver some digital items (posters, screen savers, code) electronically. Non-digital items (T-shirts, printed posters, mugs, and CD-ROMs) require physical shipping.

Customer service

Customer service must be able to interface with almost all the functions mentioned in order to help gamers with specific problems. If the problem is with the game, the representative may need to reset the gamer's profile, adjust his account, check his order -- any number of functions. Make customer service convenient for the gamer to keep him from leaving the game in frustration -- provide a variety of access methods, including chat, e-mail, and telephone.

Chat

I mentioned chat twice in the scenario -- among members waiting to play the game and for contacting customer service. Also, you probably want to offer e-mail, although it wasn't called out in the scenario. Group these functions together under the heading "Collaboration."

Billing

This is how you make money -- no kidding. You wish to bill for the initial game purchase, for the other game-related paraphernalia, for game subscription or time played, for game subscription renewal, and for anything else you think you can!

A database of game-related information

This may include information of general interest to all players of the game: tutorials, frequently asked questions, tips from other players, and so on. Besides the catalog, this is the other target for search-and-select capabilities. You may also provide information customized for specific classes of players, such as novices or experts. Ideally, the user can specify a specific interest or a group membership and automatically see new information customized for that class of user. This implies personalization, integrated with the directory.

Oddly enough, when you look at this list, notice that the game developer is really only interested in the first item. The rest of the items are, well, boring -- non-creative heavy lifting that most game developers would rather let someone else do.

Diagramming the solution overview

You can create a solution overview diagram (as shown in Figure 1) to provide a concise representation of the key functions required for the proposed solution. All functional requirements for the base version are included here.

Figure 1. A solution overview diagram

At this point, a few major themes are already obvious.

Clearly, an online game playing infrastructure has some requirements specific to the online games marketplace, driven by the kinds of devices in use and the business models common in this industry.

Many of the other functions, however, look familiar because of their similarities to e-business infrastructures from the dot-com era. Many companies implemented these components in the last few years (Internet-based commerce, customer self-service, community-based tools). The years since the dot-com era have also given a plethora of off-the-shelf solutions time to mature into fully-tested, stable products.

In this world-view, you might regard the game as the online game industry's industry-specific business application.

From this solution overview, move to the next step in this pattern-based approach.