Selling EA – 3: What and how

How do we ‘sell’ enterprise-architecture? How do we explain what it is that we do – and why we do it?

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.

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? – the ‘why’ for EA, from others’ perspective
3. What do we do, and how do we do it? – this part, exploring the straightforward practical questions about, well, what we do and how we do it
4. What’s it worth? – both in terms of delivered value, and the kind of price we should charge

So far we’ve established the shared-enterprise that enterprise-architecture shares with its clients, namely making our organisations more effective, for everyone; and we’ve also established the basic value-proposition for enterprise-architecture, that it’s about finding ways, or helping others to find ways, such that things work better when they work together, on purpose.

The latter, though, kinda brings up more questions than it answers – especially when we start to get down into the detail. This becomes clear as we expand that nice comfortingly-generic assertion out into its component parts:

• things – what things? who decides?
• work – ‘work’ in what sense? what work?
• better – better for what? or for whom? who decides?
• when they work together – what kind of ‘together’? how? why?
• on purpose – who decides the purpose? for what?

There are two ways we can deal with this – the quick answer, and the more-detailed answer. For those with TL;DR tendencies, let’s deal with the quick-answer first.

What do EAs do? – the quick version

Enterprise-architects do all kinds of stuff. (No surprises there, really.)

All of the stuff they do is about those two themes above: getting all kinds of different things – and people too – to work together better, so as to help make the organisation become more effective as a whole.

Much of this is about the stuff that’s between the boxes, between the silos – the bits that most people don’t seem to notice, but without which things just don’t work.

A lot of it is also about what are sometimes somewhat-confusingly described as ‘non-functionals‘, all the qualitative stuff about efficiency, reliability, performance, security, environment and so on – stuff that again most people don’t seem to notice much, but are really important for overall effectiveness.

It’s mostly about decision-support, not decision-making: helping others make decisions, not making the decisions for them. The job is about finding the right information, and the right connections, so that people can make the right decisions in context of the whole.

What enterprise architects do, to make this happen, would typically include:

— Set up and engage in conversations – lots of them! Enterprise-architects seem to spend most of their time just talking with people – but it’s for a very good reason, because the conversations provide ways to connect this person with that one, this change-project with that one, help re-think how things work together, re-think how to work with change, and many other themes like that.

— Create and maintain models and diagrams – often the most visible part of the work, but not always the most important one. To a significant extent, models are just ‘decision-records’: and it’s the process of deciding, rather than the end-decision as such, that’s the most important in enterprise-architecture, because it’s what gets people engaged in and committed to the outcomes of those decisions, and the architecture of the whole as whole.

— Develop some aspects of system-design or overall design – though not much, because that’s mostly someone else’s job, and we shouldn’t tread too much on their turf unless they invite us in. Most often the designs will be about ‘what-if’ ideas and experiments, or the overall big-picture: very rarely would it be about detailed-design, other than as an illustration of how various different things or projects might fit together in better ways.

You’ll also hear from enterprise-architects, very often, three responses to questions:

• “I don’t know… (though I do know how to find out, or find someone who does)”
• “It depends… (yet I know how to find out what it depends on)”
• “Just enough… (and I know how to find out what that ‘just enough’ is)”

When you hear that, it’s not because those enterprise-architects are being awkward or indecisive. It’s because they know, from long experience, that they have to work with uncertainty – rather than hoping or pretending that it doesn’t or shouldn’t exist…

Most enterprise-architecture is best done by internal teams, people with a very broad range of skills and experience and, usually, deep social-networks within and beyond the organisation. Consultant enterprise-architects do have an important role, but it’s mainly about helping those internal teams develop and extend their skills-base and the maturity of their discipline and practice – not to try to do the architecture-work itself.

You’ll notice that there’s a bit of overlap there with the work of process-managers, project-managers, system-designers, solution-architects, quality-managers, security-specialists and many others – just about everyone, in fact. But that’s the whole point: enterprise-architecture must overlap somewhat with everything, and everyone, if it’s to be able to help people explore how all the different aspects of the enterprise could work together in more-effective ways.

So what do enterprise architects do? – anything that’s needed to help people get things to work better, together, on purpose, and to make the enterprise more effective overall. Simple as that, really – though note that ‘simple’ ain’t the same as ‘easy’, of course…

What do EAs do? – the more-detailed version

Probably the simplest way to explain what EAs really do is to do a real example of EA in action. Along the way we’ll see some common themes in enterprise-architecture:

• use of frameworks to guide the overall exploration
• use of a toolkit of techniques, tests and methods for sensemaking and to guide decision-making
• iteration and recursion, looping through the same context in many different directions and at different scales, to create an overall picture of the context
• use of model-templates to guide descriptions and sensemaking
• creating descriptive models to guide decision-making and action

In this case we’ll use the Five Elements framework as our base-method here. (Although there are plenty of others we could choose, this one probably fits this need best.) It guides an architectural-assessment in terms of five distinct phases, based in part on the stages of the classic Group Dynamics project-lifecycle:

In this framework, the cycle starts at the ‘Purpose’ stage – the reason to do the work.

That’s Phase #1: Start from a real business-question. We start with an explicit purpose for the work to be done – which, in turn, also gives us some clear indicators of success in terms of that purpose, so that we we know that, and when, we’ve delivered real business-value.

[This is a really important point that should not be missed: EA is always about delivering real business-value, by addressing real business-questions with real business-needs and real business-outcomes. In that sense, it’s not an ‘academic’ discipline at all, but highly practical – and very much business-focussed. The only thing that might seem ‘academic’ at first is that quite often – as we’re about to see – it looks at a business-context in a somewhat different way from what some business-folk might expect; but as you’ll also see in a moment, it would also need to do so in order to get the job done.]

So for something to work on, let’s pick up on that first set of business-questions with which we started the first part of this series:

• What do we do about complexity?
• What do we do about the stuff we can’t control?
• What can and can’t we automate?
• Why can’t we get our strategy to be followed?
• Why do our front-line staff screw up all the time?
• Why can’t our front-line staff work things out for themselves?
• What training do our staff need? – and for what?
• What skills do we need, where, how, why, and when?

At first glance, those questions might all seem somewhat different from each other: but when seen with an enterprise-architect’s eye, there’s a common theme there straight away – they’re all about different aspects of working with real-world complexity. That’s so much a consistent theme in business, with so much pain about it all too evident when we look around our organisations, that it kinda suggests there’s something here that’s making it perhaps much harder than it need be to address that complexity. But let’s hold that thought for moment, whilst we make our first moves into the next stage of this architecture-cycle.

And that’s Phase #2: Identify and engage with the stakeholders – an emphasis on the people-aspects of the context.

So who are the stakeholders here, in tackling organisational and enterprise complexity? The short-answer is almost everyone, really. For here, though, we’ll focus most on the nominal ‘key decision-makers’ – executives, managers and the like, the people who would usually be described as ‘business leaders’. It’s their usual ways of thinking and decision-making that we’ll most need to address here.

Which brings us to Phase #3: Identify what’s going on in the context – otherwise known as sensemaking.

So how do people usually tackle themes such as sensemaking and decision-making, about complexity and suchlike in business? The classic ‘take control!’ approach to this kind of context, to which I’d guess most of our putative paying-clients would at first adhere, would have these kinds of expectations:

1. Predictable, pre-proven answers – pre-made ‘solutions’ for predefined ‘problems’
2. Predictable, certain, step-by-step instructions
3. An absence of responsibility on their part – the ‘solution’ is in effect Somebody Else’s Problem
4. Once it’s solved, they don’t need to think about it any more – it stays solved, it’s ‘fit-and-forget’

It describes change in terms of ‘problem-space’ and ‘solution-space’: every change is described as a problem, requiring a solution. To illustrate this in visual form, we’d start with a problem – full of all sorts of unwanted uncertainties – which, in classic business-analysis, we’d describe in terms of a problem-space:

We then apply classic business-analysis techniques – break the problem into its component parts, eliminate complexities, all that sort of thing – building requirements for a solution, in solution-space:

All of this is supposedly the responsibility of ‘special-people’ – the business-analysts or whatever – who might well be brought in from outside because of their special knowledge of existing plug-and-play ‘best-practice’ from elsewhere. (Note this key point that the ‘problem’ – whatever it is – has already been reframed by this as Somebody Else’s Problem.)

On their advice and guidance, the solution is implemented – and that’s the end of it. End of problem – no more problem. Once a problem is solved, it stays solved – that part is important.

All of which is, yes, highly desirable in most business-contexts – which is why there’s a huge business-consultancy market selling endless variations on a theme of pre-packaged ‘solutions’ for this-that-and-the-other. (It’s not just business-consultancy, of course: for example, ‘Gardening Solutions’ emblazoned across the service-truck of the landscaper visiting my neighbour across the road this morning.)

There’s only one catch: it doesn’t work.

Okay, that’s a bit unfair: it does sort-of work, at least well-enough to keep a lot of people in business. Yet when our aim is to address the kinds of complexities that we face in many business-contexts – and, in particular, those that involve working at the level of an overall architecture – classic Taylorist-style ‘solutioneering’ only works well, if at all, in a narrow small subset of those business-concerns: not all of them, as is so often purported or proposed. And trying to use classic ‘solutioneering’-type techniques outside of those specific domains will usually only make things worse – or, even more, uh, fun, will seem to work for a while, and then suddenly fail in ‘inexplicable’ ways. Not such a good idea…

The way that is proven to work well with almost all types of complexities is this:

1. It’s all about getting clear about what the real questions are
2. There’s no certainty about the steps – and we work with that uncertainty, rather than trying to ‘control’ it
3. All of what happens must remain the stakeholders’ own responsibility and ownership – otherwise it won’t work
4. It typically requires a lot of thought and engagement

Which, unfortunately, is almost the exact opposite of what our clients would often expect or want. Awkward…

Yet since so many people are so wedded to this notion of ‘solutioneering’, which we know doesn’t work, how do we convince them otherwise?

Short-answer: we don’t – not at first, anyway.

Instead, we do it ‘by stealth’: working in ways that look they’re regular everyday solutioneering, but actually aren’t. Crucially, we don’t ever tell them that they’re ‘wrong’ – just that sometimes we need to do it a slightly different way, before we can get to the simple ‘solutions’ that they know and want. We reframe what we have, into what people seem to believe they want, such that they get something that works, and we get a chance to actually get paid for what we really do. For example, the reframe might look like this:

1. Finding the right way to frame the question itself delivers ‘the answer’; finding the key factors in a wild-problem enables dynamic ‘re-solution’
2. There is a clear process, with clear activities and clear outcomes – it’s only the selection and sequence of those activities that varies, dependent on context
3. Acknowledging personal-responsibility creates power and engagement, and helps in supporting ‘Unique Selling Proposition’ and suchlike in their marketplace
4. The thinking and the exploration also makes it feel worthwhile – creating engagement with stakeholders across and beyond the organisation

Interestingly, one of our key allies here is the ISO9000 family of quality-system standards – which most of our prospective clients either do or should already know. There are four distinct layers:

• work-instruction: the step-by-step instructions for a predefined ‘solution’
• procedure: instructions for how to create new work-instructions when the conditions have changed
• policy: guidelines for how to create new procedures when the broader context has changed
• vision: principles to guide creation of new policies when the overall context has changed – ultimate anchor for all policies, procedures and work-instructions

When the detail-level changes, we need new ‘solutions’, new work-instructions: we go up to the procedure to tell us what’s needed for those. And likewise for when we need new procedures, or new policies – all the way up to the enterprise-vision, which does not change. (If it did, we’d no longer be in the same enterprise: it’s that fundamental to what the enterprise is and does.)

And, for enterprise-architecture, we have our shared-vision: “making our organisations more effective, for everyone”. And we have our core value-proposition, which drives our policies and so on, in relation to that shared-vision: “things work better when they work together, on purpose”. It all fits, just fine – enterprise-architecture as a practical expression of the aims of ISO9000 and the like.

But notice one important catch: ‘solutions’ only apply at the work-instruction level of a quality-system. For any other level – procedure, policy, vision – we’re going to need something else. Which is what all of this is about.

We’ve already explored the top-level bit – the vision. That’s pretty much done, I think? So what we need now is a systematic approach to the rest of it – how all of that works, in practice.

One way we can illustrate this is with the SCAN framework on sensemaking and decision-making:

The first point with this framework is that there’s no real distinction between ‘problem-space’ and ‘solution-space’ – it’s all one contiguous, interactive, interweaving context-space, a description of how ‘problems’ and ‘solutions’ interweave with each other in that context.

The vertical dimension here is a fairly arbitrary metric of the amount of time available before we must take action – marked as ‘NOW!’, at the baseline. At some point along that dimension, there’s a distinct kind of boundary, such as that between theory and practice, or between plan and action. That boundary can move around a lot, but in effect it divides the space vertically in two – with what are often distinctly-different tactics and ways of working, either side of the boundary.

The horizontal dimension is another arbitrary scale, from absolutely-certain or absolutely-same over on the left, to infinitely-uncertain or unpredictable or unique extending towards infinity over on the right. And again there’s another kind of somewhat-dynamic boundary some way along this line – a ‘boundary of effective-certainty’. To the left of that boundary, if we do the same thing, we’ll always get the same results; to the right, if we do the same thing, we might or may or will get different results, or we may have to do different things to get the same results. And as with that boundary on the vertical dimension, there are distinctly-different tactics and ways of working, either side of that horizontal-dimension boundary.

In effect, these two dynamically-changing boundaries split the context-space into four different domains or modes of working-on-the-world – all of which are ultimately in the same context-space, ‘problem’ and ‘solution’ all interweaving with each other.

The classic Taylorist-style split between ‘problem’ and ‘solution’ only works well with tame-problems – ones that stay the same once we’ve ‘solved’ them. Yet in exactly the same sense that domesticated-stock and other tame-animals are a small subset of the real-world set of wild-animals, tame-problems are only a subset of wild-problems , problems-in-the-wild (otherwise known as ‘wicked-problems‘, though it’s perhaps a bit unfair to describe them as such?). Or, to put it the other way round, the real-world consists only of wild-problems; tame-problems are just a special-case that, for now, seem somewhat amenable to the taming-tactics of ‘business-rules’ and suchlike (yet may – again like some seemingly-tame animals – suddenly revert to their true wild-nature, seemingly without warning…).

Which, when we map it onto SCAN, looks a bit like this, with the blue part being what works reasonably-well with Taylorist-type tactics, and the rest in grey that doesn’t:

As we can also see from this, the supposed certainty and ‘tameness’ of many apparently-predictable ‘solutions’ often turns out to be a lot less real once we move down from theory into practice, from plan into real-world action… Otherwise known as ‘the Devil in the detail’ – or Yogi Berra’s classic catchline that “In theory there’s no difference between theory and practice; in practice, there is!”.

This also helps to answer two of those other business-questions with which we started here:

• “Why do our front-line staff screw up all the time?” – it’s probably because things look a lot more ‘controllable’ at a safe distance away from the action, than they do when you’re in it, having to respond in real-time
• “Why can’t our front-line staff work things out for themselves?” – it’s probably because you’re not allowing them to do so, by forbidding them from doing anything than follow your rules, formulas and predefined processes, that in practice simply don’t work ‘at the coalface’

The ISO9000 set can come back into play to help us at this point, because each of the layers is a kind of ‘meta-layer’ for the next one below.

[There’s nothing strange or scary about ‘meta-‘: it’s just a label we use to mean ‘next level up’ in terms of where and how it works.]

The classic ‘solutioneering’ is a set of methods that, in effect, describe how to move from plans and procedures to real-time work-instructions, such as implemented in business-processes or computer-code. So to define new procedures – that structures and frameworks that apply those methods – we’re going to need metaframeworks and metamethods, driven by policies. Then to define those, in turn, we’re going to need metametaframeworks and metametamethods, drawn directly from the vision itself. And all of these are just methods and frameworks, but used in a ‘meta-‘ way, that’s all.

Yet there’s one more very important twist: the enterprise-vision, and the attendant meta-meta- stuff, are what we’d also rely on at real-time when the work-instructions don’t work and there’s nothing else to turn to and no time to do so anyway – which happens a lot. That’s why the vision is so important to an enterprise, and any organisation working within that shared-enterprise – and why it’s so dangerous, all too often, people in the organisation don’t even know what the real vision is…

We can see all of these relationships mapped-out on a SCAN cross-map with ISO9000 – perhaps in particular, note the SCAN ‘edges’ that also denote transitions of tactics, techniques and ‘meta-‘ layers:

The part that might seem confusing at first is that, again, what actually happens in making sense of real-world complexity is a lot messier than that supposedly nice smooth transition from ‘problem’ to ‘solution’ would seem to suggest. Some while back, I mapped out onto the SCAN frame, in as much detail as I could track, everything that I’d done to try to make sense of a really simple-seeming everyday problem: the toaster had stopped working. Even something this trivial turned out to be surprisingly complex: there were at least 30 identifiable steps in the sensemaking-process – all of the assessments, decisions and actions that were needed to eventually arrive at a workable conclusion. And, as can be seen from the graphics below, they jump around, literally all over the context-map:

Imagine, then, what it’s really like with a business-problem bounded by real complexities: ‘all over the map’ would at first seem like an understatement in the extreme… That’s where the skills of an enterprise-architect really come into play, in helping people make sense of what’s actually going on in that kind of real-world mess.

Yet notice that there is a map here: a consistent frame in which activities can seemingly jump around ‘all over the place’, and yet still make sense as a whole. That’s why enterprise-architects use all of those frameworks and suchlike: they provide a reference around which some kind of sense can coalesce, even in the most complex of contexts.

Given all of that, let’s move to a more realistic business-type example, using the same SCAN framework. Imagine that we’ve been tasked with rethinking the operational-architecture of a surgical unit in a hospital. We want to look at everything that goes on or that is needed – or might be needed – leading up to a surgical-operation in an operating-theatre: activities, information, incidents, events, assets and suchlike. As part of this, we might map out various of these items on the SCAN frame, in terms of what certainties or uncertainties we might have or need – the ‘horizontal’ dimension in SCAN – versus how far ahead in time each of these might occur, or need to occur, relative to the ‘NOW!’ of the moment of the operation itself – the ‘vertical’ dimension in SCAN. If we do that, we’d probably end up with a context-map that looks a bit like this:

Those items over towards the left are what we’d probably think of as routine: not much more than tick-the-box exercises, really. And yet they’re all absolutely essential: there should be no doubt about that at all. For these, we’d want, as far as practicable, to eliminate all uncertainty and complexity:

And because this is certain, and needs to be certain, this is one area for which automation is a very good fit – certainly as back-up and confirmation for ‘manual’ processes. Which, in turn, gives us part of an answer towards one of the questions about complexity with which we started here: “What can and can’t we automate?”.

Moving towards the right, at or close to or somewhat beyond that ‘boundary of effective certainty’, there are a bunch of items around which we expect there to be uncertainties – complexities that we know we cannot actually remove. We’re dealing with human uncertainty here: for example, the patient’s condition might change at any time. Staff-availability may change at any time, no matter what it says on the automated work-roster. And as we get closer to real-time, real-world uncertainties may march into the picture, ‘beyond our control’ and all that: for example, the hospital’s need to respond to a major road-traffic incident might push our surgeon and her team out of the operating-theatre, with their patient already in pre-op. For these, we’d need clear, practised protocols to guide response to each expected uncertainty, each ‘known unknown’ – because we have no choice here but to embrace the complexity:

And this also adds another aspect to that answer to the question about “What can and can’t we automate?”. Trying to automate all of this, with predefined ‘business-rules’ to attempt to cover every eventuality, will risk leading us back into ‘analysis-paralysis’: better, then, to use automated systems here primarily for decision-support, not decision-making.

Further to the right again, we start to move into the territory of ‘unknown unknowns’ – the real uncertainties and emergencies:

If these ‘not-quite-unknown-unknowns’ (unexpected, yet a known risk) are far enough away in time from the point-of-action – in the operating-theatre, in this case – then we have some chance that some predefined protocol might help. For example, given the risk that other members of the patient’s family might get into a panic about the risks of the operation, we’d aim to have a chaplain and other support-services available on-call, ready to respond at a moment’s notice, and keep the family away from the operating-theatre – otherwise they’d increase the risks to the patient…

Yet when it gets much closer to real-time, or in real-time itself, then we really are into ‘unknown-unknowns’ – the true emergencies, where something must be done, right-here, right-now, to bring whatever’s happening right-here right-now back towards the initial intent of the action. In an operating-theatre, it’s quite probable that the ability to do that – and do it well – is literally a matter of life and death. And a matter of real human skill, too.

Which, again, adds another aspect to our answers to that question “What can and can’t we automate?” – the more inherent-uncertainty or inherent-uniqueness there is, the less we can automate, and the more we must rely on human skill. Which means that we need people to develop those skills in the first place – and not rely on automation to do it all for them at the press of a button.

Which, in turn, points towards probable answers for two of our other questions: “What training do our staff need? – and for what?”, and “What skills do we need, where, how, why, and when?”.

The short-answer to the first question is that we’re going to need some form of training for everything that happens in real-time – and especially so where we need people to respond appropriately ‘without thinking’, via learned-reflexes, as they must do in any real emergency. (The same applies to machines, too: in a quite literal sense, every computer-program is a form of training, such that the system responds appropriately in real-time to its inputs and environment.)

And the short-answer to the second question is that we’re going to need someone available at all times with skills sufficient to tackle anything that might occur on the far side of the ‘boundary of effective certainty’ – in other words, anything over to the right-hand side of the SCAN frame. The process and system will fail if it meets up with irresolvable uncertainties when those skills are not available. The classic Taylorist approach – escalate ‘upwards’ until you meet up with someone who does have the requisite knowledge and authority to resolve what’s going – can sort-of work in certain slow-moving processes: but by definition it slows things down, because with each step ‘upward’ it moves further and further away from the ‘NOW!’ – and, as a side-effect, tends to create ever-increasing levels of ‘failure-demand‘. If we need uncertainties resolved in real-time, we must have appropriate types and levels of skill available at the point of action – not tucked safely away in the manager’s office or the executive suite.

Which brings us to Phase #4: Take action, ‘Follow the process’ – which, in a sense, also sort-of happens at the same time as Phase 3, because sensemaking, decision-making and action all interweave with each other at the point-of-action – iterative, recursive, fractal, all that kind of stuff. Yeah, it’s kinda complicated… complex… whatever… – and yet all of it is centred around that overall theme of ‘things work better when they work together, on purpose‘.

Note, of course, that the enterprise-architects wouldn’t attempt to learn all of those skills in every context themselves – though they do need to learn ‘just enough‘ to understand all of the key factors in an ‘it depends…‘ about each context in scope. Instead, as we’ve seen above, the main action that enterprise-architects take is to hold conversations with stakeholders; use frameworks and models of any appropriate kind to map out the context in whatever ways will help sensemaking and decision-making in and for that context; and help guide that decision-making, and subsequent action, to support appropriate change in the context.

One point we do need to add here is the notion of ‘maturity-levels’. This is not about arbitrary labels – for example, purporting that one organisation is ‘more advanced’ than another – but much more about identifying where the enterprise-architecture team could deliver best value at the present time. This is the maturity-scale I use in my own work, as described in the book Doing Enterprise-Architecture:

(The overall maturity-model, architecture-process and the details for ‘Step 1: Know your business’ are all described in the free-sample edition here, with the complete maturity-model described in the full ebook editions here.)

Each Step in the maturity-model represents the recommended focus or emphasis for the current stage of enterprise-architecture work, and builds capability towards the next maturity level: respectively foundations; vision and basics; ‘horizontal’ clean-up; top-down; bottom-up; and ‘bring on the pain’ – tackle the business pain-points, its real ‘wild-problems’. It’s not that we can’t do the work from ‘higher’ Steps – we can tackle some of the pain-points right from day-1, if need be – but the clean-up and capability that we add with each systematic Step will make the outcomes more durable, resilient, self-adapting to future change: in other words, the nearest we’ll ever get to ‘fit-and-forget’ for any real wild-problem.

Which, finally, brings us to Phase #5: Performance – otherwise known as ‘Benefits realisation and lessons-learned‘. Which we won’t tackle here – we’ll leave that for the next and final post in this series.

So let’s stop here for now: probably more than enough, I’d guess? But hope it’s useful, anyway – over to you for comment and suchlike.