Context-perspectives and enterprise-architecture maturity

In what ways does what we do within the enterprise require a different perspective on the enterprise itself? In what ways does our maturity-level – our skills, competence and experience – affect what we can and should do within the enterprise? And what happens when we bring those two concerns together?

This one started out as a classic bit of context-space mapping: take two supposedly-different models, put them side by side, and see what insights arise. But then it got kinda interesting…

The first of these two models is about different perspectives that we need in order to make sense of what’s going on within an enterprise – inside-in, inside-out, outside-in and outside-out:

If we frame the overall shared-enterprise as a kind of ecosystem, within which the organisation is merely one element amongst many:

Then those four perspectives describe the views most relevant to any one player – ‘the organisation‘ – within that shared-enterprise:

— inside-in – the world viewed as if the organisation is the only thing that exists. We need this view in order to focus on internal efficiency and suchlike.

— inside-out – the world viewed as though it exists to serve the needs of the organisation. We need this view in order to determine how to present and execute an offer of product or service to other players in the shared-enterprise.

— outside-in – the organisation viewed as if it may be something that the world needs. We need this view in order to identify what other players within the enterprise actually want, and how to interact with them – especially over the longer-term, beyond just the immediate ‘sales-cycle’.

— outside-out – the respective ‘world’ in its own terms, whether or not the organisation exists. We need this view in order to identify the values – what value is – within the enterprise, and hence what value-metrics to apply, what hidden costs and anticlient concerns and kurtosis-risks and suchlike might apply, and how to position our organisation and its offerings overall in relation to the shared-enterprise.

Note that much of this is recursive and fractal – for example, much the same applies in the relations between the organisation and its employees.

The other of the two models here is about enterprise-architecture maturity, and the respective focus of what we need to do at each level of architecture-maturity:

Classic maturity-models, such as the CMMI-based maturity-model in the TOGAF framework, focus on measuring supposed levels of maturity – as per the five CMMI-type levels across the horizontal axis at the top of that diagram above. Much more helpful, though, is to identify the tasks that help us move from one maturity-level to the next – the ‘stepping-stones’ for enterprise-architecture, as described in detail in my book Doing Enterprise-Architecture. In effect, we reach ‘Level 1’ maturity when we’ve proven our competence in practice in all of the tasks for ‘Step 1’, and so on towards ‘Level 5’ and beyond.

(Note for EA folks in Australia and nearby: this maturity-model here will be the basis for my workshop-session at the Australasian Enterprise Architecture Conference in Sydney later this year.)

One of the key points we need to note about this maturity-model is whilst we might describe it as if it’s a step-by-step process, that isn’t how things actually work in practice. In effect, the steps represent an idealised sequence – the way we’d develop the architecture for an existing organisation if Reality Department didn’t barge in all the time to mess things up… – which it does, of course. Which is why, in practice, we’ll find ourselves doing tasks from each of the steps, all interweaving with each other, all of the time.

What this does mean, though, is that anything that we miss in the development-sequence – because we’re so busy doing something else – will almost certainly turn out to be something that we’ll have to come back and fix again some other time later. For example, if we haven’t cleaned up the mess (Step 2), we’re likely to end up with a messy, inefficient and potentially-unreliable implementation of strategy (Step 3); and ability to respond well to rapid real-world change (Step 4) will also depend on solid practice with moving from strategy to execution (Step 3) and a clean, efficient infrastructure (Step 2). Which is why, whenever we get the chance, we need cut down on the technical-debt from out-of-step development – and that’s where this maturity-model comes in, to provide guidance on priorities and purpose for the respective tasks.

As you can see from the above, both of those models are useful in their own right for enterprise-architecture. What’s interesting, though, is what happens when we put the models together, side-by-side – because it turns out that each of those steps places its main focus on a different perspective within the overall whole:

It’s then useful – yet worrying – to see how this compares to current supposed ‘standard’ frameworks for enterprise-architecture, such as the TOGAF/Archimate pairing:

— Step 1, ‘Know your business’: focus on identity, business-purpose, high-level understanding about the broader shared-enterprise and the organisation’s place within it.

There’s almost nothing on this in either TOGAF or Archimate: there are a few hints on this in the TOGAF Architecture Development Method (ADM) ‘Preliminary Phase’, and both TOGAF and Archimate do now include entities for motivation and the like in their metamodels, but overall that’s about it. That’s a huge gap in those frameworks, and a crucial one, because without it, there’s almost no guarantee that anything in the architecture will actually be done ‘on purpose’ relative to the shared-enterprise, or even for the organisation as a whole. Oops…

— Step 2, ‘Clean up the mess’ (and keep it clean!): an emphasis on efficiency, reliability, cost-reduction, reduction of unneeded duplication and redundancy – a classic inside-in view.

This is the kind of task that TOGAF was originally built for: to guide cleaning up the mess in a typical big-IT infrastructure, especially after merger/acquisition and the like. Up until TOGAF version 8, it was actually very good at that; it’s arguably been pushed somewhat into the background in later TOGAF versions, in part to keep the framework down to a manageable size, but also because with the rise of cloud and suchlike, those classic big-IT estates are becoming a lot less common than they previously were. Archimate can definitely help in these tasks too, though, as with TOGAF, only for IT-oriented architectures: for anything beyond IT, it’s so arbitrarily constrained in what it can and can’t describe that it can sometimes be worse than useless…

— Step 3, ‘Strategy and stuff’: an organisation-centric view, focussing top-down from strategy to execution, supporting ‘push’-type marketing via an inside-out perspective.

This is probably the main purpose of TOGAF version 9 and onwards, and likewise Archimate, especially since version 2: they’re actually very good at it, as long as your primary concern is centred around some form of IT. But that’s the catch: in both cases, the underlying metamodels and ‘architecture-layers’ model not only focus almost exclusively on IT, but actively prevent us from looking at anything else in equivalent depth – which we’d need to do if we’re to build appropriate descriptions across the architecture as a whole.

— Step 4, ‘Work with the real world’: focus on outside-in, on ‘customer-journey’ and other interactions with the organisation, and on changes coming in from the real-world, or ‘bottom-up’ – such as the real business-reasons behind ‘shadow-IT‘ and the like.

It’s true that TOGAF and Archimate can both be used for this: for example, see the work of Bizzdesign consultant Bas van Gils for practical descriptions of the latter. Yet the reality is that neither is designed to do so, and almost every aspect of them will get in the way, every step of the way. The real source of the difficulty is that, like so many other ‘enterprise’-architecture frameworks, TOGAF and Archimate are designed around, and for, IT-architecture: and anything that centres around people – as much of the work in this step most definitely does – is likely to be far beyond their capacity to help. Instead, they’re more likely to hinder – and mostly do, by constantly pushing us towards their in-built IT-centrism. Much of business-architecture is little better, replacing the IT-centrism with an almost more-misleading ‘money-centrism‘ – all too evident in Business Model Canvas, for example. To get away from those unhelpful constraints, we often need to look much wider afield, such as tools and techniques for customer-journey mapping and the like, and frameworks (PDF) that do cover far more of the overall enterprise space. Given that a lot of current core concerns in IT-oriented ‘enterprise’-architecture – such as social, mobile, big-data, customer-analytics, healthcare, cybersecurity, internet-of-things – all start from and depend on a people-orientation, then this is lot more critical and urgent than it might otherwise seem…

— Step 5, ‘Powering on’: focus on outside-out, on enterprise-drivers that would apply whether or not the organisation existed, and on relationships with non-clients, anticlients and others who, whilst not involved in any transactions with the organisation, are still capable of affecting its social-legitimacy, credibility and trust, even to the extent of causing its not-so-metaphoric ‘social licence to operate‘ to be withdrawn.

Let’s put this at its simplest: TOGAF and Archimate have nothing for this – for the tasks in this Step. (To be fair, neither have most of the other ‘enterprise’-architecture frameworks, so we shouldn’t single them out for this failing.) It’s true that they do have a small handful of process-descriptions and metamodel-entities that can be kludged to sort-of-work for this purpose – mainly the ‘Motivation’ set that’s provided as an optional ‘add-on’ in both cases. But the reality is that everything about those items is geared, at most, to supporting Step 3, not Step 5: and if we use them ‘as advertised’, we’ll likely delude ourselves into thinking that we’re doing whole-of-enterprise ‘outside-out’ when all we’re actually doing is another self-centric ‘inside-out’ – which is not a good mistake to make… As with Step 4, we’ll have to look a long way outside of mainstream ‘enterprise’-architecture for concepts and toolkits that can actually help with this.

(The above summaries show us that whilst the TOGAF/Archimate pairing are undoubtedly suitable for certain types and aspects of IT-architecture that focus on Step 2 and Step 3 tasks, neither of them include much, if anything, to support Steps 1, 4 or 5 – without which real-enterprise architecture cannot be done. Hence, to be blunt, the TOGAF/Archimate pairing is not an enterprise-architecture framework in any meaningful sense of the term – and they should not be described as such. Because of their severe yet too-often-ignored limitations, their continuing supposed ‘success’ in the marketplace in effect also represents a scale of damage to the profession and disciplines of enterprise-architecture – and we really do need to bring an end to it as soon as possible, before the damage becomes irreparable and irreversible. See the posts ‘Spot the difference‘ and ‘On layers in enterprise-architecture‘ for more detail on this.)

Perhaps the single most important insight from that crossmap between the perspectives-model and the maturity-model is about what happens between inside-out and outside-in, and between Step 3 and Step 4. At that point, we hit up against what is still, for many people, an impassable road-block: a requirement for a fundamental shift in paradigm. Key concerns in this shift include understandings and assumptions about:

• how enterprises work
• the nature of value
• what is the real centre (or even the definition) of the enterprise
• what is and is not ‘in scope’ for the organisation, the enterprise and its architectures
• content versus context
• the nature of problems and their solutions
• the role of management, IT and other support-services

Up until this point – the Step 3/Step 4 boundary, or facing up to the complexities of customer-journey and the like – the usual assumptions are that:

• enterprises exist to ‘make money’ for shareholders and employers – and perhaps also, secondarily, for employees
• ‘value’ is exactly synonymous with ‘money’
• the organisation is ‘the enterprise’, and every analysis or concern revolves around the needs of the organisation alone
• anything within the organisation may be in scope; everything within the organisation is partitioned into fiefdoms or domains; boundaries are absolute; anything beyond the current fiefdom, or certainly anything beyond the organisation, is Somebody Else’s Problem
• the primary focus is on content, as specified by predefined ‘solutions’ and ‘best practices’
• problems are expected to be solved – and once solved, to remain solved
• the role of management is to keep everything under control, for which purpose IT is well-suited to assist

Such assumptions still seem to form the core of most current business-education, and can be seen implicit in most existing ‘enterprise’-architecture frameworks such as TOGAF. In SCAN terms, for example, we could summarise the IT side of those assumptions visually somewhat like this:

Whilst the management attitude would probably look more like this:

And if the world doesn’t fit the assumptions – as in the lower real-time-oriented part of that diagram, with “should be in control” and “ignore it (it doesn’t exist)” – then it’s the world that’s deemed to be at fault, not the assumptions…

The risks with that attitude should be kinda obvious, I’d guess…? There’s also this useful reminder in a Tweet this morning from Jörgen Dahlberg:

Architecture as a way of thinking and reasoning about business has to focus on context, because business is all about context.

Yet to get beyond ‘inside-out’, or to make sense of Step 4 and beyond, all of those assumptions need to change: it’s not just that “business is all about context”, it’s more that everything is all about context. The changes in perspective would include:

• enterprises exist to deliver value to all of their stakeholders – not just arbitrary subsets of those stakeholders
• money is, at best, a minor and often misleading subset of value: price, value, worth and cost are all different from each other, and interweave with each other in complex and often unpredictable ways
• the organisation and enterprise are not the same; the organisation is always in context of the broader shared-enterprise
• anything within the enterprise may be in scope, and may bridge across any number of boundaries such as fiefdoms or domains; all boundaries are arbitrary; everything is interconnected, and interdependent on everything else, hence there is ultimately no such thing as ‘Somebody Else’s Problem’
• the primary focus is on context, as guided by contextualities such as ‘worst-practices‘, ‘It Depends‘ and ‘Just Enough Detail‘
• only a small subset of problems in the business-context are tame enough to be ‘solvable’ once and for all; all others include wild-problem elements that may well turn ‘wicked‘ if not treated with appropriate respect
• the role of management is to provide specific types of support-services, and not get lost in delusions of ‘control’

In this paradigm, whatever is in scope is whatever turns out to be in scope – whether we choose it or not. We can’t drop-kick all of our wild-problems into the ‘too-hard basket’, or handball them over to someone else as Somebody Else’s Problem – because if we do that, we’ll almost certainly find them coming back as Our Problem, and often in newly-wicked form…

In short, tame-problems and wild-problems can’t be separated out as such, but always interweave with each other as part of the same continuum – a point that we could summarise in SCAN terms as follows:

All straightforward enough: but it only works if we stop pretending that tame-problems are all that there ever are…

So what this crossmap really shows us is that there’s a choice here:

• we can stay with the mainstream ‘enterprise’-architecture frameworks, and the standard ‘organisation-as-machine’ metaphor, if and only if there are no real people-oriented concerns in the architecture, no technologies beyond classic big-IT, no wild-problems of any kind, no need to consider anything from an outside-in or outside-out perspective, and no need for any of the tasks in Step 4 or Step 5 (or Step 1, for that matter);
  or:
• we can tackle those broader issues and concerns if and only if we shift to a more all-inclusive and more people-oriented ‘enterprise-as-ecosystem’ paradigm, based on systems-thinking, design-thinking, living-system metaphors, and iterative, fractal, holographic, participatory and collaborative depth-tactics such as OODA, CLA, SCAN, SCORE, Enterprise Canvas and suchlike

We can’t have it both ways: we can’t cling on to the old mindsets and old IT-centric frameworks and expect them to work well with the people-oriented concerns of the new business-landscape.

I know which I would choose, of course.

Your choice, though, is up to you.

Something to consider carefully, perhaps?