What the heck does a solution architect do anyway?

In this post I’ll look at what it means to be a solution architect. I am not going to provide a formal definition you can hang on a wall or a position description to give to an employee, rather, I’ll look at my experiences and the kinds of issues I often get asked to help out with.  

First let’s look at what is meant by solution architecture. TOGAF describes solution architecture as ‘A description of a discrete and focused business operation or activity and how IS/IT supports that operation’. So that limits the scope to addressing the IT needs of a specific business problem or capability, usually through implementation of a single project. In my experience, the most common scenario I get faced with relates to implementing a new line of business application.  

Next let’s clarify what is meant by architecture and architecting. This has primarily to do with the level of abstraction at which you look at a particular solution. Architects are known for taking the ’50,000 foot view’. While 50,000 feet is probably straying into the realms of Enterprise Architecture, it is the level of detail at which a solution architect operates that differentiates them from the other IT specialists involved in a project. The solution architect is concerned about the technical decisions being made regarding the solution and how they impact the business outcomes. Most of my focus tends to be on weeding out and addressing the non functional aspects of the solution or identify requirements that require some big choices to be made about the technology being used (otherwise known as the architecturally significant requirements).

So the solution architect assumes primary responsibly for making some of the bigger decisions around the nature of the solution. Throughout a project I am making choices (or providing recommendations) that impact the selection and use of technology, such as should we build or buy a solution, what technology platform should we use, how will the solution scale to meet expected user demand, how should the solution components be deployed, and how will the solution integrate with the other systems we have. This all leads to defining and establishing the solution architecture, starting from an initial conceptual ‘vision’ and evolving into a more concrete software architecture specification.

A major part of defining the solution architecture is understanding and addressing the concerns of the key stakeholders. I have found that stakeholders and their needs can be roughly summarised as: (1) enabling greater productivity or lowering cost (senior management), (2) streamlining day to day activities (business users) and (3) providing a secure, stable and supportable environment (IT Support).

Being an architect requires the ability to balance everyone’s needs and implement a solution that obtains the desired business outcome. You may be thinking that architecting involves a lot of verbose modelling and documentation, but in reality I find that I spend most of time providing technical leadership. That is, providing guidance to the various stakeholders about issues relating to the solution being implemented. This may cover a wide range of topics from the technical design, the development methodology being used, to assessing the business impact certain technical choices are likely to have.

Providing effective technical leadership requires a broad understanding of information technology and solution delivery. Leadership entails working across the business, applications and infrastructure domains. This is not to say that a solution architect is a ‘jack of all trades- master of none’ - to the contrary, it is that architect’s deep technical knowledge that the project stakeholders rely upon to make informed decisions. What’s key is the architect’s ability to apply their technical knowledge and experience to solving broader, project wide issues.

Finally, it is important to understand that a solution architect need not be a formal role but that decisions about architecture will be always made, either wittingly or unwittingly. Tradeoffs between functionality, system qualities and costs cannot be avoided. Whether it is a developer choosing an ORM tool or a manager choosing a CRM product, there is always an impact to the quality of the outcome.