The ArchiMate Files – 4. Internal vs external

Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Nov 14, 2011

Enterprise Architecture, ArchiMate

Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.

This is the fourth posting in our series on using ArchiMate in practice. The goal of this posting is to come to grips with the structure of the language, building on the previous posting where we considered the structure vs. behavior aspects. Simply put, we argued that:

  • Architects observe the world and come to a mental model through abstraction
  • When analyzed, this mental model consists of behavior elements and structure elements that are associated with these behaviors
  • Structure elements that ‘perform’ behavior are called active structure, whereas all other structure elements are considered to be passive structure

We also discussed the three domains in ArchiMate: business, application and technology. Here we continue this discussion by considering the ‘internal’ and ‘external’ aspects of each domain.

Life is like a box of chocolates

Recall from the previous posting that each of the layers is said to offer services to its environment. Understanding what this means is the basis for understanding the internal vs. external dichotomy. The following diagram illustrates the main idea:


Suppose we see the organization as a box. In line with the classic “black box / white box” views of systems, we recognize two aspects:

  • External: what are the services that the organization offers, and through which channels can we access them?

o   Example: at my bike shop around the corner, I can order a new bike, pay for it, pick it up, et cetera

  • Internal: what do we have to do to realize those services?

o   Example: once a bike is ordered, we receive the order, assemble a bike, tune it, make sure payment is handled, and then deliver the bike. To make that happen we employ different people in different roles.

Relation with the three domains

This line of reasoning is re-used through the three domains. The main idea is that the business layer offers services to “the environment” (i.e., the customers of the organization), whereas the application layer offers services to support the (internal aspects of) the business layer, and so forth. The following diagram illustrates this:



To make this more concrete, consider the following example:


Here we see that a service is offered to the environment (bike ordering) which requires a process that is executed by some clerk. In order to perform his work, the clerk requires some automated functionality (i.e. handle the transaction in the systems). To make this happen we switch to the internal aspects of the application layer and specify that we need several functions that are executed by the ERP system. We then repeat this line of reasoning in the infrastructure layer.

Using ‘internal/ external’ to guide the design process

While the internal/ external dichotomy may seem trivial, it should be noted that the mechanism is very useful from a design perspective. In practice we see that many architects get ‘carried away’ in describing the details of a domain under consideration. Our practical guidance is to “model as little as possible, but not less” (paraphrasing Einstein). We will revisit this discussion in subsequent posts, so for now we will suffice with the practical guidance:

  • First focus on the “what” question by modeling the services.
  • Then, consider the “how” question by modeling processes and functions that are required to realize these services. Also consider how these behavioral elements are grouped in structure elements based on (construction) principles
  • Finally, select the actual realization / manifestation of this architecture that will be ‘deployed’ in the organization. This manifestation may differ from what was originally architected for various reasons

This way of working is quite similar to what is proposed in TOGAF (using Architecture Building Blocks and Solution Building Blocks). The following example illustrates the point and concludes this post.


Conclusion & outlook

In the next posting we will pick up our discussion on the foundations of the ArchiMate framework. We then look into some practical as well as philosophical language issues that modelers may run into in practice. If you have any questions or suggestions: feel free to drop us a note! Stay tuned! 



Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:


Subscribe to Email Updates

comments powered by Disqus