- 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
A technology architect’s guide humans part one: humans are human
It doesn’t take long working as a technology architect to realise that technology is easy, but humans are hard. Today’s technology is complex, can be difficult to understand, and changes at an ever increasing rate. But technology behaves in predictable ways, even when it fails. As you long as you understand it at a sufficiently fundamental level, technology does what you tell it to.
By contract, humans are less predictable, and less inclined to do what you ask them to do. They ask questions, they raise objections, they suffer fear, uncertainty and doubt. They need to be emotionally committed as well as rationally persuaded before they apply all their energy. They misunderstand and they forget. But when they are persuaded and committed, they bring imagination, passion and creativity that no machine can match.
If you are a technology architect, you probably work with humans every day. Your family and friends are likely to be humans and, unless there have been unexpected advances in AI since I wrote this blog post, you are probably a human too. Yet, if you’re anything like me, I expect that you feel that you still haven’t figured these humans out yet.
This not a negotiation: beyond win-win?
When is a negotiation not a negotiation? And can we do even better than win-win?
In the HSBC Architecture team, we aspire to the three dimensions of architecture excellence we call Zang Jing Ge: technical excellence, communication mastery and leadership power. In a recent article, our Head of API Integration and Microservices, Marco Tedone, argued that we need a fourth dimension: negotiating skills, or Minghzhi De, meaning ‘wisdom’.
I agree that all architects need good negotiating skills, and believe that we can fit them in the centre of the Zang Jing Ge model: good negotiation needs technical excellence (knowing what you want), communication mastery (getting the other party to understand your position and goals) and leadership excellence (leading everyone, if possible, to a win-win outcome).
AI ethics: one FAQ, two concerns and a hope
In the last two weeks, I was honoured to be invited to sit on two panels on the topic of AI ethics and responsiblity, one as part of a training course within HSBC, and one as part of the Google Next 2019 conference.
I was asked a similar question in both panels, which went something like this: how does the combination of my academic background in ethics and my professional background in enterprise technology shape my perspective on AI ethics?
I’ve been asked this question often enough for it to count as an FAQ, so I thought it might be helpful to share my answer here.
Before I share it, though, I have to give one big caveat. Studying philosophy and attempting to keep up with the latest developments in technology teach me both humility and the depths of my ignorance, so I am aware that any thoughts I share here are provisional, personal and have a strong likelihood of being wrong.
You don’t need any magic in this magic
Jonathan Creek, the protagonist of the BBC TV series of the same name, is a magician’s assistant who solves unlikely crimes using the same understanding of mechanics, engineering and psychology that he brings to the design of magic tricks for the stage.
In the very first episode Jonathan (played by Alan Davies) is reluctantly persuaded by a journalist, Maddie (played by Caroline Quentin), to perform a magic trick, and then to explain how it works. After Jonathan has duly amazed Maddie by apparently reading her mind and conjuring a name onto a piece of paper, he then disappoints her by showing her that the trick was nothing but some sleight of hand, misdirection and assistance from an accomplice. Maddy declares the trick to be ‘mind-numbingly banal’.
That’s Jonathan’s point: everyone is amazed by magic and claims to want to know how the trick is done, but they don’t really want to know the mundane reality behind the scenes.
What is the C that you 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).
ShenXian: two models of leadership
Every time I go to China I learn at least one new thing. On my last visit to Guangzhou, our Head of AI Engineering, Ray Zeng, introduced me to a whole new way of thinking about IT leadership through the concept of ShenXian.
(At this point I have to confess that, unlike Ray, who lives in Hong Kong, but grew up in Shanghai, I am no expert in Chinese culture, so I am sure that I will get some of these ideas wrong: I will let my colleagues from China correct me in the comments.)
My understanding is that the term ShenXian is used to describe two distinct types of heroes, immortals or saints. Shen are beings who have been part of the world since the start of time, or who have been promoted to their divine status through their great feats while they were on earth, often on the battlefield. They might be warriors or generals, and are portrayed flamboyantly, wearing armour or shining clothes. They are often associated with large armies.
Planning for a cloudy day
On 3rd June 1979, the American Institute of Architects held their annual national conference at the Kemper Arena in Kansas City, a building they had honoured with an award.
Less than 24 hours later, the roof collapsed. Fortunately, no-one was hurt.
The cause of the collapse was partly due to excessive rainfall during a major storm. The roof has been built with rain in mind, with a drainage system designed to release water gradually into the sewer system to avoid overwhelming it. What it had not been designed for, however, was the day when there was so much rain that the sewer system was already overwhelmed, causing water to back up onto the roof. Water is heavy, and the additional weight, coupled with high winds, caused a supporting bolt to give way, triggering a series of further failures and the collapse of the roof.
Aging is a funny thing: you only do it once
In our HSBC Technology Town Hall meetings we have a rule: if the team wants to know the answer to a question, we answer it, no matter how awkward. (We use an online tool, let everyone post and see questions, and vote them up and down: we then answer the most popular).
In our most recent Town Hall meeting, open to people from all over the world, we got a question along the following lines: ‘The Technology Leadership team are all 50+ years old. Where’s the new blood?’.
It would be easy to feel defensive about such a question (especially for the team members well under fifty), but Darryl West, our Group CIO, gave a very straight answer: he thinks that age is less important than learning, and that it is essential for those of us who have been around for a while to consciously keep learning and reinventing ourselves.
I think that Darryl is right, but this question prompted me to think a little more deeply about what age means to those of us in technology leadership roles, and to consider what it means to me.
Rough and ready rules for writing
In the HSBC Architecture team, we try to live up to the three principles of Zang Jing Ge: technical skill, communication mastery and leadership power. All of these dimensions are important, but in a Technology team of over 40,000 people, distributed around the world, communication is particularly important. Although it helps to work things out by writing them down, architects are often accused of being unclear in their written communication. In order to get better at this, we have built thirty two rough and ready rules which we try to practice every time we write a document or produce a presentation. They are not formal and not perfect and many of them may seem incredibly obvious, but they seem to help us, and I’d like to share them here:
Beware the SMAC trap
Terms such as SMAC are a tool and a trap.
SMAC stands for Social, Mobile, Analytics and Cloud. It seems to have been coined sometime between 2010 and 2012, but it’s difficult to find its first usage. The idea behind SMAC seems to have come from Gartner’s research on what they call ‘the Nexus of Forces’, although that research talks about Mobile, Social, Cloud and Information (I guess that SMAC is more catchy than MSCI).
The idea behind the term is useful: there are technology trends which are reshaping our world and our businesses, and these trends amplify each other rather than acting in isolation. For example: social media provides new ways for us to connect and communicate; social media on mobile makes it ubiquitous; analytics applied to social media on mobile gives unparalleled insight into our behaviour and preferences; and Cloud provides the storage and compute capacity required to run an analytics driven social network accessed continuously through mobile devices.
How often do you patch or upgrade your mental models
How often do you apply patches?
Patching isn’t just a job for sys admins any more. Even people who have never performed a technical role routinely apply patches to their PCs and the apps on their phone: if they’ve turned on auto-updates, they may not even realise that they’re doing it.
Major upgrades are a different matter, though. Sys admins still approach them with caution, accompanied by a lot of planning and testing. And the rest of us approach major upgrades to our PCs and phones with some suspicion. We watch the Internet to find out how others have got on with the latest OS version, to see whether it’s going to break our apps, drain our battery or have other weird and unexpected consequences.
I think that we manage our mental models of technology in a similar way.
Work things out by writing them down
On 28th February 1571, Michel de Montaigne retired to a tower in the Dordogne and began to write his Essays: reflections and explorations of such grand concepts as age, friendship and vanity, as well as more basic matters such as smells, drunkenness and the custom of wearing clothes. Montaigne called these explorations essays (essais in French) as he considered them to be trials (from essayer): ways of testing his own ideas, particularly his own understanding of himself, by writing things down. As a result, these essays - these trials - are digressive, discursive and full of both insight and contradiction.
There are many lessons we can learn from Montaigne, and many of his essays are surprisingly readable near 450 years later. However, I believe that the most important lesson which IT architects can learn comes from the nature of Montaigne’s whole endeavour: the importance of working things out by writing them down.