At the risk of tunnelling in the rabbit hole...
(I agree with Glassboy, check out FIBO as a practical solution to your current issues. I'm leveraging the
excellent example you've provided, Modesto, to explore some issues
I'm thinking about.)
I think you should boil it down to the relation between use case and actors. Lots of the above just seem to be attributes of concrete actors (which can be at any complexity) and you would apply some constraints upon them (like Government Department can do this but Internal System can do that).
To me, the use case is the driving fact. What actors (or what roles do they play) do you expect when interacting. Trying to build an organizational chart of actors is of no big use (in my eyes). Organization change but the roles are very stable.
q.
Don't forget, q is using Actor in the UML sense. A UML Actor is an ArchiMate Role (it pretty much says so in the UML spec) - which begs the question why didn't they use the term
Role?
The original profile extends the Actor metaclass as shown above but stops at the 2nd level (minus roles) and treats anything else as attributes/tags. However, I am not convinced it works, it appears that we are going to need 1 or 2 extensions to enhance how we model organisations and how organisations are grouped into data exchange networks, please think GDPR.
There are two kinds of hierarchies, Tree and Lattices. Tree nodes must have only one parent (superordinate), Lattice nodes could have more than one parent.
Most ontologies are lattices (which a tree structure finds VERY difficult to accommodate)
I haven't decided if the ontology is going to be a Tree of a Lattice and we have to have an internal conversation about this. (Information) Systems as actors are the spanner in the works. If we were going to go for a Tree we will need to have 2 systems one to handle the behavioural aspect - i.e., systems as actors - and the other to handle the structural aspect of systems - i.e., systems as a structured group of application and components.
Thoughts, please?
I'm looking into how can I express both the structural and behavioural aspects for the same item. That is, I believe we CAN create a tree - based upon the structural aspects of the items since that seems to be pretty disjoint. A person IS NOT a computer system. The behavioural aspects are expressed relationally.
Since then, I've come to the view that the concept of actor represents the behavioural aspects of a thing, not the thing itself. We describe a person as an actor because they exhibit behaviour. Similarly, a system can be described as an actor because it, too, exhibits behaviour. But a system IS NOT a person.
We CAN say that structurally, a person IS a biological entity that HAS behaviour and therefore renders as an actor.
Similarly, a system IS a technological entity that HAS behaviour and therefore renders as an actor.
I'm still looking at the modelling implications of the above.
Thoughts?
I agree that actors represent the behavioural aspects of a thing but the behavioural aspect could be expressed via roles because the same human or system can perform many actions depending on the role they play.
There is a very subtle difference between the following statements:
- A Mortgage Applicant (Actor?) applying for a Mortgage (thing/business object?)
- A human (Actor?) performing the role of Mortgage Applicant (Role?) to apply for a Mortgage (thing/business object?)
Using my Actor/Role/Agent metamodel this would be:
A Mortgage Applicant Agent (whether Human or computer Actor) playing the Role of Mortgage Applicant applying for a Mortgage (thing)
A Human Agent (since we have a human Actor) playing the Role of Mortgage Applicant applying for a Mortgage (thing)
As you can see one is a specialization of the other.
The KEY thing we've learned is that in (certainly English) language, we often use abbreviated terms for the names of things and so can get REALLY confused...
You need to be quite precise if you are to express the reality in the model.
For example, An organisational position is usually named after the principal Role of the Primary job that it undertakes
Thus, I, Paolo, (the Actor) hold the Position of Data Architect, because the primary job is Data Architecting, whose primary role is Data Architect.
But as you can see one "Data Architect" is the Position name and the other is the Role name. I could have made things worse by describing the job as Data Architect, but I tend to use the active form for the job (since it describes a form of activity).
So because we use
ambiguous names, we can get horribly confused about what is
actually going on.
In a complex organisation, like the one we are modelling, the first approach is likely to result in a very long list of data actors. However, a close inspection of such list of actors suggests 2 things: 1) there are levels of abstraction - e.g., Applicant can have various specialisations: Mortgage Applicant, Loan Applicant, and Credit Card Applicant, 2) applicant sounds more like a role than various people - Paolo, Modesto, qwerty and Glassboy can perform, all humans I think 
but it can also be performed system to system via an API. Thus the advantage of the 2nd is that it reduces the list of actors and allows generalisation.
In your example immediately above, I don't think the system is the applicant, the person is always the applicant (At least until we have AI's taking up residence in dwellings). As far as the mortgage application approval system is concerned, the request is either coming direct or via an API - or have I got that wrong?
Paolo
