Tom Graves / Tetradian

Yes, I know I’ve gone a bit quiet in the past couple weeks, and no, I haven’t abandoned those ideas about SCAN sensemaking and real-time decision-making and the like.

Reality is that those ideas are very much in the ‘work in progress’ stage at the moment, and as yet still quite some way from a form that might make much sense to anyone else. To illustrate, for the past couple of weeks I’ve spent rather too many hours staring at and tweaking of a set of whiteboards that look like this:

In other words, it’s coming together, sort-of, but it’ll take a bit more time yet to clean it up into usable form. Watch This Space, perhaps?

Why do we need enterprise-architecture in a business? And why does that EA need to be broader than just IT, often all the way out to a true enterprise-wide scope?

One reason is implied this Tweet by Belgian consultant Patrick Van Renterghem:

itworks: Big discussion now about what happens when cloud vendors go bankrupt or out-of-service. Should [be] in the contract… #BAEA

“Should be in the contract…”: yes, indeed – but what should be in that contract? And why?

Without an enterprise-architecture that covers a broader scope than just the bare IT-transactions, we have no way to know what actually needs to be in that contract – and also in the parts that can’t be covered by contract, and that really do depend on relationships and trust. Which could be a serious problem from a business perspective. Hmm…

I’ve covered a fair bit of the detail of this in other posts here, such as ‘Enterprise-architecture and the Cloud‘. Some people seem to have misunderstood the questions there as somehow being ‘anti-Cloud’, or even ‘anti-IT’: it’s not. It’s about really looking at the whole context – about the whole ‘market-cycle’, about understanding the full implications of a customer-centric view, about maintaining consistency of service across all in-source and out-source relationships, and so on. And we do need to do that: because if we don’t, it can get really expensive.

Yet cloud-outsourcing is only one small example. As enterprise-architects, we also need to be able to extend out to a much broader business-picture, as Steve Denning describes in his Forbes post, ‘Clayton Christensen: How Pursuit of Profits Kills Innovation and the U.S. Economy‘

when a firm calculates the rate of return on a proposal to outsource manufacturing overseas, it typically does not include:

• The cost of the knowledge that is being lost, possibly forever.
• The cost of being unable to innovate in future, because critical knowledge has been lost.
• The consequent cost of its current business being destroyed by competitors emerging who can make a better product at lower cost.
• The missed opportunity of profits that could be made from innovations based on that knowledge that is being lost.

Failure to apply a proper enterprise-scope architecture-assessment of such themes can be more serious than merely expensive: mistakes at that level can easily kill a corporation. In short, it matters.

That kind of in-depth EA assessment might at first seem pernickety and pedantic, especially to those who just want to get moving. But as John Seddon warns, most of the ‘conventional’ methods to save money and effort usually end up costing far, far more: if we do need to cut costs, for example, we need to take more systemic, whole-of-context view in order to find the real places where those costs can be cut back. And the reality is that often they’re not where we’d expect them to be: hence, again, the need for a true enterprise-scope architecture.

Cloud-IT and other forms of outsourcing often look like the quickest, easiest and most practical way to cut costs. But Steve Denning quotes John Maynard Keynes to warn:

Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist.

Most often, those ‘defunct economists’ have failed to account for the hidden costs of a context – particularly the real human costs, which can be ignored only at our peril, especially in the longer term. There are good reasons why those ideas became ‘defunct’: but unfortunately, it seems each new generation has to re-learn those reasons time and time again…

In our domains, those forgotten lessons are reflected in IT-centrism and the like, and the over-simplification of otherwise-valuable ideas such as ‘scientific management’ and ‘business process reengineering’, and, now, cloud-based IT-services. A key role of a whole-of-enterprise architecture, here in the context of outsourcing, is to remind us of why those lessons about the real complexities of outsourcing and the like are so important, and what they mean in real-world practice to Keynes’ ‘practical men’.

In short, use enterprise-architecture to help identify the real hidden-costs of outsourcing – so that your business doesn’t get hit by the bill when those hidden-costs come back to bite…

What is it that drives decisions at the exact moment of choice and action? – even in the most mundane, everyday action? If the choice-point itself is a true moment of chaos – a point where literally anything is possible – then what is it that guides us through each of those infinitesimal yet ubiquitous moments?

A lot of this is still tentative, very much ‘a work in progress’. Yet what I’ve found myself returning to again and again over the past few days, whilst working on the design and workflows for the SCAN app, is a pairing of two words: belief, and faith.

[Don't worry, I'm not going to go all religious on you. (Well, probably not, anyway. ) This is still the same enterprise-architecture exploration about the context of SCAN, about sensemaking and decision-making at real-time, particularly in what some would term the 'Chaotic domain'.

Minor warning, though: this is written in English, and from the perspective of an Anglo culture. I think (believe? guess?) that what follows is close to generic across all human cultures, but note that you may well need to do some translation here, both linguistic and cultural.]

Where SCAN’s ‘Simple’ and ‘Not-simple’ are about about how to describe sensemaking, belief and faith seem more about decision-making – the actual moment of choice that immediately precedes each moment of action. In other words, decision-making in real-time. And because sensemaking, decision-making and action are all intertwined with each other within real-world practice, belief and faith also map onto the SCAN frame in much the same way as for real-time sensemaking.

[There's also a mapping to the full SCAN, that extends this outward to the scope where there is more time available for review, but I'll describe that in another post.]

In short, belief maps to the known, the certain, the Simple; whilst faith maps to the unknown, the uncertain, the Not-simple:

As in sensemaking, the crucial distinction occurs where the modality of the decision-choice changes from a Simple deontic true/false to a Not-simple true alethic logic of ‘possibility and necessity’:

– over on the left-side, belief provides a straightforward black-or-white choice: true or false, right versus wrong, culturally ‘proper’ versus ‘politically incorrect’;

– over on the right, choices are more blurry, more uncertain, more ‘shades of grey’ – or more colourful, perhaps – and the only guide we have is faith or trust that what we do is right. (Right in its own way, but still ‘right’ in some sense.)

Both of these are actually about the individual, about ‘I’. Which it should be, of course, because that’s all we have at the exact point of action: our own choice, and our own ‘response-ability’.

Belief is fast, and importantly doesn’t demand any personal skill as such: the whole point is that they’re deemed to be ‘true’ for all who enact them, regardless of who or what enacts them. (A belief may be believed to apply only to self – such as ‘nothing goes right for me’ – but is still held as an ‘absolute truth’ in that sense.) This has both advantages and disadvantages, mainly relating to how well the belief does match up to actual reality. Advantages include:

• simple beliefs are useful when the person enacting them has only a limited level of skill and ‘response-ability’ – “just follow the instructions, kid…”
• even for those with skill, simple beliefs are useful as a structured fallback for whenever the faith falters in the context and in one’s own ability – “when all else fails, follow the instructions”
• advising acceptance that some contexts are constrained by ‘laws’ of some kind – particularly the physical-world constraints implied by ‘scientific law’ and the like
• beliefs are also useful as a disciplined means to temper excess enthusiasm – “trust to Allah, but tie the camel first”

A classic example of a structured belief of that last type is the checklist - mapping out essential safety-checks and other ‘known truths’ prior to or during any activity that is inherently uncertain.

The disadvantages of ‘prepackaged’ belief-structures are more complex, and often rather more subtle:

• the usefulness of beliefs ultimately depends on the myth of ‘control’, the myth of predictability and certainty – none of which may be valid in a real-world context
• beliefs themselves can and do act as perceptual filters, potentially rendering invisible essential contrary information from the context
• as guides for choice and action, beliefs can apply inappropriate constraints to action in any given context – following ‘the letter of the law’ rather than ‘the spirit of the law’
• in much the same way, beliefs can be used to evade difficult or challenging choices – for example, ‘morals’ as ‘the lazy-person’s ethics’

Faith is often the only choice-mechanism available whenever the context is inherently uncertain. It also correlates closely to skill – so much so that, in essence, ‘skill’ is a proxy for the real-world reliability of faith in one’s own ability to work with the inherent uncertainties of a given type of real-world context. In other words, skill is what determines whether we really can do what we believe or hope we can do in that kind of context.

Sometimes, though, it isn’t about skill: it’s just about faith, or trust. Every change of belief requires ‘a leap of faith’; innovation or experimentation always requires us to accept that we don’t know what the outcome will be. (That’s very different from belief, where we do expect the outcome to be what we expect.) A modal-logic of possibility and necessity is the only place where ‘the impossible’ first becomes possible – and thence, through skill, becomes probable, then predictable, and eventually something resembling certain, a kind of ‘law’ in its own right. It may end up as a checklist or some other pre-packaged set of beliefs – but it always starts with faith, in the midst of a moment of inherent uncertainty.

As with belief, there are disadvantages to faith too: not least what we might describe as ‘misplaced faith’, where lack of skill – or plain old lack of awareness – leads to inappropriate outcomes. Whether we like them or not, sometimes the constraints of belief do apply – such as in most (though not all) assertions of ‘scientific law’ and the like.

So in practice we need to be able to bounce back and forth along SCAN’s ‘horizontal’ axis of modality. Sometimes we need to hold to a Simple true/false belief; sometimes we need to let go into the Not-simple world of faith and trust. And of course, recursively, there are no set rules about which one should always apply at any given moment – which means that this too is a skill in itself. It’s Complicated, perhaps, or Complex… yet in real-time action we don’t even have time for either of those. All we have is this decision, right here, right now – no time for anything else. Belief that we know what to do; or faith that the results we need will arise from within the chaos itself.

All of which means that, as enterprise-architects, we need to understand how belief and faith work within our organisation and enterprise, and provide structures to support them in real-world practice.

Enterprise-architecture implications

It’s essential to draw a distinction here between the individual and the organisation. Belief and faith are expressed in practice directly by the individual, or indirectly by proxy, such as via the design or operation of a semi-autonomous machine or IT-system. Yet in an organisational context, it’s the collective belief and faith that we want expressed in action – expressed by the individuals on behalf of the organisation, the collective.

In effect, that’s the key role of organisational culture – and despite the wishes of executives and others, it’s not as simple as it looks… For enterprise-architects, it also means that we often have to address aspects of organisation-architecture that are more usually the territory of HR and change-management and the like – which means that we have to tread carefully at times, and engage in some potentially-challenging negotiations. But the payoff is an enterprise-architecture that really works – for everyone.

The organisation’s beliefs-in-action are expressed in definitive statements such as work-instructions, reporting-relationships and business-rules. One of the architectural concerns here is to provide support such that these business-rules and the like are actually implemented in practice, in real-time decision-making.

To make this work, we in effect need each individual to take up those shared-beliefs as if they are their own personal beliefs. This is especially important wherever these rules must normally be followed ‘to the letter’ – such as in regulatory compliance.

It’s crucial to understand, though, that rules cannot be imposed onto individuals from outside, whether by fiat or threat of force. Although as an organisation we can give ourselves the illusion that this has been done, it rarely works in practice: instead, there will usually be a myriad of small ‘failures’, ranging from unconscious errors to covert rebellion, which effectively sabotage the intended functional impact of the rules. (The former will tend to occur more often in collective-oriented cultures, the latter especially so in individual-oriented cultures.)

What does work is to engage people in the rules – the ‘why’ as much as the ‘how’ and ‘what’. To use the terms from Hagel, Brown and Davison’s The Power of Pull, we create that engagement by shifting from ‘push’ to ‘pull’. In an enterprise-architecture, we do this by treating organisational-beliefs in much the same way as for organisational-values. The Enterprise Canvas model describes a generic structure for this purpose:

• create awareness of the rules-structure, its purpose and rationale, and the context for its use
• build capability to apply the rules-structure in real-time practice
• apply the rules-structure in run-time decisions
• verify and validate the usage of the rules-structure
• derive lessons-learned from the (attempted) usage of the rules-structure

Working with HR, change-management, process-management and others, we create what is in effect a PDCA-type learning-loop, to develop, apply and revise the business-rules and other belief-structures for the organisation.

The faith-in-action side of that decision-making modality-spectrum deals with anything that isn’t covered appropriately by business-rules and the like – which is a large part of most real-world organisational contexts. For enterprise-architecture, the two key focus-areas are skills-development, to enhance individual ‘response-ability’; and vision, values and principles, to enhance consistency in decision-making across the collective.

The skills-issue is one that is almost completely missing from most current-enterprise-architectures, especially those of an IT-centric bent. That’s rapidly becoming a lethally-dangerous oversight – see the Sidewise post ‘Where have all the good skills gone?‘ – and one that we need to address, working in conjunction with HR, organisational-development units and suchlike. EA will come into the picture by mapping out skills-requirements and competency-levels needed within enterprise-capabilities; the actual skills-development would usually be out of scope for EA, of course, though overall much of it would follow that generic structure for values as above.

The values-issue is one I’ve been pushing for a very long time as the true core of the enterprise-architecture: for example, it forms the topmost layer of abstraction in Enterprise Canvas, and thence acts as the anchor for the generic structure described above for values-management services. The reason why it’s important is that if the organisation isn’t clear about its values, then what will be used instead – as the drivers for ‘faith’-type decision-making – will be whatever values happen to be around for that individual. Which could be anything at all. Including not just a destructive ‘me-first’, but a really destructive ‘me-only’. In other words, not a good idea… clarity on values matters.

A lot more that could be said on all of that, but I’d probably best leave that for the moment. The only point that does need to be added here is the importance of story – the enterprise as story, the enterprise is the story – as the ‘glue’ that holds all of this together.

Overall, the real point here is this: that at the point of action – and despite whatever we might plan beforehand – decisions seem to be taken primarily on the basis of belief, or of faith or trust. Which means that, architecturally, we need to design for that fact. Not a trivial point, then.

More on this in another post soon, but any comments so far, anyone?

As the economy shifts ever onward from manufacturing toward services, how do marketing and market-relationships need to change with this shift? And what enterprise-architectures do we need to support this?

[In part this is a follow-on from Dave Gray's excellent Dachis Group article 'Everything is a service': I strongly recommend to read that post first before continuing here.]

As Dave Gray indicates in his article ‘Everything is a service’, many people in and around business are seeing a ‘Great Reset’ – a fundamental shift in the nature of the economy, and with it a fundamental shift in the nature of a viable business: a change in focus from products to services.

In a product-oriented economy, an organisation’s market is built around transactions, exchanges of goods and services. Within this metaphor, services are quasi-products, another type of ‘thing’ to be ‘consumed’ by a passive marketplace of ‘consumers’. Financial services, for example, are packaged as ‘products’; so-called service-organisations sell ‘solutions’ to often-unspecified ‘problems’ that a ‘consumer’ is presumed to face.

Producers produce, consumers consume: the roles are explicit, and explicitly separate and distinct. The role of marketing there is to create a market ‘want’ – often entirely artificial – for whatever product the producers want to sell. The role of enterprise-architecture and the like is to support creation of the maximum volume of product for the minimum necessary effort and cost.

The overall view – perhaps still illustrated best by the implied left-to-right flow in the structure of the Business Model Canvas above – is a linear structure of processes. A supply-chain (‘Key Partners’) feeds into the business-processes of the organisation (‘Key Activities’), the results of which are then sold on to ‘consumers’ (‘Customer Segments’). The sequence ends at the ‘consumer’, or more specifically at the moment that the customer has paid for the ‘product’; and everything is centred around the organisation, as ‘the enterprise’.

This view of the market is also often possession-based, with very unequal power-relationships assumed between the organisation and everyone else: we talk about ‘capturing’ a market, ‘owning’ market-share, and so on. This often leads in turn to a very combative relationship across the market, both between organisations competing for ‘possession’ of market-share, and between an organisation and its customers, employees and broader communities – all of whom, perhaps unsurprisingly, may well object to being treated as possessed ‘objects’ or ‘subjects’ of the organisation.

In business terms, one of the key drivers behind the ‘big reset’ or ‘big shift’ that Dave Gray describes is that this model of the market is rapidly becoming less and less viable. Most markets are either at or approaching saturation-point; the hidden-costs are becoming more visible, and harder to externalise; and the supposed economies of scale of mass-production and mass-marketing deliver steadily lower returns, especially relative to smaller and more adaptable technologies and business-models. And in bald economic terms, there are practical limits as to how much ‘stuff’ we can continue to make and sell on a finite planet – limits which in many cases we’ve already overshot. Some real problems there… – and yet they’re inherent in that model of the business-market.

A service-oriented economy is radically different, in that the market is built primarily around relationships. As Dave Gray put it:

A service is at its core a relationship between server and served. Service is work performed in support of another. At every point of interaction, the measure of success is not a product but the satisfaction, delight or disappointment of the customer.

Within this metaphor, products are best understood as proto-services, typically as part of the means for self-delivery of some service. Everyone in the market is both ‘producer’ and ‘consumer’: the roles blur, and are inherently much more equal or peer-based in nature than in the product-oriented economy.

This view of the market is also based much more on mutual responsibilities: we talk about co-creation, about partnering in a shared enterprise. The power-relationships are much more equal, and necessarily focussed on building and maintaining mutual trust – rather than the combative contracts of the possession-model, which mostly reflect an absence of trust.

The overall model still has transactions and processes and supply-chains, but the perspective is different. As Verna Allee describes it, that linear ‘supply-chain’ is actually one view into a much more nuanced ‘value-network’; and a product- or service-transaction is merely one phase within a much larger market-cycle:

Importantly, the fundamental focus of relationships is inverted, from organisation-centric to customer-centric: as Chris Potts puts it, “customers don’t appear in our processes: we appear in their experiences”. The sales-focus also shifts from ‘push’ to ‘pull’, from manipulating or even forcing the ‘consumer’ into a single once-off ‘the sale’, to building a continuing long-term mutual relationship. All of this requires radically different approaches to sales and marketing, but it can be done – and increasingly, is much more profitable than the ‘push’ model.

[For example, compare your experience of the usual soulless time-driven 'customer-as-product' sales call-centre - such as that which interrupted me just now whilst writing this, and who cut me off in the middle of saying "Thank you, but no" - to an intentionally relationship-oriented call-centre such as that run by US retailer Zappos, which focusses much more on respect and mutual trust. Which approach would you prefer to deal with in your business day? The answer's fairly obvious: which is why the conventional call-centre model is becoming less and less viable, no matter how much pressure is put upon the long-suffering staff.

Another first-hand example: a couple days ago I was looking at cameras in the local branch of a medium-sized national chain of camera-stores. The absence of pressure was really noticeable; and the saleswoman's quiet passion for photography per se shone through. The change in energy of the place was very noticeable, compared to the last time I'd been there, a year or so ago: more like an Apple Store than a 'normal' sales-obsessed high-street retailer.

Talking with her, it became clear that the company had made that crucial shift from product-orientation to service-orientation. The key was that they'd come to understand they made most of their money not from selling cameras as such, but from the ongoing photo-print service. Camera-sales became viewed as a means to support that service: it needed to be profitable in its own right, but it wasn't the primary focus for profit. Hence it became much more important to match the camera to the client's actual needs - and that emphasis on matching real needs itself became a key foundation for mutual trust, and hence for long-term relationships that would be profitable to all parties.

Contrast that with the usual high-street high-pressure retailer, where the emphasis is more likely to be about offloading the highest-margin object that the 'consumer' could afford, then dropping the attention instantly so as to move on to the next 'punter' as quickly as possible. "I worked in a place like that for three months", she said, "and I felt like I aged ten years while I was there. Soul-destroying, for everyone. So I know why I'm working here! - because I want to be here."]

So what kind of enterprise-architecture do we need for a service-oriented enterprise? How does it differ from the conventional product-oriented architectures – particularly in its business-architecture and process-architecture? Probably the key requirement is an awareness of the implications of one simple statement:

A service exists to serve.

But what does it serve? And whom does it serve? Architecturally, those are not trivial questions…

In the highly unequal power-relationships in the conventional product-oriented model, the answers are very clear indeed: there is often a thin pretence of ‘customer-service’, but in reality the ‘consumer’ is deemed to exist solely to serve the organisation and its perceived ‘need’ to sell.

[And the organisation in turn is deemed to exist solely to serve the 'needs' of the stockholders, but that's another story...]

But in a service-oriented enterprise, there are two fundamentally-different types of service going on: and the architecture needs to support both of these.

One type – which we might describe as ‘horizontal’ – is the conventional ‘supply-chain’ structure: the service-producer serves the needs of the service-consumer. The issues here that the architecture needs to support are that:

• the relationships between producer and consumer are essentially peer-to-peer
• the roles of ‘producer’ and ‘consumer’ will often blur or even swap over, especially in the ‘co-creation’ relationships that are common in a service-oriented model
• the overall relationships are built via the self-reinforcing loop of the full ‘market-cycle’, as above

The other type of service is more ‘vertical’: within the context of those ‘horizontal’ supply-chain service-relationships, every player in the shared-enterprise serves the same overall vision and values. The market exists within the context of a broader shared-enterprise, defined by a distinct purpose or ‘vision’ and its associated values.

Remember Chris Potts’ point above, that “we appear in customers’ experiences”: there’s a crucial difference here between the organisation and those with whom it interacts. Architecturally speaking, the organisation chooses the vision and values to which it will align. When customers’ experiences – and, for that matter, suppliers’ experiences – happen also to align with that same vision and values, there is then a basis for a shared connection. Serving the same ends – the same vision and values – creates the basis for mutual trust, which then starts the market-cycle rolling.

So the service is delivered through the ‘horizontal’ connection; but the connection only exists because both parties share ‘vertical’ alignment to the same vision and values.

Note that the customers’ experiences – or even supplier’s experiences – may only align with the organisation’s chosen vision for a brief period: think of a restaurant at lunch-time, for example. But whilst that alignment exists, there is the basis for conversation and connection – and hence the first stage of the market-cycle already in progress.

[Back to the camera-shop. The focus throughout the conversation was photography, what kind of photography I might need to do, about cameras in general. Firstly, there was a conversation - which in some stores doesn't even happen at all; and the conversation didn't have an all-too-obvious undercurrent of 'how can we sell you a high-priced camera that you don't need?' - which I've had all too often in the high-pressure stores. Instead, I felt listened-to, respected, safe, served - all of which increases the likelihood that I'd go back there when I am ready to buy another camera. In other words, that first part of the market-cycle is already in progress; and I feel safe in the belief that the closing 'post-sale' part of the market-cycle would be there, too.

Yet note that I wouldn't go there to buy a sandwich, or clothes, or anything that wasn't about cameras - because that isn't part of their vision or purpose that they present. They're clear about what they do and what they don't do, and demonstrate their vision and values in practice: so I know when to go there, and when not to go there. Sounds obvious, perhaps: but some organisations are so sales-obsessed that they give the impression that they'll sell us anything, whether they have it or not, just to make up their sales-quota - and that's really confusing, for everyone.]

Architecturally, the vision and values are the core of a service-oriented architecture: everything in the organisation needs to be understood as serving that vision.

Hence, for example, the value of a service-viability checklist that explicitly includes tracing of support for each of the values as they touch on every aspect of the enterprise.

Hence also the importance of ensuring that that same vision is carried across any partner- or outsourcing-relationships – especially where key customer-facing connections are handled by outsourced others such as an external customer-service centre.

And hence also the importance of keeping the focus on those shared-relationships overall, such as with Chris Potts’ aphorism above. As enterprise-architect Pat Ferdinandi put it, in a comment on an earlier post here:

That’s a brilliant line by Chris. It’s the corporation’s adjustment between customer service and customer loyalty. Customer service is viewed as a “fix” of problems. Customer loyalty is earned by the customer’s experience with the corporation but not necessarily from the corporation. The experience can be from word of mouse of a trusted friend. The experience can be from reviews by “specialists” in the area.

There’s a lot more on these themes scattered around on this site, and in the various books. For example, take a look at the post ‘Where marketing meets enterprise-architecture‘, or any of the articles here on Enterprise Canvas; and the books ‘The Service-Oriented Enterprise: enterprise-architecture and viable services‘, and ’Mapping the Enterprise: modelling the enterprise as services with the Enterprise Canvas‘. The chapter ‘Step 1: Know your business’ in the book ‘Doing Enterprise Architecture: process and practice in the real enterprise‘ also describes the practical processes needed to set up the initial architecture-models for a service-oriented enterprise. It’s all there: all we have to do is do it.

It’s simple, and straightforward: yet it’s often not easy at all. And the reason why it often isn’t easy is because it does require a real shift in perspective, a paradigm-shift – and no-one should underestimate just how hard those shifts are in real-world practice. Yet also don’t doubt that, as Dave Gray says, it is the way that the business-world is moving: so as enterprise-architects we do have to support our enterprises in that change, in whatever ways we can.

Enough for now, anyway: comments, anyone?

Several people picked up on this one after Gerold Kathan sent out a note about it, but perhaps David Sprott said it the best:

• davidsprott: RT @gkathan: John Seddon – a master class in how NOT to use IT in services. Optimize value, not cost. Brilliant. http://tinyurl.com/dygdcpg

It’s a 40-minute video (split into three parts) of a keynote by John Seddon at an IT-conference somewhen last year. And it’s magic – absolutely brilliant.

If you’re into enterprise-architecture, business-architecture, organisational-architecture, service-design, or any related field such as service-management of any kind, you need to watch this video – there’s no other way to say it.

Some of the insights I picked up on my first pass through include:

• “standard times are for dummies”
• “manage for value, not cost; if you manage to costs, your costs go up”
• “it’s failure-demand, not value-demand”
• “specialise – it increases the costs”
• “people who study systems focus on demand”
• “[you get better results because] you’re trained to identify the things you’re not capable of doing”
• “we get rid of all the activity-measures, because they’re of no value whatsoever”
• “whenever we create a back-office, we see an increase in activity: it should be a signal… but what do they do, no, they specialise the activity, they outsource it, they lean on people to do more faster, and that just creates more work.”
• [vid3, 05:00-07:30 "it's just wrong"]
• [on 'Lean'] “never give it a name: if you give it a name, the managers will expect if to come in a box”
• “the problems you’ve really got are not the problems you think you have, when you study”
• “[Taiichi] Ohno’s favourite word was ‘understanding’”
• “[managers think] if you’re a service organisation, and you standardise the work, the costs will go down – wrong!”
• “when you standardise and specialise in service design, you stop your system absorbing variety, and your costs go up: economy comes from flow, not scale”
• [important summary in vid3: 13:00 - 14:30]

I’m going back to watch it again… very strong recommend.

Maslow’s Hierarchy isn’t a hierarchy.

Spiral Dynamics isn’t a spiral.

They’re not levels in a stack; they’re not linear progressions.

They’re dimensions.

I was reminded of this by an excellent post on the Psychology Today website, by Pamela Rutledge: Social Networks: What Maslow Misses. She makes the point that none of the ‘levels’ in the ‘hierarchy’ make much sense without an understanding of the role of social connection: this has significant implications for social-media, and hence enterprise-architecture. She redraws the ‘hierarchy’ as a circle/cross-format, an ring of relationships between the nominal ‘levels’, with ‘Connection’ at the centre. In other words, a flattened-out tetradian-like layout, portraying a set of independent yet interdependent dimensions.

I don’t know why people are so enamoured of hierarchies and simple ‘stack’-type structures, but the reality is that it rarely works that way in practice. Take Maslow’s Hierarchy, for example: the Abraham Maslow website shows us this graphic:

And then asserts:

Abraham Maslow’s model indicates that basic, low-level needs such as physiological requirements and safety must be satisfied before higher-level needs such as self-fulfillment are pursued. …[W]hen a need is satisfied it no longer motivates and the next higher need takes its place.

But it’s a classic example of that adage about “For every complex problem, there’s a clear, simple, easy-to-understand wrong answer” – because the reality is just not that simple. For example, from first-hand experience about survival in a concentration-camp, psychologist Viktor Frankl explains:

Spiritual life strengthened the prisoner, helped him adapt, and thereby improved his chances of survival.

In that extreme context, the ‘hierarchy’ is inverted: survival depends first on ‘self-actualisation’, without which there is loss of access to any of the other ‘levels’.

I’ve long seen exactly the same about the Spiral Dynamics model. Spiral was derived (some might say ‘mutilated’…) from the work of Clare Graves [no relation], a contemporary and colleague of Maslow.

[And, apparently, a very close colleague at times - so much so that apparently Maslow's later versions of his 'hierarchy' do draw strongly on Graves' work.]

The Spiral model is invariably shown as a linear progression, each ‘level’ able to incorporate and extend the capabilities of each of the levels beneath:

(The original Graves letter-codes are just-visible here on either side  of each ‘level’-colour – individual on the left, collective to the right.)

But again, the reality is quite different. In most ‘traditional’ societies we simply don’t see the supposed characteristics of the Red, Blue, Orange or even Green layers – but we do see key instances of the systemic views that are supposedly characteristic only of the ‘higher’ Yellow and Turquoise layers. As I’ve said in other posts, it makes much more sense to think of Spiral not as a simple linear ‘stack’, but as a set of intersecting dimensions.

A key reason why we don’t see much of Spiral’s mid-’levels’ in ‘traditional’ societies is that those types of characteristics only become relevant in larger, denser social contexts, with greater complexities arising from multiple-order Dunbar-Number social-connectivity.

For example, the Green ‘level’ still needs an ‘Other’-group – a ‘Them’ – to carry the blame for everything; it’s only in a systemic-viewpoint (Yellow or ‘above’) that there is awareness that in practice there is only ‘Us’. Yet within a small grouping, there’s simply not enough separation to create much of a meaningful distinction between ‘Us’ and ‘Them’: hence the apparent Spiral ‘stack’ is compressed to just Beige (survival-individual), Purple (family – survival-collective), Yellow (systemic-individual) and Turquoise (systemic-collective), because the supposedly-intervening ‘levels’ simply aren’t relevant in that context. Thinking in terms of dimensions rather than ‘levels’ makes this point much easier to understand.

In Clare Graves’ original work, societies and individuals ‘move around’ within the ‘stack’ – which, again, makes more sense in terms of dimensions, because each change is usually an adjustment of intensity or focus along one dimension at a time. A key complication – which is often missed by Spiral aficionados – is that whilst individuals may place themselves anywhere, they’re likely to find themselves in significant social difficulty if their ‘position’ is more than about half a ‘step’ away from that of the mainstream culture in which they live. In practice we often see people simulating a ‘position’ that they don’t actually hold at all: and the tension of maintaining that ‘non-natural’ simulation can cause significant damage – a point that, as Scott Adams’ Dilbert cartoons document so well, definitely applies to ‘survival-tactics’ in overly-bureaucratic organisations…

Another huge danger with any linear-progression model is that it can be used to prop up delusions of ‘superiority’, and hence assertions of ‘right’ to priority or privilege. The problem is particularly severe with Spiral Dynamics, where ‘higher’ is all too easily conflated with ‘better’.

[As summarised on the Wikipedia page, Chris Cowan seems acutely aware of this danger; Don Beck and his co-'Integral' partner Ken Wilber don't seem to be aware of it at all, and even seem to encourage it, which is not a good idea...]

Shifting perspective from a linear progression to an intersecting of dimensions helps us to break free of this trap – which again can be extremely important in a business context.

So Maslow’s Hierarchy isn’t a hierarchy; Spiral Dynamics isn’t a spiral: those are just the largely-illusory outcomes of viewing a complex set of intersecting dimensions from a single arbitrarily-selected viewpoint. Once we move away from that fixed view, some very interesting implications can arise, along with some very interesting possibilities and options.

Over to you, anyway – comments, anyone?

Those notions of ‘whole-enterprise architecture’ that I’ve been describing in the ‘no-plan Plan‘ series of posts make solid sense to a fair few people – particularly those who’ve some experience of systems-thinking, design-thinking and the like. But it’s painfully clear that it doesn’t seem to make much sense to anyone else: and I must admit I’m struggling a bit with this…

How do we bring those different worlds together, so that we can put these ideas to practical use?

How do we make it make sense?

Okay, so part of the problem is the age-old clash between theory and practice. Practice needs theory; theory needs practice; that point seems fairly well accepted, I think? Yet there’s that old joke (from Yogi Berra?) that “In theory, there’s no difference between theory and practice. In practice, there is.” Which means that practitioners tend naturally to be somewhat wary of too much theory. And there’s the ‘time-compression’ problem as wel: right out the rough edge of real-time, people simply don’t have time to stop and think about theory. Yet the fact that they don’t look enough to theory may itself be a key reason why they don’t have the time…

Chicken and egg: which comes first – theory or practice? Yes… therefore no… sometimes…? How do we get out of that loop?

There’s also the “in a perfect world” excuse, as my colleague Marcus [not his real name] was bewailing the other day:

It’s just chaos out there, doing everything the hard way. But if I suggest anything to cut down on the chaos, even something really simple like using scripts in a spreadsheet, so that they could get a chance to get started, it’s always the same response: “yes, Marcus, in a perfect world, but…”, “that might work in a perfect world, but…”, “we could do that in a perfect world, Marcus, but in the real world…”.

What’s worrying was that this was the architects – the people who were supposed to understand IT-architecture. Worse, he said, they were hardly using any of their architecture tools to clean up the architecture: in fact, of the thousand licences for a high-end EA toolset that their corporation had paid for, they were actually using just six.

Sure, many people are running on extreme overload most of the time; but with these guys, and many others like them that I’ve dealt with in so many different disciplines over the years, I sometimes feel a bit like that line from the old Jethro Tull song, that “Your wise men don’t know / how it feels / to be thick / as a brick”. These guys are all really smart, and I’m acutely aware that in most ways I’m the one who’s “thick / as a brick”, the one who doesn’t fit in, who doesn’t think the same way as everyone else; yet what the heck is going on here? It just doesn’t make sense.

I remember a string of conversations here about value in business, and about why we couldn’t use money as the only measure of value within an enterprise-architecture: but that went straight down like a lead-balloon too. Likewise just about all of those themes in the ‘no-plan Plan’; likewise many other what seem to me fairly straightforward points such as the one about ‘people are not assets’. It’s really clear that these notions just don’t make sense to most people in business and elsewhere. And as for some of the more way-out themes – such as an end to most current management-models, an end to money, and end to ‘rights’ or, ultimately, an end to possession itself –  that, in a futures-sense, I see as shifts that will and must be inevitable in the longer term… well, to most people that seems like all of that’s just on another planet. Cloud-cuckoo land. Forget it.

Or, perhaps, is it just too scary? – too far out of comfort-zones for people who must be able to purport being ‘in control’ at all times? I just don’t know. As Peter T pointed out in a recent comment here, even simple factual implications from a decent SCM [software configuration-management system] were deemed all but too fear-laden to face: so how the heck are most business-folks gonna face a mythquake that is – for most people, it seems – literally of almost unimaginable proportions?

And even though what we’re doing is ‘enterprise architecture’ in the most literal sense of those words, we can’t even use that term any more, because it’s been too ‘poisoned’ by Open Group and their ilk: their consistent misuse of the term has made things so bad for all of us – themselves included – that no one in business would trust us if we used the ‘A’-word at all. Which leaves us in a bit of a quandary even as to what we can call what we do…

It doesn’t make sense. And it needs to. Urgently. That part at least does make all too much sense…

Anyway, the quick summary of what we need to ‘make sense’ would seem to be much as per that initial post on ‘the plan that is no-plan‘:

• it’s about the architecture of the enterprise as a whole – how everything works together towards some overall aim
• it’s about the underlying ‘why’ of the overall enterprise, and how that links to the ‘how’ and ‘with-what’ and so on that make everything happen
• it’s about both structure and story, in the broadest sense of each
• it’s planning for and working with change, with inherent-uncertainty, rather than trying to fight against it
• it’s about identifying and managing hidden costs and risks – and hidden opportunities too
• it includes a strong focus on where people fit within the overall enterprise
• it’s about defining and using toolsets, visualisations, dashboards and other techniques to help people make sense of what’s happening within the enterprise, and in making decisions about how to keep the enterprise on track
• it’s about bringing all of these themes down into really practical, concrete, everyday expression, enhancing effectiveness through the enterprise

All straightforward and obvious – to me, at least. Also straightforward and obvious – to me at least – is that lack of awareness and integration of these themes is a large part of why there’s so much stress at work and elsewhere. Yet it’s also obvious that most of this just doesn’t make sense to most people. And the really serious ‘really big picture’ problems really don’t make sense to most people – so much so that even talking about them at all usually gets me labelled as crazy or worse. But if we don’t do something about those themes, a lot sooner than just Real Soon Now, we’re in deep trouble. (Okay, we’re in deep trouble already, frankly, hence this would be even worse Deep Trouble from which there really is no way out…) Yet if it doesn’t make sense, then no-one is going to do anything at all – until it’s too late even if it does finally make sense.

Really struggling with this feeling of “thick as a brick”, the lost toad-in-the-road, ‘the crazy ones’. When something that makes obvious sense doesn’t make sense to anyone else, how do we make it make sense? Or should we even try?

A real serious challenge here, in almost every different sense. Oh well.

How can we ensure that the ideas and models that we use are appropriate to the context? What methods can we use to evaluate new ideas? Perhaps more to the point, how do we protect ourselves from ideas that won’t fit in our architecture-ecosystem?

This extends the previous post on ‘Coping with the toad-in-the-road‘, where the ‘toad’ is “a clear, simple, easy-to-understand wrong answer” – in other words, something that isn’t appropriate or useful in the context.

(Again, I want to emphasise that the ‘toad’ here is an out-of-place idea or model or theory – not a pejorative description of a person!)

In general I use the idea of a ‘living system’ as my core metaphor for an enterprise – which in turn suggests other metaphors such as an ecosystem or, on a smaller scale, a simple suburban garden.

So imagine that the ‘garden’ describes the ways in which we ourselves do our enterprise-architecture. It’s a garden of ideas and models and tools and techniques – an environment for ideafarming, perhaps. Some people’s gardens might be formal, constrained, regimented, rather like that at a classic French chateau. Other people’s might be large enough to contain the kind of sweeping vistas of which Capability Brown might be proud. I’d have to admit that my own idea-space is, uh, a bit more eclectic? – the style sometimes referred to as cottage garden’, with its own definite charm and vibrancy and bright colours everywhere and occasional surprising juxtapositions, but with so much semi-intentional ‘unorder’ that some people might at first see it only as a mess. Oh well.

Whatever the style of garden, though, we need to be careful what we introduce. Some ‘good ideas’ can run rampant if they’re let loose in the wrong place: consider the damage done by now-wild rhododendrons in northern Wales, or gorse (furze) or rabbits in Australia. Which, in turn, brings us to the metaphor of the toad-in-the-road.

I like toads. We used to have one that lived very happily for years in the laundry-drain just outside the house: we had to remember to take it out of there before we did any washing, and politely put it back again afterwards. (True story. ) They’re often very long-lived; some can survive drought for decades, hibernating in a little patch of damp somewhere beneath the surface, popping up again as soon as the conditions are right. And although there are some toads that we won’t want in a garden – or anywhere, really – most of us wouldn’t mind a toad that will fit in well with our ecosystem. Toads are wonderful for keeping down the slugs and other garden-pests: if we have a strawberry-patch, we definitely want a good toad. But we don’t want that toad in the road – or anywhere else where it doesn’t fit, is probably putting itself at risk in any case, and is demanding our attention when we could really do without it being there.

Hence, the same with ideas that are out of place for the context: the metaphoric toad-in-the-road.

It’s not ‘an elephant in the room’. It’s not ‘an eight-hundred-pound gorilla’, or ‘a bull in a china-shop’. It really is quite small: it’s just a toad in the road – an idea that’s in the wrong place. (If it was in the right place, it’d be back under the strawberry-patch, happily munching on slugs. Metaphorically speaking, anyway.) But it somehow looms much larger in our attention than it really is – especially when it’s sitting out there, in the road, in the way, and generally making a right old nuisance of itself. Sigh… “oh no, not again”… yep, that kind of feeling.

In the previous post, I came up with a list of four categories of toad-in-the-road:

• the friendly toad that gets in the way a bit, but is really useful in the right place
• the not-much-use-for-anything toad that gets a bit too much in the way, especially when it’s over-excited
• the bloomin’-nuisance toad that we’re best off to toss out of the garden, and keep out as best we can
• the darned-dangerous toad that we need to keep out of our space at any cost

In reality, though, there aren’t any categories as such: they’re all toads, each with their own characteristics. And in terms of working out what to do with the toads – especially those that have just arrived in our garden – it might be more useful to take a somewhat different approach:

• what is the natural habitat for this toad? [where does this idea or model really belong?]
• are there any seasonal concerns, such as mating-season? [where is this idea in terms of the 'hype-cycle' and the like?]
• are there any behavioural characteristics of which we need to be aware, such as aggressiveness or excessive timidity? [in what ways is this idea promoted, and by whom?]
• is it likely to be toxic or invasive in our ecosystem? [does this idea tend to destroy, override or block out other more-useful ideas?]

Every toad-in-the-road has its own distinct combination of these themes – and the combination will usually vary over time or context, too. Hence it’s probably more useful to take this approach than some overly-simple set of categories.

Every idea has its own habitat – the place or context where it would most naturally fit. When evaluating a new idea, a key part of that task is to identify where it claims to fit, versus its ‘natural’ fit – because often there’ll be a mismatch. In many cases, the mismatch will arise from a conflict on terminology: a term that has a specific meaning in one context has a significantly different meaning in another context – which creates a toad-in-the-road when the previous meaning is carried through to the new context.

One example from the previous post was Roger Sessions’ work on minimising ‘complexity’ in IT-systems: it’s a very good idea that does make sense in an IT-context, where ‘complex’ is a kind of synonym for ‘extremely complicated but controllable’ – but it doesn’t make sense in non-IT enterprise-architecture, where ‘complex’ means something that, by its nature, cannot be controlled. In that sense, its ‘natural habitat’ is IT: we need to ensure that it’s only used in IT, and gently dissuaded from wandering anywhere outside of that domain. We might describe that as negotiating with the toad to help it find its way home.

Some of the most useful ideas are ‘mash-ups’ – a fertile hybrid resulting from a re-mix or re-use of an idea in another perhaps-’unnatural’ habitat. Perhaps the most important point in evaluating these is that it’s technology, not science – almost by definition it can be unlikely to make sense in strict ‘scientific’ terms, because it’s doing a mix-and-match across domains. For the same reasons, evaluating such ‘mash-ups’ may require quite a lot of contextual skills and experience – a lot more than the simple logic-proofs that apply in the straightforward ‘exact-sciences’. We should also note that whilst people who are over-enamoured of science-like certainties may rail against ‘miscegenation’ and the like, fact is that ‘mix-and-match’ is an important part of evolution, and hybrids often bring vigour back into a tired environment.

We don’t have to look far to find examples of valuable ‘mash-up’ ideas: they’re common in almost every environment, though in some cases they have to be hidden for a while from the ‘truth police’ until they prove their value – the story behind the discovery of quasicrystals, which won the 2011 Nobel Prize for Physics, being one infamous example of the latter. (We also see fascinating examples in the natural world: for example, blue-tits and other small birds taught each other how to peck through the metal-foil caps on milk-bottles in Britain to get at the cream underneath.) Mixing metaphors a bit – and why shouldn’t we, in this case? – we might describe this as an ‘ugly duckling’ kind of toad: we need to work with the toad to help it find out who it really is and where it would truly belong.

Some ideas are just plain wrong – often because there’s not enough rigour or muscle behind them, or because they’re a kind of sterile hybrid from the wrong kind of re-mix. This, of course, is the flip-side of ‘mix-and-match’: many of the mash-ups just won’t work in any domain. The evaluation-rules will vary according to context – science for science, art for art, and so on – so we need to take especial care when an idea bridges across domains, whence multiple and often conflicting evaluation-rules would apply.

An example of a cross-domain mismatch – also mentioned in the previous post – is the notion of ‘engineering the enterprise’, embedded in parts of the Zachman framework, implicit in almost all of Taylorist ‘scientific management’ and its derivatives, and also in many of the ideas about ‘enterprise ontology’. This notion might make sense if ‘the enterprise’ was some kind of machine: but by definition it’s a human construct – “the animal spirits of the entrepreneur” and suchlike. The only way that ‘engineering the enterprise’ can be forced to make sense is if we force people to act as if they’re machines – which rarely delivers good outcomes for anyone. Sadly, once we’ve evaluated this kind of idea and found that there really is no way it could work, the only kind thing to do is put it out of its misery: we could describe this as respectful euthanasia for the toad.

Some ideas may be too simple to survive on their own – usually the result of too much repetition in the same place, slowly wearing away all of the useful rough-edges and exceptions. Simplicity is not inherently a problem – in fact it’s often of real value when we look for a starting-point for new hybrids, or a mix-and-match to address true complexity. What we’re evaluating here is the crucial difference between ‘simple’ – which often isn’t simple at all – and overly-simplistic – which isn’t much use to anyone.

Every ‘law’, ‘rule’ or ‘regulation’ – whether scientific or otherwise – is an abstraction of some kind, a simplified version of some aspect of the real world. There are no shortage of examples: in most contexts we’re surrounded by them, everywhere we look, and there’s no question that they do usually make work and life more simple. It can become a toad-in-the-road, though, whenever anyone starts to believe that the world really does work accordance with that purported ‘law’ or whatever: because the blunt fact is that the real world is rarely that simple. If it is too simple, yes, it does still have its uses, but we need to acknowledge its limitations: we could describe this as finding a sheltered space for the toad, protected from the rough-and-tumble of the real world.

Ideas may have their own seasons – often following the ‘hype-cycle’ or some other lifecycle. For any new idea, the early part of the hype-cycle is like a breeding-frenzy – and however useful the idea may turn out to be in the longer term, we’re not going to get any sense out of anything until that mating-season is over. We need to catch the idea either before the breeding-frenzy starts, or wait until all the dust and hype settle down again.

On the IT side of enterprise-architecture right now, obvious examples include the hype around cloud-computing and IT-consumerisation and, of course, the wild proliferation of ‘certification schemes’ (or scams, as some would put it…). For business-architecture it’s all the excitement about business-models rather than business-plans. We can also see that previous breeding-frenzies around ideas such business-process outsourcing, Agile development or Six Sigma have faded back enough for us to be able to evaluate what aspects might be useful in specific contexts. But whilst the breeding-frenzy is in full flow, just about all we can do is put up large warning-signs, and hope for the best.

(By the way, that triangular symbol above is the standard ‘Migratory Toad Crossing Ahead‘ warning-sign: UK DOT 555.1, to be precise. An essential item for your enterprise-architecture office! )

Ideas can be aggressively territorial – it ‘hogs the space’, blocking out everything else. Often this will be associated with a ‘term-hijack‘, where a narrow subset of a context is purported to be the whole of that context – actively blocking out any view of the rest. These types of ideas can be a serious pest, because they’re so busy claiming and defending ‘their’ territory that they can make it all but impossible for other often-more-useful species in that ecosystem to survive. When evaluating new ideas or models, we need to test for any such tendencies: these are usually typified by over-simplification or over-certainty, endless repetition of its catch-phrases, habitual attempts at term-hijack, and a strong tendency – sometimes backed by force – to redirect any straying attention back to itself.

In enterprise-architecture, the most obvious example at present is the IT-centrism inherent in TOGAF and the like, though a new ‘business-centrism’ is also now coming to the fore. In both cases the underlying driver – in addition to the rather pointless ‘need’ to dominate the entire ecosystem – is an overly-simplistic misuse of the notion of a ‘centre’ to the architecture. (In reality, there is no single centre to the ecosystem, but rather that everywhere and nowhere is ‘the centre’, all at the same time.) There are all too many other examples of the ‘territory-grab’ problem, of course, in just about every aspect of enterprise-architecture. As for tactics, we may need to put up metaphoric warning-signs – as for any idea’s breeding-frenzy – but our best approach here is to always emphasise the whole ecosystem, and adjust the structure of ecosystem as necessary to dissuade this toad’s dominance.

Ideas can be too noisy in the way they promote themselves – ‘too noisy’ in the sense that, again, they drown out out other potentially-valuable ideas, but more by actively demanding our attention rather than blocking our view of everything else. This tends to happen a lot when the hype around some new idea is building at full blast, and especially so where the idea is forcefully promoted by some charismatic figurehead. It’s difficult to evaluate any ideas at all when we can barely hear ourselves think, let alone hear about anything else…

A good example for enterprise-architecture was all the hype around the earlier versions of Andrew MacAfee’s ‘Enterprise 2.0‘. The notion of using social-network software within a business was – and still is – a good idea: but the initial over-focus on technology above everything else was plainly absurd, and describing it as ‘Enterprise 2.0‘, implying an entirely new kind of enterprise, was even worse – a ludicrous if largely-unintentional term-hijack. But again, this is only one of all too many examples: the current over-hype of ‘anything-Cloud’ is another ‘noisy toad’ that we’re dealing with right now. Probably the best tactics here are to block out the sound where necessary, and emphasise our other senses instead.

Some of the most useful ideas may be too quiet for us to notice – the converse of ‘too noisy’. There are a lot of good, useful ideas out there: but they’re often so diffident and quiet that it can be difficult to identify their potential value to our ecosystem when we find them, or even to find them at all.

For me, in enterprise-architecture, one example would be Nigel Green‘s VPEC-T. Another would be the stream of ideas on sensemaking and the like on Cynthia Kurtz‘s StoryColoredGlasses website, and especially her crucially-important concept of ‘unorder’; which leads in turn to the work on business-story work by Shawn Callahan and colleagues at Anecdote. Everyone has their own examples, no doubt. But given the cacophony and near-chaos that’s always around us in the idea-garden, we do need to make a deliberate effort to understand the deeper needs of our ecosystem, and keep our eyes and ears and other senses open for the ‘the quiet ones’ that often matter most.

Some ideas are naturally toxic – they make it impossible for other ‘competitor’-ideas to thrive, or even survive, in that context. These are the cane-toads of our idea-garden: and whilst any idea can be toxic in some sense, it’s especially common with out-of-place paradigms, because by definition they purport to be a complete or final ‘the truth’ about the whole of a ‘world’ – and hence will always attempt to exclude every other possible view. When evaluating new ideas, we need to note how much they depend on asserting that something else is ‘wrong’ – and if so, why. We also need to identify the contexts to which it does apply, and which it doesn’t – because any ‘territory-grab’ beyond its natural context will automatically tend to make it toxic to other more-useful ideas in that broader space.

There’s a subtle point to watch here. In a sense, any idea that’s over-territorial or even over-noisy is sort-of-toxic: it will certainly tend to block out everything else, for a while at least. But in the case of ‘cane-toad’ ideas – truly toxic ideas – it’s not a behaviour as such: more that they poison everything, just by their very existence. As I said in the previous post, we probably don’t have many true ‘cane-toads’ in enterprise-architecture as such – though IT-centrism certainly comes close – but in the broader business sphere and beyond, such ‘cane-toads’ definitely do exist. Examples include the near-feudal concepts that still dominate most management-models; the absurd over-obsession with money as a measure of value in business; the insanely-inadequate notions of ‘economics’ on which our world supposedly depends; and, going deeper, the dangerous delusions of ‘rights’ and, deeper still, the all-pervasive, ever-pernicious paradigm of possession. (Those last are so toxic that, to be blunt, we need to kill them off before they kill us all…)

We do need to careful not to harm something that’s simply out of place, so for most ‘cane-toads’ the preferred tactics would be to isolate and remove, and publish warnings to other ‘gardens’ about the risk. Yet for any lethally-toxic toad – one that poses an existential threat to every ecosystem – the only safe tactics are to eradicate and exterminate entirely: and we do need to face up to the fact that on rare occasions that is the only option we have.

Many ideas can hibernate, re-emerging whenever the conditions seem right – and we need to note that this applies even to the most toxic of ideas. Every ‘toad in the road’ is “a simple, clear, easy to understand wrong answer”: and because they’re simple, because they seem clear, and because they’re easy to (sort-of) understand, that tends to make them very attractive, and very popular. Which means that despite the fact that they’ve long been identified as a ‘wrong answer’ – in some cases a ‘wrong answer’ for any question – they still on keep coming back, and coming back, and coming back, like a toad re-emerging with the rains after a drought. The catch with ‘idea-toads’ is that they often change their surface-appearance each time: but underneath it’s the same mistakes, the same old shallow, stupid, over-simplistic ideas – hence that dread feeling of “Oh no, not again…”.

For our discipline, probably the classic example is Taylorism – or rather, the vapid belief beneath its supposed ‘scientific management’ that everything can successfully be made subject to a simplistic sense of ‘order’. We know it doesn’t work, other than in quite narrow and clearly-constrained contexts: that fact has been proven time and time again, not least by Deming and others at the ‘front-line’ of production and elsewhere. But the same mistake still keeps coming back, time after time, for the simple reason that people want to believe in the myth of ‘control’. Hence, for example, Davenport and Hammer & Champy’s ‘Business Process Reengineering‘, an almost unmitigated disaster – other than in the few cases that didn’t try to use technology as the sole basis for complex business processes. Hence, for example, the many misapplications of Six Sigma, which by definition only makes sense in a context where there are literally millions of identical events. And hence, at present, the sad struggles of proponents of ‘business-rules engines‘ to get them to deliver any real value in business-contexts that, again by definition, are often inherently beyond any feasible rules’. Oh well…

For any of us blessed – or cursed – with long memories, dealing with the vampire-like return of yet another formerly-vanquished toad can be both sad and extremely frustrating. So in evaluating any supposedly-’new’ idea that has aspects that we sense we might have seen before, we need to check its anatomy and underlying structure – and we need to be especially careful to do so whenever the conditions are right for the return of any well-known toxic-toad.

Ideas may take on any combination of these characteristics – and the combinations may vary even for a single idea in different contexts or in different stages of its lifecycle. In evaluating ideas, and testing for a potential ‘toad in the road’ we do need to be careful of applying assumptions that themselves may not be valid in a different time or place. We also need to respect the nature of the toad itself: applying ‘scientific’ criteria to evaluate an artistic idea has never worked well – and the inverse has rarely been much use, either…

We see a lot of these ever-changing combinations in enterprise-architecture. For example, IT-centrism is a Simple idea that keeps re-emerging from the depths, no matter how much we push it away; and as soon as it appears again, it has an immediate and usually very-noisy mating-frenzy with whatever the current technology might be. It’s much the same with Taylorism, as above. Right now, the ‘big noise’ is around ‘cloud-computing’ and related ideas such as ‘platform-as-a-service’ – which, once we think about it for more than a minute or two, is just a current hybrid of some very old ideas (centralisation, service-orientation) and some somewhat-newer ones (access-from-anywhere, any-platform). So whenever faced with this, or any other ‘new’ idea, all we need to do is apply the various tactics described above – and erect the appropriate ‘Toad Warning’ signs wherever they’re needed.

Do remember, though, that it’s ‘Toad Warning’ – not ‘No Toads!’ (A nice shiny triangular sign, as above – not the more threatening circle-with-a-slash-through-it type of sign.) We like our idea-toads; and even if we don’t want to touch them (ugh…? yuk!), most toads are good – in the right place, such as out in the garden, protecting our precious plants from parasites and pests. So all that we don’t want here is – yikes! – a Toad. In. The. Road!

In short, be kind to your idea-toads, treat them well, treat them with respect, find them their proper place if need be – and remember, that next toad-in-the-road that you meet could well be one of yours…?

Every discipline is blighted by their own versions of an all-too-common problem: “For every difficult, complex, challenging question, there’s at least one clear, simple, easy-to-understand wrong answer”.

In Australian parlance, that type of magnificently-misleading ‘wrong answer’ is known as ‘the toad in the road’.

Every ‘trade’ has its toads, in some form or another. In the case of enterprise-architecture, given our necessarily very broad scope, we do seem to have rather a lot of them. Oh well.

It’s a toad. It sits there, blocking the way. In reality, it’s not actually that big, but it somehow demands our attention, making it difficult to deal with anything else. But we can’t just drive over it, stomp on it, squash it into a literally bloody pulp: I know that some people would do that, but it does have its own right to live, after all. Yet we do need to be careful: some toads are downright toxic. And, it’s well, kinda, yuck… no-one seems very willing to pick it up and put it politely out of the way… Oh joys…

Yeah: that kind of problem.

So how do we deal with ‘the toad in the road’?

It’s different in every case, of course.

Some of the toads in our space are really no problem: they’re just in the wrong place, that’s all. Some of them are positively genial, the kind of toad that, if it had a hat, would doff that hat with a broad smile and an offer to share a slightly-chewed slug. Like all toads, of course, they’re stubborn and they’ll stand their ground, which isn’t exactly helpful when they’re in the middle of the driveway and we need to get moving for the day; but they’re usually quite cooperative as long as we’re respectful about how we shoo them back under the strawberries instead.

Roger Sessions‘ IT-oriented version of ‘complexity’ is one such toad: it’s fine for IT, but for enterprise-architecture it’s an over-extension of ‘order’ into a realm of inherent ‘unorder’, and it really doesn’t work. Likewise John Zachman‘s notion of ‘engineering the enterprise’: it would make sense if an enterprise was an aircraft, which, however, it isn’t. Oops. In both cases, it’s definitely “right idea, wrong place”; and yes, we do all kinda know it. Sure, there will always be arguments about the positioning of that kind of toad: but people like Roger and John are unfailingly courteous and polite, so much so that it’s always a pleasure to disagree with them yet again.  It’s just a kind of game we play from time to time, and we all know it’s a game – sort of how a toad would really like it if the driveway would turn itself into a strawberry-patch because that’s what they know best, and it’s somehow our fault that it isn’t.

There are other kinds of toad that are somewhat similar, but they often seem a bit brainless, so it’s lot harder to negotiate with them. The real problem is that there’s just so many of the darn things: they turn up everywhere, all crawling over each other beneath our carefully-tended bushes and shrubs, digging around for worms and grubs, and generally making a right old mess of everything in the process. Their all-pervasive slime and stench is… well, let’s just say we wouldn’t call it pleasant? – and they don’t really help in any way in the garden.

At present, the dominant toad of that type in our space is IT-centrism, though there are signs that a relatively-new species of business-centrism is beginning to move into our enterprise-architecture garden as well. Perhaps we shouldn’t mind so much, but it’s difficult to get any rest with the constant croaks of “Cloud! Cloud!” and the like… Sigh… Unfortunately, it is hard keep them out of the garden – and if we do somehow succeed in doing so, we’d probably block out all the friendly toads as well, which would be a real loss. Other than the mess that they make, though, these toads are fairly harmless, and there’s probably not much we can do anyway until they get the other side of their current breeding-frenzy (otherwise known as ‘sales-hype’ and ‘certification’). In the meantime, we just need to be careful where we tread, and keep on tidying up the mess as best we can.

There are a few types of toad that we really don’t want in the garden – in fact we need to apply considerable care to keep them out of the entire metaphoric country. These are the cane-toads of a trade – so poisonous that they’ll kill off just about everything in sight, just by their mere presence. Yikes… The real tragedy of the cane-toad, though, is that often it’s initially thought of as some kind of saviour – as was true of Taylorism in our industry’s case, for example. But the reality is that they’re seriously toxic, in almost every possible way – and that toxic nature soon wipes out any possible value they may have had. Not a good idea…

Some disciplines – social-work, in particular – seem beset by cane-toads on every side; by contrast, we don’t seem to have any at present in enterprise-architecture, which makes us fortunate indeed. There’s some risk that IT-centrism and the like could turn into cane-toads, but they don’t seem to have done so as yet – though they’re certainly enough of a problem for us as it is. Taylorism and its more recent sub-species such as BPR and over-hyped ‘business-rule engines’ have been fairly serious cane-toads for us in the past, but each seem now to have faded back into a more natural niche in the overall enterprise-architecture ecosystem. The existence of cane-toads, though, should warn us to be very careful of what we introduce into the enterprise-architecture garden, and to be wary indeed of the ever-present risk of unintended-consequences.

And there a few types of toad that are kind of in the middle – literally in the middle, too, because often it seems that all they really want to do is get in the way. In some cases there may only be one individual of a species in our garden: but like the brainless toad, it somehow manages always to be right in the middle of where need to be – and it won’t budge. At all. Unless it can do so in order to get in our way again… It’s perhaps not as toxic as the cane-toad, but it’s definitely in the wrong place – yet will not respond to any kind of reason, or any request to move on. It just sits there, puffing itself up like a bullfrog, making lots of noise, demanding our attention, and generally acting like it’s the only thing that could matter to anything or anyone in any way. It could perhaps be of use elsewhere in the garden: but since it won’t move there, we never really get much of a chance to find out. What it somehow never manages to accept is that in reality it’s nothing special – it’s just another toad. That’s all. A toad in the road: another darn nuisance that we could really do without…

For enterprise-architecture, IT-centrism has been a bit like that, though it is getting somewhat more amenable these days. All the hype around Cloud is getting to be a bit too much of a toad-in-the-road these days, too. But for me at least, by far the worst toad of this type is Cynefin. It seems we can’t ever talk about complexity without Cynefin insisting on getting in our way. We struggle to talk about even the simple or the complicated without accidentally invoking its unwanted presence. We can’t talk about uniqueness or inherent uncertainty – the business sense of ‘the chaotic‘ – without Cynefin demanding that it alone knows the truth about that space – when in reality it has nothing useful to say other than that we shouldn’t be there. Much like IT-centrism, it has perhaps rather too many characteristics of a cult. And whilst in principle it could be useful in enterprise-architecture, we can’t make much use of it in practice, because its promoter endlessly insists on barging into our space, spitting venom at anything he regards as ‘heresy’ - literally, ‘to think different’ in any way from himself.

We’ve all spent too much time hiding in fear from those attacks: I know way too many people – myself included – who’ve had to invoke Bob Sutton’s ‘No Asshole Rule‘ in that person’s direction, too. The bleak reality is that I’ve spent way too much time and effort pandering to his insatiable demands – much like the pointlessness we supposedly ‘must’ go through in order to get round a toad that endlessly insists on putting itself in our way, and then blaming us for the resultant conflict.

After the last attack, though, I took a more careful look at his snarky putdowns, in which he dismissed my work as valueless, a “hash-up”, “invalid in certain essential aspects” – yet notably failing to give any details as to how or why it should be so regarded. Hmm… time to stand up for myself, for once? So I’ve spent the past few days proving, to myself at least, that my work on context-space mapping is of value, by using it to assess Cynefin itself in terms of its usefulness – or lack of usefulness – for our enterprise-architecture discipline.

The results have been, uh, interesting… (I’ll publish it here if anyone wants, though I’d warn that it’s kinda long even by my standards…) It certainly confirms that, in present form, Cynefin is indeed likely to be useful in the Complex domain; but it’s of questionable value in any other domain, and inherently worse than useless for anything in the Chaotic domain. Another interesting point was that, despite its promoter endlessly railing at anyone who dares to use Cynefin as a categorisation-framework, that’s exactly how he himself uses it in ‘his’ much-publicised HBR paper [PDF]. And that analysis also highlights some nagging suspicions that the base-level Cynefin Framework is actually a Simple-domain technique that’s merely masquerading as a Complex-domain tool – which would be neither helpful nor wise.

Perhaps the most disturbing point, though, is what came up from a more detailed cross-comparison from the context-space map. That’s that the simplified version of Cynefin that’s all that most people see, and the way in which it uses its purported theoretical base in complexity-science, make it an almost perfect tool for (mis)use by any consultant who wants to pander to the fears of worried executives, and provide them with spurious ‘evidence’ that they’re ‘in control’ of something that, by definition, cannot be controlled. That’s not good – doing that would be seriously dishonest, so surely no-one would be so unethical as to do that, would they? And yet that temptation is built right into the very fabric of the framework… worrying indeed…

But the most important point this is this: it’s just another toad. Yes, sure, for our own safety, we might well need a shovel to scoop the wretched thing up: and, despite the strong temptation to use the shovel in another way entirely, we can toss that toad into another discipline’s garden where it might be more at home – and then make darn sure that it doesn’t come back again into ours. That’s probably the best way to deal with that type of toad.

So that’s four types of toad-in-the-road we all have to deal with, perhaps rather more often than we’d like:

• the friendly toad that gets in the way a bit, but is really useful in the right place
• the not-much-use-for-anything toad that gets a bit too much in the way for a while, especially when it’s over-excited
• the darned-dangerous toad that we need to keep out of our space at any cost
• the bloomin’-nuisance toad that we’re best off to toss out of the garden, and keep out as best we can

What’s your experience of ‘the toad in the road’? What are the various types of toad that you have to wrestle with in your own work? And how do you best cope with each?

Comments/experiences/suggestions, anyone?

[Update: A reminder, because a couple of people already seem to have missed this point: in this context, the 'toad' is not a person, it's an idea - "a clear, simple, easy-to-understand wrong answer". For example, the idea of IT-centrism is an example of the second type of 'toad'. This is very important indeed: for example, in no way would I describe either Roger Sessions or John Zachman as 'a toad' (though knowing them both, they might quite like the image above of "doffing a hat with a broad smile and offering to share a slightly-chewed slug"... )]

A great conversation this morning with Nigel Green, about his post ‘When is striving for Simplicity in IT-EA a good thing, and when…?‘ (“…is it less important, or even unhelpful?”, was the completion of the sentence).

He’d been having a long discussion with another well-known figure in the IT-architecture space, who’d insisted that we should always aim to simplify. Nigel was uncomfortable with that assertion, in fact was all but certain it was only true under specific contexts, but wasn’t sure how best to describe those contexts or the differences between them.

At that point he turned to the diagram from his previous post ‘A thinking framework for Business/IT ‘Systems’ behaviour based on Cynefin‘:

As you’ll see from his ‘Simplicity in IT-EA’ post, he then started filling in more detail about what each of those domains would look like in terms of IT-applications:

• Organiser (‘Simple’) – “most IT sits here: Office + ERP”
• Expert (‘Complicated’) – “CAD/CAM, rules-engines, complex-management systems”
• Adapter (‘Complex-Adaptive’) – “sense-and-respond systems, ‘complex event processing’, BPMS”
• Connector (‘Chaotic’) – “web + social-networks”

Which is a very useful way to split up the IT space.

But if we have just one domain called ‘Simple’, is that the end-point of all simplicity? Could everything become defined by simple rules? Could everything ultimately be reduced to definable IT? That other well-known figure clearly thought so. But Nigel didn’t; and neither do I. To explain why, I’ll quickly summarise what Nigel and I talked about in our conversation.

Some of the same themes can be seen in my previous post ‘Backbone and business-rules‘, which also points to Nigel’s earlier post above. Perhaps the key point is a slightly different way to use the Cynefin-categorisation, emphasising what we use for decision-making within each of the domains:

• Simple – rule-based
• Complicated – algorithms
• Complex (‘Complex-Adaptive’) – patterns and guidelines
• Chaotic – principles

The crucial factor here is that there are fundamental differences between each of the domains.

In the Simple domain, cause/effect relationships are linear, and direct: we can use simple rules to drive decision-making. Simplification here consists of finding ways to reduce the number of rules, and to remove any duplications or conflicts.

In the Complicated domain, cause/effect relationships are still linear, but may be indirect, with multiple interacting factors, feedback-loops and delays. We can still use linear true/false logic – the kind that almost all computers use – but we can’t reduce it to simple rules: we have to use algorithms, and those algorithms can become very complicated indeed. Simplification here consists of cleaning up the algorithms, and identifying ways to simplify relationships between all the various factors: but again, it can’t all be reduced to simple rules.

In the Complex domain, at least some of the cause/effect relationships are non-linear: cause and effect become intertwined, and to some extent interchangeable. We shift from a simple true/false logic to a modal-logic (alethic logic of possibility, probability and necessity), with decisions guided by statistical patterns or more fluid guidelines. IT-systems shift from decision-making to decision-support, such as pattern-matching for final decision via ‘human-in-the-loop’; IT-based algorithms may be used for the pattern-matching, but cannot (or should not) be used for the final decision-making itself. Simplification here consists of refining the patterns and pattern-matching algorithms, and developing and refining training, education and guidelines for the human-element in the decision-making.

In the Chaotic domain, no distinct cause/effect relationships can be identified – typically either because the event is in some way unique or non-repeatable, or because it occurs at or near real-time, without sufficient time to assess causal links. Because there is no apparent repeatability, attempts to use true/false logic make no sense; decision-making is typically via principles or some other equivalent ‘guiding star’. Decision-making here will always require ‘human-in-the-loop’. The main role of IT-systems here tends to be information-capture and presentation: they cannot (or should not) be used for decision-making here, other than perhaps by inserting deliberate randomness into a human decision-making process to disrupt inappropriate assumptions and other ‘pattern-entrainment’. Simplification here consists primarily of clarifying information capture and display (decision-journey, user-experience, infographics etc), and of refining the applicable principles by identifying and clarifying priorities, conflicts and the like.

In the ordered domains (Simple and Complicated), repeatability can be eventually guaranteed, although varying levels of difficulty (‘complicatedness’) may be needed to achieve it. Einstein’s dictum applies here: we would be crazy to do the same thing and expect different results. In these domains it is possible for decision-making to be entirely IT-based: to many people, this brings a satisfying sense of ‘control’ over the context.

In the unordered domains (Complex and Chaotic), repeatability can not be guaranteed, regardless of how much effort is put into the analysis. (The distinction between ordered and unordered domains is qualitative, not merely quantitive: despite the assertions of many IT-folks, true complexity in this sense is not the same as ‘very complicated’.) Einstein’s dictum often becomes inverted here: we would be crazy to do the same thing and expect the same results. Any notion of certainty or ‘control’ here is illusory at best, and often a dangerous delusion. In these domains it is not possible (or rather, it is usually unwise) for decision-making to be entirely IT-based: efforts to ‘simplify’ by attempting to remove all ‘human-in-the-loop’ elements will often convert an already difficult problem into an irresolvable ‘wicked-problem‘, and will always make things worse.

Note that very few real-world contexts will fit solely within one of these domains; most contexts will include elements from all of them. One of the first requirements for simplification in IT-architecture or a broader enterprise-architecture would be to identify which elements of the context are in which of these domains – Simple, Complicated, Complex, Chaotic – and apply the appropriate simplification-techniques to each. Using one domain’s simplification-techniques in a different domain will usually make things less simple: if a context seems to be becoming more complicated, complex or chaotic, it’s probable that the wrong type of ‘simplification’-technique is being used.