14 February 2011 Sally Bean 2011 All rights reserved Page 1 of 10

RE-THINKING ENTERPRISE ARCHITECTURE USING

SYSTEMS AND COMPLEXITY APPROACHES
Sally Bean
Abstract
This paper looks at the issues currently confronting enterprise architects and the challenges posed when
extending EA to be the architecture of the enterprise rather than just its information technology. It
describes the contribution that Systems Practice and other disciplines can make to Enterprise
Architecture, and considers how the Cynefin sense-making framework can be used to help indicate the
most appropriate types of approach. The paper was commissioned for the Journal of Enterprise
Architecture and published there in November 2010. It develops ideas that were presented at an ICEIMT
workshop on The Future Enterprise Architecture: Fusion of Management Science and Engineering in
Bled, Slovenia in December 2009, and at the EAC Europe conference in London in June 2010.
CURRENT STATE OF ENTERPRISE ARCHITECTURE
Enterprise Architecture is a discipline that aspires to improve enterprise coherence, yet is itself often
seems rather incoherent, mainly due to the fact that it is still relatively immature. There is confusion over
its meaning, purpose and scope, and also the role of the EA function. Its often unclear from reading
current literature on EA whether an author is referring to a knowledge base, a process/practice or a team
of people. So it will be helpful to begin this paper with a brief overview of the current state of Enterprise
Architecture, since opinions of what it actually is or should be are so diverse.
The majority of EA efforts to date have been directed at organizing IT systems (data, applications and
systems software and Infrastructure) from an enterprise-wide perspective, ensuring that these are
consistent with business strategy and adaptable to change. EA is now increasingly being extended, with a
greater focus on business architecture, since it is becoming difficult to separate business decisions from
technology ones. However, there are variations in the way that this extension is viewed. Some
enterprise architects view business architecture purely as a descriptive tool for describing organizations in
a structured way in order to provide a better context for IT exploitation and management, whereas others
see it much more as a strategic design of the enterprise itself to improve efficiency, effectiveness or
innovation.
Most definitions of EA take enterprise to be an organization or business unit. In practice, EA techniques
are often applied to the implementation of an endeavor, i.e. a large programme or project. Potts
proposes that a definition of EA that makes more sense to executives ought to be more orientated
towards the entrepreneurial meaning of enterprise, and suggests that EA should be about the creation of
structural innovations (Potts, 2010). Both Potts and Graves assert that the scope of EA goes wider than
the organization, and includes the world around the enterprise (Graves 2010).
There are usually 3 strands to EA activity, each of which may have business, information and technology
elements:
14 February 2011 Sally Bean 2011 All rights reserved Page 2 of 10
A prescriptive strand determining, agreeing and promulgating fundamental design principles,
policies and standards in support of organizational strategies, risk reduction and key
performance characteristics. These can then be applied to relevant decision-making in
business/IT development projects.
A descriptive strand creating an aligned set of formal models that define key elements of the
business, its information systems and its technologies and managing these in such a way that the
relationships between these different elements can be clearly understood. These facilitate
understanding of what is involved in business or IT change and can provide a common starting
point for new business or IT development projects.
A programmatic strand: - designing a target state architecture and identifying and coordinating
the significant projects, commitments, and milestones to move towards it, including the
development of core building blocks that can be shared across different projects.
Existing EA teams typically carry out blends of these 3 strands of activity with varying emphasis on
business, information, applications and technology architecture.
Overall coherence is achieved by the use of guiding principles and an enterprise architecture framework.
A formal approach to EA requires that such a framework is underpinned by an underlying metamodel that
shows how all the different elements of the framework are related to each other. A less formal approach
simply uses a framework as a classification tool to organize different types of knowledge artifacts that
guide business and IT development.
The existing frameworks and methodologies for EA practice are generally very oriented towards the
internals of EA content and processes and make it very difficult for business people to grasp how an EA
approach will benefit them or their organization. The Zachman framework has a clear logic to it which is
easily grasped in theory but hardly any organizations have successfully managed to achieve the expected
benefits of creating and exploiting Zachman-compliant models in practice. The sequence of processes in
the TOGAF ADM makes logical sense to an IT person, and can be mapped to IT planning and
development lifecycles, but is more difficult to link into the normal processes of an enterprise
This means that the practitioners in a typical EA team often struggle to demonstrate the value of their
efforts. They frequently fail to achieve the right degree of business involvement, may be out of touch
with whats happening on the ground in project deliveries, and viewed as barriers to progress, rather than
enablers of change. The standards and knowledge assets produced by EA teams may not be effectively
promulgated and are not always appropriate or easily consumable by their intended audiences. Often
several iterations of EA programmes are required before an organization finds an approach that works for
it.
Despite these difficulties, there is now good evidence that organizations can benefit from an effective
approach to EA. Ross, Weill and Robertson assert that such companies have higher profitability,
experience a faster time to market, and get more value from their IT investment. (Ross, Weill,
Robertson, 2006). Some EA groups are gaining increased influence in their organizations and using their
EA knowledge-bases and experience to help make more informed strategic decisions about business
change as well as IT investment.
14 February 2011 Sally Bean 2011 All rights reserved Page 3 of 10
BUSINESS-ORIENTED ENTERPRISE ARCHITECTURE
The term enterprise architecture is somewhat misleading, since even those people who are part of a
business-facing EA team are not actually designing enterprises; they are more likely to be acting in an
advisory role and/or to be managing a repository of information. For example, a definition of EA recently
produced by The Enterprise Architecture Research Forum in South Africa (EARF, 2010) defines EA to be
the continuous practice of describing the essential elements of a socio-technical organization, their
relationships to each other and to the environment, in order to understand complexity and manage
change.
On the other hand, people who have been highly successful in designing or evolving enterprises are rarely
or never termed enterprise architects. Examples include Steve Jobs of Apple who has exploited the skills
of designers in his organization and new business models to generate value from technologies invented
by other people, and AG Lafley who embedded Design Thinking into P & Gs way of working (Martin,
2010) to focus more directly on the end consumer. Executives will generally turn to management
consultancies when they need advice on business change design, rather than their enterprise architecture
team. However, the problem with many strategy consulting approaches to business change is that they
are highly context-dependent what works in one organization doesnt work in another, and they dont
turn out to be particularly sustainable as learning is not retained. Additionally, top-down approaches do
not take sufficient account of problems or opportunities at the working level, and this is becoming more
of an issue as organizations become more networked and fragmented. Many authors (e.g. Haeckel ,
1999)have described the need for organizations to become more responsive, which means the ability to
respond to changes in the environment without the overhead of costly transformational projects.
Establishing a role for an EA team whose remit goes beyond IT is a major piece of organizational design in
its own right which needs to be considered in the context of this new, more networked world of business.
This is fundamentally different from simply thinking of an EA team as a group of people providing services
to the rest of the organization. It requires the organization to carefully examine its current business
change capabilities and then explore the concept of enterprise architecture; what it means, whether its
appropriate, how it might make a difference, and how it can best be positioned within the organization.
This then needs to be revisited regularly in the light of experience.
In doing this, an organization should also recognise that there are many other fields that provide relevant
knowledge in this area, which may need to be incorporated as part of an EA practice. Particularly relevant
areas of interest are systems practice and complexity science. These offer a range of different ways of
understanding organizations and proposing interventions for changing them, and will be discussed later
on in this paper.
The management of the EA discipline must take account of politics, power and competing interests. The
value system inherent in EA is generally seen as promoting the overall enterprise longer-term
perspective over short-term local considerations, which creates resistance from people who have
different interests. It should be observed that this value judgement is not baked into EA which should
really be more about creating a process where these types of trade-offs are evaluated and considered
rationally to assess whether they are consistent with the organizations strategy and operating model and
whether they are taking appropriate account of risks.

14 February 2011 Sally Bean 2011 All rights reserved Page 4 of 10
WHAT IS THE ESSENCE OF ENTERPRISE ARCHITECTURE?
As we have seen, current perspectives on enterprise architecture are diverse. The author believes that a
standard definition, acceptable to all, is unlikely to be developed in the near future and each organization
will need to develop its own definition for its particular context.
While the overall heritage of EA is the domain of IT, there are different roots such as software/
hardware architecture, and John Zachmans Framework, based on empirical observation of how large
complex objects are engineered and constructed to meet the needs of a client owner. The danger with
these engineering perspectives is that they dont take account of the human, behavioural dimension of
organizations, and are predicated on an assumption that order is invariably a desirable quality of
business. On the other hand, we should not lose the IT dimension of enterprise architecture altogether,
since information is crucial to enterprise performance.
As Morgan points out in his book Images of Organization (Morgan, 1997), mechanistically structured
organizations have great difficulty adapting to changing circumstances because they are designed to
achieve predetermined goals, they are not designed for innovation. Morgan describes the strengths and
weaknesses of other organizational metaphors, and shows how applying several metaphors in turn can
help to generate insights while avoiding the traps and limitations of taking metaphorical views too far.
As long as one is mindful of the risk of over-extending metaphors, direct comparisons with building
architecture can be useful and interesting. Insights can be drawn from the work of architects such as
Christopher Alexander (1979) who has inspired much interest with his work on architectural patterns and
Stewart Brand, whose book How Buildings Learn (Brand 1994) describes how the architecture embodied
in some buildings allows them to change and evolve gracefully over their lifetime. This can incorporate a
more humanistic dimension, since architecture of buildings and to some extent, cities, is concerned with
aspects such as context, purpose, meaning, conceptual integrity, style/aesthetics as well as structure.
Most current EA practice does not address the social aspects of organizations, since the scope of the role
has been historically oriented more towards rational, ordered analysis of business issues. In their book
Lost in Translation Green and Bate (2008) point out the risks of this, and illustrate how their VPEC-T
approach incorporates some social aspects of business change, by including the dimensions of Values and
Trust in their analysis. Gartner have recently published a research paper on Hybrid Thinking (Gartner,
2010), that is centred on human aspects of change and how they fit with enterprise architecture and
other similar practices.
Doucet et al (2009) consider the major goal of EA to be coherency management. They describe a
progression of EA from Foundation Architecture (Aligning IT with Business Goals) through Extended
Architecture (Co-designing Business and IT change simultaneously in projects), to Embedded
Architecture, where generically architectural methods and ways of working are embedded in the normal
processes of the organization and a level of coherence that is appropriate to the organizations culture
and operating model is achieved and maintained organically.
What is a generically architectural way of working and is it always appropriate? What level of coherence
is necessary in a given organization? While it is true that all too many employees and customers of
businesses find them bewilderingly incoherent at times, a degree of diversity and unpredictability is also
healthy in order to engender creativity and innovation.
14 February 2011 Sally Bean 2011 All rights reserved Page 5 of 10
The essence of architecture in an abstract sense can be summarised as follows
A non-linear process of enquiry, exploration and design
A clear understanding of context
A minimum subset of guiding principles required to achieve coherence, guiding design decisions
with an eye on the future. Knowing when to override them and how to manage the
consequential risks.
A set of models that enable visualisation and exploration of different perspectives on the
situation
The ability to differentiate areas of stability from areas of change
The ability to identify common patterns and ways of reproducing or avoiding them
An ultimate result that is pleasing and inspiring to the user and is capable of evolving gracefully
over time
This list has much in common with the field of Systems Practice which has various methods to explore
properties such as coherence. It might therefore be argued that Enterprise Architecture can be thought
of as Systems Practice and Information Systems for the enterprise. This will be explored further in the
next section.
APPLYING SYSTEMS AND COMPLEXITY-BASED APPROACHES TO EA
EA and Systems Practice share modelling as a key activity, along with a number of other characteristics. A
comprehensive treatment of the history of systems practice is beyond the scope of this paper, but in
essence, it is a collection of different ways of looking at phenomena or problems in a holistic way, as
distinguished from the more common reductionist approach of logically breaking problems or situations
down into constituent parts and working on them separately. Systems Practice values wholes over parts,
emphasises natural laws such as feedback and requisite variety, and uses a variety of models to
understand inter-relationships and consider how situations are likely to evolve over time. In this context,
the word system has a much wider meaning than information system or even a designed physical
system like an aircraft, and refers to a way of looking at the world in general.
Wilson gives a good example of this, relating to the programme to produce the Concorde aircraft in the
60s. The aircraft itself was a designed physical system with a technical specification covering
characteristics such as speed, capacity and number of engines. However, as a human activity system, the
Concorde programme could be viewed as having a number of different purposes (each open to
interpretation and discussion, including the obvious one of transporting passengers rapidly and the less
obvious one of persuading the French to let Great Britain join the European Common Market (now the
EU). This example illustrates how methods of investigation need to be able to surface multiple viewpoints,
worldviews and perceptions and find accommodations between them.
The scope of Systems Practice is broader than EA and it can be applied to organizational units, or messy
issues in any context.
Like EA, Systems Practice is a discipline that draws on different traditions and approaches, and these
approaches have themselves evolved over many years. Systems Practice in an organizational context
usually involves the construction of a conceptual model which can be used in a number of ways:
to reason about conditions in the real world from a range of perspectives
14 February 2011 Sally Bean 2011 All rights reserved Page 6 of 10
to provide a reference model against which other architectural elements can be mapped
to provide a basis for planning information systems.
An example of this type of model being produced and used in an enterprise architecture context is given
by Bailey (2008). The Conant-Ashby theorem states that organizations cannot be effectively managed
without such a model (Hoverstadt, 2008). Note that the systems practice community is somewhat
distinct from the complexity community, which has a different set of ways of looking at the world. These
will be discussed later.
In the case of Systems Dynamics (Forrester, 1961), the models represent the cause-effect and feedback
loops that drive behaviour in a non-linear way. Management cybernetics and the Viable System Model
(Beer, 1972) provides a means of looking at the ability of an organization to adapt to changes in its
environment by recursively considering different types of activity , how they are related to each other
and assessing how to cope with variety. The Soft Systems Methodology (Checkland, 1990) views systems
thinking as an ongoing process of enquiry , using models of purposeful activity , and analysis of roles,
norms and values to structure a discussion that improves shared understanding of multiple perspectives
on a problematic situation and actions to improve it. Value Network Analysis (Allee, 2002) is a means of
mapping tangible and intangible value creation among participants in an enterprise system.
There is an important distinction between ontological models of a reasonably well-understood domain
that purport to represent parts of the real world, and epistemological models that are used to explore
perceptions of the real world (Checkland 2004). Epistemological models are not necessarily models of
reality but are designed to support discussion, debate and argument about peoples perceptions of
reality, where the real nature of the problems to be tackled is unclear. As Hoverstadt (2008) points out
such a process can be very valuable, as otherwise, mental models slide undetected into discussions and
then dominate the way that managers think about their situation.
Soft Systems Methodology is based on an epistemological viewpoint, whereas Systems Dynamic s models
are more likely to be used for predicting outcomes, based on observations and assumptions about the
real world. The Viable Systems Model tends to be associated with deterministic approaches but is
amenable to an epistemological exploration as well, and is very useful as a diagnostic tool to identify
areas where organizational cohesion and information system flows can be improved.
The utility of systems approaches is therefore highly dependent on selecting ones that are appropriate to
the situation. The Cynefin Framework (Kurtz & Snowden, 2003), which originates from Snowdens work in
knowledge management but is informed by complexity science and is also applicable to strategy
formulation, provides a means of exploring different organizational contexts and selecting approaches
accordingly. Cynefin is a sense-making framework which allows people to better understand the contexts
within which they are operating. It is based on the following systems typology, where agents are anything
that interacts with the system:
Ordered Systems are characterised by repeating relationships. Cause and effect are readily
discoverable by empirical observation or other investigation. The nature of the system constrains
the agent.
Chaotic Systems have no discernable relationship between cause and effect. Agents are
unconstrained and present in large numbers
14 February 2011 Sally Bean 2011 All rights reserved Page 7 of 10
Complex Adaptive Systems exhibit no discernable relationship between cause and effect. Agents
and system co-evolve. The result is a system that operates in far from equilibrium conditions and
is inherently unpredictable.
Current Enterprise Architecture practice (and indeed most management theory) is predicated on an
assumption that organizations would be more effective if they exhibited a greater degree of order, but
this may or may not be true in a rapidly changing world that is becoming more networked and diverse.
Snowden (2009) points out that the nature of complex adaptive systems renders many current
approaches to strategy and planning, where complicated and detailed plans are constructed, to be highly
questionable. He also points out that overly constraining a complex adaptive system, treating it as if it
were an ordered one, can lead to chaos.
The Cynefin framework illustrates the principle of bounded diversity; different tools and methods apply in
different contexts. So if Enterprise Architecture is to be successful as a discipline, its practitioners must
recognise this phenomenon and adapt their practice accordingly. The framework is shown in Figure 1. It
positions the above 3 types of system relative to each other with a further split of Ordered systems into
those which are Simple, where cause and effect are easily discernible, and those which are Complicated,
where cause and effect can only be discovered by expert analysis. Figure 1 also includes recommended
strategies for dealing with issues in each domain.


FIGURE 1: THE CYNEFIN FRAMEWORK
Snowden recommends the use of narrative capture techniques and safe-fail experiments to explore issues
in the complex domain, where defined outcomes cant be identified and it is important to consult widely.
Guiding principles may be appropriate to influence desired behaviours and discourage those that are
undesired. He proposes that the value of the types of systems models described earlier will diminish as
organizations become more networked and the level of complexity increases. Note that Cynefin is a
sense-making framework, not a categorisation framework. It is intended to be socially constructed as an
emergent property of peoples interaction and discussion about factors and elements in a particular
14 February 2011 Sally Bean 2011 All rights reserved Page 8 of 10
context. For this reason, there is a 5th domain in the centre of the diagram, that of disorder, where
people cannot agree on how something fits.
While it is true that use of narrative provides a rich human perspective on situations, it has been the
authors experience that, even in the complex domain, simple epistemological models can be extremely
powerful as a means of coalescing emergent ideas and helping to explore messy situations where there
are lots of different viewpoints, missing information or novel thoughts emerging. Such an exploration can
expose different mental models and clarify a coherent path to move forward, often involving the
identification and shaping of appropriate projects. Such ideas might include a complicated but bounded
project that is more amenable to rational analysis and design or a set of safe-fail experimental projects.
It is possible to envisage pathways in time through the Cynefin space and create an evolutionary portfolio
of projects. An organization might decide to explore a vague and complex business idea, such as customer
relationship management, and begin by making observations and collecting narratives from customers
and the people who deal with them to understand what customers really think about the organization
and how employees relate to them. This might generate areas for further investigation, in the complex
domain, to explore how information, resourcing or other human issues inside the organization impact
customers and their relationship with the organization. These could be carried out with VPEC-T or Value
Network analysis. Alternatively the organization might decide to run some safe-fail trials of new ideas for
products and services. The narrative analysis might also identify some resourcing problems which could
be analysed by an expert with a more deterministic modelling tool a complicated activity, or some
operational problems with a simple process that could be tackled with some diagnostic activity.
Having developed a concept of what customer relationship management means for the organization
(which could be explored and agreed using Soft Systems methodology), a project could then be
established to acquire or build an information system to support it. This could involve a mixture of
complex and complicated activity. All of this activity could be mapped against a capability model so that
the impact on different parts of the organization can be assessed and any risks identified.
Johnstons paper (Johnston 2005) illustrates very clearly how the Cynefin model can be applied
specifically to IT architecture. He points out that IT architects must understand and work with the forces
of Unorder and also proposes that clear concise IT system visions can help reinforce the development of
desirable patterns. This view of the value of a simple overall architecture diagram as a cohesion
mechanism for the organization is reinforced by Ross, Weill and Robertson with their recommendation
that Enterprise Architecture is encapsulated in a Core Diagram which is widely circulated.
FURTHER IMPLICATIONS OF THIS APPROACH
Enterprise Architecture must support an organizations requirement to adapt and innovate, as well as to
execute. This paper has proposed that, as an alternative to being someone who is concerned primarily
with IT, a future role for enterprise architects in organizations could be to become facilitators of an
evolutionary process of change through the application of systems and complexity approaches and the
maintenance of models and other knowledge assets. They will design multi-disciplinary participative
processes, drawing on external ideas and a wide range of skills from different parts of the enterprise to
identify patterns of behaviour, explore different mental models and develop shared ones. They will
develop a customised framework for managing and maintaining the strategic knowledge assets which are
appropriate for the organizations context and maturity in EA. For this to be successful, the choice of
14 February 2011 Sally Bean 2011 All rights reserved Page 9 of 10
knowledge assets must be carefully made, mindful of the effort required to maintain them, the
importance of communicating them, and getting feedback. This needs to be treated as an iterative
learning process, which evolves in the light of experience and changing priorities.
However, relatively few leaders in organizations today are thinking in this way, and all are facing different
challenges. Enterprise architecture teams who want to adopt this way of working should.
Identify the organizational dynamics and issues that demand EA, rather than trying to push it at
sceptical executives.
Apply the approaches and principles described in this paper to EA as a function itself, being very
clear that its a networked discipline that spreads beyond the core EA team, with executives
responsible for decision-making which is informed by EA activity, and subject matter experts
responsible for contributing to the activity and promulgating the results of it.
Be very flexible in their thinking and appreciative of other peoples perspectives.
Be adept at demonstrating the value of this approach with appropriate anecdotes and concrete
examples.
AUTHOR BIOGRAPHY
Sally Bean is an independent Enterprise Architecture consultant. She advises large organizations in the
private and public sector on how to develop their EA capability and embed EA approaches into their ways
of working. She has over 15 years experience in the field, with 10 years as a member of the EA team in
British Airways. Here she championed many successful initiatives to exploit technology and share data
and applications more effectively across the organization. She also worked on the early stages of the
Terminal 5 project and led a successful Architecture Community of Practice. She is particularly interested
in systems thinking and complexity approaches and their applicability to enterprise architecture, as well
as the human side of enterprise architecture.
REFERENCES
Alexander, Christopher (1979), The Timeless Way of Building, Oxford.
Allee, Verna (2003) The Future of Knowledge Butterworth- Heinemann.
Bailey I.White paper: Using Soft Systems with MODAF 2008. Retrieved 30 Sep 2010 from website:
www.modelfutures.com
Beer, Stafford. (1972) Brain of the Firm. Wiley.
Brand, Stewart (1994) How Buildings Learn, Phoenix Illustrated.
Checkland, P., Holwell, S, (2004) Classic OR and Soft OR an asymmetric complementarity. Published
in Systems Modelling Theory and Practice. Wiley
Checkland, P., Scholes, J. (1990) Soft Systems Methodology in Action. Wiley
14 February 2011 Sally Bean 2011 All rights reserved Page 10 of 10
Doucet, Gotze, Saha, Bernard Coherency Management, iEAi, 2009
EARF (no date) Definition of EA as defined by EARF Retrieved 30 Sep 2010 from website:
http://hufee.meraka.org.za/Hufeesite/collaborations/earf/definition-for-ea-as-defined-by-the-group
Forrester J.W. (1961) Industrial Dynamics. MIT press
Gartner Group white paper Introducing Hybrid Thinking for Transformation, Innovation and Strategy
Retrieved 30 Sep 2010 from website:
http://www.gartner.com/DisplayDocument?ref=clientFriendlyUrl&id=1352013
Gorzynski Bob and Snowden, Dave (foreward) (2009) The Strategic Mind, Management Books.
Graves, Tom (2008) Real Enterprise Architecture. Tetdradian.
Green, Nigel, Bate, C arl (2008) Lost in Translation. Evolved Technologist Press
Hoverstadt, Patrick (2008), The Fractal Organization. Wiley
Johnston, Andrew (2005) Masters of Order and Unorder. Retrieved 30 Sep 2010 from website:
http://www.agilearchitect.org/agile/articles/order%20and%20unorder.asp
Kurtz. C.F. and Snowden, D.J. ( 2003), "The new dynamics of strategy: Sense-making in a complex and
complicated world", IBM Systems Journal, Volume 42, Number 3, 46 also see: www.cognitive-edge.com
Morgan G (1997), Images of Organization. Sage
Potts, Chris (2010) Presentation at EAC Europe: Driving Business Change with Enterprise Architecture
TOGAF
TM
Version 9 (2009), The Open Group Architecture Framework. Open Group, www.opengroup.com
Zachman J A. (2003) The Zachman Framework
TM
for Enterprise Architecture. A Primer for Enterprise
Engineering and Manufacturing,
.