An architecture consultant that I was working with a few months ago used the phrase “harvesting value from architecture”, and it made me sit bolt upright. The phrase really resonates with me, as it speaks to how it's too easy to let architectural discipline become a background task that you 'just do'. But, as with farming, adopting the architectural discipline is about realizing rewards later on in time. You'd be hard put to find a farmer who sows their crop but never harvests it or checks their yields – yet many organizations who set up an architecture practice don't monitor what they are harvesting from the investment.
Summary: Setting up an architecture practice is merely the first step. You need to collect examples of how it is adding value to keep it running. There are some techniques for how to do this explored below.
To start with, let’s be explicit about why there is a need to do this. The bottom line is, in any environment with budgets, there will be competition for money. This should not be news to anyone. At the same time, I've encountered a sizable number of managers who are either skeptical of the value of architecture modeling... or in a couple of cases that I've run into, accept that it can have value but don't see why they should support a program that will probably only deliver value a couple of years down the line (at a time when they are thinking in terms of their next quarter).
So, it's important to be able to point to examples of how the architecture has provided value, which means it's important to collect cases where the organization has received value from architecture. Then the sponsors of the effort have some ammunition in the form of specific examples. Having worked in a sales role, I can confirm that case studies are a very effective technique for convincing people.
Now, how to collect these case studies? First of all, it's best to target the major initiatives that have taken place or are ongoing. First of all, they'll have higher visibility within the organization. Second, the larger programs tend to be more complex, and hence more prone to benefit from architecture.
In trying to estimate a value, the trick is keep an understanding of how architecture adds value to the organization. To put it another way; what were you expecting to see change as a result of the use of this architecture? From this, you can assemble a list of anticipated benefits. An example of such a list is given below:
- Reduced time for industry compliance activities
- Reduced impact analysis time
- Earlier discovery of potential problems
- Re-use of existing solutions
- Reduced time to define interfaces
With this list in hand, it is possible to go to a given initiative and ask them to give a rough estimate of how much time they saved in each category in the list, with an idea of how much time the initiative saved.
There's a couple of caveats here; a given program manager may be openly hostile to the idea of architecture and modeling, in which case they are not likely to estimate much value, even if others on that team feel otherwise. Therefore, it's important to consider which initiatives have made a bona fide effort to use the architecture model.
Second, some initiatives may feel that they did get value, but struggle to estimate it. Here the thing to do is adopt the technique of the wheel, as described by Hubbard in his book “How to Measure Anything”. The simple summary; estimating a range of values that you are comfortable with is 90% likely to contain the true value. To be sure that you are happy that the range is 90% likely to contain the true value - ask if you'd rather bet on the range containing the value, or a slot machine that pays out 9 times in 10.