Digital Thinking: 5 counterintuitive principles for successful IT delivery

Three trends have changed the way we think about IT delivery: richer services, faster deployment, and pay-as-you-go charging. Together these factors offer as much challenge as opportunity, with more choice of how, when, and where we deploy new systems.

We've got pretty good at exploiting this flexibility, with received wisdom gleaned from manufacturing, statistics, and simple hard-won experience. But much of this wisdom is counterintuitive, or takes existing ideals to new extremes.

As an example, "Measure twice, cut once" makes little sense in an IT context where raw materials like as data can be moved, held, and copied perfectly for virtually no cost. In this world, managing time is often the critical factor in delivering effective IT investment.

This post pulls together a pretty eclectic range of sources that I presented under the title Digital Thinking at our 2019 Trustmarque XPO. I am responsible for almost no original content in this post, and am grateful to the many and varied thinkers who took the time to explain their specialist knowledge through books, blogs, or code.

I've included a comprehensive set of references at the foot of the post for anyone who wants to explore the ideas further.

1) Fail Fast

It took Thomas Edison and his team over a thousand iterations to perfect the incandescent light bulb. His experience serves as a useful model for thinking about the importance of failing fast.

Assuming it takes Edison four hours to test each bulb, he's going to spend four thousand hours to reach the magical v1000 that worked. But, if he invests an hour improving his test bench, maybe he can reduce the test time to two hours. Suddenly, it's only 2001 hours to reach v1000.

Iterative development is the foundation of many improvement systems, including modern software delivery, Lean Startup^[1], and even rocket science^[2].

While the iterative process itself enables opportunity to reflect and change direction, it's also vital to work on optimising the cycle itself. Investment in tooling and process improvement^[3] can reduce the cost of running the cycle, leaving more cycle capacity for delivering value.

In a famous exchange, a reporter once asked Edison how it felt to have failed a thousand times. He responded:

"I didn’t fail 1,000 times. The light bulb was an invention with 1,000 steps."

This highlights an important issue with the idea of failure: we tend to think of it as negative. As thought leaders, it's important to try and reframe this in a more positive light. We can do this by:

1. Calling failure, "organisational learning". Which it is^[4].
2. Using depersonalised language: "I have a hypothesis, let's run an experiment to validate it" (see also, Lean Startup).
3. Leveraging techniques like "5 whys"^[5], which typically ends in a failure of process or policy, rather than people.

Iterative processes allow us to fail fast, and active improvement of cycle efficiency helps us fail even faster. This is an ideal framework for evaluating and exploiting new services and deployment channels.

2) Deliver Less

While Hollywood blockbusters often revolve around incredible powers (Infinity Stones, the Force, the Power of Greyskull), they often overlook their less known cousin: the Power of Small Batches.

Like all powers, the Power of Small Batches has a popular backstory. This narrative describes the problem of folding leaflets to fit into envelopes: if you fold all the leaflets before putting them into envelopes, you may be in for a nasty surprise if it turns out your folded leaflets don't actually fit in the envelope, and you have to fold them all again.

To avoid this waste, it's best to fold and put into the envelope one-at-a-time, the smaller batch size enabling you to fail faster, reduce waste, and ultimately have a more efficient process.

However, it's not always so simple. Sometimes, you have more costs involved in a process, so the optimum batch size might not always be "one". This handy graph shows where your optimum batch size lies:

In this graph, transaction cost describes costs involved in performing the operation with a batch, and holding cost describes the cost of not processing the batch. The U-curve is constructed by summing the two, and the optimum batch size lies around the lowest point of the curve.

There are many excellent explanations of optimising batch sizing online^[6], but to get into the detail I'd direct you toward books that explain the economics of queues in production processes^[7].

Bonus: work visibility

Kanban is a lean technique for work management that aims to limit "work in progress". By matching processing capacity and demand, a very efficient flow is created. In this way, Kanban exploits the power of small batches.

Kanban also emphasises the importance of work visibility. A secondary benefit of small batches are that they keep focus on restricted problem domain. This can be particularly beneficial in an IT context where assets are often intangible: data, licences, ideas, or knowledge.

3) Gain Foresight

Toyota's Jidoka technique empowers production line operators to halt work across the production line on detection of a defect. This is another way to fail fast--there's no point using good material to produce a defective product.

However, the commoditisation of powerful analytics services, combined with increased connectivity, presents new options for deploying sensors across value-producing processes. The data from these sensors can be used to develop new, smart analytics that can prevent defects before they happen.

This is sometimes referred to as Industry 4.0, or Smart Factories.

Data can be consolidated into increasingly sophisticated analytics mechanisms:

• Descriptive - Describes the current and/or past metrics and data.

• Predictive - Extrapolates metrics and data into the future, perhaps leveraging machine learning to predict complex patterns.

• Prescriptive - Identifies activities to mitigate issues predicted by the data set.

You actually have all three of these in your car: the fuel gauge is descriptive, your trip computer's range predictive, your fuel light is prescriptive.

While the received wisdom of jidoka makes good sense once a defect is detected, cloud technology allows us to go a step further, detecting and preventing issues before they occur.

4) Encourage Disruption

Sophisticated systems create new and more complex ways to fail, with emergent failure behaviours^[8] that can be hard to predict or prevent. Instead of trying to prevent these, we can instead try to mitigate their impact.

Netflix famously^[9] employed chaos engineering^[10] in the form of the Chaos Monkey, an agent in the Netflix environment which disrupts the steady (working!) state of Netflix' systems^[11]. By introducing controlled disruption into their environments, Netflix were able to increase the overall resilience of their systems.

Whilst the specific technologies employed by Netflix may not be applicable to more common use cases (or budgets!), we can still learn from this thinking. Concepts like immutable infrastructure^[12], combined with blue-green deployments^[13], offer business-as-usual processes that can support disaster recovery and solve the problem of configuration drift.

5) Finish Nothing

Finally, the idea of finishing nothing. Evergreen IT^[14] aims to create the necessary abstractions within applications to enable each app layer and component to be updated separately, and can therefore be always up-to-date.

This also emphasises a "service posture", with focus on process and responsibilities. These can then be carried out on a continuous basis, as opposed to as special gatherings of skills, deliverables, or investment (typically in the form of projects).

One example of this is security: continuous deployment requires continuous security practises. We can't rely on periodic, big-bang exercises to mitigate risks, and need more comprehensive solutions baked into our business-as-usual processes^[15].

Thinking about the processes and responsibilities that new technology creates helps us to define the services that our organisations require. With those in place, big budget remedial projects should become a thing of the past.

Summary

Exploiting new technologies is hard due to the pace of change, flexibility of deployment options, and breadth of affortable services. Applying lessons from industry can help us create the culture and processes to turn these disrupting factors to our advantage.

And hopefully, have fun doing it.

If you've enjoyed this post, I encourage you to spend some time exploring the footnotes.

Image credits

Post header: Ferdinand Stöhr
Slide #5 "Traditional": Andrew Preble
Slide #5 "Evergreen": Adrian Bar