The Tarchitecture Roadmap
You are building an application expected to have multiple, ongoing product releases. You have a Market Map and a Feature/Benefit Map to identify specific markets and the features/benefits that they want. You may have an existing architecture that supports one or more markets.
How do you manage/leverage technological change?
Create a technology map that shows how your architecture will evolve . It should relate to the market map and feature/benefit map by showing how specific technologies produce benefits that are desired by key market segments.
Review this map whenever important milestones are realized and no less than once every six months. Examples of important internal milestones include code freeze, product shipment, and when 50% of current customers have upgraded to the most recent version. Examples of important external milestones can be a competitor issuing a new product release, new patent discoveries, whenever a member of the technical staff identifies a significant discontinuous technology, or whenever market events occur.
The creation and management of the tarchitecture roadmap requires that at least one member of the team scan the external environment for new developments in the field.
If marketing has identified a feature that cannot be supported by existing technologies (either directly or because of performance/cost curves) the tarchitecture roadmap can help the team maintain focus by periodically scanning the environment to see if any new technologies have emerged that meet this need.
The good news is that you will identify promising technical futures for your product. The bad news is that unless your team has sufficient discipline they will want to explore every possible futurethe dreaded "shiny new object" syndrome.