Page tree

Architectural Thinking Framework

Skip to end of metadata
Go to start of metadata

Values of the Architectural Thinking Association®

All deliverables to be produced under the brand of the Architectural Thinking Association©  must comply with the following values:


Each and every architectural model, map, principle, and integration artifact and its significance must be self-explanatory and understood by relevant stakeholders within a minute.

The Architectural Thinking Framework© only includes models, maps, principles and integration points that have proven to be valuable and work in any mid- to large size company. It defines an invariant minimal core that can be extended by companies easily.


In Architectural Thinking, 80 percent of architectural work is done by the many e.g. by autonomous, cross-functional teams. Thus, everybody becomes an architect on a micro level contributing to the overall big picture of the company. Dedicated architect roles are used for ensuring conceptual integrity on capability- and enterprise-wide levels only.

Collaboration is fostered by easy to be understood, lean models and maps, and by using Web 2.0 features (like Wikis) as central architecture repositories, where everybody can contribute and comment.


Business Architecture drives Technology Architecture, not vice-versa. Business people are encouraged to start thinking in architectural structures that are connected to each other. Thus business is treated as part of the architected system not only as its user. Four out of five artifacts of the architectural model (Value Streams, Capabilities, Business Objects, Application) are purely business related. We value the work of the Business Architecture Guild and their BIZBOK®


  1. Agreed that Business or the derived/defined concepts are key and drive the use of technologie i.e. define the directions and/or environment of a solutions. But with emergence of new technologies, also the business models might change and therefore influence on the Business level, so that you adapt because of technological reasons

    Just found Formulate Vision around new Capabilities that arise with new Technologies that's the point

  2. I think we should add "sustainability" as a fourth value.

  3. I'm not convinced about #1.  How can we judge which models may be effective for an organization.  Different orgs are in different situations and have different priorities.  Sometimes a diagram will be very useful for one org and useless for another.  All we can do is give options and advice for when we'd use them.  I wouldn't prescribe a collection of "blessed" diagrams or models.

  4. Another thought: I would start with the value statements, then describe them.  Right now this page reads more like an article than a set of value statements.

  5. >>Different orgs are in different situations and have different priorities.  Sometimes a diagram will be very useful for one org and useless for another.

    I don't agree here. Capabilities, are mandatory and the core of AT. We want to define the minimal core which is (almost) mandatory in most situations. Later on we could define optional maps.

    Defining a simple, small core is mission critical for me.

  6. How about a manifest for architectural thinking as a mindset? This would accompany the values. Something like:

    In Architectural Thinking we see benefit in both sides of the following list, but we value

    1) common vision over regulation among stakeholders

    2) overview over details in our models

    3) individual customers over market segments in our solutions

    4) sustainable, extendable solutions over small scoped optimizations in our solutions

    5) small steps over big leaps while introducing Architectural Thinking (because it’s a matter of change management)

    6) pull over push induced activities (in the “Lean …” sense)


  7. I think there are both a set of unarguable principles, as well as mindset around a continuum. 

    One core principle I suggest is "architectural integrity".  I'll elaborate on it further in another post when I have more time.

    I like the idea of a mindset as J. Gruppsuggests above, although I don't necessarily agree with items 2 and 3, which I see as goal and stakeholder dependent, which leads to the next point. There are many different goals and stakeholders for architecture, so I think we need to hypothesize on our scope fairly early in the process. Some important attributes of scope might be:

    • scenarios (what problems are we trying to help solve, architectural use cases) - transformation, greenfield projects, application rationalization, M&A, product introduction and rollout, organizational redesign, operational automation, digital twin, ....
    • stakeholders (who is involved in the solution that we are trying to address)- IT owners, business owners, architects, designers, agile developers, portfolio managers, UX, ...
    • cultures / geographies (how do they think) - North America, South America, Northern Europe, Southern Europe, Asia, Australia...There is some rough connection between where you are and how you think. I've done projects in all of these areas and all of them have different cultural biases that affect the organizational structure and what architectural approaches are effective
    • industry verticals - finance, manufacturing, healthcare, education, we have a preference? Do we expect to be applicable across all of them? Again, different industries have different environments, cultures, forces, etc. that need to be accounted for in any architectural approach
    • company size - small, SMB, enterprise, global...
    • What else?
  8. I would add "Humble" to the values. It's only by being humble that we can seek to understand, work to collaborate, put a greater solution ahead of our own ideas, being willing to risk, adapt, fail, advance and learn. 

Write a comment…