In today’s practice, solution teams produce two kinds of architectural maps:
Technological Maps (software and system architecture)
Software and system architecture are usually modeled with the widely used Unified Modelling Language (UML). Both disciplines are mature. arc42.org is an excellent source of information for technical architects.
However, solution architecture with UML usually jumbles technological with business-related architectural elements. This suits the needs of the software development team, but makes the business architectural elements hard to grasp for their stakeholders (business people).
Solution Requirement Map
There are many approaches to structure requirements. From more strictly formalised (user cases) to less structured (user stories/epics/themes). There are only a few rules for structuring requirements in agile teams. Every team structures them according to other dimensions. Concepts such as epics/themes/stories allow a lot of freedom for interpretation.
What is different in Architectural Thinking?
Technological Maps
Software and system architecture are both mature disciplines. For this reason, Architectural Thinking does not make any further suggestions as to how to model the technical aspects of this kind of architectural maps, but refers to arc42.org as an excellent source of information for technical architects only.
However, a strict separation of technical and business-related architectural elements is mandatory in Architectural Thinking. For this reason, Architectural Thinking defines two mandatory, purely business-oriented maps: the ‘Solution Business Object Model’ and the ‘Solution Application Interface Map’ that define the business objects of the solution and how they are passed between surrounding applications. Technological maps must be derived from these maps.
In Architectural Thinking, business people are the owners of the business object model, the applications and the logical, business orientated interfaces between the applications. Thus, architectural maps must be designed in a way that is understandable for them, which means that they must be kept simple and free from technological details.
Solution Requirement Map
A strong connection between architecture at enterprise and at solution level is mandatory in order to make Architectural Thinking work. For this reason, it defines a simple yet powerful rule: each and every requirement must be easily traceable to the business architecture models of the enterprise level. This means, for example, that naming is used consistently at enterprise and solution level, and that requirements should be linked to the business capabilities they support.