Business
capabilities as formalised social systems
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.
What does it mean to say enterprise architecture regards an enterprise as a system, or system of systems?
This is one of several papers answering that question.
Contents
The
relevance of the above to EA
Table 1 presents two contrasting viewpoints that capture distinctions made by Seidl and Boulding.
|
Table 1: Theory viewpoints |
A set of |
Who act |
Form a |
|
Actor-centric |
Actors |
As they choose |
Social Group |
|
Activity-centric |
Actors playing Roles |
According to rules |
Social System |
Actors in a social group communicate by using a language to create and interpret messages as they choose to.
Primitive social groups used primitive languages, and members could exchange
only limited information.
Evolution led
to more refined languages and more sophisticated information exchanges.
Actors in a social system don’t communicate or act so freely.
They play roles in which they respond to messages by acting according to rules.
They must
have access to not only the language, but also rules and current state of their
system.
Regulation of
communication and behaviour is essential to the notion of system.
A social group becomes a social system when and where its actors play defined roles.
Moreover, one social group can act as
several social systems – its actors can play unrelated roles in (say) a
football team and a choir.
Using the terms above, EA is about social systems rather than social groups.
Humans have formalised social communication to standardise the transactions of government and commerce.
EA is about formalised social systems, or business capabilities, that are under change control.
EA assumes
communication is formalised using data types to define the meaning of data
items.
Data flows
and data stores are essential to business system and system integration.
Why are the
terms “data” (signal) and “information” (meaning) so confused in EA?
Because the
assumption is that physical data carries the same logical information to all
senders and receivers.
A data flow
sent by actor A will be read with the same meaning by actor B, in a different
time and place.
A data store
records the current state of business entities in a shared memory all
understand the same way.
To this end,
the meaning of data types (for data items and message structures) must be
agreed and defined by system architects beforehand.
Thus,
business capabilities formalise what is fuzzy and ambiguous in purely social
communication.
It is not essential that all individuals in a population share a common language, specialist individuals may communicate using a private language.
EA may strive for a common language, but given a heterogeneous population, there are places where private languages are appropriate.
EA assumes
behaviour is formalised using business rules.
Business
customers, suppliers and employees must share business facts, and understand
the same rules.
Business
system actors act according to rules applied to data flows they receive and
data stores they access.
An actor in a
business system needs to know its language and behavioural rules, and its
current state.
Consider an
order for 2 copies of a book, costing 20 dollars each, to be sent to this
address with these payer details.
A customer
follows rules to encode the order information onto a data entry form
On receipt of
the order form, the supplier decodes the same meaningful information, and acts
according to rules.
When the
supplier takes payment, the customer should be able to detect that system state
change.
With no overarching
direction, human social groups are unstable and evolve continually.
Many social
groups are so unstable it is questionable whether they can be regarded as a
system at all.
By contrast,
the language and behavioural rules of a business system must be stable for a
system generation.
Table 3 presents Enterprise Architecture as being about discrete change rather than continuous change.
|
Table 3: Four kinds of change |
Discrete change |
Continuous change |
|
State (adaptive)
change |
Enterprise Architecture (EA) |
System Dynamics |
|
Generational
(evolutionary) change |
Enterprise Architecture (EA) |
No describable system |
First, the
language, roles and rules of a business system are agreed and documented (in
contracts or in software).
Once the
business system is started, it operates according the documented rules until a
change request is received.
Placing business capabilities under change control is essential to system integration and
EA.
(Though actors and societies evolve accidentally after copying errors in
breeding, communication and recording.)
Enterprise Architecture (EA) regards business capabilities
as formalised social systems.
(This section is replicated with graphics in the associated slide show.)
“The sociological tradition suggests two alternatives: either persons [actors] or activities.” (David Seidl, 2001)
An actor is a discrete structural entity able to perform activities.
An activity is an event-triggered element of behaviour performable by actors
Taking the actor-centric view: given some actors, the question is: what do they do? Or what can they do?
Taking the activity-centric view: given some activities, the question is what actors are needed?
EA is prioritises the activity-centric view.
How does a social
system differ from a social group?
A social group becomes a social system when and where its actors play defined roles.
Discussion of an organisation or enterprise as a system tends to confuse the two concepts..
A social group (actor-centric view) is a set of physical actors who communicate as they choose with each other.
A social system (activity-centric view) is defined by its logical roles (as in a choir or business system).
EA assigns activities to logical roles, then seeks actors to play the roles.
Social systems elements
As Boulding suggested in 1956, the element of a social system is not an actor; it is their assignment to a role
It is that tiny part of an actor’s time and energy that is dedicated to the system of interest.
A social system is not composed of actors, it is composed of their assignments to roles.
At the level if human individuals, there are roles and actors.
A role is the usual or expected function of an actor; it describes a group of activity types one actor can perform
An actor is an individual person, organization, or system that has a role.
An actor may have a number of roles.
Actors (not roles) perform activities.
System descriptions usually name roles rather
than actors.
NB: In a system description, the names of roles and actors are logical identifiers
An actor’s name may correspond to concrete entity locatable in space, in an operational system.
By contrast, a role name will never correspond to a concrete entity, unless that role is played by only one actor.
At the level of groups, there are functions/capabilities and organisation units.
A function describes a unit of business capability, a group of processes that organisation units can perform.
Structured analysis maps functions onto organizational units, which are given managers and objectives.
Organisation units (not functions) perform processes.
System descriptions often name organisation units and/or functions.
Since
the 1960s. software systems have formalised the business capabilities
that formalised social systems.
At the individual level, there are classes and objects.
A class describes a group of operations that one object can perform.
Objects (not classes) perform operations.
System descriptions usually name classes rather then objects.
Business capabilities can be seen as formalised social systems in which actors communicate, play given roles and follow given rules.
Business transactions can be seen as formalised social transactions in which facts are communicated using standard messages and shared memory spaces.
The aim is to enable, support, monitor or direct business behaviour (activities, services…).
Structure - the focus of building architects - is secondary.
The behaviour
is usually orderly, repeatable and under change control (not changed without
approval).
What kind of business capabilities is EA
concerned with?
“EA is the determinant of survival in the Information Age.” (Zachman)
“information-intensive organisations…is the main focus” (ArchiMate v2.1)
“Today’s CEOs know that the effective management and exploitation of information through IT is a key factor to business success.” (TOGAF 9.1)
“EA structures and gives context to activities delivering concrete business outcomes, primarily but not exclusively in the IT [IS] domain.” (TOGAF 9.1)
Data or Information?
Information is data at the point of creation or use by an actor.
(See “Information theory” on the “Sense and nonsense in system theory” page at http://avancier.website.)
In practice,
the terms are interchangeable. Why use a long word when a short one will do?
“Business change” working alongside EA
Taking an actor-oriented view: a business change team may address the groups and customs of actors using a socio-cultural approach.
Taking the activity-oriented view: EA formalised activities which are assigned to roles
People do act above and beyond these roles.
EA does not and cannot
describe every activity that happens in a business.
Architects look to:
· standardise, integrate and share common services between business operations
· realise system descriptions in operational systems
· review compliance of business operations to EA.
Things
essential to business system integration and EA include
·
Formalisation
of information in messages and memories
·
Formalisation
of roles and rules
· Formalisation of change control
· Abstraction of system descriptions from operational systems
What does formalisation mean? EA frameworks are based on two presumptions that few make explicit.
As the UML 2.1 standard puts it:
“all behavior in a modeled system is ultimately caused by actions executed by so-called “active objects”
“behavioral semantics only deal with event-driven, or discrete, behaviors”
Formalisation typically follows this sequence:
· Define events to be recognised and processed (or discrete services to be offered)
· Group the required activities into logical roles (which require abilities that can be found in one actor).
· Hire, buy or build physical actors to act in the logical roles.
Thus, EA
addresses business activities that can be modelled as
discrete event-driven systems.
Business operations include physical actors acting (supposedly) according to their logical roles.
At run-time, an actor responds to an event by performing an activity in the range of activities that define their role (depending on current state information or a memory of past events).
Architects abstract from the infinite complexity of real-world actors and activities
Their business architecture is a logical description of rules applied to the processing of events.
They define roles;
they rarely name an actor unless there is only one of them to play a role.
At most the formal end of business capabilities, there is digitisation of event-driven systems.
Digitisation means business processes are driven by discrete events, and create and use digital data.
Human and computer actors are the components (active objects in UML) of the system.
Communication
of information is via digital data flows; and recording is in digital
databases.
Read this page Sense and nonsense in system theory for more.
Footnote:
Creative Commons Attribution-No Derivative Works Licence
2.0 12/06/2016 20:22
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