Tips for reconciling Architecture Roadmaps across an enterprise (Enterprise Architecture 101)

"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

What I learnt in a year running an Architecture Review Board (ARB)

Among my first tasks after joining the Enterprise Architecture team for my employer - a multinational Ag Biz company - was to redefine the Architecture Review Board (ARB), a need that was triggered by a review of our Enterprise Architecture program.

The head of architecture explained the company’s “history” of architecture governance and the shifting focus of the architecture function. As in many large multinational enterprises, the company’s IS team continues to evolve to mirror changing business drivers. The pendulum had swung from extremely governed to the laissez faire model, and I was tasked with operationalizing a fit-for-purpose ARB.

So, what did I learn?

As should be expected of any global organization, the architecture landscape is complex. Running the ARB process gave me a ringside view into changes being introduced into the landscape.

To appreciate the value chain, understand organization change

• The architecture tradeoffs used to review proposals and the ARB recommendations are a good dipstick into the stakeholders’ appetite for change.
• The ARB is integrated into the portfolio and program management processes. Hence, ARB members can try and understand Who (stakeholder/sponsor) is paying for the change, and Why (the value expected from the investment)

Appreciate the subtleties of “business” engagement

Passionate debates on engaging with business frequently surface in online Enterprise Architecture forums. Some of it is because the term ‘business engagement’ is nebulous, and may be used to describe several things

• People – Business user of a business system or process
• Functions - Business function like Finance, HR, Supply Chain etc, or Business unit - like the British or Turkish subsidiary of a multinational or the “Houston manufacturing plant”
• Leaders and leadership teams – Ranging from top tier CxO reporting to the CEO/Board to leaders of functional or business units and others in between

During ARB reviews, I sometimes find it easier to just work with the sponsor - people with money or people who know people with money - than to debate how to engage “business”. The assumption is simple: sponsors follow the money.

Aspire for a “seat at the table” but be pragmatic

Engaging business to “define strategies” is another topic of continual debates in Enterprise Architecture forums. In reality, a seat at the table may be more about effective realization of strategy than about ideating on business scenarios in an ivory tower. For example, a few scenarios:

• M&A: Mergers & Acquisitions are generally strategic business decisions involving a handful of people - the board, CEO, CXO, a business head or two and handpicked lawyers and accountant with sundry advisors.
• Decision to expand or divest business: Also strategic business decisions involving only a handful of people.
• Decisions to enter new line of business. E.g a software services company deciding to operate data centers or expand into “cloud operations” or an AgBiz company introducing a complementary solution for farmers

In these scenarios, EA’s and other senior managers may be engaged to enable execution *after* such strategic decisions are taken.

In this article, I try and highlight a few of my empirical observations and learnings. A more detailed discussion of Architecture Review Board and my case study can be found in this month's Cutter IT Journal article (Enabling Successful EA Governance -link).

Cross post from my Linkedin Pulse