"Show me the roadmap for XYZ domain" is among the first questions a new CIO or Executive asks their Enterprise / Business or Domain Architects. Questions like these, and a review of existing roadmaps can lead to a more detailed, engaging conversation on the baseline and assumptions driving the target state architecture. This can also be an opportunity for Architects to demonstrate their knowledge of the underlying capabilities enabled by processes, platforms and systems. The implicit understanding is that the Architects have validated and reconciled the roadmap in question with other dependent artifacts across the enterprise.
So, what are Architecture Roadmaps, and why do we need them?
The intent of Architecture roadmap is rather straightforward - to inform and address strategic questions with sufficient insights and assumptions that can guide business transformations. Architects draw on their analytical, data driven thinking along with the empirical skills, stakeholder engagement and the ability to visualize a story. This process, especially for complex landscapes can involve a lot of research, reviews and stakeholder engagements. There are dozens of different graphic templates and techniques and perspectives ranging from Transformation maps (t-Maps), Gantt-charts, portfolio views, workflow charts to other block diagrams. Architects may use a variety of such lego-blocks to define roadmaps.
As per TOGAF -
The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap highlights individual work packages' business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps.
The ‘What’ and ‘Why’ of roadmap definition are rather well understood by Enterprise Architects, and a lot of references and body of knowledge exist to guide the effort. However, Roadmaps for a domain, platform or business function in an organization do not exist in isolation. Such artifacts must be reviewed alongside other viewpoints across the functional, regional and Architecture (BIDAT) domains. The process of reconciling Architecture roadmaps across an organization (‘How’) however remains nebulous.
How do we reconcile roadmaps across enterprise domains?
A few years ago, I defined and operationalized the architecture governance process at my company, and helped drive the periodic Architecture roadmap review sessions. (Ref my post on ARB) During the initial reviews, we realized that we also had to address the challenge of reconciling roadmaps across domains. Like many large organizations, we had several functional and regional domains that coexist along with Business, Information, Data, Applications and Technology (BIDAT) areas.
Architects responsible for their domains and functional areas were passionate about their viewpoints, but no two architects represented them with similar visuals. I had to get the extended team to agree on a few basics, including a common table of contents (TOC), guiding principles, structure to capture the requirements, assumptions, timelines and other building blocks. As a precursor to reconciliation, it was assumed that Architects had engaged their stakeholders and validated their assumptions, drivers, timelines and the proposed transformations. Here is a link to the Table of Contents (TOC) of EA roadmaps
We agreed to strip the ‘metadata’ in roadmaps from their visual representation. The data thus extracted into a common XLS based template helped the team focus on the facts and figures rather than the variety of visuals. For example, a Technology Architect had assumed that the global ERP platform would be upgraded to version 5.5 by the middle of 2018. This version of the ERP came with digital invoice workflow capabilities. With this information, Finance Domain architect could recommend invoice-digitization for her business processes in the 3rd quarter of 2018. A similar process of reconciliation continued across domains and platforms.
After the reconciliation of the facts and figures, the Architects updated their roadmaps with assumptions, drivers and timelines before proposing recommendations to their stakeholders and transformation program managers.
Here is slideshare with a few slides on the process of roadmap reconciliation
A few lessons learnt while rolling out the process:
- Focus on the basics and stay grounded – Well defined roadmaps abstract the details while highlighting significant capabilities, However, while reviewing roadmaps across an organization, Architects should examine and synch up the details.
- Plan for a continuum of reviews – Business domains evolve, strategies get updated, and new capabilities are periodically introduced in organizations. Therefore, the roadmaps will periodically become obsolete, and must be updated and reconciled.
- Stakeholder engagement - Reconciling roadmaps at a large organization does not happen in isolation. One must engage Architects and stakeholders from across functional and business boundaries which may present logistical challenges. Engaging teams that are geographically dispersed will require consulting and change management skills.
- Consultative more than directive – A roadmap review should take into account organizational (human) dynamics and organizational constraints. The reviews and reconciliation should be consultative, although some aspects - like external vendor inputs or Technology Debt (link) - may have to be directive.
My views on the topic continue to evolve, and I look forward to hearing about experiences in your organization too.
Thanks for reading! Please click on Like, Share, Tweet or Comment below to continue this conversation | Reposted from my LinkedinPulse
