- 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
- films
- 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
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
New Year’s resolutions won’t fix bad code
This is the time of year when many of us start planning New Year’s resolutions.
We feel that we could lose some weight, we could be fitter, and we could do more to improve ourselves. A few days of idleness and indulgence has made us feel restless, a little more guilty than usual, and ready for a change. The turning of the year feels like the right time to make that change.
So we make vows that this time - this time - we will change our ways. We will join that gym, enter that diet programme or enrol in that course.
The only problem is that New Year’s resolutions don’t usually work. There’s been lots of research done about why they don’t work, and how we can make them more effective (for example, Richard Wiseman’s Quirkology site has a characteristically interesting and entertaining article: http://www.richardwiseman.com/quirkology/new/USA/Experiment_resolution.shtml). However, while this research can be helpful, we don’t really need it to tell us that New Year’s resolutions don’t usually work: we’ve always known that. New Year’s resolutions are often the punchline to a bad joke, a list of things that we know that we won’t be doing by February.
For good APIs, legacy systems need an attitude adjustment
Why is opening up legacy systems using APIs still so hard?
As IT architects, we tend to focus on the technical reasons: data formats, protocols, messaging capabilities and so on.
I believe that we should also focus on another reason: our legacy systems have an attitude problem.
Do systems really have an attitude? Most of them can’t talk (yet), but imagine if they could. The batch, COBOL, mainframe systems I wrote in my first coding job might have sounded something like this:
"I don’t talk to other programs. I’m not even sure whether they really exist. All that I know is that once I day I wake up, I take that pile of data over there, I do some stuff to it, and I move it over there."
Good complexity, bad complexity
Technology architects give complexity a bad name.
We often make the mistake of talking as if complexity is inherently bad. We then compound that error by saying that complex architectures are difficult to understand, slow to charge and hard to recover. Then we make things even worse by counting big countable objects (systems, machines, products, versions and so on) and believing that we have measured the complexity in our architectures.
Some things are just inherently complex.
Fortunately, there is a way to correct these mistakes, but it requires us to embrace four ideas:
complexity can be good
complexity can also be bad
counting objects is a bad way to measure bad complexity
there are some better measures of good complexity.
Sometimes speed is a feature, not a goal
Is faster always better? We often assume so: our technology revolution is powered by faster processors, faster storage and faster networks, and we use them to build faster experience.
But faster is not always better in the field of user experience.
I realised this recently, when I bought a new e-reader (I won’t mention the brand, but you know what it is).
I have been using e-readers for many years, and have built a library of several hundred books. As soon as I had powered up the device, connected to the network and registered my account, I looked for the option to download my entire library.
From design conflict to design harmony on cloud
The dome of St Paul’s is an iconic part of the London skyline: it’s instantly recognisable, and can be seen from far away.
What’s harder to see, though, is that the famous building is also a famous architectural compromise. Sir Christopher Wren’s original plan was for a floorplan shaped like a symmetrical cross, in line with the classical inspiration for his design. The clergy disagreed, though, and insisted on the more traditional layout for an English church, with an extended nave. As a result, we have a classical dome on top of a medieval floorplan.
Most design involves compromises like this: we have design goals (build a beautiful structure following classical ideals; demonstrate visual continuity with church tradition) which cannot be satisfied simultaneously, and we have to figure out which goals we will give priority to.
One of the things that attracts me to Cloud, though, is that design goals which have traditionally conflicted can be brought into harmony.
Be cloud ambidextrous not cloud agnostic
I am lucky enough to own a PlayStation 4 and an Xbox One.
(It’s okay in 2018 for a senior technology professional in his fifties to admit that he still plays video games, isn’t it? No, not Red Dead Redemption 2 yet, although the original is one of my all time favourites. I’ve still got God of War to finish. And if you don’t think it’s okay for adults to play video games, go play both of those and then come back and tell me again.)
I don’t own both consoles because of any technical differences between them: I’m not really into comparing frame rates and textures, and will buy a game on whichever console is cheapest. But there are console exclusives which I don’t want to miss out on.
I think that this is a good way for enterprises to think about Cloud.
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.