Two Cryptic conversations

Not actually ‘cryptic’ in the usual sense – just that the cafe in the Crypt below the church-cum-concert-hall of St Martins-in-the-Fields is a useful and pleasant place for meetings in the middle of London. (It’s just off Trafalgar Square, and a very long time since it was literally “in the fields”, next to the garden of the convent that is now known as Covent Garden.)

Anyway, two great conversations yesterday with Chris Potts and Sally Bean on enterprise-architecture and an assortment of other related topics. More details after the ‘Read more…’ link.

The starting-point for the conversation with Chris Potts was a straightforward-sounding question from one of his clients: can we use TOGAF 9, unmodified and in its standard form, to model not-IT technology such as trucks and assembly-lines. The short answer is no, we can’t – to make TOGAF work beyond IT, we have to modify it, sometimes in quite radical ways. We rambled for a while through the various options for doing this, such as described in my books ‘Bridging the Silos: enterprise-architecture for IT-architects‘ and ‘Doing Enterprise-Architecture: practice and process in the real enterprise‘.

We then turned to Chris’ recent work with John Gøtze and a group of EA (enterprise-architecture) students in Copenhagen. He’d come up with some really useful ways to challenge would-be EAs to make their work useful, by tackling genuine business-problems via modelling scenarios against specific financial-performance ratios. (As described on his website and in his book ‘FruITion: creating the ultimate corporate strategu for information technology‘, investment-strategy in relation  to IT and change is Chris’ main business-consultancy focus.) The slides also included some unusual yet really useful definitions:

Enterprise:
A bold or courageous undertaking
The ‘animal spirits’ of the entrepreneur

Architecture:
The art and science of designing structures
A style of structure

Enterprise architecture:
Discovering, investing in and successfully exploiting structural innovations

As Chris said in our conversation, it’s about the people exploiting the structures – not so much about the structures themselves.

As you’ll see here, one of the highlights of any conversation with Chris on enterprise-architecture is that so many of his views are so refreshingly different from the usual perspectives. For example, he argued that much of what purports to be ‘EA’ these days is little better than glorified asset-management: “architecture is about the structure, not redecorating the walls of the building or putting in new phone-lines”. He also often takes a fairly strict economics-oriented approach to enterprise-architectures, viewing ‘enterprise’ in terms of the classic three strands of economics: land, labour, and capital. Again, this is a fairly unusual approach – especially by comparison with those who still think that EA is solely about IT – but it’s definitely a useful and insightful line to explore.

We also talked briefly about the ‘experience economy’ – a term I hadn’t come across before, but makes immediate sense. As Chris explained:

People don’t appear in our business-processes
– we appear in their experiences

It’s a different, much more customer-centric view than the usual organisation-centred approach to architectures – especially business-architecture – and one that again seems valuable to explore further.

At this point Sally Bean arrived to join us. The conversation wandered a while around the topic of effectiveness, which to me is one of the most central themes in enterprise-architecture. As usual, Chris has a usefully different view on this: that effectiveness is actually part of a ratio:

efficiency = effectiveness / economy

‘Economy’ is the input, in essence a measure of cost, or cheapness; ‘effectiveness’ is a measure of good-ness, or fitness-for-purpose.

Chris had to go on to his next appointment, and Sally and I then turned to the planned topic for our own discussion, my recent work on meta–methodologies,  and the various cross-maps in the framework I’ve had to label temporarily as tinc, and that draw in very small part on one specific aspect of twf (aka ‘That Welsh Framework‘).

What became evident very quickly from the conversation was that whilst the notion of traversing through ‘solution-space’ is fairly clear in my own mind, I haven’t yet described it anything like well enough for it to be clear to many of my colleagues. In short, whilst I may think I know ‘what it all means’, others often don’t: and it’s my responsibility – not theirs – to provide conditions under which it can be meaningful for them too. (So if those cross-maps still don’t make any sense to you, or if you think they are somehow supposedly some part of twf, my apologies – please accept that this is still only a work-in-progress?)

One of the problems is that all the layerings often provide multiple meanings for the same base-map – sometimes even within the same diagram – which provides plenty of opportunities for confusion. One example we looked at in the conversation was the cross-map using dimensions of time versus interpretation:

To me this is quite straightforward, but it wasn’t obvious to Sally, and judging from some comments from others it wasn’t obvious to them either. The point I’m trying to make here is this:

• The base-map tells us our range of choices when dealing with the real world (Simple, Complicated, Complex and Chaotic).
• The ”horizontal’ axis (‘value’ vs ‘truth’) is a spectrum of interpretation, ranging from binary true/false in terms of predefined ‘objective truth’ at one end (extreme of Complicated/Simple) to almost completely subjective  and therefore necessarily principle-based at the other end (extreme of Chaotic/Complex).
• The ‘vertical’ axis (‘infinity’ vs ‘now’) is a spectrum of time available for decision-making, ranging from apparently-infinite (such as we see in the Complicated-domain  ‘analysis-paralysis’ and its Complex-domain equivalents) to a real-time ‘Now!‘ (where there may literally only be split-seconds in which to make an appropriate decision). (In the physics-ish terms I used in the ‘More on meta-methodology‘ post, the act of deciding what action to take ‘collapses the wave-function’ in solution-space’.)
• What this really tells us that Complex-domain experiments and Complicated-domain analysis are a kind of ‘luxury’ that depend on time being available for prolonged decision-making. Conversely, the closer we get to real-time action, the more we’re forced into a narrow band where we have to keep things very simple: follow the rules, or follow the principles, with no time for anything more elaborate than that. In that sense the Chaotic-domain and Simple-domain have strong similarities – in decision-making terms, the main difference between them is the extent to which the decision is ‘subjective’ (‘value’-based) or ‘objective’ (‘truth’-based).

Given this, we then need to work out which of those approaches is most appropriate for the context. To do this, we again use the base-frame, but this time in its consistent usage to map degrees of repeatability in the underlying ‘problem-space’. For example, lower apparent repeatability places us in the Complex or Chaotic domain for decision-making (i.e. ‘value’-based decisions), whilst high apparent repeatability places us in the Complicated/Simple pairing (i.e. ‘truth’-based decisions). Low repeatability and limited time (i.e. Chaotic domain) means that we must have appropriate principles in place to guide real-time decision-making – which we would typically derive from experiments in the Complex-domain. Limited time but high-repeatability (i.e. Simple domain) depends on the availability of appropriate rules – as in ISO9000-style ‘work-instructions’ – that would typically be derived from Complicated-domain analysis. The combination of repeatability (in the problem-space) and the  ‘compression’ of the time available for decision-making (in ‘solution-space’) is what forces this fairly straightforward split in decision-making choices.

As part of her own response to this explanation, Sally came up with a really useful cross-map of her own, about boundaries between the domains themselves:

• Simple: the boundaries between the domains are fixed, explicit, and absolute (either/or)
• Complicated: the boundaries between the domains are explicit and absolute, but can move somewhat along each axis (as in the way that IT can make analytic decision-making faster, and hence ‘closer’ to real-time)
• Complex: the boundaries between the domains may blur (such as where one or both of the axes are a both/and spectrum rather than a strict either/or distinction)
• Chaotic: there are boundaries, and there are no boundaries, all in the same moment

We also spent a fair bit of time going through the work I’ve done recently on extending enterprise-architecture right out to the whole ‘market space’, including ex-clients, anti-clients and the broader community. Each business actually operates not only within the transaction/money economy – usually mistakenly referred to as ‘the economy’ – but within an overall market-place of transactions, conversations, relationships and meaning that are expressed in three interlinked economies: transaction/money, attention/respect, and reputation/trust. In a mature market, there’s a clear sequence of dependency:

reputation -> trust -> respect -> attention -> transaction -> money -> profit

Bizarrely, far too many businesses seem to try to run all of this the wrong way round, starting from the notion that profit is the only important factor in this sequence, and expecting that all the preceding factors will follow. Many ‘business strategists’, it seems, barely manage to get as far understanding what part attention plays in all of this, let alone everything else that comes before it.

To me that attitude is madness – a guarantee of business-suicide in the medium- to longer-term – which is why I’ve pushing so hard for awareness of a ‘whole-of-enterprise’ view in enterprise-architecture. Sally made it clear, though, that even a conventional business-architecture is probably too far beyond most of her clients’ grasp at present; what I’m presenting here, whilst valid, is far too ‘way out’ to have much chance to make much sense to anyone other than a fairly small subset of the enterprise-architecture discipline.. Oh well. Once again, trying to get a workable idea out into the market, yet way before the market is ready for it: my perennial mistake, really…

—

Overall, a couple of great conversations with real thought-leaders in the field – I learnt a lot, and I hope this has been useful to you too.

Constructive comments and suggestions welcomed, as usual!