Hero image credit: Photo by Pixabay:

I had an interesting discussion with someone the other day about what it is that they do on a day-to-day basis as a solutions architect. And as I was thinking about things after the discussion, I came to the conclusion that it really was nothing at all like what I do on a day to day basis. The things that he was talking about as part of his day-to-day are things that I consider to be in the purview of a devops engineer or an infrastructure engineer, and not something that a solutions architect would be doing on a day-to-day basis.

When I’m mentoring or talking to people outside of tech, I often get asked about what a solutions architect does. The answer to the question honestly depends upon where it is that you work at. It’s one of those jobs that’s really different from company to company, and from place to place. You’ll find that even within the same company that a lot of times a solutions architect in one group will be doing things completely differently from what they do in another group.

For instance, the things that he was talking about were things like developing infrastructure as code using tools like Terraform, and implementing CI/CD pipelines. And while I know how to do those kinds of things, it’s not part of what I do on a daily basis anywhere that I’ve handled solutions architect responsibilities. Those have always been things that are handed off to somebody else who does infrastructure on a daily basis.

Instead, what I do as a solutions architect is the design of the application. I work on coming up with how the solution is going to work, how it will be implemented, what platforms and systems will host it, how it integrates with other systems, how it’s presented to the users, and generally coming up with the story of the applications itself. That may be gathering requirements, designing application architecture, creating solutions diagrams, creating proof of concepts, and all the other things that pertain to that realm of design of an application.

I work with the client to prioritize tasks and needs, and I work with the developers to refine the technical approach and to help review the actual implementations that they come up with to solve the assigned user stories. I help plan out the road map of what we’ll be working on next sprint, and next quarter, and next year. I help resolve technical issues and problems. I help mentor less experienced developers and to help them learn and grow.

I think most places that I’ve worked that’s been the role and responsibility of the solutions architect.

But I have seen it be completely different in other companies, like how he was describing to me. And that’s the problem with IT in general. Titles really are a nebulous thing. They can mean something completely different from one company to the next. Take, for instance, a senior engineer position. What does that mean? At what point do you become a “senior” engineer and are you no longer a junior or a mid tier developer? Again, it’s one of those things that’s completely different from company to company. There is nothing which, as an industry, defines those kinds of standards. And that’s part of the problem. Yes, there are.certain things which are governed by certifications orthose kinds of things. But those are always specific to a specific technology and not to the industry as a whole.

So we find ourselves in that nebulous field of not really knowing from place to place and from company to company just what it means to be a developer, or what it means to be a “senior” developer, or a “solutions architect”, or whatever it might be. And for someone who has an idea of what they want to do in tech and they go out looking for a job to fulfil that desire, it can be pretty frustrating.