- 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
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.
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.