If you’re a technology architect, you can find something interesting in every job

Don’t believe them when they tell you you’ve got the boring project.

I remember when I had just started a new job as an architect, and was given the project that nobody else wanted to work on: to replace the scanning solutions in the correspondence handling centre. When I was given the project, I was told that it was a boring job: bulk scanners were not seen as cutting edge technology, and paper correspondence felt very old fashioned. It was a long way from digital customer experience.

Fortunately, as I had just joined the company, I was not in a position to do as many other architects had done, and find themselves a project that was more ugent, or at least which seemed more interesting.

So, I got in my car and drove to the correspondence handling centre, on what turned out to be the first day of a project that was not always easy, but was always interesting.

During that day, I got to learn about the logistics and mechanics of large scale paper handling, about what happens when you need to turn thousands of letters into data which can be fed to systems or processed by people. I got to see the practical challenges of handling the mail, of dealing with breakdowns in the moving machinery - even the security measures that were taken to ensure that all of the mail was safe, and that it did not contain any malicious, unexpected content. And, of course, I got to meet the people who worked in the centre, to see what problems they were facing, and to understand the goals and objectives of this project.

I learnt a lot about correspondence that day but, more importantly, I also learnt that if you go to see how the work is actually done, there need be no such thing as a boring project, and everybody’s job is interesting. I think that there are a few reasons why this is the case.

First, and most obviously, seeing how work is done means that you get to learn something new, and all technology architects should be eager to learn something new. (And if you think that you know everything about how a piece of work is done, and that there is nothing to learn, go look again. I bet you will find something that surprises you.)

Second, the thing that you are learning about is something that technology architects usually care about: how things work. And,when we spend time with other people and see how they do their jobs, we don’t just get to see how things are supposed to work, but how they actually work, with all the messy workarounds and compromises that don’t show up in our models.

Third, you get to meet the people whose work and lives will be changed by the architecture that you are defining. And there is no better motivator to design well than to meet the people who are going to live with that design.

Finally, you get to deploy your architecture superpowers, and to translate the everyday environment and the work that goes on within it into architectural terms. I had to do this on my correspondence handling project: to learn to think of the problem as a series of queues, events and data flows, as well as a physical combination of human action, moving machinery, computer hardware and software - all of which could go wrong in its own way, and which had its own way of dealing with problems.

This is one of the most important techniques for architects to master: to translate the real world into architectural terms. Every opportunity to practice it is a gift. If you want a great example, try reading chapter 17 of Gregor Hohpe’s book The Software Architect Elevator: ‘Your Coffee Shop Doesn’t Use Two-Phase Commit.’

When we combine this special way of looking at the world with an opportunity to learn something new, to understand how things really work, and to meet the people whose lives will be touched by the architectures we define, we can see that technology architects are not only blessed with interesting jobs, but blessed to find everybody else’s job interesting.