Developer Forums | About Us | Site Map
Search  
HOME > TUTORIALS > GETTING STARTED > SITE PLANNING TUTORIALS > CONCENTRATE ON THE GAME, PART 2


Sponsors





Useful Lists

Web Host
site hosted by netplex

Online Manuals

Concentrate on the game, Part 2
By Veronika Megler - 2004-08-26 Page:  1 2 3 4

Build, buy, or borrow?

Now that you have an overall picture of the needed functions, you're ready to decide which functions within this infrastructure to purchase off the shelf, which ones to outsource, and which ones to build in-house.

Use the runtime diagram to model and capture the buy, build, and outsource decisions on a function-by-function basis. A model such as this allows you to decide whether custom development or leveraging existing functionality is the best option.

Clearly, the game is key. Without the game, customers have no reason to join the community you're trying to form. You might develop the game yourself, commission the game from another development shop, or purchase a completed game.

Other areas, such as registration or customer service, are places you might choose to support by purchasing off-the-shelf packages from a vendor or using an outsourcing service. After all, writing your own Web-accessible commerce system has limited competitive advantage and potential additional costs.

As an example, Table 1 lists a set of IBM® and IBM Business Partner products that can provide these functions.

Table 1. Existing products that can supply the functions required in Figure 4

FunctionProducts
Registration & Login
  • IBM WebSphere® Application Server; Registration on Demand Service
Database Server
  • IBM DB2®
Directory and security services
  • IBM Directory
Collaboration
  • Lotus® Domino®
  • Lotus Sametime®
  • Lotus Quickplace®
Web Server Redirector
  • WebSphere Network Dispatcher
  • IBM HTTP Server
  • WebSphere Application Server Plug-in
  • WebSphere Application Server
Content Management
  • WebSphere Application Server
  • DB2 Content Manager
  • DB2 Universal Database (UDB)
Application Server, including Commerce App
  • WebSphere Application Server
  • WebSphere Portal
  • DB2 UDB
  • WebSphere Personalization
  • WPS Search & Indexing Portlets
Billing, Subscription
  • WebSphere Digital Media Enabler
  • WebSphere Commerce
  • WebSphere Commerce Payments
  • WC Recommendation Engine
  • WebSphere Application Server
  • DB2 UDB

Despite the number of products that apply, more work is necessary. At this level, each of these products appears to be a fit, but you still need detailed research to ensure that the products provide an implementation of these functions that sufficiently meets your needs. For example, WebSphere Commerce provides the ability to handle various kinds of subscriptions, such as a particular dollar amount, or time-based or package-based. If you want to send an e-mail to the user to remind him that his time-based subscription is about to end, this requires customization or additional development, depending on how elaborate a renewal solution you wish to provide.

In doing this detailed research, you find that while the marketing materials for some of these products do not focus on capturing the attention of the game developer, the functions provided by many of the products do; in fact, many of them turn out to be a surprisingly good fit.

And, although purchasing the products off the shelf may come with a significant monetary cost, a surprising number of utility-based or application service provider offerings are available for purchase at a per-transaction or periodic cost. This helps in two ways:

  • It eliminates the up-front cost of either purchasing- or coding-needed functionality.
  • It makes the functionality available much more quickly and with lower risk than most development projects.

Reducing capital outlay and reducing risk -- these are traditional corporate goals!

What's next?

In this article, you identified the game as the most important component of your infrastructure -- without it, customers have no reason to come to your enterprise. You applied a patterns-based perspective to help determine the shape of the game (which attributes the game demands; which patterns best answer those demands).

I outlined the reasons for applying Self-Service patterns to the game, taking you on a hunt to establish an application and a runtime pattern that meets the game's requirements. I discussed the scale of the game and detailed why the high availability/high performance Non-Functional Requirements custom patterns are a good match.

I talked about integrating the runtime patterns into a workable solution. By matching available, real-world products with runtime functions, I demonstrated that reuse can be as viable an option as building from scratch.

I also listed some required functions that are missing from this first level of structure you've built -- food for further thought.

In the next article, I'll offer a scenario that can possibly require a whole new set of functional requirements and you'll see how the first level of structure meets those requirements. You'll identify new e-commerce needs and outline how to provide an infrastructure to meet them. I'll also discuss the requirements needed to efficiently access and connect to the various devices your gamers will use to play the game.

On with the game!



View Concentrate on the game, Part 2 Discussion

Page:  1 2 3 4 Next Page: Resources

First published by IBM developerWorks


Copyright 2004-2024 GrindingGears.com. All rights reserved.
Article copyright and all rights retained by the author.