What Makes a Great Solution Architect?

I’ve worked with quite a few solution architects over the years, from many different companies in many different sectors/verticals. I’ve been an architect myself in one form or another for the last 10 years too. It takes time to become a solid architect, I really feel that you can’t just become one overnight.

If you’re early on in your technical career though and a move into architecture sounds like the sort of thing that you’re interested in. Read on. I’ve tried to describe, from someone who’s been in the industry a wee while (25 years), what are the most important skills for this role. I hope this helps.

A solution architect generally does not have a wall full of qualifications proving they know how to ‘code in a proper way’ or ‘understand architectural patterns’ as this proves nothing concrete regarding their skills. When it comes to someone directing how business requirements are translated into a robust technical solution, one that supports strategic growth, there is no substitute for experience. And experience is full of failure.

In my view, a solution architect must understand the business domain first and foremost but also bring a wide technical understanding to any business problem (be a mile wide and more than an inch deep). Experience in a variety of technical roles is the key.

Experience comes from spending time in multiple areas of technology. Seeing technology from different perspectives and being able to represent these perspectives to non-technical folk. This experience should provide someone looking to become a solution architect the ability to formulate a toolbox of technical lines of questioning, considerations, well-proven design strategies and patterns, and a way of seeing a solution from a holistic perspective.

For me, this experience should come from spending time in more than two of the following technical fields:

• Network Infrastructure: It’s important that an architect knows how the network hangs together. How machines communicate with each other and are able to use the most common OS command line/shell tools to work on remote servers and detect problems on the network. An architect should be familiar with the OSI model and the communication protocols that operate at each layer of the stack. Whilst a lot of this is abstracted away by the cloud and its virtual networks, having this knowledge in your toolbox still holds value.
• Security: This is a cross-cutting concern that’s ever-present in all areas of technology. Securing resources and controlling access to those resources are present in all other areas in this list. Understanding encryption, in transit, and at rest and testing for vulnerabilities in a systems design are crucial chunks of knowledge for the solution architect.
• Cloud Technologies: A lot of companies are in the midst of cloud migrations. It’s the future. It also means that more and more organisations are moving from server-based technologies to serverless solutions offered by cloud vendors. More and more infrastructure provisioning is declarative code, blurring the lines between software engineering and infrastructure deployment and support. Getting familiar with areas of at least one major cloud provider (AWS, Azure, etc) is a must. Consider delving into the compute, storage, identity & access management, governance, and networking services of said provider.
• Database Administration or Design: Almost all applications that a solution architect will work with will have a persistent data store of some sort. That could be relational, document-based, in memory, etc. Understanding SQL is a no-brainer. You simply cannot call yourself a solution architect if you don’t know how to SELECT from an INNER JOIN. There are also plenty of data vault/data warehouse/data lake solutions out there.
• Software Design & Development: Yes, that means that as an architect, you should have experience not just writing code, but designing robust applications and seeing those designs through the entire first cycle (ideation to deployment). This means that from a set of business requirements, architectural drivers, and design constraints you’re able to formulate a high-level solution direction and present it to the business and engineering teams. This must include a focus not only on the solution elements and behaviour but also the operational quality attributes. Its ability to scale, handle load, remain available through fault tolerance mechanisms, accommodate transient faults, etc

To be clear though, these are the areas of technical expertise and cover only half of the story.

The other half, and an area where a lot of deeply technical people fall down, is your ability to communicate your ideas and your powers of persuasion. Both in verbal and written forms.

Nobody likes a ‘know-it-all’ and everyone wants to feel like their ideas and input matter. People you work with want to be heard. A solution architect has to be able to listen to business stakeholders and really understand what it is they want to achieve (not always clear through requirements alone). The architect has to listen to key stakeholder desires and be a sounding board for solution ideas and concerns from engineering staff. No engineer wants to be handed a pre-designed high-level solution and be told to get on with it. Buy-in from engineers at the earliest possible stage is vita for solution alignment and support.

The solution architect must also be able to facilitate team disagreements and where necessary make final decisions. Design by committee is not what you want.

These are the qualities and skills that I personally believe all good solution architects I have met have. I am certainly no barometer for assessing the role but have worked with enough competent architects in my years in IT to know what skills are important. Almost all of them do not hold a lot of qualifications in the technical subjects but experience and a strategic/practical/pragmatic mindset show clearly.

To be able to conceptualise, abstract reality, direct solution development, look at every problem with the architecture in mind, provide the why, what, and how in any task arising from the development project, and support the developers are skills that an architect should hold.

My personal favourite skill observed however is the modesty of some architects. When you sit in a meeting with them, you realize their experience not from them explicitly demonstrating their knowledge at every turn, but because they’re a known guru of the business domain, they have a constant want for knowledge and that shows in their modest approach. They clearly know more than they show and that, to me, is one of the greatest qualities an architect can have. I hope to be that architect one day.