In a previous post, I discussed the structural/behavioural divide in ArchiMate and how it differs from GOFBF (Good Old-Fashioned Business Function, the one where structure encapsulates behaviour). In this (short) post, I’ll show a way to model this in ArchiMate.
Note: the content of this post has been superseded by the content on this issue in my book Mastering ArchiMate. Follow this link to the book page (with downloadable PDF) for more information.
Two posts before this one provide the foundations for this one:
- On Structure and Behaviour in ArchiMate discussed the division between structure and behaviour in ArchiMate. Some extra attention was given to the position of Business Function. Business Function in ArchiMate differs from some customary approaches where a function is structural and seen as encapsulating behaviour (both in business descriptions and software engineering);
- Business Process versus Business Function discussed the difference between both types of behaviour in ArchiMate and how you could combine both. It produced a view that a Business Function has an internal Business Process that produces the Business Services of that function which may be used in the rest of the organization.
The full world of a Business Function delivering services to the organization can be modeled like this:
The gray box contains the ‘old school’ business function. The structure (role with sub roles) and the behaviour (function and internal processes). That doesn’t look like ‘encapsulation’ yet, but using ArchiMate’s versatile (though underdefined) nesting operator, we can make a view that suggests the encapsulation:
A bit nasty, this one, because the relation between ‘A Business Role’ and ‘ArchiMate Type Business Function X’ is Assigned-To, something not generally expected of an ArchiMate nesting.
We can simplify this picture further (note, all these views come from the same model, they are just presented in different ways to convey a different message):
The Realization relations from ‘ArchiMate Type Business Function X’ to ‘Service A of Function X’ and ‘Service B of Function X’ are derived from Composition (from function to process) and Realization (from process to service). We can remove ArchiMate’s Business Function from the view and summarize one level further to get one single object in the gray grouping:
And there you have it: a GOFBF viewed as a structure encapsulating behaviour. Conclusion: If you want to model a (structural) GOFBF, you can use Business Role in ArchiMate.
R&A IT Strategy & Architecture 
You interpret quite liberally the assignement-to-nesting equivalency that is, as you say, under-documented in the ArchiMate specification. I would not have thought of nesting a function inside a role. What does that mean in the real world? That a job position performs some kind of work? I can see how that might work semantically: “Mr. Bob is a member of the department that performs these services for us.”, but what if that role is called upon at some point to effect other tasks or processes? Would you encapsulate those as well?
LikeLike
I agree that it does not feel clean to use nesting for assigned-to. But have a look at 8.1.3 of the official spec: it is said there that assignment may be drawn as nesting and they provide an app-level example.
This post was meant as an aside: I would personally not model a Business Function this way because I think Business Function in ArchiMate is behavioural, not structural. But for those among us that (want to) see Business Function as something structural (GOFBF), I tried to model in ArchiMate as close as possible that approach and then I end up in GOFBF=role.
I’ll be returning to this area of ArchiMate in a short while with a more in-depth post about Role.
LikeLike
I should have added: Mr. Bob is an actor, he can be assigned to multiple roles. Each role could encapsulate a specific function. It is not the role that is called upon to effect other tasks or processes, it is the actor that is called upon to play a different role. But, anyway, I would not do it this nesting-functions-in-roles myself.
LikeLike
What you call an ‘Old School Business Function’ is the classic misinterpretation of the term ‘Function’. A Business Function is not a Department inside which activities occur.
Business Functions are the core activities of every enterprise. Every step in a Business Process is a Business Function. All data is created, transformed and used by Business Functions.
I demonstrate this core structure and the relationship between these elements at http://integrated-modeling-method.com/data-state-modeling/business-modelling-architecture/
Another classic error is nesting one element inside another. These relationships are not hierarchical, they are a many-to-many network. For example, 1) a Process is made up of many Functions, a Function can be part of many Processes, 2) a Function can be performed by many Roles, a Role can perform many Functions.
Trying to force them into hierarchies results massive duplication.
LikeLike
In case you were under the impression that I advocate GOFBF, I do not. We agree (or more to the point, you agree with ArchiMate) that function is a behavioral element, not a structural one, certainly not an ‘actor’ like a department.
I do not agree that using hierarchies as I illustrated in http://masteringarchimate.com/2011/07/23/business-process-versus-business-function/ results in massive duplication. Internal processes of functions will not be replicated, but they may provide services which are used in many other processes. There is no duplication, because ArchiMate’s “Used-By” (via service) is what you call “being a part of (many processes)” Every function is only modeled once and may be used many times. Every process is modeled once, it realizes services that are modeled only once and that may be used many times in other functions or processes. There is no duplication at all in that approach.
I think using hierarchies is not an error at all. If a function is to be used by a process, in ArchiMate it needs to offer a service to that process. To offer a service, you need a process to realize the service (ArchiMate allows a direct realization from a function, but luckily the derived relation of composition/aggregation and realization is again realization, so that function-realizes-service can be seen as a derived relation of what goes on fundamentally function-has-process-thatrealizes-service). Hence (in my use of ArchiMate), a function must have at least one internal process to be useful to external users of that function. If you stay at a two-level approach, you can of course do something that looks like it. I assume you may have sub functions in your function and those (and only those) can create together a process that is then ‘internal’ to the ‘super’function in my approach. I suspect both approaches will turn out to be translatable one-on-one to each other (so they are identical).
With respect to “a function can be performed by many roles”: ArchiMate limits the function to be performed by a single role (but then it can create aggregations of many roles in single collaborations which are (specializations of) roles themselves). So, where you would assign many roles to a single function, to do the same in ArchiMate I would create a collaboration of those roles and assign that collaboration to the function (and possibly the parts of that collaboration to individual sub functions of the overall function).
LikeLike
Functions do not contain Processes. Processes are made up of Functions. Processes are merely a definition of the sequence in which Functions must be performed in response to specific Trigger in order to arrive at a defined Preferred Outcome. It is the Functions in the Process that create, transform and used data. It is the Functions that deliver the value and service.
LikeLike
In ArchiMate it is the process that has the definition that it is behavior grouped based on the outcome (value and service), not the function. In ArchiMate the function is behavior grouped on shared resources, skills, etc. Your method has a different approach. That is valid, and may be on-to-one translatable to a some ways to model things in ArchiMate.
I think defining value and service ‘inside-out’ is less direct and thus a disadvantage of what is otherwise a pretty OK approach. People can argue a certain function ‘adds value’, but it is only the result offered to the outside world (and that is a service) that is a good anchor point for value. Actually, your approach can be modeled in ArchiMate as well in the way you like. Just explicitly model the services the ‘elementary’ functions realize and let them be used by the processes. As I said, both approaches are probably identical.
LikeLike