Projecting the Future

If the marketect and the tarchitect pursue different visions of a future, the total system will fail. You can minimize this risk through a variety of simple diagrams that capture how you want to create your future. I will refer to these diagrams as "maps," even though they do not map what currently exists but what you want to create. These maps are reviewed briefly here and presented in greater detail as patterns in Appendix B.

The first map is the market map. It shows the target markets you've identified and the order in which you will create offers for them. (An offering is a bundle of one or more products or services). To make certain you can properly compete for these markets it is helpful to create a feature/benefits map, which shows the key features required for each identified market segment and their associated benefits. Variants of these maps are common in product development organizations. A market events and rhythms map helps to ensure that the timing of your product releases matches the market timing. Maintained by the marketect, but open to sharing and upgrades by all, these maps are key communication vehicles for the marketecture.

The tarchitecture map is the necessary equivalent of the market- related maps. It shows the natural evolution of the tarchitecture in service to the market segments, features, and benefits identified by the marketing team. Essential features that may not be supportable within the existing tarchitecture must be noted as discontinuities so that the changes needed to resolve them can be managed. Alternative, emerging technologies that hold promise for substantially improving the product and/or for opening a new market are shown so that marketects can prepare for these futures .

Examples of discontinuities abound. Consider an application originally designed for a single language. If this language becomes successful, the marketect may include internationalization in her map, but the corresponding entry in the tarchitecture map is often a major discontinuity, especially if the team is not experienced in building such applications. Another example is new business models envisioned by the marketecture. It is doubtful that the original tarchitecture was planned with them in mind, so they should be noted as tarchitectural discontinuities. In a similar vein, known problems with the tarchitecture that grate against developer sensibilities should be identified so that they can be addressed in future revisions.

Although teams can improve their performance by creating any of these maps, the best results are obtained when all are created so that they work together, as shown in Appendix B.