The Ideal Solution Architect
What does an ideal solution architect look like?
Let’s start with a confession, or maybe an insight: like most software developers, I started calling myself software architect much too early in my career. To be honest, I think I have only qualified for that title the last 2 years, even though I still prefer software craftsman. 2 people have strongly influenced my understanding of what it means to be an architect: The first is Guido Dechamps, my former colleague at De Persgroep, one of the best architects I have met in a long time and someone who refuses to call himself architect. The other one is Stéphane Jans, the enterprise architect at De Persgroep, and a very good mentor.
I switched clients in 2017, and in my new role I’m the enterprise architect (brrr…), or rather town planner. We need to hire good solution architects now, so I’ve been thinking a lot about what it means to me to be a good software architect. Here’s what I came up with: the ideal software architect shares the qualities associated with these 5 people:
I don’t mean the Flemish Nonkel Bob who sang Vrolijke Vrienden, but Robert C. Martin of course, writer of the Clean Coder books. A software architect should be a coding architect. I believe an architect must be a very experienced developer, with a lot of attention to clean design and clean code. One of her duties should be coaching developers in writing clean, maintainable code. On the other hand, the architect should not focus on implementation details, such as frameworks and libraries. Piling frameworks on top of each other is not architecture.
Eric Evans is the founder of Domain Language and the author of Domain-Driven Design. I have known about DDD for a very long time (I read his book in 2004 or 2005) but nevertheless I got stuck in lasagna architecture way too long. Thanks to the rising popularity of microservices and the relentless rambling of Guido about ubiquitous language and bounded contexts, I realised the usefulness of DDD again. I consider it the most essential tool an architect should have.
The architect doesn’t need to be the smartest person on the planet, but when I say Einstein I refer to 2 of his many famous quotes.
Everything must be made as simple as possible. But not simpler.
The job description of an architect is quite straightforward: given the functional requirements, the quality attribute requirements and the constraints, design the most efficient (the simplest) solution that satisfies all or most of them. Usually there will be tradeoffs that must be made, and usually 2 constraints are time and money. So it’s crucial to be able to identify the essence of the problem. Knowing what not to build is just as important as knowing what to build. If the requirement is that 5 people in the company need to be able to access a report once a week, it’s not necessary to build a mobile app with a backend that can scale to millions of users. An ODBC connection to a database might be enough.
The true sign of intelligence is not knowledge but imagination
If you’re a consultant or you’ve switched jobs a few times, no doubt you’ve had to endure one of those tests where you’re expected to know details about a language or an API. I find those absolutely useless. When you need to know those things, look them up. It’s much more important that you are able to think creatively, that you can come to a solution when no one has written a blog post about it yet.
A good architect always looks for the root cause of everything. When you encounter a problem, it’s not enough to fix the immediate cause. You must ask the 5 whys to get to the root cause and fix that. The same applies to a question. Let’s take the example above. Suppose a business analist asks for a mobile application for exposing some data. Asking the 5 whys might reveal that the root cause for this question is the fact that someone in the company needs a report every week. Finding that root cause could save the company a lot of money.
At least in an agile organisation, architecture has as much to do with people as it does with technology. An architect should be a coach, a mentor, a guide. The architect should belong to the supporting cast of the development teams. She should help the developers write clean code, help decide what to build and how, help asking the right questions. Ego has no place in that process, it will only get in the way. Use objective criteria to make decisions, not opinions or authority. Don’t tell people what to do, but show them what they could do.
What do you think? Is this a sensible combination of qualities, or is it absolutely impossible to have them all? I know I still have a long way to go before I’m the ideal architect, but it’s good to have goals I guess.