On ArchiMate’s divide between behaviour and structure

Archimate is divided into structure and behaviour. Active structure objects (like Business Roles and Application Components) perform behaviour (like Business Processes/Functions and Application Functions) and these behaviours act on passive structure (like Business Objects and Data Objects. This division is a fundamental property of the language, but it is slightly different than other ways to look at architecture (e.g. traditional view of software architecture or business architecture) and that does sometimes lead to discussion.

Note: the content of this post has been superseded (amended and extended) by the content on this issue in my book Mastering ArchiMate. Follow this link to the book page (with downloadable PDF)  for more information.

What I have noticed in a recent discussion is that the Business Function object is problematic in this sense. It has been customary in some circles to see a Business Function as a somewhat visible ‘part of the organisation’ that performs a certain function in that organisation. And that description shows already where the problem lies. In customary business architecture speech, a business function performs something and both there and in ArchiMate terms, something that performs behaviour is an active structure.

Application Function also suffers from this problem. In the field of Software Engineering, a function is both a piece of code (which is structural) as well as the behaviour of that piece of code. Historically, there have not been two terms in software engineering to separate that structure and its behaviour (nor in the related subject of mathematics, where formula and behaviour of a function are one and the same). Also, coming from software engineering, in UML the division between structure and behaviour is different from that in ArchiMate. In UML, we have a set of objects, some of which may play both a structural and a behavioural role, depending on the type of diagram they are in. Take for instance an Object Diagram in UML, which is structural, and a Sequence Diagram, which is behavioural, and both may use the same objects in either a structural or a behavioural role. In other words: UML allows objects that can be structural and behavioural, depending on the views they appear in (structure type of view or behaviour type of view). In ArchiMate, there is but one type of view (even if you are free to restrict yourself to certain object and relation types in different viewpoints) which combines structure and behaviour, but the objects themselves are separated in behavioural and structural. Coming from one world, the other doesn’t fully match. (UML is big, complex and mostly directed at the world of object oriented software engineering, it is not really a good placeholder in this post for software engineering in general and much more can be said about it, but I thought the juxtaposition was nice).

So, both in business descriptions and in software engineering, many people see structures as something that encapsulates behaviour all by themselves. In ArchiMate, it is possible to suggest a structure that encapsulates behaviour:

On the left you see the actual model, with assignment relation between the Application Component and the behaviour of that component: the Application Function. On the right, a visualisation suggesting encapsulation using ArchiMate’s somewhat underdefined Nesting relation, here used for Assigned-To (nesting is one of those parts where ArchiMate is pretty unclear as it can mean (a mix of) any allowed relation. I personally almost exclusively use Nesting for Composition between objects and, with a bit of reluctance, Aggregation). Though this nesting suggests encapsulation, it does not mean encapsulation. “Encapsulation of behaviour equals structure” does not exist in ArchiMate.

Back to the business layer. ArchiMate’s definition for a Business Process is: “A business process is defined as a unit of internal behavior or collection of causally-related units of internal behavior intended to produce a defined set of products and services”. ArchiMate’s definition of a Business Function is: “A business function is defined as a unit of internal behavior that groups behavior according to, for example, required skills, knowledge, resources, etc., and is performed by a single role within the organization”. In summary, both are behavioural and both group the same activities (but from a different perspective).

Business Process groups behaviour based on what it produces. It is a grouping based on an ‘outside’ parameter: the result of the activities. Business Process is therefore an ‘outside-in’ grouping of behaviour.  Business Function groups activities based on an ‘inside’ parameter: what resources and capabilities it needs. Business Function is therefore an inside-out grouping of behaviour, whereas Business Process (a grouping based on what is visible on the outside, like a service or product) is an outside-in grouping of (potentially the same) behaviour.

Both Business Process and Business Function both are behaviour in ArchiMate. For Business Process, that is not surprising for most of us. But for Business Function, that differs from other approaches where a function may be considered structural. In ArchiMate, Business Function is purely behavioural, it is itself behaviour that may be a grouping of (sub)behaviour. So, where is the structure that performs it? Well, according to the definition, a (single) Business Role (in practice often a role fulfilled by a department). So, where a business function in other approaches may be a structure that encapsulates behaviour and thus be structure and behaviour in one, in ArchiMate, a Business Function is pure behaviour and it is performed by a different, structural object: a Business Role. ArchiMate keeps the separation between structure and behaviour here seemingly intact (but not quite, see below).

And what about grouping/encapsulating of Application Component and Application Function? Same here and even nicer. Because at the application level, ArchiMate kind of sees the same sort of ‘encapsulation’ on both sides. Application Function may be an encapsulation (by means of a composition) of other Application (sub)Functions and Application Component may be an encapsulation (by means of a composition) of other Application (sub)Components. Between the Application (sub)Functions and Application (sub)Components is a one-on-one Performed-By relation. As can be seen here in nested form:

Seeing the composition of Application Functions on the right easily makes one use the word ‘structure’. And indeed, in a sense, there is a structure in the Application Function, as it is a composition of Application (sub)Functions. But though there is a ‘structure’, that does not mean the object itself is ‘structural’ in ArchiMate’s sense. Paraphrasing friend Ludwig: watch out for ‘bewitchment by language’. The fact that you are using (almost) the same word (‘structure’) does not automatically make it the same meaning.

Anyway, so everything is rosy and nothing rotten in the State of ArchiMate? Well, not quite. Take ArchiMate’s definition of Role: “A business role is defined as a named specific behavior of a business actor participating in a particular context.”. While the role is the performer of the Business Function and its position in ArchiMate’s scheme of things is structural, its definition is behavioural. But that is something for a follow-up post.

Also in another follow-up post, I will discuss how to model in ArchiMate the ‘Good Old-Fashioned Business Function’ (GOFBF), the one that is a structure that encapsulates behaviour. By the way: if you know who and what ‘GOFBF’ paraphrases, I’ll buy you a drink when you’re in my neighbourhood or I’m in yours.

[added Aug 9] The Van Haren book (ArchiMate 1.0 Specification, author The Open Group) also remarks that a business process should preferably have a label with a verb in simple present tense, e.g. “judge claim”, while a function should preferably have a label that contains a verb which ends on “-ing”, e.g. “claim processing”. Technically, ‘processing’ and other such words are nouns, I think.