The autism of Enterprise Architecture?

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.

Then there was a Tweet by Jörgen Dahlberg pointing to a review by Leo de Sousa of a webinar on the current state EA. There was a one-line quote that especially caught my attention:

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.

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:

  1. Highly effective knowledge performers prefer knowledge fragments and lumps to highly engineered knowledge parts.
  2. Parts need to talk to their neighbours.
  3. The whole is more important than the parts.
  4. Knowledge artefacts provide just enough to allow the user to get started in the real world.
  5. Learning needs change faster than learning design
  6. 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.

4 Comments on “The autism of Enterprise Architecture?

  1. To me – ‘time’ in architecture is closely related to benefit so its easy to forget about it as its usually expressed at us with ‘due by’, ‘stop what you are doing now’ or ‘where is’ opening lines. I have fond memories of you working to deadlines, stressing about completeness and making it anyway. One particular such deliverable from you is still in use as a standard – 5 years after you created vs. 1.1 (albeit at vs. 2 now).

    The big risk to the success of enterprise architecture in business now is fear. As you point out – KM and EA concepts are similar but people / business managers / staff sees a loss of power and control coming from real enterprise architecture when in fact, as a common language – it is just a connector enabling communications between real knowledge and people in support of action. i.e. we need our stakeholders to understand that their Tacit knowledge needs to stay with them while their Explicit knowledge needs to be shared to enable relationships and wider understanding with holders of Tacit knowledge so that decisions can be made and corresponding action be taken.
    Human nature resists this and people fear the implications of the implied collaboration. I believe that enterprise architecture inclusive of proactive decision making can only be effective when business leaders require collaboration and support their people on that learning curve.

  2. That point about fear is really important, and something I need to follow up in a later post – many thanks for that.

    Also brings it back to Dave Snowden’s point that sharing of knowledge can never be coerced, but is in effect a gift from the individual to the shared-enterprise – something that organisations (and everyone, actually) need to respect. It may well be that “business leaders require collaboration”, but unless they provide safe conditions under which that collaboration can occur, it ain’t gonna happen! Supporting “their people on that learning curve” is key here, as you say.

    Thanks again, anyway.

  3. We are working toward the same conclusion I think. ‘Gift from the individual’, ‘never be coerced’ – ‘provide safe conditions under which that collaboration can occur’ all start with behaviors.

    I laugh reading about ‘abilities to influence’, ‘matrix management’ and the like. These all imply ridiculous timeframes, the need to cleverly make things happen without involving the right people and pushing things through.

    With correct behaviors from the top, trust flows, misbehaviors can be dealt with opening and things can move at rates beyond peoples expectation.

    Keep up the good work..

  4. Thanks for the great post Tom.

    It seemed patently obvious to me from the first day I started on EA that its task could be characterised by two simples verbs, ‘know’ and ‘design’.

    Design is another conversation – and I think the now stabilising distinction between solutions and enterprise architecture is helpful there.

    There is no doubt in my mind that EA is a knowledge-discipline first and foremost. And I have always been clear that knowledge is something that exists only in people’s minds, and is not easily subject to the process-automation techniques we use on structured information.

    Your reflections are apposite to current practices and insightful. I particularly like the idea of ‘autism’ as a metaphor for what happens when we confuse knowledge with the information that supports its discovery, use and creation.

    All human culture, including business culture, is a means to the preservation and sharing of knowledge. Admittedly in unmanaged cultural systems the signal to noise ration can be pretty crappy. But we seem to easily forget that the default state of natural (small) social systems provides very low resistance to the spread of knowledge.

    Large, complex and arbitrarily structured social systems place a lot barriers to the easy dissemination of knowledge – often as a means of eliminating ‘noise’.

    Process – our idea which is rooted in the division-of-labour assembly-line factories of the late nineteenth and early twentieth century – has been a powerful answer to the chaos of natural social systems. It has been used to overcome various distances – in authority, location, and even personal knowledge – that complexity has created between individuals inside organisations. A corollary of overcoming that distance however is the ‘friction’ it creates to inhibit the natural spread of knowledge.

    It will most definitely not be me that leads the way on this, but I am watching with interest how knowledge-based approaches to management and value creation evolve in large organisations as social computing develops.

    For the first time we are seeing technology that supports the natural exchange of knowledge in a social system. As a result new possibilities for overcoming distance in large complex organisations are presenting themselves.

    I hope forward thinking EA’s who read you article will consider collaboration to be an imperative in their practice, and knowledge a much more concrete and viable goal than ‘alignment’. And I hope it encourages EAs to think creatively about new modes of practice.

Leave a Reply

Your email address will not be published. Required fields are marked *

*