like and creating a roadmap. It is critical for software architects to be part of this long-term planning. Architects have a "seat at the table" precisely because they help define what can be done, how seemingly unlike requirements can be combined, and how the product will need to evolve over time. Participating in scenario planning for the product is a great way of understanding likely changes that could emerge later.
Consider a traditional roadmap that shows how the product will be enhanced and evolved over time. It identifies the handful of features which product management believes will "move the revenue needle" as well as the broader set of features and benefits that the business desires. Significant market data and delivery timeframes (as called out by the business unit) are shared with stakeholdersin the product.
Our experience is that the roadmapping process is much more powerful and has more actionable results when the Architects (software, hardware, and support) are part of the roadmapping team led by Product Marketing and Management. They are able to identify key Tarchitectural changes up front, and when those changes will be needed to meet specific goals and delivery dates. Having this information at the earliest planning stage (i.e., during strategic planning) and not just when moving items from backlog into development, dramatically improves the product itself by allowing stakeholders to anticipate changes and incorporate key design improvements that may otherwise be overlooked or that are not developed due to time constraints of finding out about architectural issues so late in the design and build process. This is not to say that architect/product management teams will identify every detail of Tarchitectural change, but that good analysis and planning can provide a competitive edge.
Let us take a theoretical example and show it graphically (see Figure 1).
This simplified roadmap shows the plan for a "small office upgrade" to an existing offering. The target delivery is in Q1 of 2009. A key benefit of this offering is that the vendor can run it as a managed service, simplifying sales and deployment for customers. Since we are including the Tarchitecture group (architects and product managers) early in the planning process, they have identified "managed service" as a component that must be completed before product launch, in Q4 2008. More specifically, a move to a LINUX platform is a key technical requirement for this service element, and must be finished in Q3 of 2008 to keep on schedule. Using this roadmap, the team can then determine if delivery dates are possible (and at what staffing levels) in order to meet the business objectives. Excluding architects from this early discussion will typically mean the roadmap needs to be reworked several times or will be incorrect in its delivery date predictions, since it lacks critical input from key technologists.
This approach may also enable smarter architectural choices. Since the architects can see ahead four to eight quarters, they can anticipate some of the "surprises" which used to pop up - and design accordingly. A typical example would be the need to significantly change an underlying database's design structure, something that without architectural input may not be apparent until development begins. They can also spot technology-based opportunities that naturally fall out of their designs. In this case, for instance, they might see opportunities across projects ("there's another group building web services tools that we could use...") , for hardware platform savings ("since we're migrating to LINUX, we could virtualize some old systems and reduce overhead..."), business models ("we could easily include try-and-buy downloads, which you were