Solution Architect: Day One

Starting a new job is always difficult. It’s even more difficult if you don’t quite know what the job is, or what it means to do that job successfully.

Many technology architects find themselves in this position, whether they are solution architects, domain architects, enterprise architects or even chief architects. Despite a growing body of thought and literature on this topic, the profession of technology architect is often loosely defined and poorly understood (have you tried explaining what you do to your family?). It is not uncommon to hear of people being plucked from a role as an engineer or sysadmin and anointed as an architect with little preparation or training, to find that the rest of the team is now looking to them for . . . something.

In the HSBC Technology Architecture team, we try to do better than this. All architects are members of an architecture practice, we provide training in fundamentals to new and aspiring architects, and we all try to attain the attributes of Zang Jing Ge: technical excellence; communication mastery; and leadership power.

However, even all of this can’t fully prepare someone for actually doing the job. This article is the first in a series which will offer advice to people in their first day in the job as different types of architect. We’ll start with solution architecture, and the advice will come from the collective wisdom of the HSBC Technology Architecture leadership team.

Keep asking questions until you get the real answers. Gareth Henman, Chief Enterprise Architect and James Linsell-Fraser, Chief Architect for HSBC Private Bank

It might seem obvious that the first thing to do in a new job is to ask questions. Who is everybody? What are they doing? What do you want me to do? Where’s the coffee machine?

Unfortunately, as a solution architect, most of the first answers you get to these questions will not be enough for you to do your job effectively. They will often be calibrated to a narrow context: this is the project team; we’re here to deliver the project; we need you to produce this design document because that’s what it says on the project plan; the coffee machine is broken. But if you’re going to define the right solution, you need to understand the problem, and if you’re going to understand the problem, you need a deep understanding of the context.

Gareth’s and James’ advice is to keep asking questions until you are confident that you have reached that deep understanding. James always asks: what are we really trying to achieve? Why does it matter? When do we need to be done? How much can we afford? Gareth just keeps asking, ‘why?’ until there are no more whys to ask.

Find the person who understands how ‘the system’ works. Dan King, Chief Infrastructure Architect

In several of the architecture teams I have run, I have gathered data to find out how solution architects spend their time. I have consistently found that as much as 60% of solution architects’ time is spent in research and discovery: in figuring out how things work today before they can figure out the solution for tomorrow. Much of this time is spent scanning through shared documents and intranet sites - and it’s normal to find that these documents don’t contain all the answers.

Dan’s advice is to find the person (and it is often just one person) who truly understands how things work. This is usually someone who designed some of the oldest systems in the organisation, who has upgraded them over the years, and who has lived through failures and incidents. Once you have found that person, you should learn as much as you can from them (and figure out how you can codify their knowledge for the benefit of others). And you should remember that ‘the system’ doesn’t just mean technology: it means the entire human, procedural, conceptual and cultural system through which the business runs and things get done.

Figure out how decisions actually get made, and how they stay made. Paul Frost, Chief Architect for HSBC Wholesale Banking and Rafal Wasilewski, Chief Architect for Europe

Making design decisions can be difficult. But it can be even more difficult to figure out how to convert decisions which you have made into decisions which the organisation has made - and that other people will follow and stick to. When you first start making design decisions as an architect, you may be surprised by how many other people feel that they have the right to question, challenge or ignore those decisions.

Paul’s and Rafal’s advice is to learn the way in which your organisation makes decisions, and what it does to stand by those decisions. Part of this - often the easiest part - is to learn the formal governance processes of your organisation, particularly which decision rights are held by which people, and which decision rights are held by you.

But it is just as important to understand the informal decision making structures of the organisation. Who needs to be convinced of a decision before they will back it? What will convince them? What results do they need to see to maintain faith in a decision?

If you come to understand all decision making paths of the organisation, it will help you figure out how to convince people to do the right thing because they want to, rather than because they are told to through governance.

There’s always time to do the right thing. Andy Wrigley, Head of Communications for Architecture

There is a strong chance that, before you have even found your feet as a solution architect, you will be asked to compromise: you will be asked (or told) that you must agree to do the quick thing rather than the right thing. It is also likely that this ask will be expressed in language which implies a conflict between strategy and tactics.

Compromise is not bad, and such asks are not always unreasonable. Much design work means finding the balance between constraints: between cost and performance; between speed and functions; between product capability and product availability. But you must make sure that when you strike this balance, you understand the weights on each side of the scale.

Andy’s advice is that you take particular care when you are making the choice between delivery speed and good design, and realise that you (and other stakeholders such as project managers and product managers) will have a natural tendency to over-value today’s cost (whether in money, time or resources), compared to tomorrow’s cost. You need to be alert to those situations when an apparently attractive saving of a few days in the present will cost you many more days in the future, whether in rework, repair or increased friction.

Preserve your engineering laziness. Kate Platonova, Chief Architect for Technical Domains

Many good engineers have a positive form of laziness: when asked to do a mundane, boring job more than once, they will work hard to refactor code, write scripts and automate tasks so that they never have to do that work again.

Kate’s advice is that those good, lazy engineers who make the move into architecture should not forget their lazy engineering roots. Not all architects continue to write code that will be deployed in production, but they still have many opportunities to reduce unnecessary work by making good design choices. The best work is the work that you don’t have to do at all. Reuse is not the answer to everything, but utility components, accessed through good APIs, that do jobs that need doing, are the answer to many things.

Your technical skills got you here; your communication skills need work. Taimoor Alam, Chief Architect for Middle East, North Africa and Turkey.

You may have become an architect because you demonstrated technical excellence in your previous role. You can expect (and should want) to continue to apply, develop and prove that technical excellence in your new role. But, as an architect, you will quickly realise that it’s not enough to have great ideas in your head: you must get those ideas into other people’s heads. (The brain:hands:keyboard:screen:eyes:brain loop has now become a brain:words+pictures:other brains:other hands:other keyboards branching tree.)

Taimoor’s advice is to strive to achieve the communication mastery attribute of Zang Jing Ge from your very first day on the job - and to recognise that you will still be striving to achieve it in your last day on the job. Many architects do not start with strong communication skills, and have to consciously work on them; all architects, no matter how experienced they are, can improve their communication skills and need to consciously work on them.

Aim high: understand the spirit of what you are trying to achieve. Jules Speight, Chief Architect for Corporate Functions

On your first day as a solution architect, you may be overwhelmed by tasks which need to be completed quickly - some as early as your second day as a solution architect. You will need to get those tasks done, but also need to step back and understand what they add up to - and what you could achieve if you were more ambitious.

Jules’ advice is to remember from the very first day that all architects have a privilege and a responsibility. We are privileged to be in a job where we get to raise our heads from our day to day tasks and look into the future: to anticipate the opportunities and challenges of tomorrow. And we have a responsibility to bring that vision of tomorrow back to today, to explain what it means to our colleagues, and to change what we are doing.

Find your fellow architects and ask for help. Everybody.

All of this advice is a lot to take in, and it’s unlikely that you will be able to follow it all and still get your job done.

The most important piece of advice, therefore, is to remember that you don’t need to do this on your own. It can feel lonely as a solution architect: you may be the only person with your job title and responsibilities in your team, or across several teams. It can feel even lonelier when you need to take tough decisions that you know will be unpopular.

In the HSBC Technology Architecture team, we try to help by bringing all architects together into a practice. But even without such a construct, there are plenty of other architects out there, whether in your company or in others. We’ve all had our first day on the job and know what it feels like: we also know that it’s a good time to ask the architects.