I periodically engage in digital forums discussing the practice of Enterprise Architecture and Technology Management. Many of the conversations focus on EA building blocks, domains and on aspirations like getting a ‘seat at the table,’ closer engagement with business. However, such aspirations remain academic, unless substantiated by business fundamentals including an understanding of costs and financials.
The goal of a commercial enterprise is rather straightforward: maximize shareholder value, and increase returns for investors. Most other goals, including profit generation and operational excellence are inherent in this. However, cost and financial reviews are generally absent during Enterprise Architecture reviews. Even EA frameworks - including TOGAF, Zachman – miss the big elephant in the room or deliberately underplay it.
What is the cost of your roadmap realization?
This rather simple sounding question is likely to stump many Enterprise Architects, and leave them fumbling for a response. Even when an EA has some information on costs, s/he can easily get overwhelmed when the discussions get deeper into TCO, financials of the Business case, levers impacting the business value or a discussion on CapEx and OpEx that ultimately drive the P&L. To be fair, defining Architecture roadmaps for BDAT, functional and technical domains can be a rather involved exercise. During such Architecture reviews, practitioners might make a lot of assumptions and SWAGs and may not get down to the costs and financials.
In an earlier blog post (link), I described the process of reconciling EA roadmaps across functional and technology domains. Such reconciliation of roadmaps and capabilities across the landscape requires the extended team to agree on a few criteria, including a common table of contents (TOC), guiding principles and capture of the requirements, assumptions, timelines and other building blocks.
During roadmap reconciliation, Architects engage with their stakeholders to validate their assumptions, drivers and timelines. This is also an opportune time to engage in conversations on the cost and benefits of capability realization since KPIs, and success factors are generally tied to financials.
I have engaged with business partners and stakeholders at various stages of digital transformation - from ideation to the translation of such strategies into actionable programs and projects (link). In many cases, the conversations remain at a ‘ballpark’ and SWAG level and might get less ambiguous as the programs evolve. However, Enterprise Architecture inputs are required while strategies translate to programs not after that.
Case in point: Cost benefits of migrating a portfolio to the cloud
A few years ago, my organization decided to move forward with a cloud migration plan, and I took on the responsibility for assessing the portfolio of 2000+ application platforms. The ‘cloud suitability’ assessment of individual platforms unearthed unique challenges and dependencies across the landscape. The underlying cost of platforms including application support, hosting and infrastructure, and complex licensing costs were shared across the landscape. Some of the costs and licenses had been negotiated years ago. While individual application owners understood and tracked the cost of ‘their’ applications, most of the shared costs were tracked globally. A phased migration to the selected cloud options – IaaS, Paas and SaaS – would upend the status quo.
It was obvious that a summary of the transformation cost had to be communicated to the stakeholders. An early review of the TCO and an understanding of the different levers of ‘cost benefits’ would minimize a ‘sticker shock’ when the individual transformation programs began to take shape. The team began data gathering and engaged a financial analyst to help with the modelling and validation of scenarios.
Break through the silos
In many organizations, there seems to be an unintentional ‘Chinese Wall’ that separates folks with experience in technology costing - Program Managers, Delivery Managers, Business Partners etc – and the architecture community. Architects are expected to focus on the BDAT dimensions while the ‘managers’ bring in the cost/benefit perspectives. The reason for such segregation includes the need to take ‘unconstrained’ view of solutions and ideas.
There is a merit to the argument since an early cost review could sway the solution options: after all, you don’t want a city-planner designing a township for the next century to be constrained by today’s costs. You might want him to be unconstrained and futuristic. Even this city-planner analogy is a bit flawed since businesses, and even governments are constrained by costs.
Bottomline: Enterprise Architects should remain grounded, especially when most of their business stakeholders focus on the costs and financials.
Reposted from my linkedin Pulse blog |
No comments:
Post a Comment