The makings of a good architect

Now that Devoxx Belgium 2019 has concluded and left everyone with a warm glow, it’s time to reflect on the best talks of this year’s edition. For me personally, Venkat Subramaniam‘s keynote talk on the qualities of a highly effective architect definitely tops the list.

For those who aspire to become a software architect or are determined to become a better architect than they already are, he delved into a number of points which in his view can make all the difference. And of course, he did this with his usual combination of wit, humor and insight. Notably, most of his points do not directly relate to technical skills, but can nevertheless have a substantial effect on your team’s technical productivity.

Let’s dive right in …

Be a mentor not a tormentor

To paraphrase Peter Parker’s Uncle Ben, with great experience comes the responsibility to guide other people. In our context, this means that you as an architect (or software craftsman) should use the authority you have over other people, not to chastise them for their lack of experience, but to help them grow in knowledge and skill. You’ll find yourself growing in the process.

Allow developers to figure it out

As a counterpoint to the previous one, when you yourself have plenty of experience while someone else is struggling with their task, it’s tempting to proverbially take over the steering wheel and hand them the solution to their problem. While this might speed things up in the short run, you’ll be preventing that other person from learning, which will cost you and your team time in the long run.

Guide, don’t dictate 

When you are handing out a task, don’t micromanage how the task should be solved. Otherwise, you may be depriving your team (and your architecture) of alternative approaches that could be better than the traditional solution that you, as the architect, would suggest.

Criticize ideas, not people

When brainstorming, someone may come up with an idea that is less than ideal, that won’t work, or that very obviously (to you at least) makes no sense. You could then tell that person that their idea is stupid. Or you could say we can’t do that because it wouldn’t work due to reasons A, B and C. In the first case, you put the blame at that person’s feet (ensuring that they won’t speak up again), while in the second you acknowledge the idea, approach it as a team, and increase your team’s average expertise. To put it differently, it should be safe to be honest.

Moreover, it’s very rare that there is just one ideal solution to a given problem, since software development is all about managing trade-offs. So don’t inherently favour your own idea because it worked in the past, since the current case might have different trade-offs. This may even include delegating the decision to someone else, who has more expertise related to the current context.

Practice collective ownership

It’s not uncommon for different people in your team to focus on particular parts of the code, while mostly disregarding other parts. This may seem more efficient because you’re building on individual expertise, but it leaves your project vulnerable to being crippled when a single person is e.g. on sick leave (the well-known bus factor). Furthermore, having a variety of viewpoints assessing all aspects of your code base will typically lead to higher quality code.

Prototypes beat any argument

Your team could lose a lot of time by following a technical direction that doesn’t work out. One approach to preventing this is by having many meetings before deciding on a direction. But then, your team could lose quite some time by having a lot of meetings, and still you wouldn’t have a strong guarantee that in practice the technical direction will work. Making a prototype will shortcut this whole process, by providing concrete evidence on whether the technical direction can work. In this regard, it’s important to timebox your efforts. That way, you’ll have time to explore more technical directions.

Gain domain expertise

It’s good to keep in mind that architectural solutions are not meant to be demonstrations of technical expertise, but instead should serve as solutions for your domain. Doing that without deep domain knowledge, or at least direct access to people with that knowledge, is near impossible. So first and foremost, focus on your domain rather than the technologies.

Learn to unlearn

Even if you have acquired a lot of technological expertise, that expertise will inherently have a limited shelf life. This means that the current best practice for any specific thing might (or even, very likely will) in the future no longer be the best approach. So prepare to change your mind.

Diversify your knowledge portfolio

In the same way that your architecture can benefit from new developments, so too can you improve it by being aware of a broad range of existing technologies and approaches. This does not mean that you should be an expert in all of these; being aware of their existence and their concepts will go a long way.

Lead by example

It’s useful, and even productive, to rely on varying strengths and skills in your team. It’s counterproductive however to delegate a task to someone who doesn’t know how to perform a given task, unless you yourself have a clear idea how it could be done. That way, you’ll at least be able to guide that team member to a solution. This also prevents you from asking for something that’s simply not possible (or doable within the available time).

Write code

With software architecture, as with most other things, the devil is in the details. And in software development those details for a large part live in the code. As such, if you as an architect deprive yourself of regular coding experience, you are depriving your architecture of vital details.

Evolve the architecture

The architecture for an application depends greatly on the information that is available. However, during the first stages of a project (or before it has even started), information is far from complete, typically lacks in details, and necessarily cannot include insights that are gained during the course of the project. As such, it makes little sense to create a full-fledged and final architectural design upfront. Instead, it pays to start with a general architecture based on the scant information that’s already available, and let the architecture evolve along the way, when more information and insight is gained.

Final remarks

Many of these points may seem obvious when presented on their own. That however makes it all the more surprising – and therefore important – that architects and organizations often struggle with applying these principles. So if it’s your ambition to become an architect, or to become a better one that you already are, always keep these principles in the forefront of your mind. And for added motivation, you can have a look at Venkat’s talk and the vibrant enthusiasm it offers!