Part 1:
Building a Business Case for an Architecture Model -Approach
One of the things that comes up again and again when talking to organizations that are evaluating iServer is how to make the business case for modeling. It’s a fair question, but surprisingly, the only literature I’ve found on making such as business case always talks in high-level terms; “Improve alignment”, “Understand the business”, and so on. It’s pretty woolly in providing testable promises, so in terms of convincing people to back establishing a modeling effort, it’s not that effective.
Now, the obvious retort is that this is for a good reason – estimates of the value delivered are likely to be inaccurate. But you could argue this about every business case to some degree. To quote one lead architect I worked with:
“every business case I’ve ever seen has been fictitious.”
- I’d agree with that, and I can’t help but suspect a lot of business leaders would agree as well. And yet building a concrete business case has value, both to the person building it, and the people evaluating. It shows a structured understanding of the expected costs and benefits - more so than vague promises of ‘aligning IT to the business’. Even if the figures are in dispute (and they will be), it’s a way to focus discussion.
With that in mind, over the next 6 posts I’m going to outline one way to build a business case structure for an architecture modeling effort, one that offers estimated benefits and costs, and then I will apply the structure to a couple of (anonymized) implementations that I have seen in the field.
Now, the model that I intend to create is about creating and maintaining a model of the enterprise architecture. This could be a steady-state model that is simply maintained, one that is used for a specific purpose (such as enabling divestment of an operating unit), or one meant to enable full-blown enterprise transformation. I don’t intend to create a business case for enterprise architecture per se.
Likewise, I won’t pretend that it’s impossible for the structure to be improved. Indeed, I invite the reader to do so.
I’m also going to be assuming that this is a shared, integrated model created and maintained by multiple users from different domains – the typical architecture modeling environment that I’m used to.
I’m going to be drawing from a few different sources. The basic structure of the business case will be taken from chapter 7 of the book “Business Modeling: A Practical Guide to Realizing Business Value”, by Bridgeland and Zahavi. The authors break benefits and costs into different areas, which you can use to better estimate the quantities involved.
To start this series, we’ll identify the main areas of benefits and costs, and talk briefly about estimation techniques.
I’m going to identify 5 main areas of benefits:
Risk Reduction – having a clear picture of the architecture offers several ways to reduce the likelihood or impact of risks that may impact the organization.
Operating Cost Reduction – opportunities for elimination of waste, whether rationalizing systems or reducing the costs of business processes, are a key goal of modeling
Revenue Increase – by enabling improved responsiveness and reduced implementation costs, new opportunities may become available that were not cost effective before; and sooner, so their benefits come sooner.
Improved Decision Making – having a clearer picture of the architecture enables decisions to be taken with greater clarity and accuracy
Cultural Changes – achieving the above goals often leads to happier workers, partners and customers. This in itself is (usually) agreed to be a desirable thing.
Similarly costs fall under various categories...
Data Gathering – this is acquiring the information to create the model. It could be a number of activities; from running a discovery tool on a network, to an interview-based definition of the business functions.
Data Rationalization – sometimes the data that you use to create a model already exists in multiple locations - and they disagree. So there can be an effort involved in resolving these disagreements
Communication and rollout – to roll out a modeling practice to an organization requires an effort to get buy in, socialize the effort and communicate how things will be changing
Tooling – to maintain a shared architecture model usually requires a tool of some kind. So I’ll briefly discuss this area while attempting to be as neutral as possible.
Governance overhead – maintaining a shared architecture model implies a level of governance, which imposes overhead. So it’s necessary for a believable business case to consider this.
Each of these areas of costs and benefits is necessarily high level in order for it to be possible to tailor the model to the organization and the challenges it faces. The next 2 posts will dig into the benefits in detail, to enable estimation for each of these categories; following which the cost areas will get the same treatment.
Breaking down these areas will help with estimation, but some of the components will still be hard. So I’m going to be referencing the excellent book by Douglas Hubbard, “How to measure anything”. This book has already gained traction in one EA standard – the FAIR risk estimation method from the Open Group. I will strongly recommend the interested reader to study Hubbard’s book, but I’ll be using a few of his ideas;
To find a metric to measure something – ask yourself: why would I even care that this item changes? What changed effects am I expecting to see? So: increased customer satisfaction might be desirable, but how on earth can we measure it?
Well, increased customer satisfaction might be desirable because of more sales leads coming through recommendations. You can measure how many sales leads come through recommendations.
Next: accept that you can’t estimate an unknown quantity perfectly; but you can estimate the range that it lies within. Hubbard offers the concept of the wheel - pick an outrageous range and ask yourself: if you had a choice between betting on a roulette wheel that paid out 9 times in 10, or betting that the value of what we are estimating is in the range you picked, which would you prefer? If you don’t know, you’re 90% confident it’s in that range.
Combining these techniques, and applying them to the breakdowns of benefits and costs that we will establish, it should be possible to create a defensible model for the ROI of an architecture model.