Selling EA – 4: Proving value, and pricing

How do we ‘sell’ enterprise-architecture? What’s it worth, in terms of value, and of price? What could or should we charge for our work?

This series is a bit of ‘thinking aloud’ about our work, and how we apply our work, and how we could perhaps make our work a bit more immediately meaningful to the potential clients for that work. I’ve split it into four parts:

1. What do our clients want from us? – what they want is simple ‘solutions’ to practical business-problems, yet for which there is actually no simple answer
2. What’s the value-proposition for EA? – the ‘why’ for EA, from others’ perspective
3. What do we do, and how do we do it? – the ‘how’ and ‘with-what’ for EA, the straightforward practical questions about what we do and how we do it
4. What’s it worth? – this part, exploring the ‘worth’ of EA, both in terms of delivered value, and the kind of pricing we should charge for our work

So far, we’ve looked at the core problem for enterprise-architects – how do we get paid for the work that we do? – and then the value-proposition – supporting a core-driver of “things work better when they work together, on purpose” – and some notions of and a worked example for what we actually do in enterprise-architecture, using the Five Elements frame to guide that description:

What we didn’t explore there was the last part of that cycle, Phase #5: Performance, or benefits-realisation and lessons-learned – otherwise known as ‘what’s the value?’. Obviously there needs to be a tight lock-in to the work itself – which is why it’s explicitly described as part of that cycle – yet it’s probably useful to look at this somewhat separately from there, not least because there are a lot of useful lessons for our work that we could learn from elsewhere.

So let’s split this into two parts:

• What’s the value? – how do we identify and prove the value of enterprise-architecture itself?
• What’s the price? – how do we establish what would be a ‘fair price’ for enterprise-architecture work?

There’s perhaps always a bit of a tangle around price, value, worth and cost, but anyway let’s tackle the ‘value’ question first.

What’s the value?

Earlier, we established that we always do enterprise-architecture work in response to an explicit business-question – for example, “How do we get new products and services to market faster?”

Yet what’s perhaps not so clear is that each business-question provides its own definitions of success, in relation to that specific business-question. Preferably, the success-criteria would be specified explicitly along with the question itself. Sometimes they’re implicit, yet easily identifiable – as in that example just above, where ‘time to market’ is a clear metric for improvement (or lack of it) in relation to “get to market faster”. And sometimes the process of finding the right success-criteria and success-metrics will itself be part of the work that we’d need to do: kinda recursive, and perhaps potentially problematic – defining our own success-criteria – but usually fair enough as long as we’re open and clear about it all.

The difficulty is that, with any whole-of-system or end-to-end metric – such as L2C (lead-to-cash), T2R (trouble-to-resolve) or I2R (invest-to-return) – the delivered-value from our work on those themes wouldn’t occur without our work, yet the visible work to make it happen is almost all done by others. So we’re always somewhat caught in a dilemma: either claiming credit for others’ work, or unable to claim any credit at all, and hence seeming not to have done anything at all. Tricky…

One option might be to try to do the same as most managers: simply assert that we’re essential, and leave it at that, defying anyone to dare say otherwise. But whilst managers and the management-hierarchy seem to be able to get with that, in practice it’s a lot harder for us: people just don’t seem to believe us when we say that we’re essential too! 🙁 They usually want to see some kind of ‘proof’: and that’s hard, because, as with other whole-of-context ‘pervasives’, most of our work takes place between-the-boxes, whereas all the usual forms of proof apply only within-the-boxes. Proving our value has been one the hardest problems that the entire discipline has faced – and we still haven’t reached any kind of irrefutable ‘proof’ yet.

Perhaps a better option would be to align ourselves with other ‘pervasives’ – teams that provide active support and training for a single core-value and/or core-principle that is, by definition, ‘everyone’s responsibility‘. These vary somewhat from one enterprise to another, but some examples that are common just about everywhere – in some cases backed with the full force of law – would include:

• health-and-safety
• environment
• security
• financial-probity
• knowledge-management and knowledge-sharing
• business-ethics
• quality of products and services
• equality, diversity and respect (against workplace-bullying etc)

Each of those ‘pervasives’ has their own value-proposition, their own story: for example, that it’s of value to the whole enterprise that people should be safe at work and elsewhere, hence the need for ‘pervasive-services’ that support that need and value.

The same with us: it’s of value to the whole enterprise that it should be effective, and more effective over time, as a whole – hence the need for a specific type of ‘pervasive-services’ that help people to create an overall context in which things work better when they work together, on purpose. That’s our business-case, our value-proposition, and also our success-criteria: that things do work better because they work together, on purpose.

There are two types of metrics we could use: positive-metrics, and negative-metrics.

Our positive-metrics are about action – about what does happen – and hence are relatively easy to prove, if only at a whole-of-context level. Some of these are fairly straightforward, such as L2C, T2R, I2R and time-to-market, as above – the only complication being that we share those metrics with so many other ‘pervasives’-teams such as process-improvement and knowledge-management, as also above.

Measures of employee-engagement – or related measures such customer-, supplier- and community-engagement – provide another type of positive-metric, that perhaps have even more value as they tend to act as lead-indicators (where things are headed) rather than lag-indicators (where things have been). We can show the linkage to enterprise-architecture here both as part of our overall theme of ‘things working together better’ (the ‘things’ being real-people, in this case!), and also because so much of our work is based on person-to-person conversations and building person-to-person connections – literally creating a ‘working-together’ in each instance.

Another key action is to establish credibility as soon as possible, to build trust that what we do is valuable. If we can do that, then even if people can’t directly see the linkage between what we do and their own outcomes, they’re more likely to trust us anyway. One of the most useful bits of ‘low-hanging fruit’ that we can work on for this purpose – and that typically would only take a couple of weeks at most to create a first version for review – is what’s called a Functional Business Model (or Service Model, or Capability Model – there’s some confusion about which is which and what they each do, but on the surface they all look much the same). We start with a first-tier model, which is pretty much the same for every organisation:

Then fill in the next level of detail, for our organisation:

And, usually, one step further into the detail: at which point – in our experience, anyway – it becomes extremely useful to just about everyone. We not only cross-mapped that ‘three-tier’ version to projects and information-systems and RACI-matrices and much more besides, we also found that just about every line-manager ‘stole’ a copy and pinned it onto their wall, using it for employee-induction, ‘who-is’ look-ups, process-flow troubleshooting and all manner of other affordances – which literally put enterprise-architecture on their map.

Our negative-metrics are about prevention, about what doesn’t happen – and hence are inherently a lot harder to prove. In this we’re similar to some of the other ‘pervasives’ such as security and health-and-safety: their focus, perhaps even more than ours, is to make sure things don’t go wrong.

For enterprise-architecture, we can often show clear value in straightforward prevention and resolution of inter-project clashes and the like. One example that comes immediately to mind was a case where three separate projects from three different parts of the organisation each wanted to instal their own RFID-infrastructures – each technologically-incompatible with the others – in the exact same physical location in the distribution-depot. All we needed to do there was to bring the fact to their attention, and help in the negotiations between them – yet also making it clear that we would not allow that kind of mess to go forward into production.

Perhaps the most important type of prevention for enterprise-architectures, yet also often the most politically-fraught, relates to kurtosis-risks. These are seemingly low-probability ‘long-tail’ risks that most people would often prefer to ignore, but could well have the potential to destroy the whole organisation and its business.

One classic example – which also illustrates just how problematic these risks are – is the ‘quick-profit’ short-term version of the service-cycle:

There’s no question that it usually does give the best financial and other returns in the short-term. The catch is that it does so by destroying the connection to the longer-term – which is not a good idea for anyone who does want to be in business for the longer-term… In particular, what it does – as can be seen in the diagram – is that by taking a short-cut back towards grabbing the attention of the next customer as soon as the organisation has made its own profit, it slowly but steadily erodes shared-trust, shared-purpose, shared-values, the connection with people in general, and even the linkage between policy and purpose. (Australians would describe this as ‘white-anting‘ – external forces eating away at unmaintained foundations.) The result is that everything seems to run really well for a while – and then suddenly collapses, seemingly without warning. The kurtosis-risk here is not in any one process or department of the organisation, but inherent in the entire business-structure and business-model: which means that the risk can only mitigated at the level of the whole structure, too. Yet no-one should underestimate the political challenges involved in doing so…

Other kurtosis-risks do apply only to a single domain or department – though sometimes these may be endemic throughout an entire industry, as a ‘pass the grenade’ risk. One all-too-common example is in so-called ‘Customer Service’, which, particularly when dealing with problems or complaints, may even be intentionally structured to ‘save money’ by frustrating customers and others so much that they abandon the attempt to get their concerns resolved. In the days of social-media, though, that can be a very unwise tactic – as United Airlines discovered to their (very considerable) cost in the case of ‘United Breaks Guitars‘ (see also YouTube).

One reason why kurtosis-risks are so problematic is that, in many cases, the probability of an individual incident triggering a failure is so low that many people would (mis)interpret it as ‘no risk’; yet the constant repetition of what is effectively the same risk radically increases its probability. It’s much the same principle as in half-life for radioactive-fission: a particular type of atom may have a very long half-life, but at some point it will split – and the longer it’s left, and/or the more there are of that type of atom, the higher the effective probability that a split will occur, potentially triggering off a full chain-reaction. It’s this difference between individual risk at a single point, versus collective risk over longer periods of time, that enterprise-architecture is well positioned to identify – and to design means of mitigation of those risks, too.

The one huge danger with any prevention-focus is the natural tendency towards becoming ‘the Department of No’ – such as, in our case, ‘the architecture-police’. Although it is a natural tendency, it’s also a really quick way to lose allies and destroy perceived-value – regardless of how well we actually do our work. The trick, as usual, is ‘Just enough…‘: we could always do better on security or health-and-safety or things-work-better-when-they-work-together, yet it’s also always in context of the overall purpose – and we do need to get the balance right, otherwise it may put risk the whole point of doing anything at all. You Have Been Warned?

What’s the price?

What’s it worth? What will I get paid? What are you going to pay for it? These are kinda important questions for everyone in this space…

Yet there is actually a straightforward answer, that would be fair to everyone involved: base it off the same as all other ‘pervasives’ – all of those other ‘everyone’s responsibility’ themes.

As in all the other ‘pervasives’, there are two key types of roles in enterprise-architecture:

• internal team-member – tasked with identifying, describing, and guiding the implementation of the architectures within the respective scope
• external consultant – tasked with assisting the internal-team to ‘set up shop’, and to develop their operational maturity and capabilities over time

And as also in all the other ‘pervasives’, there are four key types of tasks:

• develop awareness of the theme – help educate people as to why this theme (‘things work better when they work together, on purpose’) is important to the organisation
• develop capability to enact the theme – help people to become better at enacting the theme within their own work (such as training, in-person conversation and suchlike)
• enact the requirements of the theme in all everyday action – the responsibility of everyone, not solely those with ‘enterprise-architect’ or whatever in their job-title
• audit, assess and verify performance for the theme – primarily to identify benefits-realisation, lessons-learned and potential and/or actions for improvement

All of which, again, is essentially the same for all of the ‘pervasive’-type themes that arise from the vision and values of the enterprise and organisation.

So to identify the appropriate salary for a full-time or part-time member of an internal enterprise-architecture team, how much would you pay for someone doing the equivalent tasks in occupational health-and-safety, for example, or security-management, or quality-management, or financial-probity? That’s how much you should expect to pay an internal enterprise-architect – something in that range, anyway.

To identify the appropriate fee for an external enterprise-architecture consultant, how much would you pay for someone doing the equivalent tasks in occupational health-and-safety, security-management, knowledge-management, financial-audit. That’s how much you should expect to pay an external enterprise-architect – something in that range, anyway.

Not more, but also not less: the right ‘just enough’, that’s all. It’s much the same kind of value as every other ‘pervasive’, much the same kind of worth – hence much the same kind of price, surely? Pretty straightforward, really: end of argument, we’d hope.

Anyway, best to stop there, and to finish this series of posts: over to you for comment, perhaps?