Are you a solution architect or a problem architect?

I am often asked what the difference is between an enterprise architect and a solution architect. My answer (which I realise not everybody will agree with) is that they are different in scope but not in kind.

I believe that, whatever kind of architect you are, whatever tools, frameworks and models you use, you need to do three fundamental things: set direction (figure out where we should be going); make decisions (figure out how we get there); and solve problems (figure out how to remove obstacles encountered along the way). The main difference, therefore, between an enterprise architect and a solution architect is the scope of the direction they set, the decisions they make and the problems they solve. I’m privileged to set direction, make decisions and solve problems at an enterprise level, but I am doing something very similar to a solution architect setting direction, making decisions and solving problems for the project or team they work in. (And, of course, we should do all these things while demonstrating the characteristics of Zang Jing Ge: technical excellence; communication mastery; and leadership power.)

But this doesn’t mean that all architects are the same. I think that there is a a more interesting distinction between architects, and that’s the distinction between solution architects and problem architects.

I’m sure that you know what a solution architect is, and probably know someone (or are someone) with the job title of ‘solution architect’.

I doubt that you know anyone with the job title of ‘problem architect’, but I bet that you know what I mean when I use the phrase.

The problem architect is the person who doesn’t just see the glass as half-empty, and who doesn’t even see the glass as over-provisioned. They’re the person who points out that you could break the glass and cut yourself, that a cup with a lid would be safer, and who ordered water anyway? They are the person who sees the challenges and flaws in every situation; the person who knows why we can’t, but offers little insight into how we can.

So, I guess that means that we don’t want to be like the problem architect.

Well . . . as usual, it’s not that simple.

First, the problem architect is a caricature. While I’ve had many frustrating conversations with architects who delighted in telling me why something wouldn’t work, why it failed every time we tried it before, and why we’d be better off if we didn’t even bother, all those architects eventually said something like, ‘But . . . maybe we should try doing it this way . . .’, and we turned the corner into solutions. It’s hard to find genuinely relentless negativity.

Second, no matter how positive we are, how decisive and solution oriented we believe ourselves to be, we all need to embrace our inner problem architect from time to time. I freely admit to being on the optimistic side of the architecture spectrum, but have found over many years that I need to temper my enthusiasm to do the new thing by thinking through what could go wrong with the new thing. That way, if I still think that the new thing is the right thing to do, at least I can do it safely.

It’s important to solve problems, but you can’t solve problems if you don’t know what they are. Cultivating our inner problem architect, taking the sideways view, anticipating failure modes, planning for a rainy day, understanding tolerances, stresses and breaking points are all part of our job.

So, there isn’t really a distinction between solution architects and problem architects: they are just different personas and modes of thought we can adopt, and people tend to have a natural inclination towards one or the other.

If you’re a solution architect with a sunny disposition and a carefree attitude, remember to check in regularly with the problem architect inside you.

And if you’re a solution architect whose problem architect lives very near the surface, remember that at some point you need to start finding solutions to all those problems you’ve pointed out.

And if you’re not an architect at all, and sometimes feel frustrated by them, remember that a good solution architect helps you as much by finding problems as finding solutions - as long as they do both. 

Previous
Previous

Do you know your system’s hierarchy of needs?

Next
Next

A technology architect’s guide to humans part four: they don’t know what you do all day (and you don’t know what they do)