Applying The Patterns

Figure B-1 captures the relationship between the patterns as they are applied. The order shown is one that has worked for me. Like most diagrams that suggest an ordering, the figure fails to show the dynamic way these maps were built. In most cases, I recommend starting with a Market Map, primarily because there is so much confusion among product development teams regarding the target market. However, if you're working in a mature market, or if your marketing communication department already has a precise calendar, you may find that starting with the market events and market rhythms pattern is the best way to begin.

Figure B-1. Applying the pattern


The most important point is that instead of arguing which pattern should be first, you should simply pick one to get started. This is because the patterns are part of a system. Like all complex systems, this one is characterized by feedback loops , shown as a dotted line in the figure. It is almost guaranteed that the application of any given pattern will slightly modify the earlier application of another one. Instead of focusing your efforts on making a "single" diagram correct, try starting by identifying one market segmentjust about any will doand then add some market events or features. Try to increase your comfort that the data you need to make sound decisions will emerge, provided you keep iterating over the results.

Discontinuous events, such as a competitor releasing a new version faster than expected, a new conference forming around a new industry, or the introduction or maturation of an exciting technology, are likely to motivate a series of coordinated changes in all of these diagrams. For example, in applications that rely on voice technology, the maturation of Voice XML or SALT first captured on the tarchitecture map may cause upward ripples in all of the other maps. You might be able to reach a new market with an awareness of these new technologies, or you might be able to provide some "killer feature" by adding new support for these standards.

Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
ISBN: 201775948
Year: 2005
Pages: 202 © 2008-2017.
If you may any questions please contact us: