I’m not that interested in job titles. What a title implies always varies from organization to organization and rarely, if ever, tells the full story of what a person does in their role and day to day routines. I’ve had more than one person ask me what I do for work and what a solutions architect is. This is my attempt to explain what a solutions architect is and does based on my experiences.
A solutions architect is someone who solves problems by analyzing and understanding the desired outcome or end state, in order to create a solution that may be a new or modified process, configuration, or system which meets the needs, desires, and requirements of the organization.
Because AI is the hot thing, I asked ChatGPT this same question and this is what it gave me:
A Solutions Architect is a professional who specializes in designing and implementing solutions to complex business problems. They typically work in the field of information technology (IT) and are responsible for understanding the requirements of a project or organization and then designing an architecture that meets those needs.
The full response pleasantly surprised me to be honest, doing a fairly adequate job of describing the majority of my experience.
Requirement gathering and analysis? Check, attending presales calls and meetings with clients to get a deep sense of what they would like to achieve and then turning those notes and requirements into a solution that isn’t just something they need, but something they want. Those two ideas, needs and wants, can be very different at times.
Solution design + technical leadership? Yep! I’m combining these two. I feel you can’t really have one without the other. Once the solution architect has finished analyzing the client’s requirements, needs, and wants, they need to do the actual designing and architecting. The architect has to understand not just the client’s desires, but how different technologies and frameworks can be applied to meet their requirements which is where technical leadership enters the picture. Solution architecture is never a one size fits all thing.
An architect needs to understand the different technologies, products, and frameworks. They need to be able to communicate and explain why one solution is better than another, how the different pieces fit together, and why they made the choices they did. And, not just to the engineers who may be implementing the solution, but to non-technical business people as well. Those individuals don’t always have a technical background, so it is the architect’s responsibility to translate the technical to non-technical.
Another thing solution architects are usually responsible for is the integration and implementation of the solution. Do they need to do the implementation themselves? No, although sometimes they do. Sometimes they take on the role of project manager to ensure things are done in the correct order or make adjustments as the solution is built and deployed. Other times they only design the solution, writing out the specs, requirements, and how things should work in the end, and hand them over to entirely different time, only answering questions and clarifying as needed.
When creating a new solution, I found it useful to work through an entire implementation myself first. Documenting it from start to finish. Making notes of issues I encountered. Even if the product you are deploying comes from a trusted vendor or partner, it won’t always be straight forward the first few times, especially if it is newer. The functional differences between minor versions may be non-existent while the interface changed slightly. Perhaps the interface looks exactly the same, but underlying functionality has been modified somehow. I’ve run into licensing issues. I’ve run into undocumented “features” and bugs that change the order things need to be done. To be a good solution architect you need to know how the pieces fit together to helpful to those doing the implementation.
Performance optimization after a solution has been designed and implemented is another important responsibility of the solution architect. Depending on the solution, optimization can occur in different places and ways. One product I worked on, I reduced the overall deployment time from 90-120 days to less than 30. For another I worked on a solution that would have allowed our team to put multiple small customers on the same set of servers, rather than a separate set for each customer. Regardless of the product or solution, a good architect will look for ways to improve it, whether it is a process or changing something under the hood.
Another critical area solution architects focus on is security. A solution that creates or introduces unwanted risk for the client is less than ideal. While this risk can take different forms and may even be unavoidable, it is the responsibility of the architect to understand those risks, communicate them, and identify ways to mitigate them when possible. This is an area I find a lot of people ignore because they don’t want to the deep work of thinking about all the ways their solution can be abused or taken advantage of.
Finally, documentation and communication is a key responsibility. “No job is finished until the paperwork is done.” We always say things like “pics or it didn’t happen.” In solution architecture, documenting the solution and being able to communicate it to others is important. How can others implement the solution, troubleshoot and fix it, or make changes in the future if you don’t?