I recommend reading Architecture is about understanding to understand my basic perspective on what architecture is. I first wrote this in 2011 and for me it has stood the test of time.
Solution architecture is about coming up with and describing a target solution so that all relevant parties and stakeholders appropriately understand it.
The mechanics of creating a solution architecture typically involves analysis of the current state, capturing requirements, designing solution options with different considerations (pros and cons), and ultimately deciding on the target solution.
Analyzing and describing the current state is often skipped. The sense is that we clearly know where we are right now. It would be foolish to think anything else.
This attitude and approach is missing an important point. Analyzing and describing the current state defines the scope of the problem domain and makes sure everyone starts of with a common understanding. Skip this step and your people will churn during the solution process. How can we manage scope creep if we do not have a clear understanding of the scope?
Another consideration is why we think we can describe an effective target solution if we have not even described our current state. The key word here is effective. Every effort to create a solution architecture will create a deliverable. The question is whether it is realistic. Is the solution architecture connected to reality in a way that makes possible to achieve? A simple and silly example may illustrate this point.
The solution to world hunger is easy. Move food from where it exists in abundance to where it is needed. Use planes, trains, boats, and automobiles of all kinds. This solution is clear and easy to understand. It uses established technology. Yet it is not realistic. The solution lacks a connection to reality. In reality there are more factors at play.
Analyzing and describing the current state “architecture” is no guarantee that a target solution will end up being realistic and achievable, but it increases the likelihood that we have taken more relevant factors into consideration.
When the target solution has been selected then a plan or a roadmap can be created to map the interim stages to achieve the target solution. The scope and size of the solution drives whether a more tactical plan or a more strategic roadmap is created.
Solution architecture as a topic and endeavor is very open ended. Context and scope impacts everything. The solution architecture for an agile sprint of a DevOps IT system will be entirely different compared to the solution architecture for a large program that is implementing a new business capability for an enterprise. Each stage of a roadmap can have its own solution architecture, and for organizations using SAFe this would be the solution architecture for each Planning Interval (PI).