Page tree

Architectural Thinking Framework

Skip to end of metadata
Go to start of metadata

Architectural Thinking defines three scopes of architecture: (i) enterprise, (ii) top-level capability and (iii) solution.

Approximately 80% of architectural work is carried out during implementation with a solution scope. A team creates architectural maps that are specific for the solution collaboratively, but connected well with the maps on the higher (capability/enterprise) levels. An ‘Architecture Owner - Solution’ is responsible for the conceptual integrity of the solution, which means that the micro-architectures of each team member fit together.

In order to ensure that solutions that support the same top-level business capability fit together, single minded architectural work with a capability scope is required. An ‘Architectural Owner/Capability’ creates the capability-wide architectural maps by aggregating and consolidating the work carried out at team level.

The remaining maybe 1% of architectural work is carried out with an enterprise scope. An ‘Architectural Owner/Enterprise’ creates the enterprise-wide architectural maps by aggregating and consolidating the work carried out at capability/solution levels.



The architectural maps at solution level are connected to the enterprise-wide maps via unique references (e.g. solution requirements must refer to exactly one business capability). This allows permanent feedback cycles between solution architecture and capability/enterprise architecture.

The business vision is an important input for the design of the enterprise-wide architectural maps. On the other hand, architectural work at enterprise-level typically leads to questions that must be addressed in the vision statement and is the perfect feedback mechanism to challenge the vision.

The enterprise-wide architectural maps are an important input for the scoping of solutions. These permanent feedback-cycles ensure that findings at solution levels that are relevant at enterprise-level are taken to the next level. Thus, the architecture owner at capability level uses the findings of the solution level as an input for the target architecture of his/her capability.

Architectural work is permanently carried out at the detailed solution level and at the capability and enterprise level side by side. Many solution teams create architecture within their scope simultaneously. Whenever they find issues relevant at the capability level, they take them to this higher level, where the architectural owner has to integrate them into the target architectural maps for his capability.


  1. I'd get rid of the concept of "levels" – there are a number of bad connotations that come from that.  ALL Architecture is about delivering business value – what changes is SCOPE.  Just like variables in code, we have different effects based on where we are.  An EA is a global, a Portfolio Architect is at the shared modules/services and integrations level, and both Solution Architects and Application Architects are directed at a smaller scope:  a few or a single Line of Business (LoB) application(s).  The only difference in my mind is that the Solutions Architect owns the platform (code & infrastructure elements) whereas the Application Architect is allowed to free his or her self from the infrastructure complexities.

    I could go on to add that because we all operate at different scopes, we may use a different set of tools.  I'd expect cyclomatic complexity (sometimes called McCabe complexity) to be something an Application Architect was concerned about, but I wouldn't expect that to be considered at the portfolio or Enterprise scope.  Similarly, ROI is somewhat of a concern at the Application scope, but would be absolutely essential at the Enterprise scope.

  2. I was not aware that the term 'level' has a bad connotation. I will discuss your feedback with members of the association and keep your comment here for public discussion.

  3. If only the word "level" has a bad connotation, than change it to stage, phase, block, views, whatever similar. Basically the idea to split it in different views (to avoid levels), is a good idea. It is easier to explain professionals and managers what business architecture is, and how the methods, patterns and methodologies should be used. So it is easier to communicate and therefore, the benefit is easier to understand. That is important to convince decision-maker (and usually they are not architects and see it as waste of money).

    Last but not least, not every company has stand-alone-architects. Therefore often Project Managers, IT Manager, Process Managers have to steer and manage the topic Business Architecture. For them it is also easier to have a defined structure with methods and tools to orientate.

  4. Wolfgang Göbl: Connect Artefacts with Architectural Levels

  5. If the 'Architecture Owner / Enterprise' is only aggregating and consolidating the work done on the other levels (or stages, views, ...), as stated above, the artefacts on enterprise level are created by a bottom-up approach. From my experience, at least some of the enterprise-wide artefacts, such as capability maps, should better be created top-down in order to ensure that the result follows a homogeneous philosophy. Of course, experts from the capability and solution level have to be involved in this top-down approach.

  6. @michael beck: yes, we should reformulate it slightly that way

  7. overall comment but especially for the pages that comes from "Overview" on,,, i would create an intro that connect the item of the current page to what the reader has read so far.

Write a comment…