The role of a solution architect
Introduction
The role of the solution architect? well, it depends on whom you’re talking to. But here I will attempt to give you my perspective based on my own experiences and observations: I had the opportunity to be a solution architect and an enterprise architect and in different organizations. Like I mentioned in another post, solution architecture is the middleman between enterprise architecture and software engineering or development. Enterprise architect focuses on strategy and very high-level concepts and abstractions. It would be a big mistake to try to cut the middleman and hand those high-level abstractions from enterprise architecture to a development team. Organizations that do this end up often with confusion, frustration, and low morale among development teams. It’s not that skilled engineers can’t do the translation, it’s rather they are more focused vertically - deep down - to write algorithms, meet requirements, and get things done. They lack the knowledge and the breadth of what’s happening in other parts of the organization and how their piece of the pie may affect the whole IT strategy or that target architecture state. Developers don’t typically understand technical debt and how they maybe contributing to it because they don’t see or understand that level of abstraction that enterprise architecture is dreaming of. Solution architecture also has a level of abstraction, but it’s more real and solution-oriented to solve specific business problems while at the same time adhering to the vision of enterprise architecture. Solution architecture is where the rubber meets the road. It behooves every organization not to overlook the importance of this role and its positive impact on the delivery of successful products and applications.
What’s the role of a solution architect?
The solution architect is responsible for the entire solution. She ensures that the proposed solution is the best solution option, given the circumstances, to meet the business requirements and solve the problem at hand. She works hard to ensure that her solution does not introduce technical debt or at least keep it to a minimum. She finds the right balance between delivering for the business, but also that the solution is within the guardrails of the enterprise architecture vision, and will lead to the desired target architecture. The solution architect is a diplomat who works tirelessly to ensure that her business and IT partners are on the same page. She explains abstract and technical concepts in layman’s terms to business partners. She pays close attention to where the data is sourced from, what happens to it, and where it’s going. She’s cognizant of when data crosses business domains. She uses industry best practices in architecture and integration patterns. But she’s not so conceptual and dreamy in her solutioning - that’s left to enterprise architects (LOL).
A solution architect typically produces diagrams, and literature that explains those diagrams. Solution architects work closely with technical architects/senior software engineers to translate solution artifacts, diagrams, into design and code. Solutions architects keep enterprise and domain architects apprised of what they’re doing. They often collaborate with other solution architects, domain architects, and security architects. Solution architects stay involved throughout the execution phase, and sometimes they are in the trenches with development teams. They attend stand-ups, and can react to any problems with the proposed solution and adjust it as needed. They deal with road blocks and advise the development team(s). Solution architects should, in my opinion, be technically savvy who actually wrote code, lots of code, and in different environments and languages. They have depth and breadth in technology. But also have excellent communication and negotiation skills and business acumen. Solution architects are trusted partners with business-subject-matter experts and software engineers. Solution architects are essential and can make the difference between success and failure.
There is a lot more to solution architecture, but that is enough for now. Just remember, architecture is an art, not a craft.
