I read some TOGAF documents, and see many places mentioned "architecture" and "solution". For example architecture continuum and solution continuum, architecture building block and solution building block. But I don't quite understand what's the differences between them in TOGAF.
Understanding architecture vs solution in TOGAF
6.3k views Asked by hardywang AtThere are 5 answers
Enterprise Continuum makes the first reference to two different kind of building blocks for and architecture, we have the Architecture Continuum and Solutions Continuum, how I see the different between the Architecture building blocks vs solution building blocks so I will explain based on the idea of building blocks.
Architecture Building Blocks: This suppose to be logical, suppose to be a conceptual idea for what we want to achieve within organization, this will guide and support our solution space, yes as you read, this ABB's will set the rules and give some guidelines to how we are going to create our solutions at the corresponding level of Solutions Continuum (foundation, common-system, industry, organization). This architectur building blocks can not be deployed and not even are physicals.
Solutions Building Blocks: We can deploy solutions as they are physical, it means solutions can be instantiaded within a deployment, this solutions represent the implementation of architectures at the corresponding level of the Architecture Continuum (foundation, common-system, industry, organization). We can build or buy solutions, build in our organization or buy from some vendors.
You can see a very good image describing the different between these concepts here. Also in my response I talk about levels you can see more about this concept and a good image describing this here.
Hope that helps.
If you come from programming background maybe an analogy with an "interface" and its "implementation" may make sense. In this case, an architecture would be the interface and solution its implementation.
Taking this analogy to reality, an architect would design a solution and decompose the and decompose it into two or more components (=abstractions). One of the components may represent the need to store, for example, customer data. So the architect would write 'a database required to hold customer data'. This is part of architectural design - the abstraction.
At some time in future, the architect may want to make it a concrete. At that time he may write "an Oracle RDBMS or a flat file or an In-memory HSql database) as its concrete implementation.
As Per Togaf Documentation for Togaf 9:
Architecture 1. A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010: 2007). 2. The str ucture of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
It doesn't provide formal definition of SOLUTION.
In layman terms, Architecture is an abstract view of solution. It can be a superset or group of solutions. A solution is a more concrete representation of a problem while architecture represents wider picture of a system.