Value case as the new centerpiece of enterprise architecture

When we talk about enterprise architecture, the first core competency to everyone’s mind is the development of a target architecture for the entire portfolio of a company. While this is correct, it is incomplete. What happens with a target architecture once it has been developed? It is chunked into achievable increments that are packaged into projects which are put onto the timeline of a transformation roadmap. Once this is completed, the roadmap is taken to the board to request funding. If the target architecture is carefully prepared and thoroughly designed, the board will quickly notice exactly that and not focus on questions about the content of the target architecture anymore but about the business case only. That’s when the questions around cost and benefit culminate. How long does it take? What does it cost? What do we get from it? Do we make more revenue? How much cost do we save? If there are no answers to those types of questions, whoever is asking for the budget will no longer be part of the discussion and very likely the funding request will fail.

Hence, a target architecture is the starting point, and it needs to be complemented with a holistic, detailed, and carefully constructed value case comprising all the relevant dimensions of balancing costs with benefits. Therefore, the development of a robust value case eventually is an equally important core competency of the enterprise architecture work. This might sound a little unintuitive. "It’s numbers, right? What do I as an architect have to care about it?”, you might potentially ask yourself. Well, as said above, if you cannot translate the proposed architecture into tangible numbers, your architecture will have no relevance for a decision board. It’s like you have architected the perfect house which you present to your client without being able to express associated costs and benefits.

While estimating those numbers must be a key capability of enterprise architecture, this skill is one which is not well-defined at all or explained in respective conceptual literature or frameworks or wherever you might potentially look for help to stay relevant in the process of decision making. In this article, we describe how to master this as enterprise architects and thus, become a truly differentiating factor as an enterprise architecture discipline and an individual success factor in every one’s personal growth journey.

The cookbook recipe to master creating a strategic value case

To calculate a strategic value case, it’s like a three-course menu. First and foremost, you need to set your base ingredients for every value lever. Once this is defined, you then calculate the impact of each value lever for every initiative. And finally, you must take care that besides the mechanics, the value case is broadly validated and syndicated.

Within the next sections, we first will explain you the different value levers and then introduce the three base ingredients: estimation categories, baseline values and complexity drivers. Afterwards, we deep-dive on both sides, benefits and costs, to detail the base ingredients and the impact calculation of an initiative.

For every value case you have multiple value levers on benefits and the costs dimension. So, what value levers of benefits are there? Let us give you three typical levers that often work very well because they are simple and resonate with most of the boards:

1. Revenue Increase or also called top line: That is of course sort of the holy grail of all benefits. Companies want to generate more revenue, either out of the existing customer base (increased share of wallet) through cross- and up-selling and equally important by acquiring new customer based on improved capabilities.
2. Business Cost Reduction (bottom line): The cost of operation is another super important focal point of companies to save cost and increase profitability. So just as an example, the business cost of operation could be related to the number of employees that are working in the call center answering customer calls. That number potentially could be reduced by a new CRM platform with a substantially higher digital maturity and significant process automation capabilities.
3. IT Cost Reduction (bottom line): Likewise, the cost of operating the IT is a significant cost saving lever that board members are focused on and want quantified suggestions for. Example here could be the cost of operating multiple diverse applications that support the same business capability, called redundancy. Consolidating those redundancies may potentially result in certain cost savings in the IT budget.

Once the benefit levers are given, you’ll move to estimate the costs. So, when estimating costs, we most often speak about the total cost for implementing a strategic initiative that realizes certain aspects of a target architecture. This includes the one-off cost and the new run cost. Therefore, we differentiate between the following two value levers on the cost side:

1. On-off costs: These are one-time investments which need to be provisioned to achieve the initiative. This includes all sorts of costs including person days and software licenses.
2. Run costs: These are costs which occur in regular cycles once the initiative is completed (e.g. subscription costs, additional operational IT people)

Once the value levers are clear, you are ready to understand the very core of the value case: the base ingredients. For all value levers, there are 3 very basic ingredients:

1. Estimation Categories: Again, all cost and benefit levers can be separated into different estimation categories (let me explain in more detail further down) that basically serve as buckets for configurations and calibrations. These categories come in very much handy for different types of categories where baseline values differ and potentially complexity drivers simply need to be differently calibrated. Categories can also be nested, so categories in categories, depending on your capacity and appetite for complexity.
2. Baseline Values: For both cost and benefit estimations a baseline value is required. Examples of baseline values are the annual IT budget of a company, the annual revenue of a company or an experience-based value of person days required for a certain activity type during a strategic initiative.
3. Complexity Drivers: Equally for both cost and benefit estimations there are complexity drivers that drive cost or benefit up or down as compared to ingredient two – a baseline value. Very often there are multiple complexity drivers that influence each other and need to be considered in a combined way.

Those above three base ingredients can be combined in many ways that can get very complex very fast but in the end, it always boils down to these three key elements.

So, to break it down, let’s take a separate look at how to estimate cost and benefit, starting with cost.

Strategic Cost Estimation

Let’s start with the estimation categories to consider that are required for a holistic cost perspective:

One-off cost that needs to be invested once, to implement an initiative.

1. All the person days that are required by internal and external people. Of course, those person days need to be multiplied with an average daily rate for those people to translate days into money values. Those values can be identified by looking at the average cost structure for internal employees and taking average values for external people if you wish even distinguishing between on-, near- and offshore rates.
2. Software licenses that need to be bought once.
3. Hardware that needs to be bought and the capitalized.
4. Connectivity and network fees that providers incur.?
5. Workplace equipment that needs to be procured.

Recurring cost that occurs every year after the initiatives had been implemented.

1. Same cost buckets as above but with different values

So, all those above estimation categories need to be calculated and combined in the end.

Let’s continue with a very practical look at how to estimate person days. In this case, we need introduce a nested estimation category, this means we introduce a set of new estimation categories for the person day estimation category.

Let’s look at all the activities that need to be executed as part of a strategic initiative that needs to be estimated and let’s categorize the predominant type of activity into separate archetypes. The following set of such activity archetypes often works well:

1. Organizational Preparation & Execution: All types of activities that predominantly focus on organizationally preparing projects and executing projects (e.g. change management) that do not include any of the below activities.
2. Vendor, Provider, Product, Service Assessment & Selection: Any type of activity where a vendor, partner, provider and respectively a service or a product is evaluated and selected for later implementation.
3. Solution Architecture, Design & Concept: Anything around designing solutions and creating specifications that will be implemented at a later stage.
4. Detailed Initiative & Roadmap Planning: Any activity that includes a detailed planning of projects.
5. Technical Implementation & Realization: This where all the actual technical implementations and realizations take place.

Of course, there are other types of activity archetypes that might work better for your specific context. Feel free to adjust and amend the above archetypes. And include them in your estimation model. So now that we have our second layer of estimation categories, and we want to estimate person days we are missing the other two ingredients: baseline values and complexity drivers. Let’s go!

Alright, we are going to define a baseline value for each activity archetype by defining the number of person days required for a typical average project of that archetype. That requires experience that either yourself or a subject matter expert of yours can provide you with. For this specific use case, it is important to base these values on sub-values that experts have a psychologically intuitive inner calibration for. The number of person days is not such a base value but the number of months and the number of people that need to work for this number of months to complete this activity is a two-step value calculation that experienced experts feel relatively comfortable with. So as an example, it is relatively intuitive for an expert to tell you that a typical, average, medium-sized project that focusses on the activity type “Solution Architecture, Design & Concept” is approximately in the range of 3 months requiring around 3 people. Months have a typical number of working days multiplied with the number of people and there you go: you have your number of person days as a baseline value. These values of course always depend on the actual context or more precisely from the size of the company. It is important to keep that in mind when calibrating the baseline values. You do that for all the activity archetypes to complete the baseline values for your estimation category person days.

Now that we have this ingredient covered too, the only thing we are still missing is the complexity driver. Let’s complete the cost estimation for the number of person days required with that last ingredient. For that we again need experience and the support of experts that sort of have natural inner relation and calibration to those metrics. Ok, so how does it work with the complexity drivers? The above-described baseline values depict the number of person days required for typical, average medium-sized activities of a respective archetype. A common and simple approach to work with complexity drivers for this case is to use T-Shirt sizes. So, for the baseline value, this would be T-Shirt size M. The complexity driver for T-Shirt size M of the above baseline value would be 1. Then of course we all know that there are other T-shirt sizes ranging let’s say from XXS or XS to XL, maybe to XXL. So, in total we have five to seven T-shirt sizes for the sake of balance between simplicity and complexity. Now, if M as a complexity driver equals 1, then e.g. S could be 0,75 and L could be 1.5 and so on. So, once you have defined complexity drivers you can take your baseline values referenced by the activity archetype and your multiply it with your estimated T-shirt size and there you go with your actual estimated number of person days. Now you have all the three basic ingredients together that you will need to calculate person days – that typically are the biggest cost driver of such strategic initiatives.

With this, you can go ahead with your list of strategic initiatives and the comprised activities. Consequently, the only thing you need to do is to 1st identify the activity archetypes of the initiative and 2nd the estimated T-shirt size of the initiative activity. Hence, the number of person days can be calculated based on the baseline and the complexity driver. That’s it.

Similarly, you can go ahead with the other cost estimation categories such as e.g. software licenses or hardware fees: you need a baseline value and a complexity driver to scale it up or down both based on experience data from yourself or subject matter experts.

Let’s move on to the chapter of how to estimate the benefits of an initiative.

Calculating Strategic Benefit

Earlier, we introduced 3 main value levers for benefits: revenue increase, business cost reduction and IT cost reduction. Let’s go through two examples of estimating benefits and we start with estimating the potential for IT Cost Reduction. Consequently, we utilize the three ingredients for it. Again, we start with the estimation categories. Typical cost categories in IT budgets are the following categories that typically work very well:

• Administration: All cost related e.g. to employees and other administrative cost.
• Applications: Cost related directly to applications such as licenses, maintenance or development cost.
• Infrastructure: All cost related to infrastructure such as servers or cloud services. If not called out separately this cost also comprises cost for network and connectivity and workplace technology.
• Cybersecurity: All cost directly related to cybersecurity incl. people, software, hardware, services, etc.

Alright, there we have our first set of categories we can break the cost down into. Now, we need the baseline. The best suited overall baseline for estimating IT cost reduction is obviously the annual IT budget of the company you are currently looking at. This typically comes in all different sorts of variations and breakdowns that can be very confusing. You now need to map the IT budget breakdown to the above defined categories, which can be a very tedious exercise. Sometimes it is impossible to do. In that situation you can always fall back to experienced-based expert knowledge about typical distribution levels of IT budget across the above categories. A typical distribution for medium sized companies that often works very well is the following percentual distribution. Obviously, this varies strongly across industries and company maturities and sizes, so you will not get around coming to an opinion of your own for that question:

• Administration: 25% of IT Budget
• Applications: 25% of IT Budget
• Infrastructure: 40% of IT Budget
• Cybersecurity: 10% of IT Budget

You can now multiply the IT budget with the percentual values in your categories and you have a baseline annual cost for that category.

We still need the third ingredient, the complexity driver. We again work with T-shirt sizes only that here the T-shirt size is not a factor but a percentual cost saving that can be realized by an activity related to an identified category. So, let’s say for example a medium cost saving related to any bucket would be a cost saving around 3-5%, translating into a T-shirt size M, then an S could be 2-3%, L could be 5-7% and so on. Again, those numbers are fed by experience and expert knowledge. That is a fundamental requirement for strategic estimations, nothing more scientific and fancier behind that than pure, powerful multi-decade, crowd-sourced, swarm-intelligence experience.

Only thing you need to do now is to 1st identify the predominant IT cost saving category of a specific activity in an initiative?and the T-shirt size and there you have a money value that provides the potential cost saving of that activity.

Similar example for revenue increase. Let’s skip the estimation categories for the sake of simplicity. A very simple baseline would be the annual revenue of the company. And again, the cost drivers are T-shirt sizes with potential revenue increase percentages that of course need to be carefully selected and that typically are very small, around 0,01% and 1,5%. Especially here, it depends strongly on company sizes and industry. But the mechanics are the same. Of course, there are other ways to estimate revenue increase potential that are more specific to very certain measures in the business operations but those must be defined very individually related to the business model of the company and how the specific business mechanics work and scale, so that there is always an individual perspective which requires much more time and alignment. If you are looking for a more strategic way, I recommend trying the proposed three-ingredient approach.

Besides the mechanics, you must take care of three very important success factors

Once, you have the numbers estimated make no mistake and directly take them to wherever you have to present it to. It is absolutely necessary to take the time to complete the following three homework activities. They are equally important as the actual estimation, so do not ever leave them out.

Document assumptions

Considering the previous sections, you probably sensed, that your estimations are not only based on facts, but you’ll need to define your estimates based on uncertainties and incomplete information, where you need to make assumptions. It’s key to document these assumptions as part of the estimation activities. A wise colleague once mentioned that assumptions are your “Get out of jail cards”. What he meant by that is that there is a possibility that you’re estimates might turn out to be wrong but the reason why they are wrong is because you based it on a wrong assumption. These assumptions were validated with key stakeholders, and at that point in time, nobody raised his hand.

Leverage Experts

Leveraging experts, it’s kind of an obvious but very powerful activity during the estimation process. Since there is mostly a lack of data, your best source of input is experts to verify and challenge your figures. These usually include senior architects, project managers and IT management people. Besides, they prefer to challenge existing numbers instead of providing initial figures. Additionally, they are a sense check also for your base ingredients e.g. the efforts estimated for the different activity types of an initiative.

Syndicate with key stakeholders

The final step is to present estimates to key stakeholders and being able to explain and defend them with confidence. Beside the actual estimates also the approach, the involved people as well as the assumptions which were taken, shall be presented.

Often, senior stakeholders will be able to understand the level of granularity you took into your estimates and derive appropriate conclusions from it. Although, in a case they’d completely disagree with certain aspects, you can always take a step back and propose to validate or detail an aspect further.

Conclusion

How ever complex the above descriptions might appear to you when you first read them, keep in mind that all those estimates are based in only three base ingredients that you combine in similar ways and of course you need some experienced experts to calibrate your model, so it’s not a no-brainer but it’s achievable. Try it out and you will be amazed how reliable and with a relatively narrow fluctuation range you will find that actual numbers eventually are compared to your initial strategic estimates.