- 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
Architecture as balance #4: finding the time
Last week, Manoj Chugh asked me for my view on how architects should balance their time between strategic and tactical priorities.
I suspect that Manoj’s question was motivated by the feeling we all sometimes have, that there is simply not enough time: we set ambitious strategic goals and have lofty intentions to realise them, but those ambitions get overtaken by the sheer quantity of decisions we must take and problems we must solve every day.
I can’t even pretend to have a perfect or comprehensive answer to this problem. I could try to point out that strategy and tactics should not be enemies, because good tactics are just the actions which are taken to implement strategy. However, even when strategy and tactics are perfectly aligned, it is easy to feel as if there is just not enough time to get everything done.
I think that we have to accept that this is just part of life as a technology architect (and many other technology roles). If our job is to figure out how to deploy rapidly changing technologies in the service of customers and of business goals, then the number of things we could do will always exceed the number of things which we can do. In this case, then the best we can hope to do is to make the best possible use of the time we have.
Architecture as balance #3: what do you do when ‘tactical’ means ‘irrational’?
Let’s spend some time with the glass half empty.
In my last article I claimed that tactics and strategy do not need to be enemies. Strategy defines goals and sets priority and direction; tactics comprise the actions that implement the strategy. On a good day, technology architects remember that strategy doesn’t happen without tactics, and successfully align the two.
But not every day is a good day. Too often, architects find themselves in situations where someone is trying to justify a design choice or course of action on the basis that it is ‘tactical’, when the architect knows that this is just code for ‘please go away and stop bothering me’ or ‘I know this is a bad decision but I’ve got to go along with it’. These situations are not resolved by remembering the proper relationship between strategy and tactics: they are resolved by hard choices and difficult conversations. Dealing with them is not the most fun part of the job, but if we don’t deal with them, then we are not really doing the job.
Architecture as balance #2: strategic vs tactical
Technology architects frequently ask me how they should balance tactical choices with strategic goals. Sometimes this question is asked in a grand, enterprise context: how is it possible to transform a complex enterprise while maintaining service and delivering immediate change goals? More often, though, it is asked in a very narrow, specific and personal context. How do I get my team to stop picking bad solutions and justifying them because they’re ‘tactical’? How do I get my project manager to let me design a proper solution, when they won’t provide the time, money and resources to do a good job? How do I convince people that they should adopt the ’strategic’ solution when it’s so expensive and hard to implement?
Almost all technology architects face these problems almost every day, and if any of them claim to have solved them once and for all, then you should go and read their blog. I can’t offer a perfect solution, but can offer some thoughts which might be helpful. These will come in two instalments: this is the first, which deals with some common conceptual mistakes made by technology architects.
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.
Lessons last: how one small idea helped shape my career
It is strange how a small lesson learnt early can last your whole life.
Forty years ago, I found myself staring at a piece of text which made no sense to me, wondering whether I had made a terrible mistake. My school offered Russian as a language and, attracted by difference and by the strangeness of the alphabet (and the prospect of a school trip to Moscow and Leningrad), it was the option I had selected. Now I felt like I was illiterate again: I could only recognise some of the characters in the alphabet, and even they didn’t sound like I thought they should sound.
That first lesson made a big impression on me. First, it helped me to decode text that was previously impenetrable: even if I couldn’t understand the words, I could start to figure out the sounds. More importantly, though, my Russian teacher, Mr Clark, pressed home on us the importance of being conscientious. He expected us not just to learn the alphabet, not just to write it, but to write it well. He would mark our work not just on grammar and spelling, but on the care and attention we took in writing. This wasn’t because he was an especially tough teacher: it was because he knew that time invested in the basics would embed the skills, and would help us develop habits of excellence and diliigence. To impress these habits in us, he asked us time and time again whether we were being conscientious, and let us know very clearly when we were not.
A technology architect’s guide to humans part five: . . . sorry, what were you saying?
Sometimes being a technology architect is like being an 18th century French agriculturalist. No, don’t go: hear me out . . .
You may have eaten potatoes Parmentier: fried potatoes with herbs and garlic. You may not appreciate, though, the effort that Antoine-Augustin Parmentier, inventor of the dish, put into getting people like you to eat potatoes.
Parmentier was introduced to the potato as a prisoner of war in Prussia, and came to believe in them as a reliable food source at a time of frequent crop failures, famine and shortages. However, he faced extraordinary cultural and legal resistance from his countrymen. Potatoes were considered to be fit for animal feed only, were believed to cause leprosy in humans, and were even banned from cultivation from 1748.
How do you spot a high performing technology architect? Look for head swivels, echoes and low batteries
Whenever the members of the HSBC architecture practice come together, I get a lot of direct and difficult questions, about technology, strategy, people and many other subjects. This week at our regular Town Hall, I was asked: ‘As we approach the end of the year and think about formal performance ratings, how do you recognise a high performing architect?’
Of course, the proper answer to this question depends on the person and their context, and should be an active conversation all the time, rather than a question that gets asked and answered once a year.
However, the informal answer that there are some signals of performance which I have found to be broadly reliable. Unsurprisingly, these are based on the three attributes of an architect we seek at HSBC, and which we call Zang Jing Ge: technical excellence; communication mastery; and leadership power. These signals comprise two head swivels, some loud echoes and low batteries.
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.’
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.’
Architecture leadership: the clarity pump
At HSBC, technology architects aim to achieve Zang Jing Ge: technical excellence, communication mastery and leadership power.
Most of us have a pretty good idea of what technical excellence looks like. We also have some idea of what communication mastery looks like, even if many of us are not as confident in our communication skills as we are in our technical skills.
But what does it mean for a technology architect to demonstrate leadership power?
It doesn’t mean that we have thousands of people working for us, or that we control large budgets. Many architects are individual contributors, and even those in leadership positions don’t usually have large teams (my team is the smallest function in the HSBC Technology organisation). You don’t normally find the architects by tracing the organisational hierarchy upwards or by following the money.
So how do we lead?
Architecture as balance #1: elephants vs building blocks
Q: How do you eat an elephant?
A: One bite at a time.
This is an old joke, and one that technology architects are very familiar with. We spend a lot of our time dealing with big, open ended questions and big problems. How do we make this legacy system respond to digital needs? How do we integrate this acquisition and realise efficiency gains without breaking the business? How do we turn this disruptive force into a competitive advantage?
One of our most basic techniques is to break the big problem down into smaller pieces: to eat the elephant one bite at a time. We progressively refactor the legacy system into micro-services. We figure out the processes, functions, systems and data of the acquired entity and map them to the integrated state. We get to grips with the fundamentals of the disruptive force, and work out the best places to start putting it to work in our current enterprise.