If everyone is in agreement about what makes a Solution Architect, then no one needs to externalise the definition … and no one will know that no one knows!
This ignorance by association approach isn’t helpful, but it isn’t uncommon.
The problem could be the term itself, so let’s take the time to break it down.
What is a solution?
On the whole, and especially in this context, problems are what you might call “less than optimal” business situations, which would be better for everyone if they were to be improved. A solution is a means of solving a problem or dealing with some other less than optimal situation.
We tend to think of problems as the starting point for developing some kind of appropriate solution. At this point the chances are that any solution can only exist in the abstract … at this point, it is little more than an idea.
What is an Architect?
For most of us, there is a mental association between architects and buildings.
And thanks to Wikipedia, I can say with confidence that an architect is a person who plans, designs and oversees the construction of buildings.
I don’t remember the widespread use of the term “architect” in the system design methodologies of old, so I can only assume that its association with system design is a recent thing.
Clear as Mud?
So, we have a descriptive job title that combines a term that refers to the abstract with a term that most people will associate with the concrete. The consequences of this mismatch in perception and understanding should not be overlooked.
Whenever someone refers to the role or function of a Solution Architect, make sure that you understand exactly what they mean. Do not assume that their understanding is the same as yours.
Is there any wonder that the hiring managers looking for Solutions Architects can’t find the Solutions Architects they are looking for?
Is it SAFe?
One hiring manager that I was speaking to told me that his organisation was building its internal competencies and processes around the Scaled Agile Framework (I wonder what the “e” is for).
I’m not criticising SAFe as an approach. SAFe is the logical progression of an Agile mindset and like all methodologies, in the right place and in the right hands it will return tangible benefits.
SAFe builds on the principles of continuous delivery and extends the processes into the wider business operation, which is good. It also makes a stab at describing the roles needed within the business to allow for the implementation of a Continuous Delivery Pipeline and for the development of the concept of DEVOPS.
There’s a lot to be said about developing a methodology that provides for a common layer of understanding and a platform for shared experiences that mean the same to everyone.
It’s an honourable quest … if it’s for the benefit of all.
Why then build a framework around the use of ambiguous terminology?
Let me try to explain
When I talk to people about their requirement for a Solution Architect, the first part of the conversation is always spent establishing what they mean by Solutions Architect.
It’s not a simple exercise because everyone knows what a Solution Architect is already … don’t they?
Why the confusion around Solution Architect?
First of all, it’s difficult to find proper references to “Solution Architect”.
I did find a reference to “Solution Architect”, but it seems to have been bolted on to an already existing “Systems Architect” function.
And here, the definition of a solution architect falls much closer to the concrete than to the abstract.
And to make sure that we have all the bases covered, we can enrol on courses that prepare us to deliver “Agile Architecture to enable the creation of business value”, with all the possibilities rolled into one.
It’s not surprising that there is confusion.
What do you really want?
I think what people are really looking for in a lot of cases are essentially extensions of Business Analysts able to translate what the Business Owner wants into something that can be delivered by whatever means the organisation has to hand.
But when I looked at the Scaled Agile Framework documentation, I didn’t see much at all that fulfilled this need. Are we saying that Business Owners and Product Managers generally know enough about the framework and architecture of the business to dispense with the need for the “bridge” between the business and the technology?
It’s not obvious, but it seems that Business Analysts don’t really hit the scene until the requirement has been handed to the Agile Team, and even that’s not guaranteed.
When people ask for a Solution Architect, those in the know are probably asking for a System Architect but are using the wrong terminology. This is usually borne out by the emphasis on technical infrastructure rather than business drivers.
I think that the rest of the people that ask for a Solution Architect are really asking for an architect of the solution: someone who can understand the business need, define the business solution and then make the information available to the Agile Developers.
The Solution Architect in this world holds a considerable amount of domain knowledge and is able to support the developers at every stage. This is the business-focussed Solution Architect, tasked with architecting the solution and supporting all those functions needed to turn the abstract into the concrete.
Pragmatically, the Solution Architect that is the architect of the solution is the curator of the functional requirements, which will evolve over time as the organisation, the business and the products move forward and develop.
There is another view of the Solution Architect and this view is focussed more on the non-functional requirements like scalability, reliability, security and performance. All these non-functional requirements are integrated with the Business Solution but they require domain knowledge relating to the platform rather than the process.
Solution Architecture: role or function?
I think that you need to make your own mind up on this question as we have been talking about a term that to all intents and purposes is adopting a very low profile in most of the methodology documentation.
However, it’s clear where the role or function sits even if it’s not clear what it does.
Whatever it is and whatever it’s called, it’s the main ingredient holding everything else together.
Conclusion
If taking a product or project from the abstract to the concrete is about discovering, describing and defining the functional and non-functional requirements, we appear to have a requirement for an architect of the solution as well as for a Solution Architect.
Without being too simplistic, the Solution Architect is defined by the non-functional requirements.
We are then left asking the question: if Business Owners and Product Management are focused on functional requirements and those functional requirements are individual, discrete backlog entries, then who is holding the big picture?
I think when people ask for a Solution Architect, they either actually want a System Architect or they want a Domain Expert Business Analyst to bridge the gap between the business and the developers … but it doesn’t have a name.
If everyone believes that everyone already knows and understands the answers, no one is going to ask the question.
