- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
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.
Philosophy for architects: which habits will you make and which habits will you break?
Many of us will be working in unusual circumstances for extended periods of time. We will be at home rather than in the office. We will see more of our family than our colleagues. When we do see our colleagues, it will be by video rather than in person. (And, of course, if we are fortunate enough to be healthy, housed and in work, we will learn to be grateful for those things that we normally take for granted.)
As we adjust to this new way of life, we will form habits. We will (or will not) find ways to exercise. We will (or will not) find time to talk to people we wouldn’t otherwise see. We will (or will not) let our frustration and impatience with technology leak through into our behaviour. We will (or will not) continuously raid the cupboard for snacks.
Ethics, the philosophy of morals, contains some ideas about habits which might be useful to us as we live through these strange times. To understand these ideas, though, we must begin with some basics.
Tinker, tailor, strategist, innovator
What do you want to be when you grow up?
I’m still not entirely sure that I know, so it’s slightly scary when people ask for my advice on their career choices. Fortunately, being a technology architect means that I’m always prepared to express an opinion on something I don’t completely understand.
Two of the career choices I am asked about most frequently are technology strategy and innovation (probably because I have people that do both of these types of work in my team). Here is some of the advice I offer people to help them figure out whether these choices are good for them, and what kind of qualities they need to do this work well. (Like all advice from a technology architect it is well meant, but possibly wrong.)
Cloud helps us solve the rocket fuel problem
Putting code into production is a bit like going to space.
If you want to reach Earth orbit from the surface of the planet, you will need some help. To start with, you can’t survive on your own in space: you need a spacecraft.
But your spacecraft needs help too. It can’t escape Earth’s gravity on its own: it needs a boost. The only way humans have found to solve this problem so far is by using rockets.
But your rockets need help too. Lifting you and your spacecraft needs fuel, determined by your combined weight. But that fuel adds to the total weight, so you will need more fuel to carry that fuel. And more fuel to carry that fuel.
Innovation needs light bulbs . . . and lenses
Thomas Edison didn’t invent the light bulb, but he made affordable, long lasting electric light a reality. And this wasn’t just because he was struck by a sudden inspiration (a light bulb going off over his head): it was because because of disciplined experimentation coupled with a commitment to industrialisation. Most people know that Edison worked his way through thousands of designs for bulbs before patenting a bulb with a carbon filament, and that, even after filing his patent, he worked through thousands more choices for the material that would provide the carbon filament, finally settling on bamboo. It is less frequently mentioned that Edison and the workers at this lab also invented much of the equipment necessary to produce bulbs at scale, as well as the infrastructure needed to distribute power.
Edison himself said of this endeavour that, ‘There was no precedent for such a thing, and nowhere in the world could we purchase these parts. It was necessary to invent everything: dynamos, regulators, meters, switches, fuses, fixtures, underground conductors with their necessary connecting boxes, and a host of other detail parts, even down to insulating tape.’
What is the C that your are trying to P?
Three little letters strike terror into the hearts of architects everywhere: P. O. C.
This seems strange. Surely in the age of digital transformation, innovation, and a willingness to fail fast, conducting proofs of concept is exactly what we should be doing. Why should architects be scared of POCs?
The reason is that, unfortunately, in large enterprises, many POCs are not POCs at all. Whether deliberately or accidentally, they stand little chance of proving a concept: in fact, it’s not even clear which C they are trying to P.
Let’s look at two types of POCs which standing little chance of P’ing a C: POCs in name only (let’s call them POCINOs) and POCs without concepts(let’s call them POCWOCs).
Zang Jing Ge: the way of the architect
The job of IT architect is a strange one.
Many people don’t really know what IT architects do (I’m pretty sure that I have never given a convincing account of my job to my non-technical friends and family).
Even fewer people understand what makes one architect better than another.
But every team knows when they’ve got a good one: problems seem to get solved quicker, decisions seem to get made faster, and the team has someone to turn to when they have questions like ‘How in the world does that work?’ or ‘How on Earth are we going to get it to do that?’
In the HSBC Technology team we believe three things about architects.
First, we believe that, whatever architects do, and whatever makes them great, we need more of them.
Second, we believe that we have figured out at least some of the features of great architects.
And third, we believe that these features can be learned.