Making Roadmapping Work

This week we have published a new version of the roadmap article by Stephen Dougall for the ITABoK 3.0. I am very excited about the way it fits into the ITABoK. You can find the article here: https://itabok.iasaglobal.org/itabok3_0/roadmap/. We are seeking public comments on the article which will go into our repository of issues related and reviewed by authors and editors.

Note: Interested in Roadmapping? Check out our Solution Architecture Course at https://iasaglobal.org/public/Event_Display.aspx?EventKey=OLSOL0520

The ITABoK is a collection of knowledge and working practice guidance for setting up a team for success. It describes concepts used in working architecture practices and decisions teams must make together about how to apply those concepts to their own practice. The ITABoK can be used within existing frameworks such as TOGAF and FEAF even more successfully than the default implementation.  

The ITABoK article describes the highly effective and important elements of roadmapping in an architect engagement model. It is an essential tool for the success of the architecture team as it aligns internal and external deliverables across time and will help the team to connect the vision, scope, capabilities and changes across program and product level change. The goals of roadmapping are:

1.     Better Communication: Roadmapping methods help align the architect team to a shared understanding of their internal and external dependencies over time and provides and invaluable communication tool with stakeholders.

2.     Better Strategy: Much of the difficulty in strategy is understanding what priorities should come first and how those priorities relate to each other. The complexity of a product or program can be hidden in business case documents but a roadmap will help the architecture team identify strategic opportunities.

3.     Better Delivery: Many delivery teams fail because they do not understand the relationship between their services and those of other teams. These complex dependencies often lead to poor implementation decisions and ‘green field’ thinking.

Roadmapping, Value and Architecture

Strategy is a complex subject which involves many multi-functional teams. There are many schools of thought in the space and Iasa has a unique and very valuable method for architects to be both practical as well as necessary to the activity. Our structure puts architects in the driver seat of business technology strategy, with different emphasis based on assignment, team and specializations.

The roadmap should contain both KPIs and Objectives based on lean or single page business cases which allow the organization to make rational decisions about the order, priority and delivery of roadmap elements. They also allow the organization to visualize transitions which are the critical milestone areas where behavior, customer, business model, employee or operations are able to do new things. By aligning the roadmap with value the architecture team will be able to better assign their members to initiatives as well as deliver the highest value output to the enterprise.

Assignment

There are never enough architects for every product, service and capability. This makes architects a scarce resource and leads to a whole number of problems. One of the key reasons for the entire architect team (enterprise, solution, business, software, etc) to be a tightly nit group regardless of size and reporting structure is that we need to be assigned in very clear ways to ensure the priority items for the enterprise get the appropriate architecture coverage. To do that we must share a common understanding of where we are going and that requires clear communication, constant sharing and discussion (with the odd argument in there as well) to be sure the team is clear in its priorities. There is another article coming soon on architecture assignment methods but roadmaps are a distinguishing factor in that process along with prioritizing the investment portfolio.

Strategic and Product Roadmaps

There are conceptually any number of roadmaps that drive the organization. Financial, operational, etc. but we have focused on the two that drive horizontal value streams (another article as well), the strategic and the product roadmaps that involve primary investment and outcome for the organization. In addition, strategic roadmaps can be seen as an enterprise wide focus area driven from capabilities and business model whereas product roadmaps are driven from customers, feature sets and technology services (when speaking of technology driven products). There is a lot of grey area there. We have created a relationship between the two that we have seen driving value in enterprises from banking to healthcare. This relationship has deep impacts on the relationships within the engagement model including deliverables, roles, lifecycle and more. Again we are speaking here about how to setup a truly capable and specialized architecture team. Notice that our focus is first on the specialist architects (business, solution, information, software, etc) and not on titled enterprise architects. This is not to discourage the enterprise architecture role, however in the initial phases of the maturity model, it is absolutely essential that the foundation for architecture maturity rest on the delivery capabilities to stakeholder groups. I will go more into this in another article related to the Iasa enterprise architecture role.

Roadmap Tools and Repository

Two more concepts play heavy in roadmapping and that is the architect tools and repository. Note by tools Iasa does not only mean tools like LeanIX, Orbus, etc, but the cards and canvases, presentation tools, collaboration tools and more that architects use everyday. The tools article in the ITABoK will connect these concepts together.

Roadmaps must be shared and updated regularly. They need to be communicated in many different scenarios and most of them link together in complex ways, especially if using multiple types. It is essential the team does not ‘over document’ beyond its capacity to maintain (that by the way should be in the architect job performance analysis). That means very tough decisions must be made by the chief architect(s) as to what is possible to maintain in the repository and how it should be retrieved, updated and transitioned to others.

It is pretty obvious this is a deeply important topic. I hope you will take a look at the fantastic article on the ITABoK and give us as much feedback as possible. Optionally you can attend our Core and Solution Architecture courses to learn more depth about roadmapping and how to make it work for your organization.