Are "Solution Architects" dead?

I recently had a colleague mention to me that Solution Architects (SA) are dead/dying and boy did I have something to say about this! Let's break it down...

With the rise of managed IaaS (Infrastructure as a Service) PaaS (Platform as a Service) offerings such as AWS's RDS (Relational Database Service), I've endlessly heard a similar thing as to why "DBAs are no longer needed" and "no one hires DBAs anymore". The simple fact is that while these services make things easier to manage, such as backups and restore, the traditional DBA isn't replaced by them. 

Inevitably when the database has an issue/outage, someone in Ops is tasked, by a panicking manager, to "get the database back up again and explain what went wrong". More often than not the person being assigned here has little/no experience with the inner working of a database and couldn't tell a "B-tree" from a "Hickory" 😉

With that aside out of the way, I'll bring it back to Solution Architecture. The fact you aren't doing it or haven't been doing it until now doesn't mean that you do not need this function in your business/development team. Ignorance is not a free pass and working in siloed teams only leads to duplication of resources and rising costs.

An example of this is that a squad in my team this year were tasked with "fixing search" in our app, which is completely fine and honestly the existing database query-based "search" should have gone the way of the Dodo well before now.

Now, what this squad did was go off and see what would work best in the framework we were currently writing this monolith in, and without weighing up other options (only a single PoC with a single tech was done), the decision was all but made to use a certain product.

Issue number 1

Another team had already set up a well-specced big data/search platform for another function, being log aggregation.

Issue number 2

Making a decision like this in isolation without taking in other business objectives is crazy, this is a large chunk of work with potential far-reaching technical debt. Think log-aggregation, big data, data warehousing, etc.

Issue number 3

The chosen technology was not a proven, industry-standard technology. The technology was chosen with "horse-blinkers" on, as to "what's the easiest technology to implement in our backend using pre-fabricated libs". This also did not take into account legacy parts of the system which would have to rely on very messy workarounds in order to achieve minimum functionality.

In my experience, when you task a developer with finding a solution to a problem, they very rarely think of anything other than what is directly in front of them. This leads to many decisions made in isolation that have far-reaching consequences. A manifestation of this is the amount of times I've seen a NoSQL database used when a relational database was better suited gives me pause.

This is really where a SA can prove their worth by evaluating technologies outside of specific technology constraints and "path of least resistance". If your business even has a vague roadmap, some level of SA is really better than none, and you don't even need to hire someone specifically for this. I believe that team members in Senior roles should be put into this as a matter of learning and understanding "whole picture thinking" as a part of their journey.

Add into the cauldron here, the fact that basically everything these days is PaaS; you end up paying through the nose for each solution you implement, so having one team implement a different tech to another, where the ultimate requirements are closely aligned, means a real hit to the bottom line. Multiply this by multiple projects a year and not only are costs doubled up on, you are increasing your technical debt exponentially, as one day someone's going to notice the costs and a consolidation effort will be inevitable.

I feel the compounding technical debt of these poorly thought-out projects leads to developers leaving after a few years, you get sick of dealing with the mess and look for greener pastures. I've done it, and I'll likely do it again before too long if these kinds of things are not thought about.

I continually advocate Solution Architecture in my current workplace, its a missing piece prior to and a companion of the Solution Design stage we kind of do now. As the person who is directly responsible for managing the Cloud costs of our team/platform, I see the direct implications of some prior poor decisions (looking at MongoDB in particular, yuck!).

The rise of IaaS/PaaS and the increase in costs associated with adopting these solutions, including the "DevOps Engineer" (such as myself) which is born of the need to now have specialists to manage these really complicated cloud systems and interactions. We end up being on the front-line and required to be DBAs of the modern era, to be able to debug all these interactions and managed systems when something goes wrong with them. 

Do not discount the "big picture" design of your systems as "too expensive" to hire someone to do it, this is a misnomer... you are actually costing yourself a lot by way of tech debt and duplicated services. Start leveraging and expecting more of your Senior Engineers, start having pre-project discussions including all teams, well before your project is started, start looking at your roadmap for high-level links between initiatives. If your team is very small, then ensure you're having input from all stakeholders before starting a project, it's "easier" the smaller the team is, you just have to find the time to do it.

In conclusion here, I believe that Solution Architects are actually becoming far more important than they have ever been in history. However the awareness of their need seems to be going the way of the DBA/Dodo...