Evolution of Enterprise Architecture Discipline
Towards a Unified Developing Theory of Enterprise Architecture Body of
Knowledge as an Evolving Discipline
Hadi Kandjani and Peter Bernus
Centre for Enterprise Architecture Research and Management (CEARM), School of ICT, Griffith University,
Brisbane, Australia
Keywords: Enterprise Architecture Discipline, Unified Theory, Viable System Model, Co-evolution Path Model,
Enterprise Architecture Cybernetics.
Abstract: When studying enterprises as complex systems through the Enterprise Architecture (EA) discipline,
researchers not only apply models, methods and theories of management and control – they ’should’ also
use the same from engineering, linguistics, cognitive science, environmental science, biology, social
science, artificial intelligence, systems thinking and cybernetics. This diversity of related disciplines derives
from the nature of enterprises as multi-faceted, multi-disciplinary entities with interacting dimensions and
different design- and evolution concerns. We believe that for the EA discipline (EAd), like any other
developing and evolving discipline, there should exist a unified terminology, models and methodology.
There already exists a fundamental and generalised theory of EAd, GERAM, however, it is a minimalist
theory, not prescribing any particular reference models or any concrete methodology. Therefore,
practitioners developed particular frameworks, adding concrete methodologies / reference models specific
to the domain / type of change to tackle. The question is: is possible to extend the EA Body of Knowledge
(EABOK) with common elements – independent from the domain / type of change? In other words, what is
a unified evolving theory of EAd? To model the discipline-as-a-system, we use Beer’s Viable System
Model (VSM) and introduce three basic components of EAd as a viable system. A ‘co-evolution
mechanisms’ for EAd is proposed, and a cybernetic model of co-evolution applied to EAd. We also discuss
a cybernetic model of EAd using Checkland’s model for discipline development.
1 INTRODUCTION
For Enterprise Architecture (EA), like any other
developing and evolving discipline, there should
exist a theory, with terminology and rules capable of
unifying the constituent models and methodologies
developed by contributing disciplines. There already
exists a fundamental theory of EA: GERAM,
however it is a minimalist theory, not prescribing
any particular reference models or methodology
(IFIP-IFAC-Task-Force, 1999); (ISO 15704 2000,
Amd. 2005).
The GERAM framework includes a terminology,
with the concepts of enterprise-entity, life cycle, life
history, modelling languages, models, instantiation
and tools, and rules of life cycle relationships,
conceived for use in the management of any change.
The framework provides the user with a generic
reference model for constituents of a life cycle and a
modelling framework, with complete subdivision of
view point concepts (NB these are called ‘views’ in
the original document, but for compatibility with
ISO 42010 (2011) we use the term viewpoint). Note
that this architecture framework and its theory are
independent from the domain and type of change.
For pragmatic purposes, practitioners who
develop(ed) particular architectural frameworks add
methodologies and/or reference models specific to
the application domain and/or the type of change for
which they are intended to be applicable.
For example, DoDAF (2009), as a particular
architectural framework, includes an interoperability
capability assessment reference model, defined as a
series of levels, called ‘Levels of Information
System Interoperability’ (LISI).
TOGAF (1999-2011), as a particular architecture
framework, comes with a methodology to develop
IT architecture, called the ‘Architecture
145
Kandjani H. and Bernus P..
Evolution of Enterprise Architecture Discipline - Towards a Unified Developing Theory of Enterprise Architecture Body of Knowledge as an Evolving
Discipline.
DOI: 10.5220/0003993401450154
In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 145-154
ISBN: 978-989-8565-12-9
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
Development Method’ (ADM).
These particular frameworks (DoDAF, TOGAF
etc.) are domain dependent and were developed for a
specific type of change; whereupon, general
architectural frameworks, such as GERAM, are
independent from the domain and type of change.
The critical question in this paper is that: how is
it possible to extend the EA Body of Knowledge
with common elements that are domain independent
as well as independent from the type of change? In
other words: what is a unified evolving model of EA
Body of Knowledge? By answering this question,
we could in fact have an extension of the theory to
the architecture of any large scale complex system.
Cybernetics and General Systems Theory (GST)
have previously attacked these types of problems at
the same, or similar, level of abstraction and
generality. Therefore, to develop and extend the EA
discipline we need to incorporate the apport of
previously related disciplines and their theories into
a unified theory. As this will no doubt be a long term
process we must treat EA as an evolving and
developing discipline.
Norbert Wiener defined cybernetics as “the
science of control and communication in the animal
and machine” (Wiener, 1948). Ashby (1956) also
calls cybernetics the art of “steermanship” which
studies co-ordination, regulation and control of
systems, arguing that the “truths of cybernetics are
not conditional on their being derived from some
other branch of science”. Therefore the field
embraces a set of self-contained groundings and
foundations, which Ashby tried to describe in his
book (ibid). He addressed the complexity of a
system as one of the peculiarities of cybernetics and
indicated that cybernetics prescribes a scientific
method of dealing with complexity as a critical
attribute of a system.
Stafford Beer believed that the dynamics of
enterprises is about “the manipulation of men,
material, machinery and money: the four Ms”, plus
an even more fundamental “manipulation” (from
microscopic biological organisms to large scale
systems, including enterprises): the “management of
complexity” (Beer 1966; 1985).
Enterprises are best understood as intrinsically
complex adaptive living systems: they can not
purely be considered as ‘designed systems’, as
deliberate design/control episodes and processes
(‘enterprise engineering’ using design models) are
intermixed with emergent change episodes and
processes (that may perhaps be explained by
models). The mix of deliberate and emerging
processes can create a situation in which the
enterprise as a system is in a dynamic equilibrium
(for some stretch of time) – a property studied in
General Systems Theory (Boulding, 1956);
(Bertalanffy, 1968). The evolution of the enterprise
(or enterprises, networks, industries, the economy,
society, etc) includes emergent as well as the
deliberate aspects of system change, therefore an EA
theory must interpret previous research in both.
This unified theory is indeed to be a developing
theory, describing evolution of the EA body of
knowledge, therefore it should remain open for
further continuous contributions of EA practitioners
and researchers. The integrating, or interdisciplinary,
aspect of EA manifests when studying enterprises as
complex systems. Here, researchers not only apply
models, methods and theories of management and
control (and apply the same from engineering,
linguistics, cognitive science, environmental science,
biology, social science, artificial intelligence,
systems thinking and cybernetics), there needs to be
a synthesis of these.
Given this standpoint many theoreticians can
contribute to the development of a unified theory of
designing / architecting complex systems, taking
into account a list of concerns expressed (issues
addressed) by different disciplines that are related to
‘designing’ systems. We call these design- or
architecture- concerns ‘metaphors’. We can describe
the architecture (i.e. ‘architecting’) process as:
a Conversation between the controller of the
system, the system’s ‘operations’ and the controllers
of environmental ‘entities’ (Conversation Theory
(Pask, 1975)),
a Decisional & Resource Allocation Process
(using GRAI Grid (Doumeingts, 1984; 1998)),
Complex Process managed to reduce complexity
and improve the likelihood of success (applying
Axiomatic Design Theory (Suh, 1990; 2001; 2005)),
an Emergent and Evolutionary Process (using
Complex Adaptive Systems Theory (Holland 1992);
(Gell-Mann 1994)),
a Planning & Prediction Process (using Multi-
Agent Systems Theory theories (Wooldridge and
Jennings, 1995); (Wooldridge, 2002)),
a Participatory Process (using models of
Participatory Design (Kensing et al., 1998); (Bødker
et al., 2004)),
a Change Process (using Re-engineering
Methods and approaches (Hammer and Stanton,
1995)), and
a Learning Process (using Systems thinking and
Cybernetics theories (Ashby, 1956; 1960);
(Senge,1993); (Nonaka and Takeuchi, 1995).
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
146
To develop a unified theory of large scale systems
evolution as an extension to the EA body of
knowledge, one should therefore review previously
developed theories, models and terminologies that
study the problem of designing / architecting
complex systems.
In order to ensure that this unified theory has
sufficient breadth and depth, it is useful to analyse
how researchers previously considered the problems
and concerns of this area. This useful to understand
underlying concerns and problems that various
researchers have had when designing architectural
processes/ frameworks, but it could also bring new
discoveries via this theory unification process.
When studying enterprises as (partially designed
and partially evolving) complex evolving systems,
many researchers and practitioners implicitly apply
methods and models derived from laws and theories
of systems thinking and cybernetics. Cybernetics, as
an interdisciplinary movement, has formulated
multiple laws and theories of complex systems, but
each one is presented on a different level of
formality, generality and abstraction. Consequently,
the application of these laws and theories in
Enterprise Architecture (EA) also lack harmony.
Therefore, we introduce EA Cybernetics as a field of
EA with the intention to harmonise, formalise,
synthesise and systematise results of multiple
disciplines, using systems thinking and cybernetics,
for a concerted and coherent application.
Manage
ment
Operation
Variety
Attenuator
Variety
Amplifier
Variety
Attenuator
Variety
Amplifier
Figure 1: Three components of the Viable System Model
(VSM) (Beer, 1985).
EA Cybernetics is the re-interpretation of old-
and new theories to understand their individual
contributions, and to point at the need for genuinely
new results when designing and creating complex
systems. Cybernetic thinking is a way to unify /
relate the apport of multiple disciplines as the
explain the ‘architecting process’. Such a synthesis
would be the source of a new, unified theory of EA,
giving rise to more powerful theories, methodologies
and reference models than available today.
2 VIABILITY OF THE EA
DISCIPLINE AND EFFECTIVE
EA PRACTICE
In this section we propose a viable model of EA as
an interdisciplinary discipline of designing, creating
and maintaining complex systems.
2.1 Beer’s Viable System Model
Beer (1979) describes every system as consisting of
three main interacting components: Management,
Operation and Environment (see Fig.1).
Every system of interest (circle in the figure) has
a meta-system as its management (represented as a
square in the figure) and operates in an environment
(represented as an oval shape in the figure), where
each component could be further decomposed into
more detailed elements. There are communication
channels among these three components to keep the
operation in homeostasis: these channels are called
‘variety attenuators’ and ‘variety amplifiers’ (Beer,
1979); (Beer, 1981); (Beer, 1985).
According to Beer (1979) the ‘variety’ of the
operations is always less than that of the
environment, and the ‘variety of management’ is
always less than the variety of operations. In
contrast, based on Ashby’s law of requisite variety
(1956), in order to achieve dynamic stability under
change, the variety of operations should be equal to
that of its relevant environment, and the variety of
management should be at least equal to that of
operations. In fact variety attenuation and
amplification mechanisms need to be designed in
order to keep the system of interest viable
(‘evolvable’) in its environment.
However, sometimes the enterprise’s mission,
instead of viability and ‘eternality’ of the enterprise,
is a temporary existence, therefore the demolition or
deconstruction of enterprise or enterprise entities is
an equally important aspect to consider. Like in
construction and civil engineering, a demolition plan
is a set of processes to tear down buildings or other
structures. The same concept applies in EA.
For this purpose, a cybernetic model of EAd
must cover the complete life history of the
enterprises as systems (and system of systems),
EvolutionofEnterpriseArchitectureDiscipline-TowardsaUnifiedDevelopingTheoryofEnterpriseArchitectureBodyof
KnowledgeasanEvolvingDiscipline
147
including all significant life events – creation,
reproduction, merger, as well as decommissioning /
end of life. It is especially this last one, end of life,
that has received insufficient attention in literature,
therefore we propose the concept of Fatal System
Model (FSM) stressing that EA should address the
cradle-to-grave aspect of the enterprise, from birth
(creation of enterprises or agglomerations thereof) to
decommissioning (states which finally make the
enterprise collapse or dissolve, perhaps preserving
valuable elements for re-use).
2.2 The EA Discipline as a Viable
System
It is possible to map the three components of Beer’s
VSM to the EA Discipline itself, and to its
surrounding environment. We consider the
enterprise-related disciplines as ‘operation’ shown as
a circle, and the EA discipline as its integrating and
interdisciplinary meta-system (‘management’)
shown as a square, with EA’s task being to observe
and cross-fertilise enterprise problem domains as
well as to observe the ‘environment’ (Fig.2).
There are communication channels (acting as
variety attenuators and amplifiers) among the three
components to achieve / maintain the requisite
variety, i.e. in order to keep the EA discipline and its
related disciplines as a system in homeostasis.
EA
Discipline
Enterprise
Related
Disciplines
Variety
Attenuator
Variety
Amplifier
Variety
Attenuator
Variety
Amplifier
Figure 2: Three components of a Viable EA Discipline.
The EA discipline acts as a meta-system that
investigates the enterprise problem domains and
using attenuation mechanism, invokes the relevant
terminology, models and theories from enterprise-
related disciplines (e.g. systems thinking and
cybernetics, industrial engineering, management
science, control engineering, information and
communication technology) to respond to new
issues arising in enterprise problem domains.
Changes in the problem domains mandate the
evolution of individual enterprise related disciplines,
so as to respond to the new requirements of the
evolving environment. In fact the evolution of
enterprise-related disciplines and enterprise problem
domains are coupled and mutually dependent, and
the EA Discipline should act as a meta-system/
management system regulating the requisite variety
between operations and the environment.
In order to harmonise this co-evolution, we need
to understand what are the relevant mechanisms to
guarantee an effective evolution of EA itself.
If we consider EA as ‘problem solving’, then the
step by step stages of co-evolution would be: 1)
diagnose a significant problem in the enterprise
problem domain, 2) invoke one or more relevant
disciplines studying the enterprise problem domain
and decide if such multi-disciplinary combined
action is adequate, and if not, then 3) provide
solutions for enterprise problems by harmonising
and integrating multiple theories, models, techniques
and methods from relevant disciplines in a synthesis
(new or extended theory), and 4) adopt any ‘new’
case records of relevant disciplines and mutual
contributions of EA and relevant disciplines into the
EA Body of Knowledge.
The need for a unifying theory clarifies the role
of EA as a meta-system (as in Beer’s VSM) that
answers the question: a) what enterprise problems
domains would be (or should be) addressed in a
specific EA practices?, b) what would be the
invoked disciplines targeting the problem domains
to solve the problem in combined use?, c) how to
formalise and harmonise other disciplines’
contributions and apply them in an EA practice?
As the invoked disciples are continuously
progressing and evolving in their specific domain
and field of application, a more effective EA
practice could be guaranteed if the evolution of these
disciplines were influences or monitored by the EA
discipline and the findings reflected in EA theory
and practice when necessary.
We discussed three components of a viable EA
discipline so far, now the question may arise: what
are the mechanisms to keep the requisite variety of
the EA discipline and maintain it as a viable system?
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
148
Evolution of the
Enterprise-Related
Disciplines
Evolution of Enterprise
Problem Domains
Evolution
of the EA
discipline
Co-evolution
of
the EAD with
the EPDs
(Effective
EA Practice)
Figure 3: An effective EA Practice: Co-evolution of EA Discipline with Enterprise Problem Domains through invocation of
relevant theories, models and methods from Enterprise-Related Disciplines.
3 CO-EVOLUTION
MECHANISMS FOR AN
EVOLVING EA DISCIPLINE
We discussed three components of a viable EA
discipline in Section 2, now the question arises: what
are the mechanisms to keep the requisite variety of
the EA discipline as a viable system?
3.1 Co-evolution Path Model, Dynamic
Homeostasis vs. Dynamic
Hetereostasis
Beer (1966) argues that a key property of a viable
system and a “measure of its submission to the
control mechanism” is its ability to maintain its
equilibrium or homeostasis, which he defines as
“constancy of some critical variables (outputs)”. In
our model of co-evolution, we define the dynamic
sustenance of requisite variety based on Ashby’s
law: "only variety can destroy variety” (Ashby,
1956), paraphrased by Beer (1979) as "variety
absorbs variety". Here, ‘variety’ is the number of
possible states of a system (Beer, 1981), or as
recently re-interpreted and refined by Kandjani and
Bernus (2011), the number of relevant states of a
system.
For a system to dynamically achieve / maintain
requisite variety and to be in dynamic equilibrium,
the system requires communication channels and
feedback loops. These channels serve as self-
perpetuating mechanism and include both
attenuation and amplification mechanisms. (Note
that for the discussion below what we call a ‘system’
includes the system’s controller.)
Considering the system and its environment as
two coupled entities, if one component is perturbed,
the effect of that perturbation on the other
component is either amplified through positive
feedback, or may be reversed (attenuated) through
negative feedback.
The role of the negative feedback loop is to
reverse the effect of the initial perturbation and
restore the system’s homeostasis (in which critical
variables are stable), while positive feedback can
create unstable states (Ashby, 1940).
We observe that both a system and its
environment (including systems in that environment)
evolve, and the change can create imbalance
between the requisite variety (maintained by the
controller) of our system of interest and the variety
that would be required for it to maintain
homeostasis. In other words, systems that want to
live long must co-evolve with their environment.
More formally: we consider the environment an
entity with a possible set of observable states and if
two such states require different response from the
system then the system must be able to differentiate
between them (thus they are two different relevant
states). (Note that we may not necessarily be able to
describe the environment as a system, although it
EvolutionofEnterpriseArchitectureDiscipline-TowardsaUnifiedDevelopingTheoryofEnterpriseArchitectureBodyof
KnowledgeasanEvolvingDiscipline
149
C
S
= C
E
Static
Homeostasis
C
S
> C
E
Amplification
Mechanism
C
S’
= C
E’
Co-
evolution
C
S’
< C
E’
Attenuation
Mechanism
C
S”
= C
E”
Co-
evolution
C
S’
> C
E’
Amplification
Mechanism
C
S
< C
E
Attenuation
Mechanism
Complexity of the Environment (C
E
)
Complexity of the System (C
S
)
Dynamic Homeostasis:
Sustaining Requisite Variet
y
Dynamic Heterostasis:
Oscillating Requisite Variety
Co-evolution
of the System and its Environment
through First and Second Feedback loops
Figure 4: Co-evolution path model.
may contain one or more systems.)
Consequently, in Fig. 4, the complexity of a
system (C
S
) is defined to be the complexity of the
model that the controller of the system maintains
(appears to be maintaining) in order to manage the
system’s operations, and to maintain adequate
interaction with the environment.
The complexity of the system’s environment
(C
E
) is a relative notion and is defined to be the
complexity of the model of the environment that the
controller of the system would need to maintain the
system’s homeostasis (although, yet again, it is
sufficient if, in the eyes of an external observer, the
system’s controller appears to be maintaining such
model). Specifically, such an ‘environment model’
must have predictive capability, so that the system,
while interoperating with the environment, can
maintain a homeostatic trajectory in time (and
space).
An environment model would include a) models
of external systems (including models of their
controllers and operations), and b) a model of the
rest of the environment. These models are needed to
be able to represent and predict the states of signals
and resources among the system, the external
systems and the rest of the environment. This
because based on the theorem of the ‘Good
Regulator’ (Conant and Ashby, 1970), a good
controller of a system must have a model of that
system with an equal complexity at its disposal as
the system to be controlled has.
Notice (Fig.4) that 1) If the complexity of the
system (C
S
) equals to that of its environment (C
E
),
then the system has the requisite variety and is in
static equilibrium. However, any change in the
complexity of the environment should be sensed by
the system’s self-perpetuating mechanism to restore
the system to its initial state or to create a new
equilibrium state; 2) If the complexity of the
environment is greater than that of the system, then
the system should attenuate the effects of this
complexity, i.e., change and co-evolve with its
environment (in other words, the environment
produced, or is recognised to have the potential to
produce, some states in which the system can not
function adequately); 3) If the complexity of the
system is greater than that of its environment, then
the system can potentially create a set of different
states and perform behaviours which are not
differentiated by its environment. The system can
identify this extra complexity as undesired, or use an
amplification mechanism to create new
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
150
differentiations in the environment (e.g. marketing
of new goods / services).
Enterprises as ‘live systems’ have a number of
variables characterising essential survival properties.
Ashby (1960) refers to these as ‘essential variables’
(crucial to a system’s survival) – modern literature
would refer to these as critical success factors
measured by strategic ‘key performance indicators’.
Ashby (1960) defines survival as: “… a line of
behaviour [that] takes no essential variable outside
given limits” (Ashby, 1960); (Geoghegan and
Pangaro, 2009). Therefore, by definition, any line of
behaviour outside limits of essential variables is on
the non-viable system path and is fatal to the
system’s lifeline.
For a system to be regarded as adaptive, and
therefore viable, Ashby introduces two necessary
feedback loops (Ashby, 1960); (Geoghegan and
Pangaro, 2009); (Umpleby, 2009). The first,
frequently operating, feedback loop makes small
parametric modifications and corrections to the
system. As opposed to this, the second loop changes
the structure or architecture of the system and
operates if the tolerance of essential is predicted to
fall outside the limits of survival. If the system’s
second feedback loop does not respond to the
changes in complexity of the environment, then the
system will be on a non-viable path.
Based on Ashby’s theory of adaptation (1960),
Umpleby (2009) indicates that the first feedback
loop is necessary for a system to learn a pattern of
behaviour necessary for a specific environment,
while the second feedback loop is required for a
system to identify the changes in the environment
and design and create new patterns of behaviour.
If there is a dramatic increase in complexity of
the environment on which the system is not prepared
to act (due to scarcity of resources, lack of dynamic
capability, inability to create new structures / adapt
its architecture in a timely manner), then the lack of
an appropriate second feedback loop makes the
system non-viable and the system is doomed to fail.
3.2 Co-evolution Path Model of the EA
Discipline
Looking at EA as a system (the ‘discipline-as-a-
system’) the co-evolution model of Section 3.1
applies to that system too, therefeore the question:
what are the co-evolution mechanisms through
which the EA discipline can maintain its requisite
variety to remain relevant in light of changes to
evolving enterprise problem domains?
EA as an integrating discipline invokes models,
theories, and methods of related disciplines, an
effective co-evolution is only guaranteed by:
a) invoking the right theories, models, and methods
from Enterprise related Disciplines (ERD) to address
new and emerging Enterprise Problem Domains
(EPD) in a combined use (attenuation mechanism),
and
b) promoting new synthesised EA terminologies,
reference models, and methods to provide solutions
in enterprise problems domains using a holistic
approach (amplification mechanism).
Thus, if at any one time the variety of the unified EA
theory is less than the variety of the enterprise
problem domains, then EA can not respond to the
evolution of enterprise and enterprise architecture as
a discipline must increase its variety by attenuating
the relevant variety through adopting new elements
from relevant enterprise related disciplines.
On the other hand, an Enterprise Architect
should also formulate and execute a promotion
mechanism if the variety of EA models methods and
frameworks is more than the variety of the enterprise
problem domains. In this case, system managers,
users, and stakeholders would not be able to
comprehend these complex EA models, methods and
etc. and would probably avoid using them in the
evolution of enterprise; therefore an enterprise
architect should decrease the variety of its models by
amplifying the variety of the models, or promote the
use of more complex models to invent solutions for
the enterprise’s extended ‘new action domains’.
By using these mechanisms (invocation and
promotion), it would be possible to sustain the co-
evolution of the EA discipline and of problem
domains, to ensure that EA is adaptively and
effectively addressing issues of its problem domains.
The evolution of enterprise related disciplines
should therefore be closely monitored so as to be
able to perform the mentioned ‘invocation’ and
‘promotion’ to provide enterprise problem domains
with relevant combined discipline-contributions in
any EA practice (Fig.5).
4 CYBERNETIC MODEL OF EA
AS AN EVOLVING &
DEVELOPING DISCIPLINE
Enterprise Architecture, like any other developing
discipline, needs a model for theory development,
theory testing and knowledge creation. Anderton and
Checkland (1977) developed a model of any
developing discipline to demonstrate the cyclic
EvolutionofEnterpriseArchitectureDiscipline-TowardsaUnifiedDevelopingTheoryofEnterpriseArchitectureBodyof
KnowledgeasanEvolvingDiscipline
151
Dynamic Heterostasis:
Oscillating Requisite Variety
EA Discipline
Saturation
Strategy
(Effective EA
Practice)
EA
Discipline
Promotion
Mechanism
Co-evolution
of
EPD & EAD
(Effective EA
Practice)
Enterprise
Related
Disciplines
Invocation
Mechanism
Co-evolution
of
EPD & EAD
(Effective EA
Practice)
EA
Discipline
Promotion
Mechanism
Enterprise
Related
Disciplines
Invocation
Mechanism
Complexity of the Enterprise Problem Domains (EA Demand)
Complexity of the Enterprise Architecture Discipline (EA Supply)
Dynamic Homeostasis:
Sustaining Requisite Variety
Co-evolution of
the EA Discipline and the Enterprise Problem Domain
s
through Invocation and Promotion Mechanisms
Figure 5: Co-evolution Path Model of the Enterprise Architecture Discipline.
interaction between theory development and
formulation for a problem, and theory testing
(Anderton and Checkland, 1977); (Checkland,
1996).
For EA to be a developing discipline (Fig.6), we
consider the real world enterprise problem domains
as the source of the development process that give
rise to issues that are addressed by theories, models
and methods in enterprise related disciplines. These
will shape ideas by which two types of theories
could be developed (Checkland 1996):
a) substantive theories derived from related
disciplines to apply relevant models, theories and
methods in enterprise problem domains, and
b) methodological theories about how to
individually apply enterprise related disciplines in
enterprise problem domains.
Once we developed such theories, we can state
problems – not only existing problems in concrete
problem domains, but also formalised, harmonised
and synthesised problem statements by EA
cybernetics within this new theory. Based on a new
theory, one could express new problems and find
new solutions / models never before contemplated.
A unified cybernetic theory of EA may be used
to develop a corresponding methodology (or rather,
methodologies) for use in EA practice. Results of
such synthesis must be tested in practice (through
intervention, influence, or observation) to create
‘case records’, which in turn provide the source of
criticism which allow better theories to be
formulated (and as a result, better models,
techniques, and methodologies). The application of
the latter methodologies should be documented in
case records which could provide feedback to
improve the individual- and the unified theories.
The EA discipline not only embraces models,
methods and theories of management and control –
it also uses the same from systems engineering,
linguistics, cognitive science, environmental science,
biology, social science and artificial intelligence.
What cybernetic thinking is able to do is to
provide a method of unifying (and relating) the
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
152
EA CYBERNETIC
CASE RECORDS
EA CYBERNETIC
METHODOLOGY
UNIFIED CYBERNETIC THEORIES OF EA
FORMALISED ENTERPRISE PROBLEMS DOMAINS
EA CYBERNETICS
Theories, Models & Methods
Gives rise to
Provide
Are harmonised, formalised,
synthesized and systematised by
Which may be
used to develop
Which may be represented using
Which produce
Contribute to
ENTERPRISE
RELATED
DISCIPLINES
ENTERPRISE
RELATED
DISCIPLINES
REAL-
WORLD
ENTERPRISE
PROBLEM
DOMAINS
Addresses
individually by
To be used in EA
Practice (intervention,
influence, observation)
Which
support
criticism
of
ISSUES
Figure 6: A Cybernetic Model of Enterprise Architecture Discipline as a Developing Discipline based on the relationship
between activities and results in a developing discipline (after Anderton and Checkland, 1977); (Checkland 1996).
apport of these disciplines: cybernetic thinking can
be used to represent the essence of multiple theories
using abstract functions and processes (and meta-
processes) and their relationships / rules / axioms
(likely to be expressed in suitably selected logics).
Following the systems thinking diagram of
Fig.6., the contributions of these disciplines needs to
be formalised, synthetised, harmonised, systematised
and eventually represented as a unified Cybernetic
Theory of EA (which we call ‘EA Cybernetics’).
5 CONCLUSIONS
In order to have an evolving unified theory to extend
the EA Body of Knowledge with common elements
that are independent from the domain and the type of
change, we focused on the viability of EA as a
discipline and discussed it using Beer’s Viable
System Model (VSM), and correspondingly
introduced three basic components of a viable EA
discipline using VSM.
We also proposed the concept of a co-evolution
mechanisms for an evolving EA discipline based on
VSM and a companion theory (Ashby’s law of
requisite variety, but with a new, refined definition
of the complexity measure for the model(s) of the
environment, that takes the relativity of this term
into account).
We also proposed a cybernetic model of EA as a
developing discipline using Checkland’s system
model for a developing discipline and introduced EA
Cybernetics as a distinct field of EA that
harmonises, formalises, synthesises and systematises
the results of systems thinking and cybernetics to
enable their concerted application in EA practice.
Future work will concentrate on the application of
this model of EA as an evolving discipline,
whereupon testing and validation of this theoretical
model is to be performed.
REFERENCES
Anderton, R. H. and P. B., Checkland, (1977) On learning
our lessons. Internal Discussion Paper. Lancaster, UK,
Department of Systems, University of Lancaster. 2/77.
Ashby, W. R., (1940) Adaptiveness and equilibrium. The
British Journal of Psychiatry 86(362) pp478-483.
Ashby, W. R., (1956) An introduction to cybernetics.
London: Chapman & Hall.
Ashby, W. R., (1960) Design for a brain; the origin of
adaptive behavior. New York: Wiley.
Beer, S., (1966) Decision and Control: The Meaning of
Operational Research and Management Cybernetics.
New York: Wiley.
Beer, S., (1979) The Heart of Enterprise: the Managerial
Cybernetics of Organization. New York: Wiley.
Beer, S., (1981) Brain of the Firm, 2nd Ed. New York:
Wiley.
Beer, S., (1985) Diagnosing the system for organizations.
New York: Wiley.
Bertalanffy, L., (1968). General System Theory-
Foundations and Developments. New York: George
Braziller, Inc, l0.
Bødker, K., Kensing, F., & Simonsen, J., (2004).
Participatory IT design: designing for business and
workplace realities: The MIT Press.
Boulding, K. E., (1956) General systems theory-the
skeleton of science. Management Science 2(3) pp197-
EvolutionofEnterpriseArchitectureDiscipline-TowardsaUnifiedDevelopingTheoryofEnterpriseArchitectureBodyof
KnowledgeasanEvolvingDiscipline
153
208.
Checkland, P., (1996) Systems Thinking, Systems Practice.
Chichester, UK, John Wiley & Sons.
Conant, R. C. and W. R. Ashby, (1970). Every Good
Regulator of a System Must be a Model of That
System. International Journal of Systems Science 1(2):
89-97.
Doumeingts, G., (1984). La Methode GRAI [PhD Thesis].
Bordeaux, France: University of Bordeaux I.
Doumeingts, G., (1998). GIM, Grain Integrated
Methodology. In A. Molina and A. Kusiak and J.
Sanchez (Eds.), Handbook of Life Cycle Engineering,
Models and Methodologies (pp. 227-288). Dordrecht:
Kluwer Academic Publishers.
DoDAF (2009) DoD Architecture Framework Version 2.0,
US DoD, Washington.
Gell-Mann, M., (1994) Complex adaptive systems. in
Complexity: Metaphors, models, and reality. G. A.
Cowan, D. Pines, and D. Meltzer (Eds) Reading, MA:
Addison-Wesley. pp. 17-45.
Geoghegan, M. C. and P. Pangaro, (2009). Design for a
self-regenerating organisation. International Journal
of General Systems 38(2): 155-173.
Hammer, M., & Stanton, S. A., (1995). The reengineering
revolution: A handbook: HarperBusiness New York.
Holland, J. H., (1992). Complex adaptive systems.
Daedalus 121(1): 17-30.
IFIP-IFAC-Task-Force, (1999). GERAM: Generalised
enterprise reference architecture and methodology.
Version 1(3): 6-3.
ISO15704, (2000, Amd.2005). Industrial automation
systems -- Requirements for enterprise-reference
architectures and methodologies. Geneva: ISO
TC184.SC5.WG1. Geneva, ISO TC184.SC5.WG1.
ISO/IEC/IEEE 42010, (2011) Systems and software
engineering – Architecture description, Recommended
Practice for Architectural Description of Software-
intensive Systems. ISO/IEC JTC1/SC7/WG42.
Kandjani, H., Bernus, P., (2011) Engineering Self-
Designing Enterprises as Complex Systems Using
Extended Axiomatic Design Theory. Proc of the 18th
IFAC World Congr. Miloan, Italy, IFAC Papers On
Line, 18(1). Amsterdam: Elsevier, 11943-11948.
Kensing, F., Simonsen, J., & Bodker, K., (1998). MUST:
A method for participatory design. Human-Computer
Interaction, 13(2), 167-198.
Nonaka, I; Takeuchi, H., (1995). The knowledge creating
company: how Japanese companies create the
dynamics of innovation. New York: Oxford University
Press.
Pask, G., (1975) Conversation, Cognition and Learning.
Amsterdam: Elsevier.
Senge, P. M. (1993). The Fifth Discipline: The Art and
Practice of the Learning Organization: Book review.
Suh, N. P., (1990) The Principles of Design. New York:
Oxford University Press.
Suh, N. P., (2001) Axiomatic design: advances and
applications
. New York: Oxford University Press.
Suh, N. P., (2005) Complexity: Theory and Applications.
New York : Oxford University Press.
TOGAF, (1999-2011) TOGAF 1 – TOGAF 9.1 (Versions
of the TOGAF Architecture Framework). Open Group.
Umpleby, S. A., (2009). Ross Ashby's general theory of
adaptive systems. International Journal of General
Systems 38(2): 231-238.
Wiener, N., (1948) Cybernetics or Control and
Communication in the Animal and the Machine. (2nd
Rev. Ed 1961). Cambridge, MA: MIT Press.
Wooldridge, M. J., (2002). An introduction to multiagent
systems: Wiley.
ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems
154
