Have we managed to design agility out of enterprise IT? Are the two now incompatible? Our decision to measure IT purely in terms of cost (ROI) or stability (SLAs) means that we have put aside other desirable characteristics like responsiveness, making our IT estates more like the lumbering airships of the 1920s. While efficient and reliable (once we got the hydrogen out of them), they are neither exciting or responsive to the business. The business ends up going elsewhere for their thrills. What to do?
An interesting post on jugaad over at the Capgemini CTO blog got me thinking. The tension between the managed chaos that jugaad seems to represent and the stability we strive for in IT seems to nicely capture the current tensions between business and IT. Business finds that opportunities are blinking in and out of existence faster than ever before, providing dramatically reduced windows of opportunity leaving IT departments unable to respond in time, prompting the business to look outside the organisation for solutions.
The first rule of CIOs is “you only have a seat at the strategy table if you’re keeping the lights on”. The pressure is on to keep the transactions flowing, and we spend a lot of time and money (usually the vast majority of our budget) ensuring that transactions do indeed flow. We often complain that our entire focus seems to be on cost and operations, when there is so much more we can bring to the leadership team. We forget that all departments labour under a similar rule, and all these rules are really just localised versions of a single overarching rule: the first rule of business, which is to be in business (i.e. remain solvent). Sales needs to sell, manufacturing needs to manufacture, … By devoting so much of our energy on cost and stability, we seems to have dug ourselves into a bit of a hole.
There’s another rule that I like to quote from time-to-time: management is not the art of making the perfect decision, but making a timely decision and then making it work. This seems to be something we’ve forgotten in the West, and particularly in IT. Perfection is an unattainable ideal in the real world, and agility requires a little chaos/instability. What’s interesting about jugaad is the concept’s ability to embrace the chaos required to succeed when resource constraints prevent you for using the perfect (or even simply the best) solution.
Consider a fighter plane. The other day I was watching a documentary on the history of aircraft which showed how the evolution of fighters is a progression from stability to instability The first fighters (and we’re talking the start of WWI here–all fabric and glue) were designed to float above the battlefield where the pilots could shoot down at soldiers, or even lob bombs at them. They were designed to be very stable, so stable that the pilot could ignore the controls for a while and the plane would fly itself. Or you could shoot out most of the control surfaces and still land safely. (Sounds a bit like a modern, bullet proof, IT application, eh?)
The problem with these planes is that they are very stable. It’s hard to make them turn and dance about, and this makes them easy to shoot down. They needed to be more agile, harder to shoot down, and the solution was to make them less stable. The result, by the end of WWI, was the fairly unstable tri-planes we associate with the Red Baron. Yes, this made them harder to fly, and even harder to land, but it also made them harder to hit.
Wizz forward to the modern day, and we find that all modern fighters are unstable by design. They’re so unstable that they’re unflyable without modern fly-by-wire systems. Forget about landing: you couldn’t even get them off the ground without their fancy control systems. The governance of the fly-by-wire systems lets the pilot control the uncontrollable.
The problem with modern IT is that it is too stable. Not the parts, the individual applications, but the IT estate as a whole. We’ve designed agility out of it, focusing on creating a stable and efficient platform for lobbing bombs onto the enemy below. This is great is the landscape below us doesn’t change, and the enemy promises not to move or shoot back, but not so good in today’s rapidly changing business environment. We need to be able to rapidly turn and dance about, both to dodge bullets and pounce on opportunities. We need some instability as instability means that we’re poised for change.
Jugaad points out that we need to allow in a bit of chaos if we want to bring the agility back in. The chaos jugaad provides is the instability we need. This will require us to update our governance processes, evolving them beyond simply being a tool to stop the bad happening, transforming governance into a tool for harvesting the jugaad where it occurs. After all, the role of enterprise IT is to capture good ideas and automate them, allowing them to be leveraged across the entire enterprise.
Managing chaos has become something of a science in the aircraft world. Tools like Energy-Maneuverability theory are used during aircraft design to make informed tradeoffs between weight, weapons load, amount of wing (i.e. ability to turn), and so on. This goes well beyond most efforts to map and score business processes, which is inherently a static pieces/parts and cost driven approach. Our focus should be on using different technologies and delivery approaches to modify how our IT estate responds to business change; optimising our IT estate’s dynamic, change-driven characteristics as well as its cost-driven static characteristics.
This might be the root of some of the problems we’re seeing between business and IT. IT’s tendency to measure value in terms of cost and/or stability leads us to create IT estates optimised for a static environment, which are at odds with the dynamic nature of the modern business environment. We should be focusing on the overall dynamic business performance of the IT estate, its energy-maneuverability profile.
Great read Peter, thanks! Absolutely agree. Love the plane analogy, diving into my own here:
The huge error made over the last 10+ years is that we tried to make one what was multiple (not going to cite the Gospel of Thomas here)
Just today I saw my customer wanting to “standardise software components”. Heck no! We have to abandon this Borg-approach and leave our children (apps) alone. We do have to raise them, and educate them. They should speak the Queen's English if need be, but can bar-bar all the way they want if no one's listening.
We shouldn't stiffen what's meant to stay flexible. I love to use languages for pointing out the differences between diversity and standardisation. There is a wild diversity of (in)audible and (n)understandable 😉 dialects spoken in Britain, and TG for that. And some of those just will not be understood by US, NL or even other UK people, and that's fine
Another Enterprise problem is its size though. As you'll see, (language and dialect) diversity will increase when size does. And they'll just continue to self-develop (evolve) at a faster pace when the size increases, and distance increases as well (cf UK <-> US <-> AU)
So, a general blanket smoothing all those differences (not eradicating them) is what we need…
Actually, I believe our modern IT solutions and estates are actually unstable and highly agile. Unfortunately the pilots are all now convinced (and have convinced others) that moving the joystick in any direction (to use your plane analogy) is not only dangerous and expensive, but bordering on impossible. This is not the case, but it is a position favoured by IT suppliers who make significant income from this belief and the ensuing extensive test regimes and bums-on-seats mentality to development.
Change the mentality and it's amazing how quickly you can do things without actually changing the underlying IT estate.
Regards
The Enterprising Architect
http://theenterprisingarchitect.blogspot.com
Interesting indeed.
Seems to me, though, that a true jugaad approach would remember that there are many other forms of 'information technology' besides those that are based on computer systems and computer networks. Pencil and paper, Post-It notes or a simple card-rack work extremely well in a kanban context, for example. I would always prefer to develop new processes by word-of-mouth and scribbled notes at first, and only later start to move the most stable parts of that process onto computer-based IT.
And there also many circumstances where we have no choice but to do information-transfers without computer-based IT. The most obvious of these is a disaster-recovery scenario where the IT is either unavailable, inaccessible or no longer existing – yet somehow we need to be able to continue to run as much of the business as practicable without it.
To identify all of our options here, we must think wider than just computer-based IT.
Definitely: less is often more. There's an old NASA war story (which a reliable source tells me is true) that NASA spent US$1m+ developing a space pen, while the Russian space program just used pencils. James Gardner is doing a stint working at the welfare front line, and finds that need often drives this sort of jugaad in just the way you describe.
Interesting view, though I'm not sure that it is possible to separate the influence of pilot and IT estate in agility, as your IT tends to reflect your IT organisational structure.
Standardisation is a tool, rather than a goal, which we often forget.