- 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
- partnership
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
AI ate my favourite quote
It’s great when someone anticipates your problems by 150 years.
Charles Babbage is one of my computing heroes, not just because he invented the Difference Engine, and not just because he collaborated closely with Ada Lovelace on the Analytical Egnine, but because he said this:
"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."
That quote resonates with anyone who has tried to explain technical concepts to non-technical people, whether that means fixing your friend’s PC or presenting an IT investment case to the Board. Of course, if we fail to explain something well, it is our fault rather than the fault of the audience. But we can’t help recognising the combination of frustration and bewilderment in Babbage’s words.
Enterprise cloud needs a PVR moment
Do you remember the first time you paused live TV?
If you’re anything like me, it felt like the way you watched TV had changed forever.
Personal Video Recorders (PVRs) were one of the first steps in the current broadcast revolution. Although they have since been joined by many streaming services, millions of us still have some form of PVR sitting on or near our TV, and watch much of our content through that box.
Yet PVRs were not initially rapidly adopted, or even well understood by consumers.
Years ago, I met a product manager for a satellite and cable broadcaster, who was trying to get people to buy their very first PVR service. Despite the amazing (for the time) features on offer, it was hard, and sales were slow.
The problem was that most people didn’t understand why these features were so amazing. They all had VHS video recorders, which let them record their programmes, and to pause, fast forward and rewind. They had DVD players if they wanted to watch movies in better quality and a more convenient format. What more could the PVR possibly offer?
Zang Jing Ge part 2: 13 leadership behaviours for architects
Figuring out what makes a good architect is hard: figuring out what makes a good architecture leader is even harder.
In HSBC Technology we expect all architects to lead the thinking of others. But we also expect some architects to formally occupy leadership roles: to build and lead architecture teams, and to occupy senior, strategic positions in the organisation. These are our architecture leaders, and we expect a lot of them.
In my last blog post, Zang Jing Ge: the Way of the Architect, I shared some thoughts about the three dimensions that make a good architect: technical excellence; leadership power; and communication mastery.
In my team, we’ve also tried to define the key behaviours of an architecture leader, and have come with a list of 13 things. This list is a lot messier than the three dimensions of Zang Jing Ge. Most architects like things to be organised: to have some kind of system and schema. But we couldn’t squeeze these ideas into a tidy conceptual structure (that’s why there’s 13 of them): they are just the things that we expect of each other, and others expect of us.
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.
There’s no nostalgia like computing nostalgia
It's development week in HSBC Technology, so I'm sharing the very first computer learning experience.
I learnt to code in BASIC on an Acorn Atom (a British microcomputer) when I was 12 years old, in 1980. I had been pestering my parents for months to buy me a computer (learning BASIC from books and trying to imagine the programs in my head wasn’t really cutting it). Switching on the machine in all its 12KB glory, (along with a portable black and white TV and a cassette tape recorder) and seeing the cursor awaiting my commands was a powerful experience.
Why does this experience from the dawn of my career matter today, though?
In the HSBC Technology leadership team, we believe that everyone should remain a hands-on technologist, no matter how senior they get in the organisation. We also realise that this has not always been the case in enterprise IT teams: for many years, the more senior people got, the more distant they got from technology, and the more they focused on managing people, finance and processes. And we realise that this is as true of us as of most people in our profession.
Anti-Shunya for careers
I knew that the concept of zero (at least as a positional notation) was invented in India, but I didn’t learn the Sanskrit term for zero (Shunya) until last month. My friend and colleague Balasubramanian Ganesh (HSBC’s CIO for Retail Banking and Wealth Management) introduced me to this term, and explained how we are using this concept (and a load of cool instrumentation) to drive zero defects, zero incidents and zero vulnerabilities for software engineering.
Ganesh also asked me on stage at our Engineering Summit in Pune, India, to share some reflections on my career, and to offer advice on what has helped me reach my current position of Chief Architect for HSBC.
My reflection was that, while Shunya is a great goal for software, it’s not something I have followed in career terms: my career has been full of defects, incidents and vulnerabilities. That’s because it has taken a while to figure out what I am good at, and it turns out that, to figure out what you’re good at, you have to do some things that you’re not good at.
Rule zero: break any of these rules sooner than do anything outright nonsensical
In his essay Politics and the English Language, George Orwell proposed several rules for writing clearly: avoid dead metaphors, cut out unnecessary words, use the active rather than the passive tense and so on.
I think that the most important of these was Rule Six: ‘Break any of these rules sooner than say anything outright barbarous.’
In fact, I think that this rule is so important that those of us in the technology architecture profession ought to promote a modified version of it to Rule Zero, and let it stand at the head of any list of rules: ‘Break any of these rules rather than do anything outright nonsensical.’