Blog

Why do Enterprise Architects have to
Justify their Existence

Friday 28th November 2024

By Ben Clark

Is there any profession under pressure to justify its existence as much as #EnterpriseArchitecture? Not a week goes by without a conversation with a Chief Architect who is struggling for funds or, worse still, feeling the heat to justify why the department even exists in the first place.

Why do architecture teams always have to feel that need to explain to business stakeholders and more worryingly CIOs why they exist in the first place and what actions can be taken to mitigate this?

Part One

There is no agreed metrix for Value of measuring success.

A wise man once told me that value is a number; everything else is just noise. With enterprise architecture, this is only possible in a small number of ways that finance people can fully comprehend. IE We are turning off x duplicate applications, saving y in license costs, etc. However, it becomes much more complicated for everything else a business capability model or target state is often met with a shrug, as they don’t mean very much on their own. It is only when they are accompanied by a metrix with a tangible value that your stakeholders understand. Also, as any architect will know realised benefits are often 2-3 years down the line and will be considered someone else’s benefit/problem by then.

There is also no agreed-upon industry-wide value metrix. The nature of enterprise architecture makes it very difficult, but when the industry itself cannot agree on how to measure value, how can you expect your business stakeholders to do so? One step on trying to make the intangible, tangible is to measure consensus. Take one of the most important artefacts you will produce, the strategy #roadmap. How long does it take to gain consensus on a strategic roadmap? 3 months, 6 months, 12 months? The time savings and benefits of halving the time are huge if you think of all of the stakeholders involved. What is the cost of renewing unloved applications for another three years if you cannot agree on the best way forward? What is the benefit of getting consensus on a decision like that?

The tools don't help (they just make it worse).

When was the last time anyone outside of your architecture team logged on to your EA tool? If you have a business stakeholder who does, I want to hear the story. In fact, I want to interview them.

I know of one global consultancy that turned off LeanIX a year or two ago. A grand total of three people—yep, three people—had logged onto a tool costing, I believe, $90,000 per annum.

The only time a business stakeholder interacts with any output from a tool is when an architect walks them through, step by step. I have been in these sessions and seen stakeholders eyes glaze over at the shear volume of information that is being presented. We all know how much harder it is to learn when you are effectively just being talked at and not doing or interacting. Even Gartner are on record stating that Enterprise Architecture tools do not produce visuals that engage the business.

The other factor with tools is how much time and data do you have to put in to get a reasonable amount of insight? Our experience tells us it is normally 6-9 months for an enterprise tool.

If you take the data out of the tool to present it in PowerPoint, it will be static, and whilst your stakeholders can use it, there is often no ability to interact. You might have managed to distil 3 months’ worth of analysis into one slide, but if they want more detail and more detail on top of that, how do you do it in a way that is manageable.

When was the last time you could say your stakeholders had an architecture output that was simple to understand, interactive and did not require training in a tool?

Focus on the artefact that is most understandable for most of your stakeholders, this is another capability model or a strategic roadmap allow people to actively engage with it.

There is a misalignment in thinking styles.

Architects are detail-oriented people. You cannot be a good architect without the ability to really think things through, analyse the various options, and present back the risks and issues, etc. This requires huge amounts of data gathering and complex thinking that would have been occupying your mind for months.

Most of the time, business stakeholders do not realise the complexity of the problem you have been solving or how much time and thought it has taken to get to the answer. They might not have even given it much thought. While it was your number one problem, it could be anywhere from 1 to 100 for your stakeholders, and where it is on that list will change daily, as I am sure you will have experienced.

One of my biggest challenges in consulting is that I have to spend a lot of time explaining that the problem is more complex than initially thought while being a trusted advisor who is not trying to overcomplicate just to try and generate more revenue. This is a problem that architects have to grapple with each day. Your stakeholders don’t understand what you do, so immediately oversimplify the problem. Architects respond with more detail…..

What is important to you, is not necessarily important to them. Forbes research ranks poor communication (62%) as the main reason why transformations fail. They don’t care about how much work has gone in, the process that you have gone through to put the 226 different pain points into seven main categories or the method you have used. They want to know the risks, the opportunities, how much & how long etc. In short, they want the result; if the result is of interest, they may be interested in the analysis.

So start with the result, and add the details afterward. Hollywood is often happen to start a firm with the end, so why shouldn’t you?

Conclusion

Is there any profession under pressure to justify its existence as much as #EnterpriseArchitecture? Not a week goes by without a conversation with a Chief Architect who is struggling for funds or, worse still, feeling the heat to justify why the department even exists in the first place.

Why do architecture teams always have to feel that need to explain to business stakeholders and more worryingly CIOs why they exist in the first place and what actions can be taken to mitigate this?

More insights