Return to RBPEA

Okay, this is where it gets scary – for me, anyway… – because it’s time for me to return to RBPEA: Really-Big-Picture Enterprise-Architecture.

(The reasons why it’s definitely scary for me – and for anyone doing any of this work, frankly – will become clear somewhat later in this post…)

There are several practical reasons for enterprise-architects to start exploring RBPEA. The obvious one is that it’s interesting, challenging, all the usual themes that drive development and skills-development in any field.

Next, perhaps, is that it’s a really good test-bed for our tools and frameworks. In the same sense that ‘classical’ physics and chemistry and the like will tend to break down at the very large scale (cosmology) and the very small (sub-atomic), we can start to see the limits and the arbitrary assumptions in our frameworks if we push those too to the very large scale (all the way up to the entire planet, and beyond) and the very small (a single line of code, or a single moment within any action) – the latter being what we perhaps ought to call RSPEA, or Really-Small-Picture Enterprise-Architecture.

Perhaps most important, though, is that much of what we find out at those scales of the very large and very small has direct and important implications for what we’re working on in our ‘day job’, with enterprise-architectures more in the mid-range, from business-scale architectures to infrastructure-architectures and the like. Often when we come across something that just doesn’t seem to work in our everyday enterprise-architecture, or doesn’t seem to make sense, the best way to break out of the deadlock and bring new ideas to bear onto the problem is to bounce up to the big-picture level. For example, it’s often the simplest way to make sense of power-problems in a business-context, as we’ll see later in this series of blog-posts.

That’s the ‘Why‘ behind RBPEA: but what about the ‘How‘? How do we do it? And with what?

Frameworks

Having by now (I’d hope) demolished the usual pretensions of TOGAF and the like as ‘enterprise-architecture’ frameworks – other than in a very specific sense of ‘enterprise’, at least – then what can we use as a guide for enterprise-architecture work, all the way out to the level of RBPEA? And how can we ensure that what we use is valid for the purpose?

The short-answer to that first question there – “what can we use?” – is anything at all. In my own case, for example, and as described in my slidedeck ‘Bridging Enterprise-Architecture and Systems-Thinking‘, I already use a lot of tools from mainstream ‘enterprise’-architecture and from systems-thinking. Here’s the ‘enterprise-architecture’ list from that slidedeck:

• Zachman
• TOGAF
• FEAF
• value-flow models
• process-models
• capability-models
• information-models
• business-models
• anything to do with IT

And here’s the respective list of tools from or associated with systems-thinking:

• quality-systems (ISO9000 etc)
• continuous-review systems (PDCA, OODA etc)
• asset-dimensions (physical, virtual, relational, aspirational)
• modality and inherent-uncertainty (the MoSCoW set etc)
• sensemaking-methods (SCAN etc)
• systems-interdependency-maps
• Viable System Model (and Viable Service Model)
• recursion and reflexion
• supportive cycles (Tuckman Group Dynamics, wu xing etc)
• post-structuralist methods (Causal Layered Analysis etc)
• worldview-models (swamp-metaphor, Spiral etc)
• power-models (SEMPER etc)
• narrative, story (NOTES etc)
• emphasis on people and spaces (NOTES etc)
• working on whole-as-whole

And all of that is just the start. To be honest, I’ll use tools from anywhere at all if I think they’ll do the job in hand…

But that’s only the short-answer: the long-answer to that question is a bit trickier… It begins, perhaps, with a reminder that whilst architecture is simple, ‘simple’ ain’t the same as ‘easy’. What we deliver for others to use will need to be simple – no doubt about that – and yet we need to acknowledge that the process of arriving at the simplicity is rarely easy at all. There are huge challenges there: and most often those challenges are to ourselves, more than to anyone else.

The real long-answer to that first-question is metaframeworks: ‘meta-level’ frameworks that are used to create and test narrower-scope frameworks that are optimised for a specific context. Or rather, it’s not so much that these frameworks ‘are’ metaframeworks, but more are just reasonably everyday frameworks that are also designed from the outset to be used in a ‘meta-‘ way. Most of the frameworks in the ‘mainstream enterprise-architecture’ section above are pretty useless at this – almost all of them are context-specific only – but most of the frameworks in the ‘systems-thinking’ list above do work well for this purpose.

Which leads us to that second question above: “How do we ensure that what we use is valid for the purpose?” Probably the main answer there is recursive use of those metaframeworks on themselves: what the Americans describe as ‘eating your own dogfood’. For example, if we use Causal Layered Analysis on itself, we can see that it’s pretty robust: it doesn’t break down into the mess of special-cases and arbitrary assertions such as we see in TOGAF and Archimate and suchlike.

We then take that cross-check one stage further, and apply multiple metaframeworks recursively onto a given metaframework, to throw up crossmaps that can surface any hidden assumptions or gaps. Again, SCAN is good for this, in fact was explicitly designed for that purpose. The principle is much the same as that used in design for mission-critical systems in the aircraft industry, or nuclear-power, in which deliberately-different control-systems – usually designed by different teams, but to the same nominal requirements – work as cross-checks against each other to mitigate against design-gap risks. Chris Lockhart describes the overall concept well in his brilliant ‘Frankenframeworks‘ post:

Frameworks should be easy to interpret, fast to deploy, amenable to adaptation. They can be picked up and used or tossed aside in favor of something that is a better fit. The framework shouldn’t fall apart if you decide to remove part of it because it doesn’t suit the problem at hand. The framework can be simple or sophisticated, but either way it should be extensible. Multiple frameworks can be put together or merged to become the methodology for a given situation. These frankenframeworks can be reused. I myself have dozens of them that I reuse or partially reuse on every project I’m on. Keeping this mini-library of frameworks enables me to be agile and flexible.

The main framework I’ll use for the worked-examples here will be one of the SCAN variants, that lists typical tactics we’d use in each of its sensemaking / decision-making ‘domains’:

We’d also use the cross-check to the ‘disciplines‘ in the crossmap between SCAN and the ‘swamp-metaphor‘:

And because a lot of this will be about conceptions of power, on occasion we’ll also call on the power-model from the SEMPER framework:

That’s frameworks, anyway. But how do we actually do the work at the RBPEA scale?

Into practice

Probably the simplest option here is to quote from the process I described in an older post of mine, ‘What I do and how I do it‘:

There’s a fairly consistent pattern about what I’ve done [in RBPEA-practice] and the sequence in which I’ve done it.

The first stage is just getting involved at all: taking the ideas and practices at face-value, and putting them into practice as if they are entirely ‘true’. That usually works for a while (not least because that’s what everyone else is doing).

I then allow myself to start to notice the niggles, the things that don’t quite seem to work, where ‘what it says on the tin’ doesn’t actually deliver what it says on the tin. The problem, of course, is that we can’t assess the validity of a logic from within the logic itself. Yet we also can’t actually work on the context without being inside the logic (or some form of the logic). This is where we hit head-on into Gooch’s Paradox: things not only have to be seen to be believed, but also have to be believed to be seen. The only way out of that dilemma is to start to use beliefs as tools – which can be kinda challenging…

In my experience, there are two parts to this:

• identify the big-picture theme for the overall context (the ‘vision’, the unifying ‘parti‘)
• apply design-thinking tactics to question everything, switching beliefs in order to experience the context in different ways, and test the apparent results

The tactics to identify the key-themes are usually straightforward. A classic example is the ‘Five Whys’: keep asking “Why?” until eventually we hit a ‘Because.’ – or rather, a real ‘Because.’ that makes some degree of sense, rather than one that’s just used to get people to stop asking awkward questions! This identifies the ‘things’ or concerns that matter to everyone in the context, what’s being done with or to those items, and why it’s deemed to be important – and it gives us a stable anchor to which we know we can return, and against which we can test anything in the context.

Then, following standard design-thinking tactics, we use a suite of ‘disruptive’ questions about the context – for example:

• what’s another version of this?
• what does this look like at a smaller scale, or a larger scale?
• what happens if we substitute something else for this?
• what happens if we invert some or all of the rules?
• is there a ‘term-hijack’ here? – does a small subset purport to be the whole, blocking the view to any other aspect of the context?

This is the point where things often get to be kinda, uh, fun… – because it’s very common to find aspects of the context that a) don’t and can’t make any sense, b) clearly don’t work ‘as advertised’, in fact usually work against the nominal aims of the overall enterprise, yet c) there are key players with a lot of vested interest in ensuring that the status quo remains unquestioned and unchallenged. Don’t be surprised at this: it happens every time.

This is where a certain amount of dogged determination becomes essential… It’s also essential to maintain a clear, insistent emphasis on the big-picture, on holding to the overall vision for the shared-enterprise – because that’s often the only thing that will persuade people that there’s no ‘personal attack’ here, that instead the only purpose of the challenge and the enquiry is to make things work better, for everyone. (We have to be real about that, too: we need belief in ourselves in order to keep going, it’s true, but we need to keep questioning ourselves as well. It’s one reason why serious self-doubt is a chronic yet necessary occupational-hazard here.)

As a quick summary of the overall RBPEA process:

• explore a context that is of interest
• identify the conceptual mismatches that occur within that context, and that make it difficult to achieve effective results within that context
• identify the vested-interests that drive and maintain the current dysfunctionalities in the context, and, where possible, devise strategies and tactics to disarm and disengage those vested-interests
• assess the details of the dysfunctionalities in the context, and identify or design workarounds for those problems, and methods to work on the context when the dysfunctionalities are disengaged
• document the end-results in various forms, as appropriate

The following series of posts put all of that into practice.

Practical applications

The whole point of all this exploration is to end up with something useful, that can be applied directly within everyday EA practice.

To that end, I’ll finish each of the following posts with a ‘Practical applications’ section, giving suggestions about how the various insights that arise from the respective enquiry can be put to practical use.

Certification

Yes, it’s enterprise-architecture, so there must be some form of certification for this, surely? ‘Certified RBPEA Architect™‘, or something like that? :wry-grin:

(Though no doubt that by the end of this series, there’ll be a fair few people who’d like to see me ‘certified’ in a rather different sense… :bleak-wry-grin: )

Yeah, certification is mostly a bad-joke – the bane of the enterprise-architecture disciplines. But I’ll warn you again that a lot of what follows will be pretty challenging stuff – in fact if you don’t find it personally-challenging in quite a few places and in quite a few ways, I probably won’t have done my job well enough… So if you would like a real certification-type test, with real test-criteria, try these:

• you’ve read all of the following material – four main posts, plus probably a wrap-summary – without giving up on any of them in disgust halfway through
• you’ve made it all the way through without screaming abuse at me – or, if you have, at some point, you’ve pulled it back together, and got back to the task at hand
• you’ve made it all the way through without dismissing me as some kind of choose-your-epithet nutcase – or, if you have, again, you’ve remembered that I’m darn careful and rigorous about every other aspect of enterprise-architecture, hence the same probably applies here, and that it therefore probably is worth listening a bit more carefully to what I have to say about it
• you’ve faced at least one major challenge to your existing thinking, worked with it rather than rejected it outright, and incorporated the result into how you now think and work in enterprise-architectures and elsewhere
• you’ve incorporated some of those learnings directly into your existing enterprise-architecture practice

If you pass all of those tests, perhaps consider yourself certified? 🙂

Worked-example

To find a suitable example to work on for this, we need only to look for something that has potential for a really large mythquake. These are the outcomes of what we might describe as ‘seismic forces in the social soul’ – and particularly those where the hidden stresses underlying those structures of tectonic teleology are huge, and perhaps already close to breaking-point. To quote from that ‘Mythquake’ post:

In what regions do the stories only seem stable, yet in reality are ‘stuck’, jammed against each other, building up more and more energy towards an explosive release, a much-feared, much-anticipated ‘Big One’?

We know all too well what damage a big earthquake can do. So just how much damage could a big mythquake cause?

Like earthquakes, little mythquakes are happening all the time, in most cases so small that we wouldn’t even notice them unless we were watching carefully, or unless we happen to be close to its epicentre. But as the tensions rise higher, the potential for mythquake-damage increases exponentially: the money-system is one example I’ve explored quite often on this blog. In the Mythquake book, the three types of mythquakes that seemed to have the highest potential for serious social damage were as follows:

• MQ-7: ‘Sugar and Spice’ – on myths of gender
• MQ-8: ‘Let Freedom Reign’ – on myths of ‘rights’
• MQ-9: ‘Possession’ – on myths of ‘rights of possession’

Again, I’ve written quite a lot here on the latter two – on ‘rights’, and on societal myths of possession – and explored some practical ways through which we could address some of those themes. The mythquake-type I haven’t written much on as yet is gender – a few posts here and there, but not in as consistent a way as with the others, anyway. Time to remedy that lack, it seems, and use that theme as our worked example here.

(Which, yes, is indeed genuinely scary, for me: in fact, I’m not joking when I say that I’m actually shaking with fear right now as I write this, at the prospect of yet more seriously-vicious personal-attacks, simply for ‘telling truth to power’, to use the old Quaker phrase. Oh well, here goes…)

The other reason to choose that theme is that over the past few weeks I’ve watched a shrill crescendo of blame and worse echoing around the net, about purported sexism and the like. And I’ve watched, with disappointment, dismay, and, frankly, occasional disgust, as I’ve watched one after another of our professional colleagues in enterprise-architecture fall for really basic methodological-errors that they would never commit in their everyday EA work, or, in some cases, not merely condone but actively promote violence against others, in ways that they would be very quick to condemn others about in any other domain. Sickening, frankly: and smacks more than a bit of professional-incompetence and serious breaches of professional ethics, too. So yeah, it really is time we called a halt on this one – using RBPEA tools that can help us identify where the real deeper mythquake-drivers are, and what we can do about them.

For sanity’s sake, though (and in the hope that it might perhaps reduce some of the violence that I know will soon be heading my way…), let’s take it slow. As we go through this series, keep asking yourself these questions:

What are you certain is true, is indisputable fact? How do you know it’s true? Who told you so?

With perhaps a little less intensity, what do you assume is true, even if you don’t know for a fact that it’s fact? In what ways do you trust that it will remain ‘true’? And why?

What would happen to you, and perhaps to others, if you find out that it’s not true, or is true only under particular circumstances? What would change? And what, if anything, would remain the same?

I’ll do this step-by-step, on four distinct themes, each one building on those before:

• On power
• On empathy
• On sexism
• On gender-abuse

And in each case I’ll either first set up, or develop within the post, an anchor-principle on equality that we can use throughout as a touchstone, to keep us on track to purpose – the purpose, again, being about how to use explorations at the big-picture to address everyday concerns in everyday enterprise-architectures and the like.

“Let’s go to it, then?”, he says, taking a deep breath…