The Myth of Architect as Chess Master

January 6th 2020

For software architects (especially at bigger organizations), it's not that uncommon to get a request like this from a manager or director:

There's this tough problem the developers have been struggling with for weeks (performance, or scalability, or whatever), so can you quickly look at it and show them the best practice, quick fix, etc. that solves it all?

Reasonable ask? No, not really. The expectation is that the architect is a chess master. It's just like that movie we've all seen. There's the young or disheveled or [insert surprising adjective] savant who, walking through central park mid-dialogue with someone else, glances for a nano-second at a pair playing chess and declares "bishop to queen 4, check mate" and then keeps walking. Minds blown.

But why shouldn't an architect be able to size things up as quickly as a chess master? Both an architect and a chess master have accumulated thousands of hours of experience in their disciplines. Both are analyzing current states of a "board" and then evaluating the trade-offs of different next moves or options.

The difference is that chess masters are always playing the exact same game. Rooks always go forward-backward and side-to-side. Bishops always move on diagonals. And because the rules don't ever change, it's easier to take a mental snapshot of a board and instantly pattern match back to some other past experience - e.g. "this is exactly like the game I played/studied four months ago".

Any given software system, on the other hand, may look the same as countless others you've worked on in the past - I mean, hey, it's all ifs and elses, classes and objects, REST and SOAP calls, etc. - but just a little bit below the surface we realize the pieces and the rules are very different. In my system the rook can jump the first 2 squares but in yours the queen has 3 lives. Each system we visit has different intricacies and rules we must learn anew.

This immense variability and complexity is baked into even the simplest software system - it's in the business domain, in the frameworks/techologies used, and in the implementation itself - and so it takes time to grok all these nuances and details before we can build the right mental picture that allows us to reason about it effectively. Even for those with years of experience this is true. Sure there are common patterns, styles, tools, specifications, etc. that, if you know them, can help in terms of more quickly sizing up a system, but almost never do these alone allow you to pull off that type of chess savant "mate in one" mastery. Real-world software solutions take time. Architecture takes time.

This is why I think it's important to think about software architecture as a process and not a destination. Being an architect (or playing the role of an architect) doesn't mean simply divining the "right" solution or recommendation and handing it off to the developers. Anyone can whip up a bunch of boxes and lines that seem plausible, but do they really apply to the game of "chess" you're playing now, or the one from your past project or from that popular blog post? To truly know the right next "move" requires first understanding the rules of the game you're in. What are the business drivers, risks, technical constraints, legacy components, integrations, possible options, trade-offs, and so on. These are the details that take time to identify, clarify, and understand, and they are subtly (and sometimes not so subtly) different from project to project and organization to organization.

In my opinion, the expectation for the architect should be to setup the framework or process by which good architectural "moves" are made (Michael Keeling describes this well in Design It). Thinking an architect is going to stroll into a meeting and find a check mate lurking in plain site is sadly unrealistic.

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (13)
January 10, 2020
💯 — this is especially difficult for non-technical folks to fully grok or understand.

have any thoughts on how to level-up non-technical leader(ship)?
January 13, 2020
@John - thanks. I agree - very often it's the non-technical folks who tend to believe the architect is the chess master, and have an expectation that they can/should be able to find quick/easy solutions to hard/complex problems.

In terms of non-technical leadership, that's a good question. I think (and others have written about this) an "empathy" mindset is an important asset to architects - making sure to see things from the point of view of other stakeholders, and appreciate their goals and concerns. Also, it's helpful for architects to not see *themselves* as chess masters who have all the answers, but rather just more experienced/travelled technical leaders who can help facilitate better solutions from the team. Some of this is just personality...but I think some can be cultivated in an organization. In Sam Newman's "Microservices" book, he has a great initial chapter about seeing the architect as a city planner. Anyway, not sure if that's helpful :)...but thanks for the comment.
January 23, 2020
> What are the business drivers, risks, technical constraints, legacy components, integrations, possible options, trade-offs, and so on.

Absolutely, this!

There's also a tendency - to over-complicate and over-engineer, which probably is the result of a subconscious drive to value enriching ones' resume over driving business value. This just gets aided by the onslaught of overwhelming choices in terms of tools for various shades of a problem.

A true architect will be very mindful of the vagaries - mostly present, and build a well-proven process that could be used to adapt to the uncertainities of the future.

As said by the champions, "the process is the product/platform".

Thanks for a good post!
Carlos Balbuena
January 23, 2020
I think problem is that there is not a consensus of what the sw architect does.
January 24, 2020
Thanks @raghava and @Carlos! Agreed on both accounts. As an industry, we do tend to favor flashy but complicated solutions for the sake of chasing the next new thing. Also, agree that the role of architect is not always clear.
Paulo Merson
January 28, 2020
Great post! I guess playing architect is more like playing Catan. There's luck and a lot of negotiation for resources involved, and each time you play the board and what you end up building are completely different. Oh, and often times you don't meet the deadline (someone else get 10 points before you do). :^)
January 30, 2020
Hey @Paulo. Haha - love the analogy. Exactly!
February 17, 2020
I couldn't agree less. I think the request to the architect is perfectly a perfectly reasonable one, or at least the first 3/4 is.

The question is what you consider a software architect to be. If they are an architecture astronaut, then this request is unreasonable, because clearly they're not capable of solving the problem. However architecture astronauts are to be avoided.

If you consider the role of the architect to be both deep and wide in technology, then this is a very reasonable request. The depth means that they can be strong enough in the code to step down to that level. The width means they can understand the context applications are running under.

A good architect can see patterns from past systems / platforms and apply them to the current situation. They can cut through to see the real problem. So it would not be surprising to see a good architect look at a problem others have been struggling with some time and put their finger on the problem.

That said, clearly best practice is something different that can't just be applied quickly.
February 17, 2020
Amazingly true, relevant, and well-written
Mateusz M.
February 18, 2020
"Searching for Bobby Fischer" - great movie! :)
February 18, 2020
You should mention that chess is a "perfect information" game.

You see the entire board at once, all the pieces, all the positions - there is no hidden variables, nothing vague, nothing that can't be seen right away.

Try find a chess master who can tell you the perfect move, if you show them only half of the board!

Maybe being a software "chess master" and seeing the best next move by just looking at a current situation, would not seem so far fetched - if the architect was presented with perfect information on the project - as in everything there is to know about it.
February 25, 2020
@David - I see where you're going with your point, but I believe the argument Ben is trying to drive home here is subtly implied with his use of the words "quick" and "all" within the hypothetical quote.

I agree with you that a truly techincally-savvy architect should find "...look at it [the problem]..." and " them [the tech team] the best practice..." reasonable requests. It seems Ben is trying to explain that when those asks are applied to a crazy short timeline and/or to a glaringly large architectural issue, management clearly doesn't understand the role of the architect versus their role in understanding team contributions/culture.

@Ben - do you find this problem to be more pervasive in your contracting work or while being an employee at an org?
February 27, 2020
@David - thanks. Where I think we agree is that a good architect should be able to provide a development team with a fresh, experience-based perspective that helps them through a given problem. We may disagree on a couple things though.

First, I don't think the architect is (or can be) *both* broad and deep. They/we are not computing super heroes. Instead, architects strive to know a lot of things, but at the sacrifice of depth. That's not to say they can't go deep in particular areas when the need arises, but when they do, they're making a conscious trade-off - e.g. "if I spend this week heads-down writing/debugging code, I'm not spending that time learning/understanding bigger picture things".

Second, I think your assumption might be that developers are necessarily junior, and the architect is the best/only one to apply past lessons to new situations. That's not my experience. Senior developers understand their problems quite well, and it's not my job as an architect to spot the "thing" they didn't see (this would be presumptuous), but instead to help identify options, weigh trade-offs, shed light on business drivers, make connections to external teams/SMEs, and ultimately make a sound decision.

In any case, I appreciate the comment!

@Me - really interesting point about perfect information!

@Steebe - thanks buddy. :) Yes...I do get this a bit in my new life as independent consultant. There is sometimes an expectation that I can come in and spot "the solution". In fact, I was once invited to what I thought was an intro meeting, but was really 5 engineers in a room thinking that in an hour I could solve their performance/scalability issues. There is no easy button.