David Knott 03/03/2022 David Knott 03/03/2022

Infrastructure can be opaque: your cloud should be see-through

Imagine this situation. You have just been alerted to a critical security vulnerability in a piece of systems software embedded in thousands of physical and virtual servers across your on-premise technology estate. Your software provider has issued you with a patch, and you need to apply it as quickly as possible. Your business and technology stakeholders understand the gravity of the situation, and are willing to accept the disruption necessary for an emergency patching programme. It’s a race against time, between your ability to patch and the bad actors coming after your systems.

You have many problems in winning this race. Some of your systems don’t have automated testing in place, and you suspect that the patch will break at least a few of them. Many of your systems aren’t properly stateless, and restarting servers will disrupt their operations. Some of your really old systems don’t like being restarted at all, and will need careful attention.

David Knott 24/02/2022 David Knott 24/02/2022

Cloud operations should be visible and invisible at the same time

Do you need a Cloud Operations team at all?

I’ve heard many companies ask this question, and believe that it is a reasonable question to ask. After all, for many people, the attraction of Cloud is to avoid the frustration they associate with central teams. Development teams who were dependent on overworked, under-resourced and under-automated infrastructure teams can now take direct accountability for the infrastructure themselves. Project managers who used to have to put long lead times for procurement, commissioning and configuration of infrastructure on their critical path can now drop those tasks from the plan. If everything is software now, and the DevOps team takes accountability for operations, why do we need another operations team?

David Knott 17/02/2022 David Knott 17/02/2022

Three steps through the thicket

Last week, I wrote about those horrible processes which still exist in most technology functions in most large enterprises - the release process, the production acceptance process, the onboarding process and so on. The process that everybody dreads, no-one seems to be accountable for, which we don’t seem to be able to change, and which stands between us and our code running in production. I suggested that the way to tackle such processes is not simply to optimise and streamline them: such ‘process gardening’ is a never ending battle against a thicket of thorns that grows back every day. Rather, it is to shift from a focus on process to a focus on trust and accountability.

I realise that’s a difficult thing to do. If everyone is telling you that the process stands between the company and catastrophe, then it takes a lot of courage to step away from it. It’s also rarely wise to abandon all of your process: you just want to get rid of those parts that add friction but not value. However, based on my own mistakes and the successes of others, I can offer three suggestions to get started.

David Knott 10/02/2022 David Knott 10/02/2022

Trust and accountability can guide us out of the process maze

If you want to know the history of a company’s IT failures, take a look at their release management process. If they’ve got more than one process, look at the gnarliest, longest, most frustrating process you can find. Typically, you’ll find a set of checks, inspections and approvals that comprise an archaeology of previous mistakes and failures. Twenty years ago several systems ran out of capacity shortly after launch, so a capacity plan is now an essential part of the process. Ten years ago, there was an audit finding questioning the validity of DR planning, so a complete DR plan is required for every release. Five years ago, there was a licensing compliance breach, so evidencing license coverage is now mandatory.

Taken individually, these steps all seem rational. Of course we want to be sure that there is enough capacity to run the system. Of course we want to know that our DR plans work. Of course we want to be compliant with our licensing agreements. But collectively, these steps turn into a complex maze, where it seems that every release must atone for the errors of the past.

David Knott 03/02/2022 David Knott 03/02/2022

The more you understand, the more you can imagine

In 2022, humanity will explore new horizons. The James Webb space telescope, launched on Christmas Day 2021, has now reached L2, a stable orbital position about 1.5 million kilometres away from Earth. When it is fully working, it will see over 13 billion years into the past, just a few hundred million years after the Big Bang.

If that’s not enough, 2022 is also the year when the Large Hadron Collider reopens, after a multi-year upgrade. The upgrade will allow the LHC to collide particles at higher energies, allowing scientists to explore mysteries within the standard model of physics.

I find these twin explorations, of distant space, and of the fundamental forces of nature, of the very far and the very small, spectacular and inspiring - particularly as they are the work of teams that kept going despite the disruptions of a global pandemic.

David Knott 27/01/2022 David Knott 27/01/2022

What could possibly go wrong?

Are technology people particularly short-sighted? The story of the millennium bug seems to say so. In case you’re not familiar with it (and, although it loomed large in my life, I have to remember that it was over twenty years ago now), the millennium bug was caused by people like me building computer systems which only used two digits to store the year. This seemed like a great way of saving storage and memory in the 1970s and 1980s, but less so when the millennium loomed, and we realised that we were going to need a bigger date. It took millions of people, hours and dollars to fix things so that systems carried on working on 1st January 2000 (and if anyone tries to tell you that the whole thing was a hoax, try asking someone who worked on a millennium project or ran tests that night).

I think that the story of the millennium bug is not a story of short-sightedness: rather it is a reminder that we are still at the early stages of integrating computers into our society. From the perspective of 2022, it seems obvious that systems will run for decades and that they need to be capable of handling all future dates. From the perspective of the 1970s and 1980s, those systems were brand new, and it seemed certain that they would have limited lifespans. Surely nobody would still be running that code twenty years later!

David Knott 20/01/2022 David Knott 20/01/2022

Completing the round trip: from centuries to microseconds

What happens when you press ‘send’ on your mobile banking app? I first posed what I called ‘the round trip question’ a few weeks ago, to illustrate that the people who build technology have a duty to explain. Over those weeks, I’ve explored the nature of computing, of digital communication, of identity, and of the humans who build and use systems. I’ll now attempt to give an end-to-end answer to the question, starting a little bit before you press that button . . .

Mid-19th century: Ada Lovelace and Charles Babbage collaborate on the Analytical Engine, intended to be the first programmable, general purpose computer, although it was never finished. Samuel Morse (and others) create a binary code for communication over telegraph wires.

1930s and 1940s: Alan Turing publishes the paper, ‘On Computable Numbers, With an Application to the Entscheidungsproblem,’ laying the theoretical foundations for digital computers. The theory is put into practice by the creation of Colossuss by Tommy Flowers in Bletchley Park.

David Knott 13/01/2022 David Knott 13/01/2022

Always remember that computer systems have humans at both ends

We should never forget that computing is a human activity that should be used to improve human lives. All computer systems ultimately have humans at both ends: the humans that use the systems, and the humans that build and run those systems.

Unfortunately, the business of building, running and maintaining computer systems can often be so difficult that, in the process of organising programmes, building teams, hiring partners, and writing plans, we forget about the humans. Indeed, for many years, the methods most large companies companies followed to build computer systems seemed designed to squeeze the humanity out of those methods and systems.

If you work for a large enterprise, you have probably been involved in some way in a technology project, even if you have never worked as part of a technology team. You may have been on the receiving end of new software or changed systems, or may have had the opportunity to define requirements or test changes. You may also have heard the term ‘waterfall project’ and picked up the impression that we don’t like waterfall projects any more - even though we still seem to spend huge amounts of time, effort and money executing them.

David Knott 06/01/2022 David Knott 06/01/2022

The servers are virtual, just like the money

In old films, the robbers broke into the bank and stole the money from the vault. In new films, the heroes often break into the computer room to hack the mainframe.

Both of these cliches have some foundation in reality. Bank vaults do contain money - and used to contain a lot more. Mainframe computers are still used in many large organisations, and often run some of their most important systems (although ‘the mainframe’ is no longer as important as films such as those in this video would have you believe).

However, there is also a fundamental flaw in both these ideas: these days, the assets they are trying to gain access to (money and computing systems) are mostly virtual. They do not exist as fixed, physical entities in the world any more.

David Knott 30/12/2021 David Knott 30/12/2021

Into the ever rising ocean of data

Data is, at the same time, the most mundane and most exciting aspect of computing.

It is mundane because of its origins in the world of folders and filing cabinets. In my first ever paid programming job, for a government department in the 1980s, the team I was part of was not called Information Technology (and certainly not Digital), but Automated Data Processing. And, while I was thrilled to get paid for writing code, the work we were doing was about as exciting as that title implies: we were doing the computing equivalent of shoveling coal from one pile to another (or moving records from one file to another). All of the data we were working already existed, in written paper records, in printed documents or even on micro-fiche. By creating Automated Data Processing systems, we were enabling data to be processed with greater speed and accuracy - but we were not creating new data.

Based on some informal surveys, I think that most people who have not had the chance to work in technical jobs, still think of data in this way. When we press ‘send’ on our mobile banking app, we imagine that the work that computers are doing is similar to the work that clerks would have done with printed ledgers many years ago: the data is hauled up from the memory of the computer, the number is read and sent out, some amendments may be made, and the data is sent back to its quiet resting place.

David Knott 23/12/2021 David Knott 23/12/2021

Shrinking space and time with dots and dashes

In 1844 Samuel Morse did two things that changed the world. He sent the first telegram in the USA, and he sent it using his famous Morse code. (Like many world changing inventions, the degree to which this was All His Own Work and the degree to which he drew from the work of others is disputed - not least by Morse). The telegraph shrank time and space for decades until it was superceded by other communications technologies: the last telegram was sent in the USA around 2006.

It may seem that the telegraph and Morse code are antiquated relics now, but I think that they help us understand an important part of The Round Trip question: networking. (This is part of a series of articles in which I attempt to answer, in non-technical terms, what happens when you press send on your mobile banking app. Or, more broadly: what does it mean to live in a world run by computers and made out of software?)

I must admit that I am not an expert in networking, and find the many network components that lie between the phone in my hand and the computer in my bank complex and difficult to understand and describe. I am hoping that simpler technology from another age can help me.

David Knott 16/12/2021 David Knott 16/12/2021

A balance between security, convenience . . . and legacy

We talk about the Stone Age, the Bronze Age and the Iron Age, and sometimes the Digital or Information Age. Perhaps one day we will talk about the Paper Age: the time when the world was run on systems and processes and information, but those systems and processes were manual, and the information was stored on paper.

Back in the Paper age, the way you proved your identity to your bank, whether to make a deposit, withdrawal or payment, was by signing a piece of paper: a paying in slip, a cheque or a letter. Today, that seems like an incredibly primitive and insecure method of authentication. Cheque books can be stolen, signatures can be easily forged, and anyone can write a letter. And, of course, banks were subject to fraud during the Paper age, to the extent that there are many slang terms for writing bad cheques: paper hanging, cheque kiting, bouncing cheques, hot cheques and so on. But many of these forms of fraud were exploiting the same feature that gave the banking system some measure of protection: it was slow. Cheques were physically transported to central sorting facilities where they were checked, reconciled and cleared. Letters could be queried. Signatures could be manually checked.