Page tree

Architectural Thinking Framework

Skip to end of metadata
Go to start of metadata

The core architectural model of Architectural Thinking consists of just five artifacts:

  • Business Capabilities describe what a business needs to do in order to generate customer value.
  • Value Streams define how the processes of the company create this customer value.
  • Business Objects define which information is needed in the capabilities and value streams.
  • Applications are computer programs that support value streams and capabilities and store business objects in the form of data.
  • Technology Components support applications.

If linked consistently and used widely throughout the entire company, these five artifacts are sufficient in order to achieve the goals of Architectural Thinking as mentioned above. They are the core skeleton model to which more specialized architecture models (such as business models, product models, customer journey models, process models, IT software and system architecture models) can be linked. The architectural model of Architectural Thinking is not in contradiction to the models used in existing tools and frameworks; it simply heavily downsizes what is in use today and focuses on the essence.

Architectural Thinking comes with detailed, practicable cookbooks that explain how to build your architectural model.

→ Comparison to other architecture meta-models used in practice

6 Comments

  1. Die Reihenfolge der Artefakte ist im Text und in der Navigation unterschiedlich. Sollte mMn gleich sein

  2. Add:

    • Roles/Organizational Structure
    • Touchpoints/Services
  3. I think we should be clear why each specific element is important, what it stands for and what it implies. As example we talked about the need to differentiate application and technology as application can mean IP, and technology becomes more and more commodity.

  4. I like the idea of the lean set of core elements. I have nothing to add to the elements...

    • Technology component (→ Technology Layer)
    • Application (→ Application Layer)
    • Business Object (→ Information Layer)
    • Business Capability (→ The "glue" between everything - the map of the enterprise, where we EAs can map the other layers on)

    But I want to discuss the element "value stream" - or maybe just the wording:

    Pro "value stream":

    • "Process" may be understood as a more detailed process description - with input, process steps, output etc. "Value stream" is more high level and therefor better to use for us EAs.

    Pro "process":

    • "Process" is a well known term for everyone. "Value stream" needs more explenation.
    • In my recents projects, we often talked about not using the term "process" but use "value stream", "customer journey" or "workflow" instead. In the end, they were all sequential processes from another viewpoint. It turned out, that everyone just used the term "process".
    • If we use "value stream" or "customer journey", it might be the case, that we forget to model essential parts of the enterprise scope. Example: in a recent project, we tried to focus on "customer journeys". A good starting point, but we figured out, that there are a lot of necessary IT components, that have no direct customer touchpoint.

    So there are pro's for every term. For me it turned out that the classic "process" still does best. What do you think?

  5. Wolfgang Göbl You commented, you would like to add additional elements. I would like to comment on that:

    • Roles/Organizational Structure: Good point. But I would like to recommend to stick with the lean model of 5 elements. Roles/Departments/OrgStructures are part of the process element from my point of view. For me, a process big picture consists of the for sub-elements:
      • process step (What is done?)
      • role/org (Who does it?)
      • optional: application (With support of which IT application?) (just a small reference on the app)
      • optional: business object (Which business object is handed over?) (just a small reference on the bo)
    • Touchpoint/service: From my experience, every service, touchpoint, <insert any other> can be translated to the other elements. Let's try to not get too fuzzy here. (smile)
  6. regarding the menu - i suggest to follow the order of the above description for matter of coherence, right now value stream and biz capabilities are inverted 

Write a comment…