Content uploaded by Hamish Sadler
Author content
All content in this area was uploaded by Hamish Sadler on Mar 22, 2018
Content may be subject to copyright.
1
1 Abstract
In this paper, a survey of definitions for
Enterprise Architecture (EA) and Enterprise
Systems Architecture is proposed and it is
discussed how Enterprise Architecture is
different from Systems/Software
Architecture. Whilst for some, the difference
may be obvious; in practice, there are cases
where the boundary becomes unclear and
vague, resulting in a mix-up that affects the
overall outcomes expected from EA. This
paper tries to shed some light on the topic
that for a CIO or CTO or any ICT Executive
could be of interest.
Keywords: Enterprise Architecture,
Systems Architecture, Organizational
Engineering, Systems Engineering
2 Introduction
It is sometimes amazing to see how adding
a single word between two others can make
a big difference in the concept but the
impacts of adding the word “systems”
between “Enterprise” and “Architecture” is
most certainly an interesting one! This may
be the result of the fact that the term
Enterprise Architecture is still being defined
and because of different definitions that
exist for it, some interpretations may result
in a mix-up, “downgrading” Enterprise
Architecture to Enterprise Systems
Architecture in the process.
2.1 Architecture
The international standard for Systems
and Software Engineering - Architecture
Description, ISO/IEC 42010:2011, defines
architecture as the “fundamental
organization of a system, embodied in its
components, their relationships to each
other and the environment, and the
principles governing its design and
evolution” [2]. ISO 42010 cites that the term
“system” is intended to encompass, but is
not limited to, entities within the following
domains:
Systems as described in ISO/IEC
15288: “systems that are man-made and
may be configured with one or more of the
following: hardware, software, data,
humans, processes (e.g., processes for
providing service to users), procedures
(e.g. operator instructions), facilities,
materials and naturally occurring entities”;
Software products and services as
described in ISO/IEC 12207;
Software-intensive systems as
described in IEEE standard 1471:2000: “any
system where software contributes
essential influences to the design,
construction, deployment, and evolution of
the system as a whole” to encompass
“individual applications, systems in the
traditional sense, subsystems, systems of
systems, product lines, product families,
whole enterprises, and other aggregations
of interest”
Insights for a CIO/CTO: Enterprise
Architecture vs. Enterprise Systems
Architecture
By Hamish Sadler
Part of the “Insights for a CIO/CTO” Series
2
It is obvious that in ISO 42010, it has been
attempted to limit the scope of the
definition for “systems”. However, the
original and more generic definition of a
system in general system theory as “a set of
elements in interaction” [3] may be of more
interests, especially within the context of
EA.
2.2 Enterprise Systems
Architecture
Enterprise Systems (ES) are generally
application software packages that are used
in an enterprise environment for different
purposes that may include support or
automation of business processes,
information management, budget/finance
management, corporate performance
management, human
resources and payroll
management, reporting,
audit, analytics, business
intelligence and many
more. In the context of
ICT, Enterprise
Information Systems are
systems that support
operations, management
and decision-making in enterprise
environments. In many cases in the ICT
domain, the terms Enterprise Information
Systems and Enterprise Systems can be used
instead of one another due to their focus on
software systems.
Just like how software architecture is
defined for any other type of software
systems, enterprise systems architecture
can be defined as “the high level structure
of a software system, the discipline of
creating such structures, and the
documentation of these structures” [4].
This level of architecture is associated with
the highest level of implementation-related
details and is concerned with the software
design principles (e.g. the SOLID object-
oriented design principles [5]), software
design architecture patterns (e.g. Model-
View-ViewModel design pattern [6]), or
software design paradigms (e.g. service-
oriented architecture [6], or hexagonal
architecture [7]).
In plain language, software systems
architecture is about fundamental
organization and structure of software
systems, described as components,
relationships between and rules around such
components.
It can be argued that what software
architecture brought to the software
engineering domain is a transformation
pathway from spaghetti-like designs
towards loosely coupled highly cohesive
componentized functionality.
2.3 Enterprise
Architecture
MIT Centre for
Information Systems
Research (MIT CISR)
defines Enterprise
Architecture as “The
organizing logic for
business processes and IT infrastructure
reflecting the integration and
standardization requirements of the firm’s
operating model” [1]. This definition is more
mindset-centric and reflects that EA is more
made of “logic” than “approach” or
“content”.
TOGAF defines enterprise architecture as
“A conceptual blueprint that defines the
structure and operation of an organization”
and cites that the intent of an enterprise
architecture is “to determine how an
organization can most effectively achieve its
current and future objectives” [8].
Accordingly, this definition has colours of
artefact, content and model orientation.
Gartner defines Enterprise Architecture as
“A discipline for proactively and holistically
It can be argued that what
software architecture brought to
the software engineering domain is
a transformation pathway from
spaghetti-like designs towards
loosely coupled highly cohesive
componentized functionality.
3
leading enterprise responses to disruptive
forces by identifying and analysing the
execution of change toward desired
business vision and outcomes”. It highlights
that EA adds value by “presenting business
and IT leaders with signature-ready
recommendations for adjusting policies and
projects to achieve target business
outcomes that capitalize on relevant
business disruptions” [9]. Gartner’s
definition is more
discipline/method/approach centric than
artefact, content or mindset centric.
3 The Problem
Despite the fact that the definitions seem
to be self-explanatory but in practice, things
are different to the extent that ICT research
firms like Gartner have compiled their list of
“what EA is NOT”, like [10]. This reflects the
fact that the roles, responsibilities and focus
of an EA capability are not quite clear yet, as
we explore the reasons.
In summary, the biggest confusion is
around whether or not an EA capability’s
domain of activity is the enterprise itself,
which is more of a business matter, or, it is
“enterprise systems”, which is more of an
ICT matter, or both.
3.1 The Zachman Transition
The mix-up and confusion in the definition
of Enterprise Architecture may have its roots
in John Zachman’s work from the 80’s
where his first papers (like [11, 12]) did
contain references to the term “enterprise
architecture” but were more focused on
“information systems architecture”.
However, somehow, in its future
incarnations, the Zachman Framework
moved away from being focused on
enterprise information systems and matured
into “a fundamental structure that provides
a formal and structured way of viewing and
defining an enterprise”.
In the author’s view, somewhere along the
way, as a thought process, it must have
looked rational that one could take the same
architectural approach that was used to
describe and model complex enterprise
information systems to actually describe the
enterprise itself.
In the author’s view, the problem of
modelling and designing an enterprise may
have originally been a better fit for business
administration or organizational engineering
domains but a software architect’s answer
to the problem of engineering an enterprise
could be a compelling one too!
Zachman’s framework has been one of the
first comprehensive enterprise architecture
frameworks in the industry but in the
author’s view, somehow along the way, the
transition from “information systems
architecture” to “enterprise architecture” is
not understood or acknowledged to the full
among practitioners. This ambiguity may
also explain why many EA capabilities are
formed inside corporate ICT divisions and
despite the efforts to engage the “business”
in the game, somehow, end up becoming
“Enterprise Systems Architecture”
capabilities without the technical depth
required in this domain. This leads to a state
of limbo where EA capabilities are not
necessarily helping the re-design of business
or the enterprise and yet, may not have the
interest or skills in the technicalities of
architecting enterprise systems either.
3.2 The EA Implementation
Spectrum
Depending on the context and
environment, the outcome of EA
implementation may result in a spectrum of
possibilities, from being focused on
“designing” the “business” to becoming a
passive governance “gateway” in the
development or acquirement of ICT systems.
4
Figure 1 - Enterprise Architecture Stages [1]
In MIT CISR’s view and definition, EA has
been cited as a strategic concept (as
opposed to tactical). This tendency goes as
far as citing EA as “business strategy” itself
[13] and creates the view that enterprise
architecture is more linked to the
administration, formulation, design, and
engineering of the enterprise itself rather
than being linked to architecting and
designing ICT systems. This view gets even
bolder when witnessing the four stages of
EA maturity (which is the topic of yet
another paper in the series), as Figure 1
illustrates. Accordingly, “standard
interfaces” and “business
componentization” have been cited as two
characteristics of the fourth and most
advanced stage of EA which
results in strategic
“business value” (which is
the topic of yet another
paper in the series), and has
been labelled as “Business
Modularity”, which
accounts for only 2% of the
studied firms [13].
It can be argued that in
this view, what enterprise
architecture brought to the
enterprise/organizational engineering
domain is a transition pathway from
spaghetti-like business-silos-infested design
of an enterprise towards a design based on
business components and standardized
interfaces.
An example that may make understanding
“business componentization” easier can be
viewed in Figure 2, which demonstrates
Delta Airlines’ EA. This encompasses the
entire business of the airline and
demonstrates a modular representation of
its “design” (i.e. architecture) and shows a
“way” of architecting an airline’s business.
What if the problem was to architect a
freight/shipping enterprise? Wouldn’t it
make a lot of sense to consider “airport
depot operations” to be a “class” of
“business components” with “similar”
inputs, outputs and
operations (i.e.
standardized
interface) and design
the business with this
mindset (which
happens to be very
similar to an object-
oriented mindset)? Or,
what about
architecting an
enterprise around the
services that it provides, which may be a
way of borrowing service-oriented mindsets
It can be argued that what
enterprise architecture brought to
the enterprise/organizational
engineering domain is a transition
pathway from spaghetti-like
business-silos-infested design of an
enterprise towards a design based
on business components and
standardized interfaces.
5
Figure 2 Delta Airline's Enterprise Architecture [1]
into the design of business.
Under this view, Enterprise Architecture
goes above and beyond a governance
mechanism with the goal to align ICT
investments with business
strategy; in fact EA becomes
the business strategy itself; a
foundation for business design
and execution.
One could extract another
definition for enterprise
architecture out of this view as
“An integrated approach to
engineering and transforming an enterprise
with the goal to componentize business and
standardize interfaces between business
components”.
If this view is taken, then an enterprise
architecture capability should operate under
(and potentially be part of the office of) the
highest-level executive role of the
enterprise; the party that owns the authority
to drive transformation and/or engineer,
design, or architect the entire enterprise.
Under these definitions, the profile of an
enterprise architect takes an interesting
shape. The dimensions and skills required for
a successful enterprise architect have been
cited as the “Enterprise Architecture
Paradox”, articulated as “technology genius
meets business strategist meets
accomplished manager meets expert
communicator” [14]. With the expectation
of being a source of
advice on
engineering and re-
desinging an entire
enterprise, the
profile of the role
may take the shape
of an executive-
calibre individual
who happens to be a technologist, leader,
persuader, and stakeholder management
guru; who willingly or unwillingly, is no
longer an executive and has landed an
enterprise architect role with the capability
and influence to convince an active
executive of custom ways to re-design their
enterprise, while being well trained to deal
with the minefield of “ego”, which is the
result of the fact that in many ways, “the
enterprise architecture position embodies
much of the paradox that faces the CIO
position” [14].
With all the above said, in practice,
observations are different. Firstly, most
Enterprise Architecture capabilities end up
“An integrated approach to
engineering and transforming an
enterprise with the goal to
componentize business and
standardize interfaces between
business components”
Author’s definition for Enterprise Architecture
6
being formed somewhere well inside the
corporate ICT divisions and operate multiple
layers below a CIO or CTO (let alone a CEO).
Now, this very fact, rather than enabling EA
to transform the entire enterprise, may even
prevent it from having any influence on how
the corporate ICT division is architected,
which can most of times be an “ICT
enterprise” itself.
Secondly, rather than being an engine for
transformation and shaping the business
(and its strategy) in a proactive manner,
they become passive entities that most of
times are filled with over-conservative (and
at times over-arrogant) “mostly ICT”
professionals in their ivory tower who may
be viewed more as a “blocker of innovation”
than its drivers.
This observation is so prominent and
common that has persuaded ICT research
firms like Gartner to compile their “Not To
Do” or “pitfall” lists for creating EA
capabilities, like [15].
In the author’s view, one of the reasons
for such a situation is how The Open Group
Architecture Framework (TOGAF) (and
potentially other similar frameworks) have
approached enterprise architecture. As one
of the most prominent enterprise
architecture frameworks in the industry, not
so surprisingly, one could extract contents
from TOGAF textbooks that may, in certain
perspectives, support these observations as
“valid” and “correct”.
Firstly, even though TOGAF’s definition of
EA as “A conceptual blueprint that defines
the structure and operation of an
organization” can be interpreted exactly like
MIT CISR’s definition to be more linked to
the design of the enterprise itself rather
than enterprise systems, TOGAF’s reliance
on ISO 42010’s definition of architecture,
which is systems-bound, somehow starts the
problems. From there on, all attempts to get
back to the design of the enterprise as the
core focus of EA gets lost in a systems-
bound universe that one can never get out
of. The confusion and paradox get even
deeper around architecture continuum and
building blocks that at times are nothing but
software systems building blocks.
Yes, there are architecture domains with
different levels and focal points but that
very fact may also be contributing to the
dilemma of Enterprise Architecture vs.
Enterprise Systems Architecture and the
resulting mix-up and confusion.
4 Recommendations
The following recommendations may help
reduce the confusion and mix-up of roles
and responsibilities around enterprise
architecture.
4.1 The Need to Refine the
Terminology and Definitions
It may be useful for the next releases of
TOGAF or similar frameworks to refine the
terminology and clarify the exact position of
these frameworks against the dilemma of
the framework being focused on the
“enterprise” or “enterprise systems”.
It may still be reasonable to depend on ISO
42010’s detailed meta model for architecture
description but it may be necessary to cite
that it is being referred to in non-systems-
bound and genericized manner. While one
could argue that the separation between
architecture domains (Business, Information
Systems, Technology) already makes it
possible to cover both business and ICT
aspects, the author is more fond of the
belief that EA concerns the entire enterprise
and ICT systems architecture fits a “systems
architecture” space more and is much more
tactical and technical.
7
4.2 The Right Mindsets and
Definitions
The understanding around subtle
differences between different levels of
abstraction in architecture is vital to get
things right. EA must relate to architecting
the enterprise itself, much more than it
relates to architecting enterprise systems. If
the architecture of enterprise systems is
concerned, solution or systems architecture
capabilities may be better answers. Let’s not
downgrade EA to just an investment filtering
(or guiding) mechanism, or a strategy
alignment enforcement method. EA should
in fact be the engine for digital
transformation and re-defining how
business is done!
The author is under the belief that MIT
CISR’s definition for EA and the book
“Enterprise architecture as strategy:
Creating a foundation for business
execution” could be of immense benefit for
the people involved.
4.3 The Right Place for the EA
Capability
The very second it is accepted that EA is
about architecting the enterprise itself, it
becomes evident that, within the
organizational chart, the EA capability must
be placed as close as possible to entities that
have responsibilities and authorities around
business optimization, performance
management, organizational management
and structure, and process architecture
rather than pure IT and ICT functions, as E.
A. Marks also highlights [16]. Failing to do so
may seriously jeopardise the expected
outcomes and turn the EA capability into an
expensive ineffective version of an
enterprise systems architecture capability.
4.4 Enterprise Systems
Architecture Actually Matters
Too!
Total cost of ownership for enterprise
systems is highly dependent on the
architectural quality and architectural
drift/erosion for such systems. This affects
testability, maintainability, supportability,
changeability and configurability for such
systems, which quite easily map to
“ownership costs”. For bespoke systems,
many of these “-abilities” can be achieved
through the rigid enforcement of the right
software design principles (e.g. the SOLID
principles). It is obvious that these are more
of “systems architecture” concerns and may
be too detailed, specific and low-level to be
among a firm’s EA principles. However, even
though EA principles and promotion of
strategy in ICT investments may yield value
and savings to the business, but in the long
run, all other levels of architecture actually
create value and benefit for the business.
This may be the basis for establishing
systems or solutions architecture capabilities
with the goal to guide the practical
application of such design principles to
improve Return on Investment and decrease
Total Costs of Ownership for enterprise
systems.
4.5 The Right Skillset
In the author’s view, compared to any
other organizational capability, the success
and failure of an EA capability seems to be
affected more deeply by the quality of its
founders. This may be due to the “Enterprise
Architecture Paradox” as cited in the paper.
Without the right combination of technical,
business and stakeholder management
skills, EA success may be jeopardised
seriously. Some like Gartner have cited not
engaging the right business people in the
establishment process as a pitfall in
8
establishing EA capabilities as a way of
ensuring that EA remains focused on
architecting the enterprise rather than
enterprise systems [15]. However, in the
author’s view, the technical skills are just as
important. In the end, there are many cases
where the success of business and an
enterprise in a very competitive setting is
intertwined with the ownership of the right
technology solutions that enable business.
Good or bad, technology solutions are
technical in nature!
5 Conclusion
This paper tried to shed some light on the
definition of enterprise architecture and
enterprise systems architecture from
different sources and while proposing
another definition for enterprise
architecture, it explains the differences
between these layers, promoting that some
concerns in these two different domains
should be separated.
All this is recommended despite the fact
that there are different architecture
domains in frameworks like TOGAF,
promoting the view that concerns are
already separated. However, in practice, the
business architecture domain usually
remains more at a “let’s understand the
business” level, than “let’s shape the
business” level, resulting in the EA capability
being too much focused on enterprise
systems rather than the enterprise itself.
In the end, this paper can be a good source
of insight into these vivid but subtle
differences for an executive (either in IT or
outside of it) and can clarify what to expect
from EA as an enterprise engineering
approach, rather than as an IT investment or
strategy-alignment-assurance mechanism.
6 References
[1] J. W. Ross, P. Weill, and D.
Robertson, Enterprise architecture as
strategy: Creating a foundation for
business execution: Harvard Business
Press, 2006.
[2] I. ISO, "IEEE: 42010: 2011 systems and
software engineering, architecture
description," International Standard,
2011.
[3] L. Von Bertalanffy, "General system
theory," New York, vol. 41973, p. 40,
1968.
[4] P. Clements, D. Garlan, R. Little, R.
Nord, and J. Stafford, "Documenting
software architectures: views and
beyond," in Proceedings of the 25th
International Conference on Software
Engineering, 2003, pp. 740-741.
[5] R. C. Martin, Agile software
development: principles, patterns,
and practices: Prentice Hall, 2002.
[6] J. Smith, "Patterns-WPF apps with
the Model-View-ViewModel design
pattern," MSDN magazine, p. 72,
2009.
[7] A. Cockburn, "Hexagonal
architecture," ed, 2007.
[8] V. Haren, TOGAF Version 9.1: Van
Haren Publishing, 2011.
[9] I. Gartner, "Gartner IT glossary,"
Technology Research, 2013.
[10] Gartner, "Myth Busting: What
Enterprise Architecture Is Not,"
2008.
[11] J. A. Zachman, "Business systems
planning and business information
control study: a comparison," IBM
Systems Journal, vol. 21, pp. 31-53,
1982.
[12] J. A. Zachman, "A framework for
information systems architecture,"
IBM systems journal, vol. 26, pp. 276-
292, 1987.
[13] R. Jaluka, D. Meliksetian, and M.
Gupta, "Enterprise IT as a Service:
Transforming the Delivery Model of
IT Services," in Cloud Computing in
Emerging Markets (CCEM), 2016 IEEE
International Conference on, 2016, pp.
32-39.
[14] M. Heller. (2013). Breaking the
Enterprise Architecture Paradox.
Available:
https://www.cio.com/article/2370294
9
/cio-role/breaking-the-enterprise-
architecture-para/cio-role/cio-
role/breaking-the-enterprise-
architecture-paradox.html
[15] Gartner. (2009). Gartner Identifies
Ten Enterprise Architecture Pitfalls.
Available:
https://www.gartner.com/newsroom
/id/1159617
[16] E. A. Marks, Service-oriented
architecture (SOA) governance for
the services driven enterprise: John
Wiley & Sons, 2008.
