Input sought: Actor - Role - Process Activity... an interesting domain model question

I have an open question.   I'd love to get community feedback.

A process can be decomposed into activities.  Who performs the activities?  Are activities performed by roles with actors assigned to those roles, or are activities performed by actors in roles?  In other words, is it a binary or ternary relationship?

Pedantic question, perhaps, but this is the kind of thing that causes heartburn when creating a domain model for IT management.  Understanding these relationships is important if we are to build software that allows an IT person to correctly capture and describe business processes.

Here are these two options, in detail...

View 1:

Ternary relationship: an activity is performed by an actor in a role.  One consequence of this connection is that a person or system (actor) is directly traced to the processes that the actor performs.  The assumption being that any actor can play any role in any process, including many roles.  It also assumes that an activity cannot be described using only a role, but MUST be described by both a role and an actor.  Another major difficulty with this view is that it is very difficult to demonstrate that conflicts of interest have been addressed, as required by corporate best practices and, in many cases, legislation.  By containing an actor within a role, it is possible to demonstrate that an actor has remained compliant.

View 2:

Two binary relationships: An actor behaves in a role, and an activity is performed by a role.  One consequence of this connection is that a person cannot be directly traced to the process, since an actor is part of a role, and a role performs an activity in a process.  This is a simpler relationship, and it allows us to describe a process activity as "performed by a role" without any notion of the specific actor that will fill that role.  This appeals to the notion of encapsulation, and allows us to constrain an actor to a role.  On the other hand, this structure does not represent reality.  The notion of a person, performing a role, within an activity is better for tracing the actual events, because a person may act outside of their assigned role, and perform an activity in another way. 

Potential resolution:

Supposition: Both views are correct.  From a planning perspective, we can insure compliance with policy by requiring actors to perform within a role, and attaching the role to the process.  Then, when recording actual activity, we would record that an actor, behaving within a role, performed the activity, regardless of whether they are actually assigned to that role.  This allows good auditing, while insuring that compliance to policy and legislation is demonstrable.

Feedback?

The reason I pose this as an open question is to ask you, gentle reader, if you view this relationship in a different way.  What does your experience tell you?  What concerns would not be addressed by the potential resolution, or have not been considered in the two views?

Addendum

Jim Ludden points out, in the comments, that I had not defined the terms involved.  So here goes:

Role

• Prescribed or expected behavior associated with a particular position or status in a group or organization. (BusinessDictionary.com)
• The actions and activities assigned to or required or expected of a person or group (Wordnet, Princeton University)

Actor

An abstraction of a person or group of people, described through an understanding of their motivations and pre-existing conditions.

Process Activity

A single logical step in a business process. (Source: WfMC Glossary)

Looking up the definitions was valuable, because it makes it more clear that the definition of a role is not independent from the understanding of the activities themselves.  In effect, a role is an assignment of activities to an actor.  Pretty much makes "option 1" a non-sequitur.  The rest of the analysis is useful, however, in that we can describe what a person Can do, and then in a seperate way, what a person Did do.  Thanks to JimL.

Comments

• Anonymous
  September 28, 2008
  Integrating both views makes perfectly sense, thanks for pointing that out. My experience is that people tend to misunderstand the ternary perspective of view 1. They rather would see actors as "member of a role", i.e. most ofen member of an organizational unit responsible for the process activity. However, view 1 enables you to model separation of concerns - actors who have a general responsibility for a process activity but are not permitted to fulfil it for the very same process instance where they perform the role's task. E.g. a 2-person team that shares work with two roles (clerk and supervisor), with alternating role assignments

• Anonymous
  September 29, 2008
  The comment has been removed

• Anonymous
  September 29, 2008
  Hi Nick, have you every looked at Archimate?  If you go to www.archimate.org and download the Archimate Primer, Appendix A has the language metamodel which shows what you're depicting in more detail.

• Anonymous
  September 29, 2008
  Hello Robert, Archimate is very interesting, and I've read through the Archimate Language.  I like the way that they model the elements of both business and technology.  However, they have not tried to create a model of IT mangement.  In other words, the business of IT, including things like strategies, processes, process metrics, information models, features, requirements, use cases, test cases, etc.   In other words, Archimate is very good for understanding the system as it runs.  It is not good for understanding the machinery that builds that system.  Archimate can only be used to model IT business the way it models any business: in the most general sense.  (It's a recursive model, in that you can apply it to any business, including the business of IT.)   Unfortunately, at that generic level, we don't get sufficient detail to address real problems within IT, like reducing time to market, increasing quality, and reducing operating cost.   Therefore, just as Archimate would not provide an answer to creating a domain model for any other complex domain (like insurance product, to use the example from the Archimate documentation), it cannot answer the need to create a domain model for the services of the IT business. It was not intended to.  Archimate is providing a business metamodel.  I'm describing a domain model for IT management. Different animals. That said, I like the work that they did.  It is quite impressive and a useful "base" model.

• Anonymous
  September 30, 2008
  IT management is not the issue here, since the problem arises everywhere someone (or something) executes a process. The answer lies in the definitions of Actor and Role. Since these definitions are not given (only assumed) the model is incomplete, and therefore the question cannot be resolved.

• Anonymous
  October 01, 2008
  Hi Nick, I currently work in Government and I fully understand the challenge you've set yourself.  I don't disagree with how you've attempted to resolve your question or that it isn't important.  I just think that in your question you've set yourself a sophistic trap, and that considering only activity role actor you don't get a meaningful answer.  Like Jim I also think it's a mistake to consider this solely an IT management issue. If I try and use any of the models you have illustrated to any of our process activities that have the most "compliance" requirements I struggle without an idea of what triggers the activity, how it is realised, and what is the effect on other activities. The nice thing about Archimate is that being a language it has particular symbols for all of the objects and relationships you're attempting to describe with Visio blobs and text.  The meaning is implicit and documented, and you don't have a 'doh' moment when you clarify your terms :-) (Direct link for those who don't know what I'm talking about http://www.telin.nl/NetworkedBusiness/Archimate/ART/generated/explanation331.html) One suggestion I do have for you is to look at your Potential Resolution and consider whether you are actually meaning to move from a logical view to a temporal one. I think if you look at the Archimate Metamodel you're actually describing that an activity results in a business object being created.  In this instance an audit trail. Your activity record has meaning not just from a compliance perspective (governance) but as a way for the business to monitor the performance of the actor and IT to monitor the performance of the system. But now I'm starting to ramble.  Must get on and do waffly things with other Government Enterprise Architecture types.

• Anonymous
  October 01, 2008
  Hello Robert, My apologies.  I had misunderstood you suggestion.   Correct me if I am wrong, but you are not suggesting that I use Archimate as input to my domain model.  You are suggesting that I use Archimate as the metamodel for my domain model. And that is something I shall seriously consider. At least, in between doing waffly things with other Enterprise Architecture types ;-). --- Nick

• Anonymous
  October 01, 2008
  I'm suggesting that the Archimate language metamodel illustrates an attempt to model what you seem to be trying to, and that Archimate has clearly defined objects and relationships.  So it can be used to test your thinking. I struggle to say too much on the subject because I've never had someone adequately explain what a domain is in terms of a domain model.  It seems to mean different things to different people, and from the example I can't see what this thing is called IT management is.  And how is it different from business management. When I apply the test what is the "stuff we do" that this silly IT person is trying to define "requirements" for test to what you're suggesting I see things missing from your model from a compliance perspective. You've modelled authorisation to perform an activity but you haven't modelled accountability for that activity.  You haven't modelled how performing that process activity has a flow on effect on whether the role can perform other process activities.  There's no indication of what triggers an actor to step into a particular role. That's what I'd need to describe business processes.

• Anonymous
  October 01, 2008
  sorry about the lack of detail, Robert.  My model has something on the order of 80 elements on it.  I make no attempt to share more than tiny slivers on a blog, for two reasons: 1) I cannot explain a problem in a blog that involves more than a tiny sliver, and 2) I cannot handle the kind of feedback that I could get if I exposed the entire thing, especially since it is not vetted yet.

• Anonymous
  October 02, 2008
  We might have to seriously score you down for not being waffly enough then :-) I'd be interested in you sharing more of your at some stage.  The reason I have been looking at Archimate is I want to model Systems Management and Monitoring.  Archimate is so far the only tool I've found that looks allow me to represent the monitoring from device right up to process activity, and represent the meaning and behaviour that should result from an alert. I need to have a meaningful discussion with IT Managers about the drivers and purpose of monitoring without having the urge to beat them with my copy of The Simple Book.

• Anonymous
  October 03, 2008
  Hi Robert, Love the reference to "The Simple Book."  Archimate is a very clean metamodel that differentiates between behavior, information, and structure.   What I am attempting to capture are the elements of an architectural description, and the relationships between those elements.  The elements themselves cross the gamut from business strategy through to code.  We collect these elements for various purposes, from building systems to owning them.   The problem is that we cannot keep any kind of memory of the information we collect unless we know what that information is.  The information may "represent" behavior, information, or structure, but it is still an element, captured in the processes of IT. My goal, if I can map out how these elements relate to one another, is to be able to create a metabase of architectural information that can be used, and reused, in many of our internal processes.  We can know what we own, why we own it, how it works, where it was built, where it was deployed, and who the stakeholders are.  Every element has EACH of these attributes.   The error is assuming that an element is ONLY behavioral, or only informational.  Not true. An element is always the product of an architectural process that involves the deeper metamodel implied by Archimate or Zachman.   Of course you can model every element using Archimate.  That is because it is a fundamental ontology of element types. But I'm not interested in the element types.  I'm interested in the elements. Analogy: Archimate is to my model as the base data types and master database of SQL Server are to the table schemas for an inventory system.  (Ok, not a great analogy.  It's late ;-) Archimate is simple and clean and very usable.  It is a good metamodel.  It is not the domain model I'm trying to build. --- Nick

• Anonymous
  October 06, 2008
  Interestingly one of the NZ Govt EAs has developed what he calls Element Models.  Elements because they aren't always quantifiable things. They're surprisingly simple and effective.

• Anonymous
  October 12, 2008
  The comment has been removed