Actors,
roles and assignments
This page is
published under the terms of the licence summarized in the footnote.
All free-to-read materials at http://avancier.website are paid for out of income
from Avancier’s training courses and methods licences.
If you find the web site helpful, please
spread the word and link to avancier.website in whichever social media you use.
This paper picks up from where “social groups and
social systems” left off
Contents
On actors in systems and meta systems
On the assignments of
actors to roles
Abstraction of roles from actors
Questions about UML use case diagrams
On human activity systems as a special case
The previous paper said the members of one social
group can act in more than one social system.
Moreover, the members of one social group can act both
in a social system and in a meta system that directs
that social system.
(This is a principle of agile development methods,
and surfaces also in the paper on hierarchies and networks)
The term “actor” can be used at both system and meta system levels
There are actors (or employees) who are hired to
play roles in operational systems.
There are also actors (or architects) who define
the operational systems.
It is possible for an actor to play both roles.
Some systems thinkers promote the idea that
employee actors should act also as architect actors.
In other words, a person acting as an employee
actor can step outside the operational system to act as an architect actor in
the meta system.
The actor ought to be clear which role they are
playing at any one time.
This paper is about actors hired to play roles in
operational systems.
What are the core elements in a human social system? This table presents three views.
|
As seen by |
The elements of an organisation are |
related by |
|
Common
man |
Human actors |
authority
or command and control relationships |
|
Weber
and Boulding |
Assignments of
humans to roles |
messages
containing information |
|
Luhmann
|
Communication acts |
references to the same “code”. |
The view of Weber and Boulding is the one taken here.
A core element in a system’s description is role.
A core element in a system’s operation is not such much actor as the assignment of an actor to a role.
One role can
be played by several actors, and one actor can play several roles, which is to
say there are three concepts:
Roles
Enterprise architecture views a business as a social system whose roles are formalised.
A role is a type that defines what actors in that role do, and perhaps abilities required for that.
Roles are defined in terms of services offered and activities performed.
One role can be played by several actors, and one actor can play several roles.
The entity that relates one actor to one role is an assignment
Assignments
An assignment is the allocation of an actor to a role.
An instance of a role type is not a human, but rather, a human assignment to that role.
Of course, assigning human actors to roles is different from assigning machines to roles.
In the operation of a system, computer actors behave in an orderly, prescribed, way.
By contrast human actors are likely to do more, less or different from what is defined in any role given to them.
And in practice, a business depends on humans doing things that are not explicitly defined role definitions.
Actors
An actor in a system is an individual or object with the ability to perform one or more defined roles.
We design software components to perform required processes, and expect no more from them.
Of course, we don’t design human actors, we hire them (and sometimes training them).
And every human
actor arrives with an immense range of abilities, outside what is required for
any business role
Though hired to play one role, a human may choose to play a different role, or change their role or invent a new role.
Also, a human is amore
needy than a computer; it is not sufficient to plug them in to a supply of
electricity.
A human actor
demands attention, in various ways, from managers, colleagues and others.
The table
below paints a picture of a spectrum from behaviour-oriented system theory to
people-oriented systems thinking.
|
Enterprise architecture & system
theory
Systems thinking & organisation architecture |
|
Processes involve roles which are instantiated in assignments performed by actors employed in organisation units |
The systems of interest here are composed of
business processes performed by human and computer actors.
Yet most of what actually happens in the
operational system is never described by business system architects.
The architects represents
only some behaviour of the
operational system, that which has to be understood or assured.
All architects rely on the successful operation of
computers’ circuit boards and humans’ internal organs (which are described
separately by computer manufacturers and biologists).
Architects describe processes in which they
abstract the roles played by human
and computer actors.
So if one actor replaces another actor playing the
same role, it makes no difference to the system.
This idealist view of a business system has a
possibly shocking implication.
Most of what makes a human human,
and a computer a computer, lies outside
of any system as it is described.
Architects do not mention:
·
electricity supply, circuit
boards, heating, lighting and ventilation
· the muscles, blood, lymph systems and
other organs humans need to keep them alive
·
almost all human hopes, dreams, frustrations,
skills and knowledge.
It is untrue that abstracting roles from actors
diminishes the part that people play in business success.
The reverse is true, that what people can do in the
real world diminishes the application of system theory.
Since not only are people vital to business
success, but much of what they do is way beyond what architects can
describe.
Business systems descriptions only lightly describe
human and computer roles – the actions they perform or services they provide.
These specified actions and services cover a small
part of what computers are capable of, and a tiny, tiny part of what humans are
capable of.
Enterprise architects (knowingly or not) presume
humans will do far more than any role or process description declares.
So, it is vital to business success that humans are
well motivated and managed.
However, this motivation and management of humans
is not described in any enterprise architecture repository I am aware of.
This is the province of Human Resources, Business
and Project Managers, Organisation Design, Business Change Consultants and so
on.
Much of it is ad hoc, and much is part of the
infinite complexity of the real machine – way beyond any business
system description.
There are
human and computers actors both inside and outside any business in operation.
Business
system descriptions usually feature the roles actors play, rather than the
individual actors.
Q) What does it take for an actor to be able
to play a role, outside or inside a system?
It takes
whatever abilities the role requires.
The role
definition for a human actor takes for granted a vast range of basic human
abilities (breathing, thinking, talking).
The role
definition for a software actor takes for granted the more limited basic
abilities of a computer.
Q) What does it take for an external actor to
interact with a system’?
The ability to supply inputs and/or consume outputs.
Where the
inputs and outputs are data flows, actors need the ability to code and decode
those signals.
Q) How do we choose where to draw system
boundaries around things outside of our system of concern?
As the focus of
our interest and attention shifts, so the system boundary may shift.
Given a system
boundary, you can regard things in the wider environment as discrete external
entities and activities.
There is no
obligation to consider how those external entities and activities may be
related in a wider system.
A use case
diagram shows processes, performed by a system, in which external actors are
involved.
Q) What is an actor in a UML use case
diagram?
The actor is
usually a role; it is an actor type rather than actor instance.
A line
connecting a role/actor to a use case says that the former is somehow involved
with the process of the latter.
The
involvement is often to supply input and/or consume output information.
The involvement
can be specified more exactly by <<stereotyping>> the line between
role/actor and use case.
Q) Why draw a whole person and not a
disembodied hand in a trivial ATM use case?
A
human actor in a use case diagram is never
ever a whole person.
It is only
that tiny, tiny part of a human actor that plays the
specified role in the specified use case.
In the ATM,
it is not the hand, is that tiny, tiny part of the person whose intention
is to make a particular use of the ATM.
Q) Are we making unspoken assumptions about
intention and intentionality?
You are
supposed name a use case after the intention (check balance, withdraw money
etc.) of actors in specified roles.
Enterprise architecture views a socio-technical organisation as an
ordered system.
That is, as a collection of actors assigned to play roles
in repeatable processes to maintain system state and produce desired effects.
Do not think of a human as an instance of a role,
rather, a human assignment is an
instance of a role.
Of course, assigning human actors to roles is
different from assigning machines to roles.
In the operation of a system, computer actors
behave in an orderly, prescribed, way.
By contrast human actors do more, and less, and
different, than is prescribed in any role.
In practice, social organisations depend on humans
doing things that have not been explicitly defined in assignments to roles.
Human nature and flexibility
We don’t
design human actors, we hire and train actors to play
designed roles.
But in the
case of human actors we get more than we designed for.
We get the
amazing general-purpose components that biological evolution has created.
So
every human has an immense range of abilities, countless more than are required
for any business role
A
human is more generally able and multi-talented than is required by any role we
design.
In
fact, a human is probably more complex than any system we design – let alone
any role in it.
And
being self-aware, a human can choose which of their diverse talents to exercise, regardless of any role they are given.
Of course, human actors may act outside any role given to them, or refuse to act as expected.
The system describer may allow for this in “exception paths”.
The system describer decides what range of choices and activities to include in the system and what to exclude.
One
individual may play the same, different or competing
roles in several social groups.
Though hired to play one role, a human may decide to play a different role, change their role or invent a new role.
By
the way, a human actor is also demanding of attention, in various ways, from
managers, colleagues and others.
(It
is not sufficient to plug them in to a supply of electricity.)
Relying on human nature and flexibility
All
businesses rely on human actors behaving in ways that are not defined in any system
description.
It is
assumed that intelligent people, being aware of an organisation’s goals, can do
what is wanted in situations that arise.
In practice, business owners depend on the ability of humans to:
·
assess the rules in a
role description
·
fills gaps in an
incomplete description
·
interpret, improve or
correct loose or badly-written rules
·
tailor general rules
according to specific circumstances
·
ignore or defy given rules to meet what they perceive the
"real" requirements to be.
Because of this, human role describers get away with informal,
vague, even erroneous definition.
Much
of what humans do is undocumented and unpredictable from any system
description.
Individual
actors may change the rules, processes and roles of the system they work in, and
even change the goals.
Some
may even pursue their own agenda, in conflict with the rules and purposes of
the system that employs them.
Does the actor shape the role? Or vice-versa?
In a human activity system, the granularity of the human actors is a given.
So, the granularity of employable actors shapes the granularity of role descriptions.
In a computer activity system, the granularity of software actors is a matter of design
So, the granularity of roles shapes the granularity of the actors.
Copyright conditions
Creative
Commons Attribution-No Derivative Works Licence 2.0 03/01/2016 20:57
Attribution: You may copy, distribute and
display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website” before the start and include this
footnote at the end.
No
Derivative Works: You may
copy, distribute, display only complete and verbatim copies of this page, not
derivative works based upon it.
For more
information about the licence, see http://creativecommons.org