Yet another longish one about enterprise-architecture (EA) and related themes – skip over it if that’s of no interest, otherwise click the ‘Read more…’ link to what follows.
This one starts not from a single Tweet, but a combination of several themes that have come up over the past couple of days.
Perhaps the first here was a one-line comment from Andrew Marosy on the long-running ‘What is the purpose of EA’ thread on LinkedIn. Various folks (including me) had been talking about EA in structural terms, but as Andrew reminded us:
EA is also about flows (information, goods, energy, control…)
…which, yes, strictly speaking, are also a kind of structure, but a structure in time – a dimension that’s all too often missed in the conventional approaches to EA. Important point, and one to which I’ll admit I haven’t paid enough explicit attention as yet in my writing on EA. Slightly blinkered in my thinking there, you might say.
think of data and information as the currency that the business runs on
…and yes, many IT-folks would think that, because that’s the ‘currency’ that they run on, too. But whilst it may be true that information is “the currency that business-management runs on”, it may not be the currency that the business runs on – a rather important distinction! We can just about get away with blurring them together when the business of the business is information – as is the case with banking, insurance, finance or tax, for example. But when the main business of the business is about things – as in retail or logistics – or about people – as in recruitment or consultancy or health or many government departments – then acting as if information is the core of the business is going to cause some serious problems. An article by KM specialist Patrick Lambe (which we’ll come back to in a moment) quotes an example where an over-focus on information about the activity has become a substitute for understanding the activity itself:
“Computerized baking has profoundly changed the balletic physical activities of the shop floor. Now the bakers make no physical contact with the materials or the loaves of bread, monitoring the entire process via on-screen icons which depict, for instance, images of bread color derived from data about the temperature and baking time of the ovens; few bakers actually see the loaves of bread they make… As a result of working in this way, the bakers no longer actually know how to bake bread… The work is no longer legible to them, in the sense of understanding what they are doing.” Richard Sennett The Corrosion of Character (New York: W.W. Norton & Company, 1998) p.68
In Cynefin terms, the information-centric view provides the semblance of control within predictable Simple or Complicated contexts, but actually prevents the understanding needed to make sense of what’s happening when the context moves into the inherently-unpredictable Complex and Chaotic domains. And much the same applies to management itself, of course: in service-modelling terms it’s just another ‘cost-centre’ support-service for the overall business – so if the managers start to think that they are the business, chaos and confusion will inevitably ensue… Failing to even acknowledge the real world outside of one’s own domain is a lot worse than ‘slightly blinkered’ – more like heading towards a form of self-centrism so extreme that it could almost be classed as a form of mental disorder. What’s frightening is that this near-‘autism’ seems to be regarded as normal, even ‘desirable’, by many in ‘the trade’ – which is not a good idea…
Which leads to the third theme in this thread, arising from another Tweet by David Gurteen, which pointed to a post on knowledge-management by Mark Gould, which pointed in turn to an old (2002) post by Patrick Lambe, and thence to a much longer essay of his, called ‘The Autism of Knowledge Management‘ [PDF, 76kb].
There is a profound and dangerous autism in the way we describe knowledge management and e-learning. At its root is an obsessive fascination with the idea of knowledge as content, as object, and as manipulable artefact. It is accompanied by an almost psychotic blindness to the human experiences of knowing, learning, communicating, formulating, recognising, adapting, miscommunicating, forgetting, noticing, ignoring, choosing, liking, disliking, remembering and misremembering.
Which fits exactly, because what we’re so often dealing with, in the obsessive IT-centrism of so much purported ‘enterprise’-architecture, is precisely the same kind of ‘autism’ – the autism of EA. In some ways it’s hardly surprising, since it’s the same kinds of people – myopic managers and information-obsessed IT-types – who are making the same kinds of mistakes in both KM and EA. And after all, EA is a close relative of KM, because much of it is about creating and conveying and applying a particular type of knowledge around the single central idea that ‘things work better when they work together’. For example, translate into an EA context Patrick’s comments (p.16) about use of a predefined ontology in KM:
The apparent objectivity of this approach collapses as soon as you look at how the ontology is derived. It must be widely agreed, and there must be common definitions with common meanings. Very little of real working life is run on agreed, common definitions. At best we run on approximations to that. Most of what we do is highly interpreted, time and place contingent, and constantly shifting. We disagree constantly on how to interpret the world.
In EA, that’s the same kind of difference between a predefined ‘reference model’, for example, and the hard-graft that’s needed to make that model actually usable in the real world. So it’s well worth reading the whole of Patrick’s essay with an EA eye, because everything fits: all of the critiques, all of the consequences, all of the actions that need to be taken to get out of the mess.
First, Patrick describes “five big myths”:
- The Myth of Reusability
- The Myth of Universality
- The Myth of Interchangeability
- The Myth of Completeness
- The Myth of Liberation.
An EA is supposed to be reusable: that’s the whole purpose of TOGAF‘s Architectural Building Blocks and Solution Building Blocks, for example. That gives us useful content; the catch is that the real world is much more context-dependent, with the result that our ‘building blocks’ are often reusable only as abstract guidelines.
An EA is supposed to be universal, to apply everywhere throughout the enterprise: blunt fact is that it doesn’t, for exactly the same reason – the inevitability of context-dependent detail, and hence of context-dependent variation.
An EA is supposed to describe components that are interchangeable. In a basic IT-centric EA, they often are; but the reality is that as soon as a business-process touches the human domain – the so-called ‘manual’ process – almost nothing is directly interchangeable. We can sometimes use IT to convert raw data to business-information, but we always need real people to translate that information into contextual meaning and business knowledge. Which means that IT concepts of ‘interchangeability’ can’t apply at the level of the whole architecture of the enterprise. Which in turn means that a conventional IT-‘EA’ will probably be too limited to be of much real use to resolve real-world enterprise-level concerns.
An EA is supposed to be complete, to cover every need in the enterprise. But as with measuring a coastline, any definition of ‘completeness’ depends on the level of granularity we choose – because the blunt reality is there’s an infinite amount of detail that could go into an architecture, which means that by definition a full description of the architecture could never be complete. Worse, the detail is dynamic, not static: by the time we’ve documented everything, the enterprise will have long since moved on. So an architecture can never be ‘complete’; the best it can be in practice is ‘complete enough‘ – which is a very different concern.
An EA is supposed to give us liberation – in particular, liberation from uncertainty. But it can’t: the world is uncertain. The best that our architecture can do is provide useful guidelines, and useful pointers for conversations towards appropriate action in an uncertain world: the key is that it’s not about whether our architecture is ‘true’, but whether it’s useful – which again is a very different concern.
Like so much IT-centric KM (and ‘Enterprise 2.0’, for that matter), IT-centric ‘enterprise’-architecture has spent a couple of decades resolutely refusing to face these facts. A few years back, much of what we saw would match all too well with Patrick Lambe’s comment about ‘the myth of liberation’ in KM:
So let’s talk about liberation. You don’t have to look far in the technical writing of knowledge-object enthusiasts to find almost mystical hyperbole about the potential of knowledge objects for humanity. Just look for the exclamation marks.
In EA these days there’s quite a lot less of that hype: instead, cynicism and disillusion have become a lot more common, especially amongst business-folks elsewhere in the enterprise, as the standard IT-centric TOGAF or FEAF architecture-developments have taken literally years to deliver little or no real business value. As a profession, EA is now at real risk of being dismissed as an insanely-expensive waste of time. So if we want the profession to survive, and start showing its real value, we need to do something about that, and fast. And the first thing we need to do is to face down the absurd ‘autism’ of so much self-styled ‘enterprise’-architecture.
Once again, Patrick Lambe shows us a way to move ‘beyond autism’. In the later section of the essay (p.20 on), he lists six key principles for a valid, functional, successful KM:
- Highly effective knowledge performers prefer knowledge fragments and lumps to highly engineered knowledge parts.
- Parts need to talk to their neighbours.
- The whole is more important than the parts.
- Knowledge artefacts provide just enough to allow the user to get started in the real world.
- Learning needs change faster than learning design
- Variety is the spice of life
To paraphrase these into an EA context:
‘Highly engineered’ components may make some degree of sense in an IT context – though in practice much less than many vendors would purport. But they don’t make so much sense at a true whole-of-enterprise level. Highly-effective users of architecture will usually prefer ‘knowledge fragments and lumps’, in the form of abstract principles and proven guidelines, than someone else’s pre-packaged ‘solution’ that may well take more effort than it’s worth to force-fit into a different context.
Much of a functioning architecture is about facilitating conversations, so that ‘parts can talk to their neighbours’. Some of these ‘conversations will be at a detailed technical level, as messaging-interfaces, APIs and transaction protocols. Others will be literal conversations between people. Sometimes some of those types of ‘conversations’ may need to be interchangeable, at every level – especially in disaster-recovery scenarios, where we may need to have people take over the IT’s usual tasks, and swap back again once the emergency is over. Ultimately this brings us back to that basic principle of all architecture, that ‘things work better when they work together’.
The real danger of an IT-centric architecture is that it deal only with one part of the enterprise – the IT, and the small subset of enterprise information managed by that IT – and pointedly ignores the rest. But the enterprise is a whole: we can’t make sense of it by pretending that most of it doesn’t exist. We also can’t make sense of it as a whole without setting out to understand it as a whole – because the whole is greater than its parts, and is more important than any of its individual parts.
We need to provide the right amount of architecture – not too much, not too little. Without an intentional architecture, the end-result is chaos; but too much architecture makes the enterprise unwieldy, unyielding, inflexible, too reactive, too resistant to the inevitabilities of change. Our architecture artefacts provide just enough to allow the user to get started in the real world: a ‘just enough, just in time’ approach to architecture and to architecture-governance will give our stakeholders the clarity and agility they need, without getting in their way – and will be a lot cheaper all round, too.
Development takes time; yet the world doesn’t wait for us in the meantime. So architecture-needs change faster than architected designs: most large projects will be architecturally out-of-date by the time they’re complete, and we cannot know beforehand everything that we’re going to need. Whatever we do, it’ll be ‘wrong’ by the time we use it; there’ll always be something that needs fixing up, making do, making mend. Frustrating: always. So we need to acknowledge that as part of our reality; accept it, design for it, and move on. Service-oriented architectures will certainly help, especially if they extend beyond IT to the whole enterprise; but simply being aware that unexpected change is a certainty will probably help the most.
And yes, variety is the spice of life, in architecture as much as in most other maters. Whatever reference-model we develop, there’ll always be something that not only doesn’t fit but can’t fit: some ‘essential’ new system that someone needs, or some ancient legacy package limping along on even more ancient hardware. That’s a fact of architecture-life too: we need to work with it, not fight in futility against it… As before, the ‘just-enough’ approach is what’s needed here: and that depends on diplomacy, the delicate art of personal persuasion, a technical architecture, perhaps, but always one that includes our own human face.
That’s what architecture really is: an active expression of “the human experiences of knowing, learning, communicating, formulating, recognising, adapting, miscommunicating, forgetting, noticing, ignoring, choosing, liking, disliking, remembering and misremembering”. All those myriad technical details are important, of course, but it’s the human factors that make it work. Falling back into the ‘autism’ of conventional IT-centric EA is a guaranteed route to failure: we forget that fact at our peril.