Career Advancement: The Highly Sought After Solutions Architect Role

Recently I attained the title of Solutions Architect in my career, which is exactly what I wanted to be when I embarked on this career path 16 years ago. Even though I’ve basically been doing the role of a Solutions Architect for a few years now, obtaining the official title and the official responsibilities has been such an incredible feeling for me. So what is a Solutions Architect, and what do we do in the field of software engineering and product development?

First some background. At most point in a software engineer’s career, a choice must be made on what path to pursue, and this usually happens around the time a developer hits the Sr. Developer waypoint: Diverge and go into management, or continue down the technical path, towards the architect end of the spectrum. In a nutshell, Solutions Architects are generally the most senior technical individuals within the organization. The next level up would be an Enterprise Architect, but for the most part, EA’s are more tasked with strategy based decisions (though are still usually highly technical individuals). Most Solutions Architects have around 15 years of experience in the field, and have both broad scope, and extreme technical depth as well.

First, where does the Solutions Architect sit within the overall organizational chart? A Solutions Architect can be thought of as a bridge between the “business” side of the organization, and the technical side. This illustration isn’t meant to be an end all be all, but it’s a decent rough approximation of the role of a Solutions Architect as it relates to their overall function within the organization.

What is a Solution Architect?

The essence of the Solution Architect (SA) role is the conversion of the requirements into an architecture and design that will become the blueprint for the solution being created. This conversion is based largely upon the previous design patterns that the SA has been involved with in the past through reading and staying abreast of the latest techniques, or through personal experience.

It is this conversion part of the role - the role of the SA -that most often is underestimated in its complexity. Just as the ability of the Functional Analyst to create a requirements document is one part science and wrote procedure so is the creation of the architecture. The rest, however, is an art form. Creating effective architectures to create a solution requires the careful balance of dozens of development concepts ranging from "Keep it Simple Stupid" to "Fail to Safe".

In the process of converting requirements to an architecture there are often parts of the SA's role which seem out of place. For instance, there is often a fair amount of research that happens during this phase. The research may be targeted at testing a technology that will become critical to the architecture. For instance, the SA may test to see if USB or serial port access is available from Java if there's a need to read a device without downloading software. This process can either be done alone or depending upon the size and velocity of the project can be delegated to a development lead. 

In addition to research on technologies and approaches critical to the architecture, there is often a review of patterns that might be useful to the architecture. Patterns are previously described and validated approaches that can be used to create portions of the solution. Patterns are released through research and can come from places such as Microsoft's software development libraries. Reviewing the pattern allows the architect to refresh their memory on the details of the pattern and to evaluate what additional guidance they will have to provide if they choose to use the pattern.

The final component to the role of solution architect is the motivation and guidance of the development leads. Development leaders need to buy into and accept the architecture, to know how the pieces will fit together at a high level. They must also see the art portion of the architecture to get an appreciation of the subtle nuances of their portion of the architecture. It's the art portion of the architecture that makes it elegant. That elegance helps to maintain cohesion between various parts of the design and encourages simplicity. It is necessary for the lower level design and approach to match the higher-level architecture for the solution to be cohesive. Once the development leader has internalized their portion of the architecture the SA must continuously motivate and reinforce the good work that is being done. They must continue to motivate the Developer Lead(s) to push through tough issues and create the solution.

The Good, the Bad, and the Ugly


  • Good: Key, High-Value Position - The SA is a key role and one which can provide immense value if done correctly. This generally means a healthy salary.
  • Good: An SA is likely to get to interact with many of the key members of the development team as well as key members of the user community. This makes it a very visible position.
  • Bad: Hard to keep up - Being a SA means keeping up to date on a wide variety of new techniques, patterns, and tools. The effort to keep up can be very draining at times.
  • Bad: Difficult to get right - The role requires balancing so many factors that it's difficult to get right. In other words, it's easy to fail.
  • Ugly: Requirements - Although a good Functional Analyst can provide great requirements a moderately skilled one may not. The difficulty is that most people, including seasoned SAs, have trouble spotting bad requirements documents before it's too late. The SA must always have to consider that the requirements may require the SA to do a lot more research and legwork into what the client really needs.
  • Ugly: If a project fails, the SA is at the top of the list for people to blame.