Who Needs a Solution Architect?

Application architecture is typically a lot simpler than this

Recently I have had a few job interviews and what I noticed is that there is a good deal of confusion about what a 'solution architect' is and what a person in that role does or should do. So I decided to do a bit of a research on the concept and also give it some thought myself. Here are my conclusions.

Definition Or An Attempt At One

'Solution architect' is a relatively new construct or at least it's been in wider circulation only recently. I don't remember many solution architect jobs just a few years back when I was looking for a job. It seems the concept and the job title has come in vogue only in the last few years. If one googles 'solution architect' a number of descriptions come up none are very useful or satisfactory. Let's look at one from TOGAF (The Open Group Architecture Framework) which is the golden standard for IT architecture. The Open Group doesn't officially recognize 'solution architect' as a specific role in its matrix of IT roles and skills but, interestingly enough, it does have a definition for 'solution architecture'. The definition states that 'solution architecture' is 'A description of a discrete and focused business operation or activity and how IS/IT supports that operation' as listed in Wikipedia.

The TOGAF definition is simple but very generic, it basically states that solution architecture is how the IT system supporting the business capability works. That's like saying 'it is what it is'. Also this definition is a passive description of the 'architecture' that already exists (the IT system supporting business functionality) but is that even an 'architecture' in any meaningful sense? After all very often the IT systems are build ad hoc where an initial small application possibly (or not) developed based on software design is continuously expanded by the development teams putting additional functionalities in as they see fit. This certainly cannot be called architecture unless one calls it 'ad-hoc architecture'.

For the concept of 'architecture' to be meaningful in IT context it needs to entail a conscious, purposeful activity in designing a specific system by a person called an 'architect'. Beyond that 'architecture' implies composition of components into a specific arrangement. This is the key, an IT architecture is composed of software components. With 'architecture' concept defined this way we can look for situations or use cases where arranging software components is meaningful and useful.

Cloud Changes Everything

Before cloud came around all enterprise IT environments were on-premises, each organization had its own local (to the organization) hardware and software 'solutions'. Some of the solutions were COTS(Commercial Off The Shelf software) some were custom developed. The custom solutions developed by the home IT team or by a third party supplier were simple. They were essentially 2-tier applications, custom code plus a database, and later a web server of some sort. There was no use or reason for a solution architect as there was nothing to architect. The database was typically provided by either the DB or infrastructure team, the same went for web/application servers. The only thing left was to design the code but code design does not an application architecture make.

The situation started to change with cloud environments but not just any cloud. The early cloud, specifically Iaas cloud, was very much like local on-premises environment, the only difference was that the hardware was not owned by the organizations but was being rented by an organization for a monthly/yearly fee. The real change came with Paas and Saas cloud options. Now the organization was not renting just hardware but also optionally the computing services (components) running on the hardware. The services made sense, they allowed faster and cheaper application development. This was the environment where solution architecture came into focus because now an application wasn't just code running on infrastructure, the infrastructure itself became code (Infrastructure As Code). And this code was packaged as discrete software components that could be assembled into solutions. It is the 'solution architect's' job to design 'the wiring diagram' of how these components should be put together to create an application.

So the first conclusion we can draw is that 'solution architecture' is meaningful in a cloud Paas/Saas environment but not so much in on-premises environment. However there is an exception to that. In an on-premises environment there might be a need for a solution architecture if the enterprise infrastructure is service based, be it SOA or microservices. I'll leave SOA aside as SOA is very rare among organizations but microservices have gained a lot of steam and even more publicity in the last few years even among smaller companies that wouldn't have dreamed of SOA.

Microservices As Solution Architecture

Many organizations now seem to equate 'solution architecture' with 'microservices'. On purely conceptual terms this is not correct as 'microservices' is an architectural style whereas 'solution architecture' is a practice that may make use of 'microservices' style. However in practical terms a case could be made that since 'microservices' style is the only viable architectural solution other than the monolith style, which by definition has no architecture (mono implies one), then it can be said that 'solution architecture' done on premises is essentially 'microservices' architecture.

But there is a caveat to even this 'pragmatic' understanding of solution architecture and microservices as being roughly the same. 'Microservices' style came about and was driven by the need to re-architect existing large complex monolith systems that were difficult to maintain, change or update. 'Microservices' as architectural style in general is not recommended as a starting architecture for a new application because the trade-offs between 'microservices' pluses and minuses is heavily skirted to minuses (additional complexity and costs in terms of development, support, monitoring, deployment etc.). Hence the best use case in on-premises environment is to use 'microservices' to re-architect an existing large system that is difficult to manage. In that case a 'solution architect' will be well worth the money.