What is the ROI of Enterprise Architecture (EA)

Life always beats fiction when imagination is concerned. Recently I want to ask, myself what is the ROI for implementing EA capability.

Businesses 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 for 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. This means that the company’s competitive advantages are based on cost killing and operational productivity. Plus, eventually, one or two business innovations managed in a siloed IS, outside the ERP.

The business 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.

Think big. Fail fast. I tried several unsuccessful ideas and Failed too

The first one was: that nowadays IS is the heart of every business strategy operational implementation. How can you imagine achieving a 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 benefits up to now from the ERP editor’s own EA. ERP Architects would have to be replaced by company ones now that ERP usage is intended to be reduced to non-strategic commodities services. Same answer: Projects leaders won’t let Architects put their noses into their business.

The third argument: let me talk to C-level guys, I’m sure they know EA value and will endorse getting it in the house again. No response. Maybe my interlocutors tried and didn’t get listened to. Or most probably they didn’t dare try without numbers.

Then the light came.. 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 on. We can probably roughly calculate the expected ROI for the company's new business strategy deployment. But it’s hard (euphemism) to isolate the part of it which will be due to a good Architectural approach at the 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 east side). What are the costs of Enterprise Architecture? Mainly time spent labor costs: architecture work, architecture comitology, architecture governance, architecture support & evangelization. Also eventually costs are associated with architecture tooling. Also, the indirect cost of added delay in the time to a market journey could be seen as revenues too much delayed (we could say the same for the security workstream).

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 are 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 they produce the 20% part which costs 80%. And these Architecture artifacts need 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 be taken at the local sub-level or at the global meta-level.

Let’s illustrate this idea.

Before engaging in 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?

• · What? : what will we change in 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 envisioned?

• · Who? : what build organization will operate the change? (and how to get a lean mapping between build organization and IS building blocks)

• · How? : Are 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 set up?

Yes, this is very similar to 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 that operate the business, and the Organization of people and other resources, in order to help the company to achieve its next strategic goal.

About Author

M Senthil Kumar is Program Head of Digital Solutions & Presales for Continental Europe at TechM. In his role, he is responsible for designing and architect digital solutions for large enterprises utilizing nextgen digital solutions with AI/NLP/ML/AR/VR/IoT/RFID/QR, etc. Spearheads Enterprise Architecture, carries 20 years' experience in IT infrastructure Service Strategy, Service Design, Services Support, Engineering, Systems and Software Architecture, Consulting, and Presales. Truly focused on customer service excellence, enabling continuous improvement by assessing and identifying customer business needs.\

Disclaimer: The opinions expressed on this site are mine and do not represent my employers (past or present) or any other entity. I give no warranty or guarantee whatsoever regarding the accuracy, reliability, or completeness of the information provided on my article/website. I will not be liable to you under any circumstances for any loss or damage arising from your use of such information. Users are advised to check the accuracy of the information on this article/website.