Agility needs a backbone

Something that’s been concerning me quite a bit over the past year or so in enterprise-architecture has been the over-obsession with agility: agility for its own sake, perhaps, without much thought behind it, much thought about why or how we need to be so agile.

No matter what it is, it seems – whether in IT-architectures, business-models, the organisation as a whole – agility of any kind is promoted as ‘the answer’. With the increasing hype around cloud-based computing, there’s been plenty of talk amongst the less-realistic IT-centric ‘enterprise’-architects that EA itself is redundant. And perhaps that large organisations don’t even need an IT department any more.

Which, to be blunt, is just plain stupid.

It’s not an ‘either/or’. It’s a ‘both/and’. Sure, over-rigid structures can be a real problem. But agility often needs a backbone to give it some direction – something to push against so it that can do more than merely flop about at random. As usual, it’s a question of balance – getting the right balance between the solid bone and the agile muscle.

Which is where enterprise-architecture comes into the picture, to help create a proper sense of the whole as whole.

To extend that simple metaphor, yes, it’s true that there are a few creatures, or parts of creatures, that consist only of agile muscle, pushing against itself:  the octopus, the cuttlefish, the elephant’s trunk. But most muscle needs something to provide an anchor around which or against which to push and pull. And if we want both agility and speed – as so many companies do – then we’re even more likely to need a backbone: think of the cat, the cheetah, the snake. If you want high efficiency, you’re going to need the right kind of balance between rigid and flexible: think of the kangaroo, that uses less energy the faster it goes. If you want agility in the air – a swallow, a falcon – you’re going to need another kind of balance, another subtle trade-off between rigidity, flexibility, lightness and strength. Many other examples there, of course.

And for large organisations, the much-hated ‘IT Department’ provides a key part of that backbone. You may not like it; you may not like its seemingly slow, lumbering rigidity, its need to get everything right, everything certain. But without it, that organisation is going nowhere. Even if everything in IT could somehow shift to the cloud and to all employee-provided technology – which would involve some massive shifts in itself, for HR and pay and expenses and tax-issues and the rest – there’ll still need to be someone who sets up and maintains the wi-fi networks, the security-policies, the software licenses and all the other myriad of ‘keeping the lights on’ issues that are so often forgotten by the cloud crew. (Yes, folks, even with everything-cloud there’ll still be some software-licenses to worry about: not everything can go onto the cloud, ‘cos you still have to connect to the cloud somehow…)

A real enterprise-architecture would show us that the backbone consists of a variety of different things that can link together in different ways to create different kinds of flexibility:

  • the vision and values of the extended-enterprise, to which the organisation aligns itself – its core ‘Why’
  • the core ‘things’, information,  services, events and places that are most relevant to that enterprise – its core ‘What’, ‘How’, ‘When’ and ‘Where’
  • the structures of relationships implemented through the organisation and its partnerships with others – its core ‘Who’

That backbone gives us something around which we can build agility. We can try all kinds of different business-models – as long as they align to that core ‘Why’. We can work on many different kinds of ‘things’, physical, virtual or otherwise – as long they link back to the core ‘things’ of the extended-enterprise. We can work with all kinds of information – but we must be able to link it back to the core-information that defines the scope of the enterprise.

Which, once we think about that for more than a few minutes, makes it plain that no business larger than the smallest start-up should ever even consider storing all of its business-critical data on someone else’s cloud. Not without some really solid questions on escrow, reverse-backup, long-term migration, jurisdictions, business-continuity, disaster-recovery and the rest, at any rate.

And no-one – not even the smallest start-up – should ever consider outsourcing any part of its core-strategy to anyone else. Ever. Whether to the cloud, to some mob of external consultants, to some government department, or to anything else. Outsourcing your strategy is a really quick way to commit commercial suicide…

Agility takes place out at the edge: things happen fast there. But in so many, many cases they can only happen fast out there because the core takes care to move slowly, cautiously, providing the solid, certain backbone for the agile edge to push against. And as in living bodies, getting the right balance between them can be a literal make-or-break. A point that it’s probably wise not to forget?

Update, twenty minutes later:

Typical. I’ve been working on the ideas behind this post for months, and been brewing how to describe it for at least a week. And literally five minutes after I post it, along comes a really nice summary of some other key issues around agility versus ‘the backbone’: Mark Ferraro’s ’10 Dynamics of Effective Agile Organizations‘. Well, at least the link is here now, anyway: hope it’s useful?

11 Comments on “Agility needs a backbone

  1. That’s a great post, Kris – many thanks for the pointer. Would strongly agree about agility being a competence rather than a ‘state’ – and I do take your point about Seth Godin’s warning that, without care, such competence can easily become the enemy of change.

  2. Tom, I agree!

    If evering would be agile… how would one be able to distinguish one agile from another agile? We definitely need a somehow ‘slower’ moving ‘background’ to be able to see agility (on the ‘foreground’).

    If everything would be fashion… would one be able to distinguish one fashion from another fashion? We definitely need a somehow ‘slower’ moving ‘background’ to be able to see fashion (on the ‘foreground’). In other words: we need tradition. Without tradition there is no fashion.

    We need a rather fixed traffic infrastructure (one backbone) in order to be able to use it together with lots of other traffic participants and in very-various and very-varying ways (agile).

    We need a rather fixed information infrastructure (one backbone) in order to be able to use it in an very-agile fashion together with lots of other information-traffic participants and in very-various and very-varying ways.

  3. Personally… the strongest one – seen from my perspective as an information architect – is… Context (as a ‘background’) for meaning of Intext (as a ‘foreground’).

    Intext (a specific piece of information I happen to focus on for some reason) gets its specific meaning from the specific context (other interrelated pieces of information) it is connected to.

    Or, to put it slightly different: All information pieces are connected somehow (an information piece -an sich- cannot exist). In such a network of information pieces I can, for some reason (motive) choose one information piece and focus on it. Because of this focus all related information pieces now ‘unfold’ as the context for the one piece I focussed on… Another focus… Another context… Another meaning. Powerful Information Dynamics.

  4. Hi Tom,

    Good post. I agree with the point re: gratuitous agility. However, agility itself is simply the latent capability to change / co-evolve as a system. The potential to adapt with one’s environment is a business imperative key to sustainability, it doesn’t mean everything is necessarily in flux all the time. Agility is certainly relative to that what remains the same (at least for the moment). I like Jan’s characterization of the foreground and background.

    I think this argument is well suited for those who promote social adhocracy and suggest that the enterprise has no legitimate interests in regulation and coordination as they suggest a spineless enterprise.


  5. Hi Tom.
    Good post.
    I particularly like your muscle analogy. Even we humans develop different kind of muscle fibre depending on whether endurance or power activities are practiced.

    Recently re-reading Fred Brooks Mythical Man Month, I was reminded that the products of agile or any other kind of group/collaborative activity need to be bound by some “conceptual integrity”. A business model in this case.

  6. And 6 years later this is even more pertinent than it was when you posted in 2011. One would hope that organisations would learn but alas it seems that there are many still think agile = lots of action, and somehow action has been confused with progress.

  7. Been wondering whether this been article on IT or about other beings of our earth 🙂

    Thanks for thorough thought process on the context and appreciate that term extended enterprise.

    Staying tuned on the topic.
    Thanks much for guiding light with expertise/experience.

    • Meenakshi A. “Been wondering whether this been article on IT or about other beings of our earth”

      In a sense, it’s also about neither: it’s actually about a systematic method for selecting models for governance according to the context – in other words, ‘governance of governance’. In practice, then, it really doesn’t care _what_ is in the context, or how whatever-it-is is implemented – whether it’s IT, people processes, physical machines or whatever. All it’s concerned about is the _why_, the decision-making and suchlike. It’s rather important not to mix those things up…

Leave a Reply

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