Selling EA – 2: The value-proposition

How do we ‘sell’ enterprise-architecture? What’s the story, the value-proposition?

This series started as a bit of ‘thinking aloud’ about 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 – because, to be honest, it’s a been bit of a struggle to make it so at present.

I’ve split this series 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? – this part, exploring the ‘why’ for EA, from others’ perspective probably more than our own
3. What do we do, and how do we do it? – the straightforward practical questions
4. What’s it worth? – both in terms of delivered value, and the kind of price we should charge

Let’s look at this in terms of a shared-enterprise, with enterprise-architecture in relation to immediate suppliers and clients, its broader ‘market’, and its overall community of investors, beneficiaries and other stakeholders:

For the moment, we don’t need to go into too much depth here about that overall community or market: instead, let’s just focus on the client/provider relationship. For that, we need to be a bit more explicit about looking at this from either side of the interaction-journey between enterprise-architecture, and its business-clients – one side looking inside-in (at itself and its internal needs) and inside-out (provider to customer), the other outside-out (at itself and its overall needs) and outside-in (customer to provider):

For a typical enterprise-architecture client, we’d usually do this kind of context-mapping with the company or organisation on the inside, looking out, and their customers and other stakeholders on the outside, looking in. But here, for enterprise-architecture itself, we need to switch it round: we’re ‘the organisation’, selling our services; and our business-clients, or our organisations, are the ones on the outside, with – as we saw in the previous part in this series – what’s probably a very different perspective to our own.

So, how do we bring these perspectives together, and bridge the gaps?

Answer – exactly as in our own architectures – is a story.

And – again as with our own architecture work – we build that story-line out of three questions:

— What is of concern to everyone in this shared-enterprise?

For this shared-enterprise, what’s of concern to everyone here is effectiveness of our organisations. There are a fair few ways to define it, of course, but the definition of ‘effectiveness’ that I use describes it in terms of five distinct dimensions or themes:

• Efficient: optimises use of resources, minimises wastage of resources
• Reliable: predictable, consistent, self-correcting, supports ‘single source of truth’ etc
• Elegant: clarity, simplicity, consistency, self-adapting for human factors
• Appropriate: supports and optimises support for business purpose
• Integrated: creates, supports and optimises synergy across all systems

In essence, we could say, effectiveness happens when everything supports everything else, in terms of those five themes above.

— What is everyone in this shared-enterprise doing to or towards or about the concern?

Short-answer to that one is ‘lots and lots of different things’ – by definition, pretty much anything and everything that’s relevant, including assessments and reviews and rethinks and and restructures and restorying and innovating and modelling and much much more – so it’s probably best to summarise it all with some kind of blurry generic such as making organisations more effective. The ‘more‘ adjective is important here: it’s not just about assessment and suchlike for its own sake, it’s about using those assessments to guide constructive change so as to help make things more effective – in an increasingly dynamic environment too, in many cases.

— Why is this important to everyone in the shared-enterprise?

Again, the short-answer is simply that it’s better for everyone when organisations are more effective – especially, when more-effective overall. Equally, consider the inverse: the miserable consequences for everyone of being involved in organisations that are not effective provide enough reason, just on their own, for people to want to put the effort in to make them more effective. This ‘why?’-question is about the emotional-drivers behind the enterprise: and dispelling that misery is certainly a powerful driver in itself.

So if we summarise all three of those answers in a single phrase: we’re making our organisations more effective, because it’s better for everyone involved that we do so.

Or, in shorter form as a storyline: making our organisations more effective, for everyone.

Does that storyline make sense for everyone in this shared-enterprise? Test it out against the perspective or viewpoint of any stakeholder in the enterprise’s context-space, in relation to or with any other stakeholder:

Okay, we might quibble about it in a few cases, perhaps, but in general it works well enough, pretty much everywhere, doesn’t it?

Which gives us two crucial things:

• the reason for the shared-enterprise to exist – the foundational ‘why’ for all interrelations and interactions in its context-space
• the definition of success and value in the shared-enterprise – if we’ve made something more effective, or are contributing towards making something more effective in the future, then that’s a success in terms of this shared-enterprise

Those apply to everyone in this shared-enterprise – every player. Yet for here, let’s bring this back to the specific case of enterprise-architecture.

Everyone in a shared-enterprise does something towards the aims and goals of the enterprise – otherwise they wouldn’t be part of it. And when we look at enterprise-architecture, the bit that we do towards that aim of ‘making organisations more effective’ is that we focus on how things link together, work together, and work together better.

We might do that just in IT, or in process-flows, or by modelling all the data for a ‘single-source of truth’; we might do it in terms of ‘business/IT-alignment’ or some such; we might do it across the client-space, for themes such as ‘customer single-view of organisation’; we might do it at a whole-of-organisation or even whole-of-enterprise level. It doesn’t really matter – there are lots and lots and lots of different aspects and different ways of doing ‘how things work together better’, and it’s fair enough to say that they’re all ‘enterprise-architecture’ in one sense or another.

Notice also what we don’t do:

• we don’t do all that much of the design side of ‘linking things together’ – that’s typically a solution-architect’s job, not ours
• we don’t do all that much of coordinating change – that’s a project-manager’s job, not ours
• we don’t do that much of linking things together at run-time – that’s done by the people, machines and other ‘operators’ of the organisation’s business-processes and their service-providers and clients

What we do – and that just about no-one else does in this space – is find out and describe how we can get all the different moving-parts and infrastructures to fit together to make things work better. (We also help others to do this, in fact we’d probably do more of that support-work – building conversations and connections across the organisation – than we do of the linking-things-together work ourselves: but it’s essentially the same end-point that we’re aiming for, whichever way we do it.)

So let’s summarise that as the part that we, as enterprise-architects, play in this shared-enterprise of “making our organisations more effective, for everyone”, is that it’s guided by a single core idea: things work better when they work together, on purpose.

(The ‘on purpose’ bit should actually incorporate all five of those themes of effectiveness as described above, and probably a lot more as well – but ‘on purpose’ is enough of a proxy for that, for our purposes here.)

Which, if you think about it for a moment, is actually our value-proposition – because the value-proposition represents what, how and why we propose to deliver value to the shared-enterprise.

That’s what we do, as enterprise-architects, and why we do it, too: we propose to our business-clients that we will deliver value by finding ways, or helping others find ways, such that things work better when they work together, on purpose, in order to support the shared-enterprise aim of making our organisations more effective, for everyone.

That’s it: that’s the story of enterprise-architecture, the purpose of enterprise-architecture, the activities of enterprise-architecture, the guiding-principles for success-metrics for enterprise-architecture – the value-proposition for enterprise-architecture – all packaged into that one sentence above.

Kinda simple, really. (Though ‘simple’ ain’t necessarily the same as ‘easy’… 🙂 )

Okay, fine: we have our value-proposition, our promise to the shared-enterprise: what do we need to do to deliver on that promise?

Quite a lot, of course: and that’s what we’ll explore somewhat in the third part of this short series. But hope it’s been useful to you so far, anyway?