David Knott 07/09/2023 David Knott 07/09/2023

Things aren’t always what they seem: cloud, ML and the duty to explain

Many things have surprised me since I started writing these articles in 2018: perhaps it is a condition of 21st century life to be in a state of constant surprise. But there are three things that have surprised me most of all, and have taught me to think differently about the field of enterprise technology. These ideas may seem obvious, but sometimes it is the apparently obvious that surprises you the most.

Cloud is not just infrastructure

Back in 2018 I was working for a large, global bank which was just getting started on public cloud. Although that was only five years ago, it feels much longer: questions about whether regulated industries such as banking would ever be allowed to run on public cloud were far from settled, and there was a lot of scepticism.

David Knott 31/08/2023 David Knott 31/08/2023

Lessons learnt from five years of learning lessons

In September 2018, I challenged my architecture team to publish their thinking in public. I thought that, as people who aspired to set the technical direction for one of the largest banks in the world, we should have a clear, distinctive voice, and we should make that voice heard outside our own organisation.

My team quite rightly challenged me back. After you, they said. Why don’t you go first? they asked. I couldn’t think of a reason to say no, so I committed that I would write some articles and publish them on LinkedIn. They pushed me: how often will you write? I said that I’d try to do it weekly. How hard could it be?

Five years later, publishing this weekly newsletter has become part of my routine. As I approach that five year anniversary, I thought it might be interesting to spend a couple of weeks reflecting on everything I have learnt over those five years, and taking the risky step of making some predictions for the next five years. First, though, I’d like to write down the answer to a question many of my colleagues have asked me: how should they go about writing their own articles?

David Knott 24/08/2023 David Knott 24/08/2023

Which is more scary: a disaster or your disaster recovery plan?

Most organisations above a certain size have technology disaster recovery plans: plans for what they will do when something goes wrong, such as a fire, flood or power failure. These plans are often elaborate and expensive, involving redundant equipment and facilities in geographically separated locations. Organisations don’t run pairs of data centres because they enjoy running data centres: they do so against the day when one of the data centres isn’t there any more.

However, despite all of this preparation and expense, many organisations have two problems which mean that their disaster recovery plans may be no use in a real disaster. First, their disaster recovery plans aren’t really plans to recover from disasters. Second, their disaster recovery plans are just plans.

David Knott 17/08/2023 David Knott 17/08/2023

Legacy isn’t a technical problem; it’s a management problem

Imagine a world in which your car was subject to a product recall every week. Sometimes the recall notice would be gentle but firm: bring your car into the garage when it’s convenient, but don’t wait too long. At other times, the notice would be more alarming: stop what you’re doing and bring the car in NOW!

If this was the case, you’d probably change your car. But what if every car in the world was the same? If you really needed to drive, you’d build regular maintenance into your schedule. It would be irritating and inconvenient, but better than having no car at all - and much better than crashing. You’d probably get pretty good at it, and so would your garage: they’d have lots of practice.

This is the world of enterprise technology. If you run commercial software of any complexity, then you receive patches and upgrades on a regular basis, most frequently to fix security vulnerabilities. Some of these patches will be minor or advisory, but others will be critical: they address immediate danger. Fortunately, we don’t have to take our software to the garage to get the patches applied: they come to us over the Internet. But there is work required to apply them.

David Knott 10/08/2023 David Knott 10/08/2023

5 Ps: ingredients for technology success

There are lots of ways of organising a digital or technology capability, and I’ve tried many of them. Most of them don’t work, resulting in slow, bureaucratic organisations which fail to realise the full potential of technology. However, over time, through difficult lessons learnt in many different places, I have come to believe that there are five ingredients of a successful technology organisation. They all begin with the letter P, so let’s call this the 5 Ps model. It can be described something like this:

Platforms are highly homogenous, standardised, software-defined technology capabilities which enable products to be built at speed, with confidence that they will scale and be reliable and secure.

Products are highly specialised functional capabilities which deliver value to end users.

People are people! But the talent and capabilities of the people who do these jobs matter, as does the level of trust and autonomy they are afforded. In this model, people are expected to to be trusted experts with the power to manage, develop and continuously improve their products and platforms.

Practices are common ways of working which unite people who are otherwise distributed into autonomous platform and product teams. They are at least as much cultural as they are formal, and are driven by the pride and experience of expert professionals.

Performance comprises a set of meaningful metrics which describe the success of platform and product teams, and which are owned and driven by those platform and product teams.

David Knott 03/08/2023 David Knott 03/08/2023

From Oppenheimer to Fargo: the ups and downs of ingenuity

Is that really a Palm Pilot?

Coverage of the recently released biopic, Oppenheimer, revealed that the film was so long that the reels at IMAX cinemas needed to be modified to contain its full eleven miles. Observant viewers with an interest in technology noticed something much more surprising, though: the IMAX reels seemed to be controlled by something that looked like a Palm Pilot, a Personal Digital Assistant (PDA) from 2002. (For younger readers, a PDA was like a smartphone, only without a touch screen, the ability to make calls, connect to the Internet, take photos or store all your music. You may wonder why we spent so much money on them. In hindsight, me too.)

It turned out that the setup did not actually use a Palm Pilot, but a Palm Pilot emulator running on a Windows tablet - which somehow makes it seem even more weird. An obsolete device has been converted into software and presented as a physical interface on another obsolete device. Coupled with the mild shock at the realization that IMAX cinemas still use physical film at all, the whole configuration seems like a steampunk mashup of technology from different decades.

David Knott 27/07/2023 David Knott 27/07/2023

What can technologists learn from board games?

Have you played a board game recently?

If not, you might find that they are very different from the games of Monopoly, Risk and Scrabble that you are familiar with. Many of today’s board games seem bewilderingly complex, packed with counters, cards and other components, described by intimidating rulebooks, and based on unlikely themes: cross-Atlantic trading in the 17th century, subsistence farming in the Middle Ages, and the construction of stained glass windows (these are all real games).

However, like any hobby, I think that they are worth paying attention to (and I have to admit that I have spent plenty of my own time playing these games). It’s a useful rule of thumb that, even if an activity seems uninteresting or difficult to appreciate at first sight, when a lot of people invest a lot of time in it, then it is good to be curious about it. Even if it’s not for you, you will learn something new.

David Knott 20/07/2023 David Knott 20/07/2023

The fox and the hedgehog

A fox knows many things, but a hedgehog knows one big thing.

I am sure that you have heard this saying before: it’s attributed to the Greek poet Archilochus, who lived in the 7th century BCE, so it’s been around for a while.

I think that this saying is useful in enterprise technology: we work in a field full of foxes (technology capable of doing many things) and hedgehogs (technology which is good at doing one big thing). It is often difficult to tell foxes and hedgehogs apart, especially when we are also surrounded by people who want to convince that their hedgehog is a fox: that it’s not just a great piece of technology that can solve one big problem, but that it can solve all our problems. If you have been working in the technology field for a while, then you will have seen several technologies and approaches promoted as the answer to everything, before they either faded away, or settled down into the life of happy hedgehogs (ESBs, anyone?).

David Knott 13/07/2023 David Knott 13/07/2023

The three flavours of legacy: sour, bitter and sweet

What does legacy technology taste like?

That might seem like an odd question, not just because it’s strange to ask about the taste of technology, but also because it might seem obvious that legacy tastes bad. We usually talk as if legacy systems are unequivocally awful. We have legacy remediation programmes, legacy reduction programmes, and legacy elimination programmes. We sometimes seem to put more effort into getting rid of legacy systems than we do in building them in the first place.

However, I think that the world is not that simple, and that it’s more helpful to think of legacy systems as coming in three flavours: sour, bitter and sweet.

David Knott 06/07/2023 David Knott 06/07/2023

Risk isn’t boring if you are a lion tamer (and we are all lion tamers now)

I was at an event recently where a presenter apologised for talking about technology risk. They anticipated that the audience would perceive it as a dry and boring subject.

I can see why they felt that they needed to make this apology. When people hear the words ‘technology risk’ they often think about processes, risk registers, controls, reviews, assessments, forms, and all sorts of reasons that they can’t go faster.

I don’t think that we need to think about risk this way, though. Risk clearly isn’t boring if you’re doing a dangerous job. If you’re a tightrope walker, an astronaut or an airline pilot, then the danger is immediate and obvious, and risk management is an essential part of your work. Checking that the safety net is in place, that your oxygen tank is full, and that the doors are closed properly are matters of life and death.

David Knott 29/06/2023 David Knott 29/06/2023

Making the unapproachable approachable

I don’t have many regrets, but I do regret not paying more attention in maths class when I was about 17 years old. I had reached the point where I was thoroughly bored with full time education. I think I must have been staring out of the window during the vital lesson when the fundamentals of calculus were explained, because suddenly I was in a world of symbols and concepts that I didn’t understand. It was like skipping a couple of episodes of a complicated TV series: I was lost and struggling to catch up. With the help of some friends, I bluffed my way through the exams and didn’t do too badly, but I never felt at ease with the subject.

To tell the truth, I don’t even regret that academic mis-step very much, as it was part of the path that led to me skipping university at 18, a choice which I wouldn’t recommend to everybody, but which had a huge influence on my personal, professional and academic life. However, I have always felt that calculus was an important hole in my understanding of the world. This has particularly been the case recently, when I have attempted to educate myself about Machine Learning.

David Knott 22/06/2023 David Knott 22/06/2023

Some problems are interesting once; others are interesting forever

Dates are horrible.

If you are a computer, or a computer programmer, it makes sense to measure time as a single continuously increasing linear quantity, such as the number of microseconds since 1st January 1970 (known as the Unix epoch). You can compare, add and subtract such numbers. However, humans insist on measuring time based on the rotation of the Earth (days), the passage of the Earth around the Sun (years), and on further subdivisions (weeks, months and hours). This means that dates and times have structure, and computers and computer programmers have to handle that structure.

Maybe there are people out there who like writing date and time handling routines. Personally, my heart sinks every time I have to capture a date from a human input and store and manipulate it in some way. If I’m using date and time functions, I always have to look them up in reference guides and on Q&A sites, and I always make some mistakes. (Is that a date or a datetime object? Did I put the month in the right place? Have I adjusted for time zones?)