Context Diagrams and Target Products

Context diagrams are a great tool for keeping the marketect and the tarchitect in step. A context diagram shows your system in context with other systems or objects with which it interacts . It typically shows your system as a "single box" and other systems/objects as boxes or stylized icons, with interactions between systems shown using any number of notations. Avoid formal notations in context diagrams and instead focus on simple descriptions that capture the important aspects of the relationships between the items contained within the context diagram. Context diagrams are not a formal picture of the architecture but a "higher level" shot that shows the system in the context of its normal use.

Context diagrams are useful for a number of reasons.

• They identify the technologies your customers use so that you can make certain you're creating something that "works" for their environment. This can range from making certain you're delivering your application using a platform that makes the most sense to ensuring that the right standards are used to promote interoperability among various components .

• They identify potential partnerships and market synergies. One of the most important applications of the whole-product concept is identifying partnerships that create a compelling augmented product and defining a map to a potential product.

• They clarify your value proposition. Clearly understanding your value proposition is the foundation of a winning business model.

• They identify the integration and extension options you need to support in the underlying architecture. A good context diagram will help you determine if you need to provide integration and/or extension capabilities at the database, logic, or even user interface levels of your application. They are a guide to the design of useful integration and extension approaches. (See Chapter 8 for more details.)

• They help you understand what deployment and target platform options make the most sense for your target customer. If you're selling to a target market that is generally running all other applications in house, it doesn't make sense to offer your part of the solution as an ASP. If your context diagram indicates that all of your partners use a specific technology to integrate their applications, it is probably best if you use it, too.

The marketect must take primary responsibility for the context diagram, although, of course, other members of the team can and should provide input to it. For example, the tarchitect can identify key standards, salespeople may suggest new entries based on how customers use the product, and so forth.