When did you first know that you wanted to be a technology architect?

It can take a long time to figure out where you fit. It needs self-awareness, often earned through a success and failure, elation and disappointment. It needs a dose of self-confidence, a shedding of self-doubt and false modesty, to admit that you are actually good at something, perhaps better than many other people. And it needs a big helping of humility, to admit that there are plenty of things that you are not good at, and which are best left to other people.

However, if you are a successful technology architect, I suspect that there was a moment early in your career where you figured out that this was the work for you. You discovered that there was something in the combination of problem solving, persuading and explanation that motivated you; that you had an itch made of equal parts curiosity, persistence and a desire to see things done right that could only be scratched by doing architecture work.

I can remember when I first realised that I wanted to be a technology architect. Except that this was so long ago that we didn’t call it architecture: if we called it anything, we called it analysis, design or Figuring Stuff Out.

I was working on a project for a company which insured other companies: the aim of the project was to replace letters we sent to our clients with automatically generated faxes (I told you that this was a long time ago).

Up until that point I had been a programmer and a programming team leader, and me and my team had written and changed code on demand to meet the needs of our users. But this was going to be a Project, and it was going to come with all of the paraphernalia that goes with a Project. (Our bosses had recently decided that we needed professional project management to control the work of the IT department: this was the beginning of the long period where we forgot all the disciplines and ways of working that were eventually reborn as Agile.) To start with, we were going to write a Project Definition Document, and it was my job to figure out how to put it together.

We had no template for a Project Definition Document, and I didn’t really know what one was supposed to look like. So, being a young programming team leader trying to solve a business problem with technology, I wrote down the things that seemed important to me: the mainframe would do this job, while the fax server would do this job; we would connect them across the network like this; we would store the fax data in a schema that looked like this; we would deal with failures and restarts like this. I really enjoyed it, and thought that, if this was what it meant to work on a proper Project, then maybe I should really aspire to be a Project Manager.

Of course, when we came to initiate the project, we found that we needed to figure out all sorts of other things I had taken for granted, such as what resources we needed, how much the project was going to cost, how we would report to our sponsors and so on. I can remember my boss gently telling me that, although I was going to lead the development, I was not going to be the Project Manager for this project. I can also remember my disappointment: surely I had defined all of the interesting things about the project.

I am pleased to say that the design worked, and the project was delivered on time and to budget as well (no thanks to me). But, because the architecture profession was not clearly defined then, it took me a long time to realise that I had been doing a good job of Solution Architecture and a bad job of Project Management, and an even longer time to realise that Solution Architecture, and other forms of technology architecture were what I really wanted to do.

Partly because of that, I spent a good chunk of my career doing jobs which were not related to architecture or design. I ran operations, I worked as a CIO, I tried to deliver projects and programmes, and I like to think that I was pretty good at most of it (whether I enjoyed it or not). However, I also learnt that I was much better whenever the work involved strategy, architecture or design (and I always enjoyed that work).

I would not change all of the different things I have done in my career: I think that to be successful as a Chief Architect, you have to have experienced what it is like to succeed or fail at the helm of a large programme, you have to have endure crunch times in development cycles, and you have to have been called out of bed in the early morning to deal with incidents. But I am also grateful that large enterprises and the software industry have figured out that architecture is a real job, and that there is a place for people like me to fit.

At HSBC we try to help people at all stages of their career figure out whether architecture could be a good fit for them. We run courses to train anyone who is interested in architecture fundamentals, as well as ongoing programmes of training, coaching and mentoring to help people move into the he profession. We run an architecture practice to provide an identity for architects and a community for them to belong to. And we follow the principles of Zang Jing Ge: technical excellence, communication mastery and leadership power.

A career as an architect is not a good fit for everybody, but we try to find those people for whom it is a good fit, and create a place where they can feel at home.