What I would Change About ArchiMate

ArchiMate 1.0 has been out for a while and ArchiMate 2.0 is months if not weeks from publication. Drafts for 2.0 have been circulating around a while now. The upcoming 2.0 version doesn’t change a lot to the core language. This new release is mostly marked by two extentions: one for modeling business motivatons and requirements and one for modeling the implementation and migration phases.

Most of what I was looking for in 2.0 didn’t made it. Here is a list of what I would have changed in 2.0 to the core language.

Define Business and Application Function as structure

It may come as a surprise but Business Function is not behaviour. Behaviour is the reaction a system has after being triggered by an event. Any behavioural element therefore represent instances that have a start time (when the event triggers), a result and an end time (when the result is produced). A business function is not such an element.

Most if not all meta models, including TOGAF, describe it as a structural element. In ArchiMate it would be a more logical version of a business actor. In other words, it’s an idealization of a business actor.

The exact same reasoning to move Application Function from behaviour to structure. An Application Function is a logical (idealized) version of an application component. TOGAF would call it a Logical Application Component.

Add Application Process as a core element

The business layer has a process element, why shouldn’t the application layer have it? An application service with the related application process would corresponds to a well known concept in IT: use cases. I would love to see them in ArchiMate!

Add dependency relationship

ArchiMate has tons of relationships, most of which should are hardly used, yet it misses one of the more important relationship: dependency. ArchiMate tried to avoid it by adding most of the specialized dependencies: Used By, Access, Realization …
But there are still places where I would like to use a simple dependencies without being forced to specify more detail.

Redesign the technology layer

ArchiMate is built around the distinction of internal versus external and behaviour versus structure. This is very visible in the Business and Application layer, especially with the above proposed changes. The technology layer is an exception. They tried to fit UML elements in this model and did a pretty good job. Yet, it feels wrong that the symmetry from the business and application layers is not showing in the technology layer.

I even wonder how wrong it is to have a behavioural item (System Software) inherit from a structural item (Node).

Something is not right in that layer and it needs to be fixed.

Share

2 thoughts on “What I would Change About ArchiMate

  1. Alright! Back to that good old “function” discussion again πŸ™‚
    Let me first say: I agree with all other comments.

    I’m not saying one is right and one is wrong, it all starts with your definition of “behaviour”. If you define behaviour as something that has a clear start and end, then yes, you are right, it only leaves process as behaviour. I think that is just one possible definition.
    If you look at definitions of behaviour:
    1. The manner in which one behaves
    2. Action or reactions in response to external stimuli
    The second definition matches yours, the first not entirely.

    Let’s take an example: I pretend “being friendly” is one of the behaviours I show. Is this a process? Does it have a beginning or an end? I would say: no. Is it behaviour: yes. It is more a combination of actions I do that makes me “behave friendly” and therefor it matches the definition of function in archimate.

    So it all depends on definitions: yes archimate and TOGAF don’t agree on this, but this doesn’t mean one is right and the other is wrong.

    Just my 2 cents.

  2. @wimdrossaert I think there are two things I can add to this.

    First, the definition of “behavior” and “structure” is not free for everyone to define. Our current theories and models of structured analysis all stem from Systems Thinking (General Systems Theory). That theory has a good understanding of what “behavior” and “structure” exactly is. Sadly, most of that understanding has been lost in the last decade. Book after book has been published by authors who neglected to educate themselves in these topics. This being said, I myself am still looking for an authoritative source. In the time being I base myself on the most trustworthy Internet sources I can find.

    Second, let’s examine your example of “being friendly”. Just those two words aren’t telling us enough. On one hand I can see it as an actual activity (like a generalization of “smiling”) and on the other hand I can see it as a desired value of the system (you). In the first case it clearly is behavior of a system, each execution of that activity has a start time, an end time and a result (or at least an attempt). In the second case we are not describing a system in the behavior/structure sense so there is no problem πŸ™‚

    I would also like to point you to the fact that abstraction often obscures the understanding of behavior and structure. By generalizing, idealizing or composing behavior or structural elements, it often becomes harder to see the “start time, end time and result” attributes. To add to the confusion, not every abstraction of behavior is behavior itself πŸ™‚

Leave a Reply