The skills you need to be a successful solution architect

Author: Greg Fullard, Published: 2021-05-12

In this article I propose an easy-to-understand framework for defining the skills needed to be a successful solution architect. The four high-level skills that make up the framework are:

1. Knowledge of, and experience with, the tools and methods used to produce design artifacts for software-intensive solutions.
2. Fundamental understanding of the implementation landscape, ensuring that design decisions are technically sound.
3. Communication and negotiation skills that adapt to business and technical contexts, as required by the audience.
4. Leadership skills to guide the implementation team when barriers are encountered.

This particular combination of skills is very rare, which is why good architects are so difficult to find. And let's be honest, everybody has room to improve somewhere.

In the real world I've noticed two particular patterns with the architects I've worked with:

Pattern 1: Experienced architects allow themselves to get separated from actual code for too long. As a result, their understanding of newer technologies slowly deteriorate. This is especially true about nitty-gritty details, and unfortunately, the devil often hides in the details.

Pattern 2: Inexperienced architects, who may have stepped up from a lead developer role fairly recently, have very strong technical skills. However, they are not familiar with the methods and tools used to present design artifacts. As a result, their design artifacts require significant subjective interpretation. These are the typical "blocks-and-lines" architectures that we see so often.

In an ideal world, we would all be able to objectively assess our own skills and work towards addressing our weaknesses. The rest of this article will dig a little bit deeper on each of these essential skill sets.

So let's jump in...

For many years, the word "Architect" has featured very prominently in technology job titles. It comes in many forms:

• Enterprise Architect
• Technology Architect
• Application Architect
• Data Architect
• Business Architect
• Solution Architect
• etc

It should be fairly obvious that these variations on the term "Architect" all emphasize that these job roles are focused on designing something, rather than actually building or creating it. This is, unsurprisingly, similar to a traditional architect who designs buildings, instead of actually building them. But the question is: What is the SOMETHING that's being designed?

We could roughly guess that an "Enterprise Architect" designs enterprises, a "Technology Architect" designs technology infrastructure, an "Application Architect" designs applications, etc.

But this is a bit too vague for me.

Let's follow John Zachman's lead and dig a little bit deeper into the world of a classical (bricks-and-mortar) architect: Classical architects produce blueprints that are used to build structures. Each architect does not use their own symbols and layout for a blueprint, instead, they use a set of agreed standards developed over many generations.

The key point here is that the blueprints produced by an architect are based on a set of agreed standards that the construction industry has adopted over many generations. These standards ensure that the blueprints can be handed over to a builder, ANY builder, without having to explain what they mean or how they should be interpreted. The builder would then be able to construct the building using the blueprints mostly, but with occasional interaction with the architect.

This is all a long-winded way of saying that classical architects have a set of skills focussed on the creation of design artifacts (blueprints) that can be interpreted universally. These skills are quite different from the skills of a builder, i.e. they are specific to the job of being an architect, not to construction generally.

This aspect of the classical architect's work can be applied almost directly to the world of solution architecture:

A solution architect must be able to produce a set of design artifacts that can be used by an implementation team to build a software-intensive solution.

Unfortunately, the tech industry has not been particularly successful at establishing standards for such blueprints. There have been many, MANY attempts though. UML is probably the most comprehensive attempt, but (for various reasons) is has fallen out of favour lately.

Furthermore, solution blueprints are much more than just UML diagrams. The Zachman Framework actually gives us a nice way to structure all the different viewpoints that may exist for a comprehensive set of blueprints. Additionally there are processes that apply specifically to the discipline of design work. The best known of these is the TOGAF Architecture development method. Although it does not directly apply to the work of solution architecture, it serves as a good reference of what methods of architecture work entail.

So let's put a pin in that, and call it the first core skill set needed to be a solution architect is:

Knowledge and experience with the tools and methods used to produce design artifacts for software-intensive solutions.

So, onto the next one...

I've often spoken to people in the construction industry who complain that "Visionary Architects" often come up with designs that might be visually striking, but that are not structurally feasible. In fact, the construction industry has put controls in place for this problem by pairing an architect with another professional: The Structural Engineer. Most design plans that are submitted by an architect require "sign-off" from an engineer of some sort.

This engineer supports the construction team to ensure the design is structurally viable. They are able to do this, because they have an in-depth understanding of the materials used for construction.

In the world of software development, there are many design decisions taken on a daily basis. These decisions often have a significant and long-term effect on the product being built. Good design decisions require a fundamental understanding of the implementation landscape. So in this sense, the Solution Architect is a bit more like a structural engineer from brick-and-mortar construction.

The problem with the software world is that things change rapidly and, if we're being honest, it is difficult for an architect to be intimately familiar with the inner workings of all the technologies involved in a project. So the architect needs to have the humility to engage domain-specific technical experts to offer guidance regarding design decisions. Additionally, it is imperative that such decisions are documented for future reference (but that's a topic for another day)

Even though the solution architect can (and should) engage technical experts in some areas, the architect cannot simply be a "traffic-cop" for a collection of technical experts. The Solution Architect must maintain a solid understanding of the solution being built, so that the advice from domain experts can be evaluated in context. This is a long way of saying that the architect remains accountable for the design decisions and must always be a respected technical practitioner.

Let's wrap that one in a bow as the second core skill set needed to be a solution architect:

Fundamental understanding of the implementation landscape, ensuring that design decisions are technically sound.

Onwards and upwards..

For most large-scale software projects, there are many stakeholders. These stakeholders can simplistically be split into two groups: Those who understand and care about how the technology works, and those who couldn't care less, as long as it works. Let's refer to them as the "Tech People" and the "Business People"

"Tech People" and "Business People" really struggle to understand each other. And the reason is not simply due to their language and experience. There is often deep-rooted (but concealed) animosity at play as well. The great satirical YouTube video "The Expert" explores this topic in hilarious fashion. (https://www.youtube.com/watch?v=BKorP55Aqvg)

The solution architect is generally the communication bridge between these two groups, which requires the ability to "translate" critical information into a language that can be understood (and trusted) by team members from both sides of the divide. This is a tricky prospect, and is often when experience is the only real teacher.

Even though communication may come naturally to some people, effectively explaining complex topics depends on a thorough understanding of the topic at hand. In Einstein's famous words: "If you can't explain it simply, you don't understand it well enough.". Which again highlights the need for the architect to be a technical expert themselves.

The architect also needs to be politically astute in such communications, because it is easy (but very dangerous) to simply tell people what they want to hear. In fact, the architect's message is often the very thing their audience does NOT want to hear. This requires the ability to both explain AND convince.

So we've arrived at the third core skill set needed to be a solution architect:

Communication and negotiation skills that adapt to business and technical contexts, as required by the audience.

These first three core skill sets are finally brought together during the execution stage of a project where the architect plays a significant leadership role. As mentioned earlier, the solution architect is where "the buck stops" for design decisions.

As a result, when the implementation team faces technical barriers, the architect must be ready and able to assist in the resolution of issues. Sometimes this includes rolling up their sleeves to get some complex code written, other times it involves constructing skeleton implementations that the team can flesh out. And very often it may just be to serve as an arbitrator of conflicting implementation options.

Let's just list that one explicitly:

Leadership skills to guide the implementation team when barriers are encountered.

So there we have it, 4 core skill sets needed to be a successful solution architect.

Of course, each one of these is complex in its own right, but I feel it's important to be aware of them all. This enables careful self-assessment and ultimately professional growth.