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?