I’m David Knott. I’ve been working in enterprise technology for over forty years and I’m still learning. This blog is based on mistakes, failures, lessons and some things I find interesting:
Thinking differently about . . . collaboration
How often have you accidentally hit ‘reply all’ when sending an email? Or included someone on the cc: list that you didn’t intend to? I think that we all know the feeling of making that mistake.
I had a similar experience in my new job at Google last week - but it turned out to be a lesson about collaboration instead of a mistake.
I was editing a document using Google docs, and when I hit the share button, I was asked whether I wanted to share it with the same people as the document I had copied it from. I hit ‘yes’ - then realised that I had shared the document with about a hundred people, rather than the half dozen I had intended it for. I had a sinking feeling for a moment - then remembered that I needed to think differently about collaboration.
Thinking differently about . . . cloud
I will always associate the concept of Cloud with a view of the Thames. That’s what I could see on the day when the Cloud light bulb first began to flicker on in my head. One of my colleagues had arranged for the CTO of a Cloud company (not the one I work for today) to visit us, and he was explaining how his company had built their platform to support their own business. I started to realise how Cloud differed from traditional enterprise infrastructure and why I, as a technology architect, needed to pay attention.
As promised, this article is one of a series on how I learnt to think differently about key concepts in enterprise computing, written in the hope that they may be useful to people on the same journey. Before we go further on Cloud, though, I should declare that I work for a Cloud company (Google), but that the views in this article are my own. I should also say that I work for a Cloud company because I believe in the value of Cloud, not the other way round.
Thinking differently about . . . the persistence of code
This week I learnt that some of the code I wrote thirty years ago is still running in production. I don’t know whether to be pleased or terrified, but I know that it’s not the first time I’ve had that surprise.
Back at the beginning of my career, I wrote part of a system using technologies which barely exist in memory today: Application Master on an ICL mainframe accessing an IDMSX database. Ten years later, I did some more work for the same company, and was surprised when the year 2000 project team (yes, this was around 1999) approached me, asking me whether I knew anything about this code with my name on it. I recognised the code, but had never imagined it would be running ten years in the future.
Chief Architect: Day One
What should you do in your first day as Chief Architect of a large organisation?
I got to ask myself that question four years ago, when I started as Chief Architect for HSBC: it took me a long while to find (some of) the answers. Now that I have left HSBC for a new role, my successor has also had the chance to ask that question.
Here are some of our combined thoughts, in the hope that they will be useful to other people stepping into such a role. As with all offers of architecture advice, they are offered with a combination of confidence (won through learning from many mistakes) and humility (recognising that anyone people taking up the role will already have found some better answers than mine).
When is it reasonable for technology architects to go to unreasonable lengths?
Teller, the silent half of the duo of magicians, Penn and Teller, is not always silent: he’s given interviews and written articles on the theory, practice and psychology of magic.
Any insight into how people perceive and believe can be helpful to technology architects, but I think that one principle shared in this article is of particular use: make the secret a lot more trouble than the trick is worth.
The idea is that every trick has a public side (what the audience sees) and a secret side (how the effect is achieved), and that most people will assume that an apparently simple effect (the magician identifies the right card) is achieved by a similarly simple cause, and, if they cannot figure out that cause, will be mystified and entertained.
Learn sense making and storytelling from the world around you
My wife and I paid a (socially distanced and suitably masked) visit to the Tower of London last week. It was a strange experience to be visiting this site of so many historical events whilst in the middle of our own historical event, and even stranger because it was so quiet: visitor numbers are currently strictly limited.
The quiet gave us an opportunity to spend a little time longer with the exhibits, and to appreciate them in more detail. The one that stayed in my memory was an exhibit in the Bloody Tower which told the story of the princes in the Tower. (If you’re not familiar with this story, then you can learn more on Wikipedia or, if you’re in London, plan a visit when conditions permit.)
This exhibit held my attention because it told the story in two very different ways.
Take a trip in your architect’s time machine
I have claimed in the past that technology architects have superpowers, particularly x-ray vision and, even more importantly, the ability to figure out how things work. But if you are lucky enough to work with a technology architect, you should make the most of another one of their special abilities: time travel.
You have probably already realised that architects can travel to the future. After all, they spend a lot of their time talking about the fantastic advantages that new technology will bring us, and how great our lives will be one we have built their vision. They also spend a lot of their time giving us dire predictions of how things will be if we make the wrong choices in the present. They may even talk about future state architectures (although this is not a phrase I am a fan of - I will explain more in an upcoming article but will just say for now that attempting to define a single fixed ‘state’ for anything which changes as rapidly as technology architecture feels like a mistake).
Make Feedback a Batch Process
How do technology architects know that we are doing a good job? We are often working as the only architect on the team, making decisions which others may not agree with, making sense of complex and ambiguous topics, and trying to set a direction which others can follow. How can we tell that this all adds up to something useful?
One way to find out is to ask for feedback. We do better when people tell us freely why they disagree with us, whether we are successful in making ourselves understood, and whether the paths we lay out lead to the right place.