Although I still primarily identify as a “Full Stack Developer”, during the past few years I’ve also found myself in a role called “Solution Architect”. The thing about being a solution architect is that there isn’t really a clear definition of the role, what it involves, or the scope of responsibility. I suppose it depends largely on the organization and the project. The role mostly involves making techical decisions on a larger scale, like project-wide or organization-wide, rather than on the micro day-to-day technical decisions involved in a typical software development involves. These decisions can encompass not just coding, but also requirements gathering, application design, database design, modelling, testing methodology, processes, deployment, and so on.
This is actually pretty much what I was doing during my last full-time job anyway. I was basically involved in technical decision-making at all levels. So there’s not much change, except that now there’s a formal name/title to the role.
Despite that role, in my past job I still insisted on taking on some of the coding work myself, typically the more difficult ones. I think it’s important as a technical person to maintain some familiarity with the low-level coding details, even when you’re transitioning to higher-level work like management or architectural work. (Also, I still enjoy the vagaries of day-to-day coding.)
For a solution architect in particular, it helps to be familiar with a wide array of technologies, since it informs your technical recommendations. You won’t always get such exposure through official projects either, so it helps to be interested in these things on your own so you can read up or try them out in your spare time.
Interestingly, the term “solution architect” has been increasing in usage over the past few years, if Google Trends is any indication:
(I originally tried Google Trend’s embed option, but the embedded chart kept crashing my browser tab, so now you get a screen capture instead)
If you’d asked me five years ago I would have said such a role was within the scope of a senior engineer or technical lead. I guess as time goes on, the role becomes more distinct and formalized? At this point, I think the concept might still be a bit too nebulous for anyone to really specialize in it though.