Organisations,
roles and actors in EA repositories
This page is published under the terms of the licence
summarized in the footnote.
All
free-to-read materials on the Avancier web site are paid for out of income from
Avancier’s training courses and methods licences.
If you find
them helpful, please spread the word and link to the site in whichever social
media you use.
Our concern is human and computer activity systems in which
individuals act (cooperatively) in described roles.
The individuals are mostly human actors and computer actors.
The human organisation (as well as the computing) needs design, but who does it, and who records it?
This paper discusses organisations, roles and actors in relation to an enterprise architecture repository.
Contents
Preface
and points of interest
Aside on the nature of human actors
Abstraction of business functions from organisation
units
Organisation design and documentation
Abstraction of types from individuals
Abstraction of roles from actors
Actors as attributes of assignments
Architecture frameworks assume an
enterprise
architecture repository will be maintained.
This architecture repository will be structured according to an enterprise architecture meta model
TOGAF, ArchiMate and other such meta models include an architectural entity called “actor”.
Architects are expected to record abstract roles and types of service, process, component etc.
And they are concerned with systems in which particular humans and computers act in described roles.
But the willingness and ability of architects to document individual human and computer actors is limited.
And in relation to the human organisation, questions arise:
· Who is responsible for organisation design?
· Who is responsible for documentation of an organisation’s management structure?
· Where are organisation units documented? Where are they mapped to business functions/activities?
Relevant facts and principles include:
· Architects are rarely if ever responsible for organisation design – though they must be aware of it.
· Designers should be responsible for documentation of their design.
· Architectural entities are commonly documented in several repositories.
· Human actors may be recorded in an organisation chart, a directory, and HR systems.
· Computer actors may be recorded in a configuration management database, asset register, server monitoring system.
· For data integrity, master-copy relations between such repositories must be considered.
Of course, a human actor can do more than any role they are asked to play.
Obviously, a human being is much, much more than a performer of described activities in described roles.
But architects do not document what an individual human might do unsystematically or unpredictably - in addition to or in conflict with role definitions.
And a human’s out-of-role feelings and needs, and undescribed activities, are mostly beyond the architect’s reach.
They are the concern of that human, his/her line manager, the HR department, the facilities management department and others.
And wherever architectural change affects them, architects usually turn for help and guidance to those other functions and/or a business change team.
Management structure view of activities - activities
under the organisation structure
Classical structured business analysis starts from the organisation chart.
This management structure may show the people employed in each organisation unit.
But people come and go, and who they are is secondary to what the organisation units do.
Architects should focus on the essential activities and services of a business.
So analysis may proceed by replacing the actors listed under each organisation unit by the activities performed.
A trouble is: human social structures evolve continually.
Organisation units, managers and employees are frequently shuffled.
It would be impractical to maintain an EA repository in which many architectural entities are mapped to today’s organisation chart.
So how to insure the bulk of the EA repository against reorganisations that redistribute and perhaps duplicate activities between organisation units?
Logical structure view of activities -
activities under a business function/capability hierarchy
Structured analysis recommends defining an abstract version of the organisation structure called a business function/capability hierarchy.
This shows purely logically cohesive groupings of activities performed, with no duplication of activities between functions.
People use the same idea to build generic industry reference models for multiple enterprises.
A business function/capability hierarchy features individual business function instances.
But they are abstracted from individual instances of organisation units, managers and employees.
Sometimes business functions do correspond to organisation units.
But there are many reasons why an organisations structure may be different, of which geographical distribution is perhaps the most obvious.
Other system elements can be mapped to the relatively logical and stable business function/capability hierarchy.
E.g. applications are commonly mapped to business functions that require them.
Behavioural view of activities - activities
in sequential processes
Every activity/step in a business process flow should be assignable to a node at the bottom of the business function hierarchy.
In other words, each elementary business process is also an elementary business function.
Complete correspondence is a theoretical possibility, but few get to complete their models.
So the function hierarchy usually stops at a high (3rd or 4th) level, and some process models descend to a lower level.
People view of activities - activities
performable in roles
A role is a group of activities that is performable by one actor - by virtue of the skills required.
Architects may define what abilities are needed to perform a role.
Architects are
usually more interested in types/roles than particular instances/individuals.
An EA repository usually records roles rather than individual human actors.
Even where one role is performed by only one actor, the role name is usually preferred to an actor name.
For future flexibility, an architect may name the entity using the role name, and perhaps record the actor name as an attribute.
Data view of activities - activities that
create and use data entities
This view may be recorded in TOGAF by drawing a Data Entity / Business Function matrix.
Application view of activities - activities
supported by application use cases
This may be recorded
in ArchiMate by drawing an Application Usage Viewpoint diagram.
Who is responsible for organisation design (the human equivalent of computer actor configuration management)?
There seems no satisfactory general answer, though organisation design is commonly done by business managers.
Whoever does it should ensure the
organisation decomposition structure is documented wherever it is needed
E.g. in an enterprise directory, in HR systems and in configuration management databases.
And this implies
deciding which data store is the master version, and which are copies.
Whoever does it should also map
organisation units to business functions (at any level from high to low that
fits).
Surely, it is advisable not to record this relationship in several data stores?
This implies deciding which data store is the master version for recording that relationship.
· The master of the business function hierarchy (the enterprise architecture repository)
· The master of the master organisation structure (perhaps another repository).
An enterprise architecture repository may be structured according to meta model like that of TOGAF or ArchiMate.
Such a repository holds abstract descriptions that typify system elements.
The Unified Modelling Language explicitly says it is concerned with types rather than individuals.
“A UML model consists of … model elements … used to make statements about different kinds of individual things”
In other words, M1-level software architecture models, drawn using the UML, show types of individual.
You can model a singular object, but you model it as a class, which happens to have only one instance.
“UML models do
not contain [individuals], because [they] are part of the domain being modeled,
not the content of the models”.
In other words, the state of particular individual actors is recorded in M0-level run-time information systems.
· Human actors are recorded in some kind of company directory and in HR systems.
· Computer actors are recorded in a configuration management database, asset register or server monitoring system.
Hmm... Does an enterprise architecture model only types, never instances?
Individual performances of behaviour (services and processes) are surely not recorded in an enterprise architecture model.
But what about instances of structural entities (components and actors)?
Particular individual actors are recorded in regular business information systems.
You can model a singular entity, but your model shows an abstract type, which happens to have only one instance.
Below are three somewhat different standard definitions.
UML v2.5 says: “An Actor
specifies a role played by a user or any other system that interacts with the
subject.”
This definition suggests an actor is a kind of external entity that triggers or reacts to system activities (but does not perform those activities).
The “subject” is the operational system that is modelled; the “user or any other system” is an external entity in the environment of that system.
TOGAF v9.1 says: “Actor: a person, organization, or system that has a role that initiates or interacts with activities.”
This also appears to suggest an actor is an external entity that triggers or reacts to system activities (but does not perform those activities).
The implication is that the actor is an individual (human or other) who is recognised as existing outside of their role wrt the system.
ArchiMate
v2: says “A
business actor is an organizational entity that is capable of performing behavior.”
Surely, “performing” activities (ArchiMate) is different from “initiating and interacting with” activities (TOGAF?
This wording appears suggest that an actor is an internal entity that instantiates a role required to perform activities within the system.
However, further reading of the standard shows a business actor can be an external entity also.
TOGAF and ArchiMate abstract roles from the entities that play them.
You can model a singular actor, but you are usually advised to name it as an abstract type, which happens to have only one instance.
The architects’ interest is usually in the type that an actor (human or computer) instantiates in an assignment, rather than the individual actor.
Perhaps it is fair to say an architect’s interest is more in the assignment of actors to roles, rather than individual actors?
An assignment is the employment of an individual in a role; it is an instantiation of a role.
In a model diagram, the many-to-many relationship can be resolved thus: Role ---* Assignment *--- Individual.
In an actor / role matrix - actor (row) plays role (column) - assignments are recorded in the cells:
The word “actor” is used various to mean an individual, a role, or one assignment of one individual in one role.
An enterprise architecture repository might record the actor as a distinct entity
Or else, perhaps, record an actor merely an attribute of one or more assignment records.
Actors in movies
You may hear a person described as an actor, meaning their main (if occasional) employment is to act in film or theatrical roles.
Of course, the human person is more than a film or theatre actor – much, much more than an instance of that named type.
Reading a movie’s credits you may see a person’s name listed against a role; relating that role to the person who acted it.
But you know that acting in the movie occupied only a fraction of that person’s time for a fraction of their life.
In short, the person is more than an actor.
One person can be listed as an actor many times, playing different roles in different films, or even in the same film.
If your favourite movie web site records Kevin Spacey separately every time he is employed as an actor in a role.
If it does not record the existence of Kevin Spacey outside any particular role he plays.
Then the site isn’t really interested in actors, only in their assignments to roles.
Actors in business
In business systems, there is a many-to-many relation between roles and individuals.
One individual may be employed in several roles, and from that individual’s viewpoint, each employment looks like one role played.
One role may employ several individuals; and from that role’s viewpoint, each employment looks like one individual.
The entity that resolves this many-to-many relation between role and individual is here called “assignment”.
If your business records a person separately every time he/she appears in a role.
If it does not record the existence of a person outside any particular role he/she plays in the business.
Then your business isn’t really interested in people, only in their assignments to roles.
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0 07/01/2016 20:00
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.co.uk” 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