The Return On Investment (ROI) of Enterprise Architecture (EA)vhanniet - 2022/02/28
Are you kidding?
Life always beats fiction when imagination is concerned. Recently a large company asked me to show proof of ROI for implementing EA capability again.
This company have had Architects in the past, and got rid of them at the time they choose a big Enterprise Resources Planning (ERP) solution as the company’s operational Information System (IS) backbone. It made sense in a way: IS was organized around all ERP capabilities. So what is the need of Enterprise Architects in such a situation? Furthermore, we can probably consider that Company’s EA Architects were de facto ERP editor’s ones.
A company without Enterprise Architects gets a default Enterprise Architecture. This default EA is thus, in this case, driven by the strategy of the ERP editor. It can work, and has worked in this case, as long as the company’s strategy lays on commodity services implementation excellence. Which means that company’s competitive advantages are based on cost killing and operational productivity. Plus eventually on one or two business innovations managed in a siloed IS, outside the ERP.
This company recently achieved a business and IT review, and found that ERP was a bottleneck against deploying new business lines and the IT enablers needed for that. So they decided to overturn the ERP in many IS strategic domains. But they are now lacking of Enterprise Architects. And Program and Project leaders have now a long habit of doing Architecture for their own needs, mainly, and don’t want to change this practice. Hence the question of EA ROI proof in order to have a chance to get some high level sponsorship to counter the operational resistance to change.
My answer has not been “Are you kidding?” but sounded to much as it was it. I lost the deal.
Think big. I tried several unsuccessful ideas.
The first one was: nowadays IS is the heart of every business strategy operational implementation. How can you imagine achieving successful strategic outcome if there is nobody to drive IS architecture? The answer was: “Up to now we don’t have Architects anymore and everything is OK. This argument doesn’t proof EA value”. Objectively as the situation is going to change the answer doesn’t really apply… but it’s a customer, I can’t say that.
The second argument was about having benefit up to now from ERP editor’s own EA. ERP Architects would have to be replaced by company’s ones now that ERP usage is intend to be reduced to non strategic commodities services. Same answer: Projects leader won’t let Architects put their noses into their business.
Third argument: let me talk to C-level guys, I’m sure they know EA value and will endorse getting it in house again. No response. Maybe my interlocutors tried and didn’t get listened. Or most probably they didn’t dare try without numbers.
Then the light came. Jeopardy. What EA is the answer for? Why do you want EA back again? It’s not a joke when you think of it: you do want EA so, what for?
How comes the idea that EA costs too much?
The more abstract something is, the more difficult it is to associate exclusive gains with it. So the Return part of EA ROI is for sure something hard to elaborate. We can probably roughly calculate the expected ROI for company new business strategy deployment. But it’s hard (euphemism) to isolated the part of it which will be due to a good Architectural approach at Enterprise level. Even with a bad, or a default, EA approach we can still have some gain. And the fact that the gain would have been larger with a good managed EA implementation will probably (euphemism) never be assessed.
It’s easy to compile costs (seems to be, but let’s take it on the easy side). What are the costs about Enterprise Architecture? Mainly time spent labor costs: architecture work, architecture comitology, architecture governance, architecture support & evangelisation. Also eventually costs associated with architecture tooling. Also indirect cost of added delay into the time to market journey which could be seen as revenues too much delayed (we could say the same for security work stream).
These costs happen even with a default EA! Nobody can build an Information System without taking Architecture decisions. The question is: do we want to organize these decisions in a managed way? or do we want to let individuals decide at each decision point? taking into account, or not, architecture decisions taken elsewhere? In this “default” way, EA costs will not be compiled so we can’t see them.
The misunderstanding about EA
The biggest mistake about EA is certainly to believe that Architects have to do all the Architectural stuff. And the Architects are the only guys able to use architectural stuff to tell “truth” because Architecture is complicated.
This situation is well known as the ivory tower syndrome. In this situation, Architects work together and produce architectural documentation that is only used, and usable, by Architects. Eventually they produce some transformation impact analysis: often the produce the 20% part which costs 80%. And these Architecture artifacts needs to be frequently aligned with the “real world”. With costly tools.
The 80% part at 20% of the overall cost, which is just enough for anybody else, is either produced by architects, or other people, or even not or partially produced. It all depends on the perception of architectural matters by stakeholders. And it happens that the core architecture description is made, and associated decisions taken, without the Architects supposed to be in charge!
We don’t want to get there again. Understandable. This “bottomless well” cost source without significant impact is a major contributor to distrust against EA.
How to make EA great again?
Let’s try to get the 80% of EA benefits with only 20% of the EA “big picture” costs.
The idea is to get control back onto Architecture decisions on a strategy / organization level. And to avoid letting these decisions to be taken at local sub-level or at global meta-level.
Before engaging any major strategic transformation it’s a good idea to explain what we want to do, why, how, etc. How Enterprise Architecture can take place in the envisioning?
Let’s illustrate this with the 5W2H method:
- What? : what will we change into the IS organization (Architecture)?
- Why? : how comes we will change the IS Architecture?
- Where? : what part of the IS will be concerned?
- When? : is there any roadmap envision?
- Who? : what build organization will operate the change? (and how to get a lean mapping between build organization and IS building blocks)
- How? : is there any IT enablers to get for an easier change?
- How much? : what are the costs associated with the architectural debt to reduce? with the new IT capabilities to setup?
Yes, this is very similar with Phase A: Architecture Vision in TOGAF Architecture Development Method. Similar but not the same. Here we don’t focus on Architecture for Architecture, but we want to focus on Architecture as part of a whole overall. Architecture is involved in the transformation as any other consideration.
The idea here is: let’s share the Architecture vision with everybody. The same way we do with the Business vision, Product vision, Organization vision…
Enterprise Architecture is the glue between Business requirements, SI products which operate the business, and Organization of people and other resources, in order to help the company to achieve its next strategic goal.