See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/313820912

Different Approaches to Enterprise Architecture

Article · February 2017

CITATIONS READS
6 4,706

1 author:

Svyatoslav Kotusev
University of Melbourne
56 PUBLICATIONS   396 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Enterprise Architecture Teaching Pack View project

All content following this page was uploaded by Svyatoslav Kotusev on 17 February 2017.

The user has requested enhancement of the downloaded file.

Article
Different Approaches to Enterprise Architecture
Svyatoslav Kotusev

Abstract
Enterprise Architecture (EA) is a description of an enterprise from an integrated business and IT perspective intended to
bridge the communication gap between business and IT stakeholders and, thereby, improve business and IT alignment.
Unfortunately, many companies are dissatisfied with popular heavyweight approaches to EA due to their excessive
clumsiness and rigidity. At the same time, alternative lightweight and flexible approaches to EA have also been proposed;
however, their existence is not widely acknowledged. In this article I briefly describe these alternative approaches to EA,
compare them with the widely-known heavyweight approach, and illustrate their applications in real companies.
Keywords
Enterprise Architecture (EA), problems, approaches, traditional, MIT, DYA

develop and use EA. This traditional heavyweight step-

INTRODUCTION wise approach to EA was highly influential and
Presently, Information Technology (IT) plays a significant essentially shaped the modern understanding of EA
role in improving the competitive positions of many theory and practice (Spewak & Tiemann 2006). In fact,
companies. However, many companies investing most modern EA methodologies are derived from this
substantial funds in IT systems do not get the expected traditional approach. Unsurprisingly, they also
returns. Often the effectiveness of IT investments is recommend developing a considerable volume of EA
undermined due to misalignment of business and IT documentation and suggest approximately the same
plans. In other words, IT departments often implement sequence of steps to practice EA (Bernard 2012; FEAF
information systems that do not address the real 1999; TOGAF 2011).
strategic needs of their companies. Many companies willing to improve their business and IT
In order to address the potential misalignment between alignment embark on EA journeys following popular
business and IT strategies the concepts of information formal and heavyweight approaches to EA such as the
systems architecture and then Enterprise Architecture TOGAF Architecture Development Method (ADM)
(EA) were introduced (Kotusev 2016). EA is an (TOGAF 2011). Unfortunately, many of these
overarching plan describing organizations from the companies fail to succeed with EA because of the
integrated business and IT viewpoints. EA takes a excessive rigidity and clumsiness of selected
holistic perspective and shows the relationship between approaches (Holst & Steensen 2011; Lohe & Legner
business goals, strategies and processes, and IT 2014). At the same time, alternative, more lightweight
capabilities, systems, and technologies. Typically, EA and flexible approaches to EA had also been proposed
describes business, data, applications, and technology (Ross et al. 2006; Wagter et al. 2005). These alternative
®
domains and their relationship (TOGAF 2011). Using approaches can help EA practitioners struggling with the
EA helps bridge the communication gap between popular heavyweight documentation-oriented
business and IT stakeholders, improve the alignment approaches to master EA and achieve better alignment.
between business and IT plans, and, thereby, increase However, the alternative approaches were undeservedly
the returns on IT investments. Presently, the potential of left unnoticed by EA practitioners and academics and
EA as a powerful organizational instrument is widely even the very existence of different approaches to EA is
recognized and the majority of large companies have still not widely recognized (Kotusev et al. 2015). In this
started EA programs (van der Raadt et al. 2007). article I will discuss the alternative lightweight
approaches to EA, compare them with the traditional
The classical approach to EA was inspired by heavyweight approach, and illustrate these approaches
conventional engineering and architecture methods at work in real companies practicing EA.
(Spewak and Hill 1992). Unsurprisingly, it is largely
mechanistic, relies on extensive formal documentation,
and advocates following strict sequences of steps to

Journal of Enterprise Architecture – Volume 12, No. 4 9 © 2016 Association of Enterprise Architects
TRADITIONAL APPROACH TO EA practice as well as the understanding of the very notion
The traditional approach to EA, as a revamped version of EA. Unsurprisingly, the concept of EA and traditional
of the earlier IBM’s Business Systems Planning (BSP) approach to EA are synonymous for many practitioners.
approach (Kotusev 2016), was initially presented by
Spewak and Hill (1992) and subsequently inspired most
modern EA methodologies (Armour et al. 1999; Bernard
2012; FEAF 1999; TOGAF 2011). These methodologies
suggest that EA is developed step-by-step by enterprise
architects who are competent in both business and IT,
and possess good communication and systems thinking
skills. First, enterprise architects study the current
business processes and IT landscape and then
document them in detail with a large number of models,
diagrams, or blueprints. Second, enterprise architects
develop the desired long-term future state according to
the strategic plans and objectives of the organization’s
executives. Typically, the future state development
starts from the business architecture as the main driver
of EA efforts and then proceeds to the data, applications,
and technology architectures. Third, enterprise
architects analyze the gaps between the current and
future states and develop the transition plan describing
the information systems that should be implemented to
transform the organization into the envisioned target
state from the current position. After being developed,
this transition plan is used by the project teams Figure 1: The Traditional Approach to EA
implementing the necessary IT systems under the
However, despite its popularity in EA literature, the
supervision of enterprise architects. When the plan is
traditional approach to EA is heavily criticized. EA
implemented, a new EA project or iteration is initiated to
practitioners disparage the traditional approach for its
carry out the same sequence of steps all over again. In
excessive clumsiness because it prescribes following
the course of this process, business stakeholders are
overly complicated processes and creating an
also expected to use EA documentation for analysis and
unreasonable number of descriptive models (Lagerstrom
decision-making.
et al. 2011). EA efforts often fail and many companies
The traditional approach to EA is shown schematically in become disillusioned with EA altogether because of the
Figure 1. overly mechanistic focus of the traditional EA
The advantage of the traditional approach is its methodologies (Holst & Steensen 2011).
conceptual simplicity and intuitive appeal. EA planning “The problem here is that the enterprise isn’t an ordinary
for the whole organization is carried out in a centralized system like a machine or a building, and can’t be architected or
manner by a small dedicated team and does not require engineered as such.” (Bloomberg 2014, p.1).
significant involvement of other stakeholders. Since Lohe and Legner (2014) identify three typical problems
most EA activities are accomplished by a group of expert with the traditional approach to EA and all of them result
enterprise architects, it is not necessary for an from its mechanistic, documentation-oriented,
organization to be particularly IT-savvy to use this heavyweight, and clumsy nature:
approach. Therefore, the traditional approach to EA is 1. Unreasonable efforts needed to create and maintain
best applied at small, centralized, and stable the necessary EA documentation due to high
organizations, especially if their competitive advantages organizational complexity, large scope, and
are not very dependent on IT. dynamic environment
A successful case of the traditional approach to EA is 2. Low utilization of EA documentation due to its poor
illustrated in Vignette 1 (overleaf). quality, obsolescence, wrong level of detail, and
mismatch with the real information needs of its
PROBLEMS OF THE TRADITIONAL APPROACH
stakeholders
The traditional approach to EA is, undoubtedly, the most 3. Poor integration of EA practice into the organization
discussed and widely known approach to EA. due to its isolated step-wise lifecycle
Essentially, it defines the present understanding of EA

Journal of Enterprise Architecture – Volume 12, No. 4 10 © 2016 Association of Enterprise Architects
These problems make the traditional approach An unsuccessful case of the traditional approach to EA
unsuitable for large, dynamic, and decentralized is illustrated in Vignette 2.
organizations working in volatile environments and
requiring significant involvement of various stakeholders
in decision-making processes.

Successful traditional approach to EA at Australian Bureau of Statistics (Gregor et al. 2007; Lynch 2006)

Australian Bureau of Statistics (ABS) is one of the most admired statistical agencies in the world. It is a relatively small and stable
government organization operating since 1905. Currently ABS employs more than 3,000 people and provides a high-quality statistics
in two major areas: economic and population.
The EA program at ABS was initiated in 1999 when the ABS executive formed a small and multi-disciplinary architecture team of four
people responsible for EA development. The architecture team works according to the home-grown EA method based on the
traditional EA methodologies and frameworks. Therefore, the ABS approach to EA includes documenting the current state,
developing the target state, analyzing the gaps, and then identifying the necessary IT investments to close these gaps.
The architecture team completed the first version of the necessary EA documentation in September 2001 and then updated it to
version 2.0 in March 2003. Subsequently, EA documentation is reviewed and updated on a periodical basis every 6-12 months by the
technical leadership team headed by the CIO. EA documentation describes ABS at three abstraction levels: business, logical, and
physical. After being developed or updated, EA documentation is communicated to all ABS employees with a number of A3 size
posters demonstrating the main architectural diagrams. The ABS EA Director argues that EA is “a corporate artifact to be ‘taken
away and used’ by all staff at ABS”. Thereby, EA guides the activities of multiple business and IT stakeholders at ABS.
Using EA helps ABS to achieve a high degree of alignment between business objectives and organizational information systems.
Unsurprisingly, EA practice at ABS is highly respected by other government organizations. However, most Australian agencies could
not replicate the ABS success with EA due to their larger scopes, more dynamic businesses, and decentralized environments.

Vignette 1: Successful Traditional Approach to EA

Unsuccessful traditional approach to EA at the US Federal Government (Gaver 2010)

In 1996 US Congress had enacted the Clinger-Cohen Act obliging the Federal Government and all its departments to develop
consistent architectures in order to improve the usage of information systems in this large and decentralized organization. As a
response, in 1999 the Federal CIO Council initiated the Federal Enterprise Architecture (FEA) program and published the
corresponding FEA Framework (FEAF). FEAF suggested describing business, data, applications, and technology architectures in a
segmented manner and embodied the traditional approach to EA including documenting current and future states, analyzing gaps,
developing transition plans, and implementing them.
However, the FEA program has faced numerous challenges since its inception. The huge efforts required to create EA
documentation undermined the institutional commitment and lowered the priority of EA-related activities. A lack of common
understanding of what should be included in EA and terminological issues in FEAF caused disputes and misunderstanding among
various program participants. Manual modeling was a very slow process and EA documents often got outdated before being
delivered. Most managers who were expected to work with EA documentation could not understand it, especially if they were
unfamiliar with modeling.
Consequently, EA diagrams were unsuitable for analysis and reporting and the data from architecture repositories was almost never
used. Producing EA documentation quickly turned into an end in itself. EA-related activities hindered normal IT activities instead of
facilitating them. Periodical EA maturity assessments showed that the overall EA maturity of the Federal Government was decreasing
rather than increasing over the years.
Therefore, despite the best efforts of the architects involved in the program, FEA produced only minimal value for the money spent
and never accomplished its original goals. Taking into account that the total expenditures for the program exceeded a billion dollars
and much of it (perhaps even most of it) had been wasted, FEA is arguably the most impressive failure of the traditional approach to
EA. “Look at all the efforts that have been launched under the idea of architecture and all the money that has been spent under the
umbrella of architecture that has all resulted in unusable shelfware”, commented Paul Brubaker, co-author of the Clinger-Cohen Act.

Vignette 2: Unsuccessful Traditional Approach to EA

Journal of Enterprise Architecture – Volume 12, No. 4 11 © 2016 Association of Enterprise Architects
 1. Enterprise-level IT governance – top management
ALTERNATIVE APPROACHES TO EA
decision-making framework including the core
As a reaction to the aforementioned problems of the diagram
traditional approach to EA caused by its clumsiness and 2. Project management – disciplined project delivery
sluggishness, two alternative, more pragmatic methodology with necessary checkpoints
approaches to EA had been proposed by Ross et al.
3. Linking mechanisms – processes and committees
(2006) and Wagter et al. (2005). These approaches are
ensuring the connection between enterprise-level
more flexible and can help overcome the typical
decisions and project-level activities
challenges associated with the heavyweight traditional
approach. However, they were undeservedly left After the IT engagement model is established, EA
unnoticed by EA practitioners and academics (Kotusev embodied in the core diagram is continuously translated
et al. 2015). into concrete project-level decisions through the linking
mechanisms involving business and IT managers on
I will discuss them further under the titles MIT (Ross et
different organizational levels. Therefore, in the MIT
al. 2006) (because it was developed at MIT) and DYA
approach each IT project eventually accomplishes both
(Wagter et al. 2005) (because this title is given by its
local and global objectives and gradually moves a
authors) since they do not have any established titles in
company towards the desired long-term architectural
EA literature.
vision.
MIT Approach The MIT approach to EA is shown schematically in
Figure 2.
The MIT approach to EA was derived from research
findings at Massachusetts Institute of Technology (MIT)
Sloan School of Management by Ross et al. (2006).
Ross et al. (2006, p.vii) argue about the historic
ineffectiveness of the traditional approaches to EA and
criticize them for:
“… remoteness from the reality of the business and their heavy
reliance on mind-numbing detail represented in charts that look
more like circuit diagrams than business descriptions and that
are useful as little more than doorstops.”
According to the MIT approach, as a first step of EA
program business and IT executives should decide on
the organizational operating model, defined as:
“the necessary level of business process integration and
standardization for delivering goods and services to customers”
Ross et al. (2006) argue that an operating model
provides a more clear, actionable, and stable basis for
EA development than a business strategy. As a second
step, business and IT executives should collaboratively Figure 2: The MIT Approach to EA
develop the core diagram – a critical EA document The MIT approach to EA facilitates the balance between
describing the main business and IT capabilities, enterprise-wide and local needs. It provides an
corporate data, principal customers, and key organization with a long-term global architectural vision
technologies. The core diagram is a one-pager that but leaves enough flexibility to react to emerging short-
represents a long-term abstract enterprise-level term local requirements. However, the MIT approach
architectural vision reflecting the integration and requires a very considerable involvement of business
standardization requirements of the chosen operating stakeholders with an EA program and the establishment
model. Finally, business and IT executives should of complex architecture governance mechanisms
design and implement the IT engagement model, permeating the whole organization. Therefore, the MIT
defined as: approach is best applied at large and complex
“the system of governance mechanisms assuring that business organizations with relatively stable business models
and IT projects achieve both local and company-wide heavily dependent on IT for achieving competitive
objectives” advantages in their markets.
The IT engagement model includes three essential
elements:

Journal of Enterprise Architecture – Volume 12, No. 4 12 © 2016 Association of Enterprise Architects
A successful case of the MIT approach to EA is A successful case of the DYA approach to EA is
illustrated in Vignette 3. illustrated in Vignette 4.

DYA Approach

The DYA (DYnamic Architecture) approach to EA was

developed at Sogeti Nederland in 2001 and presented
internationally by Wagter et al. (2005). Wagter et al.
(2005) criticize the traditional approach to EA for its
impracticality and notice that following the recommended
processes and developing the heaps of recommended
documentation often result in useless “paper tigers”
instead of working architecture.
The DYA approach advocates “just enough, just in time”
architecture; no EA is designed until there is a need for
it. All EA activities in the DYA approach are carried out
by architectural services and always triggered by
concrete business initiatives emerging in the process of
the strategic dialogue when business and IT managers
collaboratively decide on which objectives to pursue.
After business and IT leaders have determined the Figure 3: The DYA Approach to EA
potential business initiatives to be implemented, they are COMPARISON OF THE THREE APPROACHES TO EA
elaborated into concrete business cases and project
proposals and the role of architectural services in this Each of the three approaches discussed employs EA to
process is to provide necessary principles and models to facilitate business and IT alignment. However, each of
facilitate decision-making, impact analysis, and financial them employs it in a different manner, follows different
analysis. Then, architectural services prepare a project- logic, and even the very nature of EA is different in each
start architecture describing the scope, design choices, of them (Kotusev et al. 2015). Unsurprisingly, each
standards and guidelines for the new IT project in order approach has its own advantages, disadvantages, and
to ensure that this project seamlessly fits into the situations when it is best applied.
existing IT landscape and larger picture. Development Comparison of the three approaches to EA is
teams typically use provided project-start architectures in summarized in Table 1.
their projects (development with architecture). However,
sometimes projects are implemented without project- CONCLUSION
start architectures (development without architecture) if EA is an important organizational instrument employed
there are justifiable reasons for it; for instance, acute by many large companies to improve the quality of their
time pressure, legacy systems involved, or necessary IT landscapes and align them with the business goals
resources unavailable. and strategies. Traditionally, EA is associated with a
The DYA approach to EA is shown schematically in large number of models and complicated processes.
Figure 3. However, heavyweight and documentation-oriented EA
methodologies often fail due to their excess rigidity. On
The advantage of the DYA approach is its totally the other hand, alternative, more flexible and lightweight
pragmatic “just enough, just in time” attitude towards EA. EA methodologies have also been proposed but their
It provides the right stakeholders with the right EA existence is, arguably, not recognized by the majority of
documentation at the right time for the right purpose. EA practitioners and academics. In this article I
The DYA approach focuses only on concrete business presented a broad overview of existing EA
initiatives instead of abstract intangible visions methodologies, briefly described them, illustrated their
emphasizing utilitarianism, agility, and flexibility. work on real-world examples of EA practice, and
Naturally, the DYA approach does not imply any long- compared them with each other. Since this article
term strategic planning beyond individual business provides only a brief review of EA methodologies and
initiatives potentially undermining the general strategic covers only a tip of the EA iceberg, I encourage the
effectiveness. Therefore, the DYA approach is best readers to study the different approaches to EA in detail
applied at organizations operating in very vibrant, using their definitive publications (Ross et al. 2006;
dynamic, and unpredictable environments and markets. TOGAF 2011; Wagter et al. 2005).

Journal of Enterprise Architecture – Volume 12, No. 4 13 © 2016 Association of Enterprise Architects
Successful MIT approach to EA at Delta Air Lines (Ross et al. 2006; Weill & Ross 2004)

Delta Air Lines, established in 1929, is one of the world’s largest airlines. Currently Delta employs more than 77,000 people and
serves an extensive US and international network including more than 300 destinations on six continents.
The EA program at Delta started in 1997 when its newly appointed CEO found that organizational information systems were
developed independently by different functional units and isolated from each other. EA activities followed the MIT approach and were
driven by Delta’s CIO who assembled a team of senior executives to define the role of IT in the company. The executive team
decided on four standard enterprise-wide processes supported by IT (customer experience, operational pipeline, business reflexes,
and employee relationship management) and nine global databases critical to their execution. After that, IT leaders chose the
appropriate IT infrastructure to support these processes and data and the resulting high-level architectural vision was fixated in
Delta’s core diagram. Totally, it took about 60 iterations before all the members of the executive team agreed on the core diagram.
This core diagram was subsequently used by Delta’s governance bodies for decision-making to allocate IT investments and prioritize
projects. Combining the simultaneous investments in applications and underlying infrastructure helped balance short-term and long-
term needs and eventually build a solid platform for implementing new business initiatives in a timely manner.
In a few years after the commencement of EA program, Delta had significantly improved its financial results and moved from last to
first on main industry indicators; for instance, on-time departures, customer satisfaction, and lost baggage.

Vignette 3: Successful MIT Approach to EA

Successful DYA approach to EA at BNM Banking Group

BNM Banking Group (fictional name due to anonymity requirements) is a large international financial institution with multi-billion dollar
revenues. BNM employs more than 26,000 people and is among the top 100 largest banks in the world. It operates in a very
dynamic market in the Asia-Pacific (APAC) region and provides a full spectrum of financial services to individual and institutional
customers.
BNM started a full-scale EA program in 2004 with the help of consultants and then fine-tuned the EA methodology according to its
specific needs and environment. The EA function at BNM works in the logic of the DYA approach and produces three main
deliverables: blueprints, Solution Architecture Documents (SADs), and High-Level Designs (HLDs). Blueprints are abstract
deliverables intended for executive-level stakeholders (board of directors, executive committee, strategy team, etc.). SADs and HLDs
are more concrete and technical deliverables intended for lower-level stakeholders (business and IT operations, project managers,
project teams, etc.).At first, senior business and IT executives try to define potential initiatives to be implemented in line with the
general strategic direction of the bank. Then, the EA function develops a blueprint for each initiative providing the initial assessment
of its value, cost, solution, impact, and risks to facilitate informed decision-making. After the initiative has been approved by all top-
level stakeholders, the EA function develops SADs outlining its conceptual implementation and then HLDs describing its detailed
technical implementation. Finally, EA documentation is passed to program and project managers driving the actual implementation of
the initiative according to the planned architecture.
EA at BNM provides the effective instruments to align IT capabilities and business needs, coordinate change, facilitate simplicity and
re-usability, consolidate and standardize the IT landscape, speed up the delivery of new IT systems, and gradually decommission the
legacy ones.

Vignette 4: Successful DYA Approach to EA

Approach to EA Traditional MIT DYA

Definitive source(s) Spewak & Hill (1992), Bernard Ross et al. (2006) Wagter et al. (2005)
(2012), TOGAF (2011), and other
sources

The essence of approach Document current state, describe Decide on operating model, For each business initiative
future state, analyze gaps, develop core diagram, and then prepare diagrams for decision-
develop transition plan, and use it for decision-making at all making and then project-start
implement it organizational levels to balance architectures for implementation
local and global needs

Essential EA artifacts Detailed current state, detailed Core diagram (abstract Principles and policies for the
future state, transition plan enterprise-wide architectural whole organization, supporting
vision) documents for individual
initiatives

Journal of Enterprise Architecture – Volume 12, No. 4 14 © 2016 Association of Enterprise Architects
Approach to EA Traditional MIT DYA

Key terms Current/future (as-is/to-be, Operating model, core diagram, Strategic dialogue, architectural
baseline/target) state, gap IT engagement model, linking services, development with(out)
analysis, transition plan mechanisms architecture, project-start
(roadmap), iteration architecture

Advantages Conceptually simple, does not Provides a long-term global Pragmatic, flexible, and agile,
require significant involvement of architectural vision but leaves provides only necessary
stakeholders, organization can be enough flexibility to react on documents for the right
not IT-savvy emerging short-term local stakeholders at the right time for
requirements the right purpose

Disadvantages Scope can be too large, plans Requires considerable Does not imply any long-term
can be unstable, documentation involvement of business strategic planning beyond
can be incomprehensible, stakeholders and establishment individual business initiatives, can
isolated from other organizational of complex governance undermine general strategic
activities mechanisms effectiveness

Applicability Small, centralized, and stable Large and complex organizations Organizations operating in very
organizations where competitive with relatively stable business vibrant, dynamic, and
advantages are not very models dependent on IT for unpredictable environments and
dependent on IT achieving competitive advantages markets

Table 1: Comparison of the Three Approaches to EA

ABOUT THE AUTHOR M.S. Holst, T.W. Steensen: The Successful Enterprise
Architecture Effort, Journal of Enterprise Architecture (7:4),
Svyatoslav Kotusev is a researcher at RMIT University, pp.16-22 (2011).
Melbourne, Australia. He has spent the last three years
studying EA practices in organizations. Prior to his S. Kotusev: The History of Enterprise Architecture: An
academic career he held various software development Evidence-Based Review, Journal of Enterprise Architecture
® (12:1), pp.29-37 (2016).
and architecture positions in industry. He is a TOGAF
Certified expert. Svyatoslav can be reached at S. Kotusev, M. Singh, I. Storey: Consolidating Enterprise
kotusev@kotusev.com. Architecture Management Research, in Proceedings of the
48th Hawaii International Conference on System Sciences,
REFERENCES R.H. Sprague (Ed.), Kauai, HI: IEEE, pp.4069-4078 (2015).
F.J. Armour, S.H. Kaisler, S.Y. Liu: Building an Enterprise R. Lagerstrom, T. Sommestad, M. Buschle, M. Ekstedt:
Architecture Step by Step, IT Professional (1:4), pp.31-39 Enterprise Architecture Management’s Impact on Information
(1999). Technology Success, in Proceedings of the 44th Hawaii
S.A. Bernard: An Introduction to Enterprise Architecture (3rd International Conference on System Sciences, R.H. Sprague
Ed.), Bloomington, IN: AuthorHouse (2012). (Ed.), Kauai, HI: IEEE, pp.1-10 (2011).

J. Bloomberg: Is Enterprise Architecture Completely Broken?, J. Lohe, C. Legner: Overcoming Implementation Challenges in
Forbes (2014); retrieved November 11, 2014 from: Enterprise Architecture Management: A Design Theory for
www.forbes.com/sites/jasonbloomberg/2014/07/11/is- Architecture-Driven IT Management (ADRIMA), Information
enterprise-architecture-completely-broken/. Systems and e-Business Management (12:1), pp.101-137
(2014).
FEAF: Federal Enterprise Architecture Framework, Version
1.1, Chief Information Officer Council, Springfield, VA (1999). N. Lynch: Enterprise Architecture – How Does it Work in the
Australian Bureau of Statistics?, in Proceedings of the 17th
S.B. Gaver: Why Doesn’t the Federal Enterprise Architecture Australasian Conference on Information Systems, S. Spencer,
Work?, Technology Matters, McLean, VA (2010). A. Jenkins (Eds.), Adelaide, Australia: Association for
Information Systems, pp.1-14 (2006).
S. Gregor, D. Hart, N. Martin: Enterprise Architectures:
Enablers of Business Strategy and IS/IT Alignment in J.W. Ross, P. Weill, D.C. Robertson: Enterprise Architecture as
Government, Information Technology & People (20:2), pp.96- Strategy: Creating a Foundation for Business Execution,
120 (2007). Boston, MA: Harvard Business School Press (2006).

Journal of Enterprise Architecture – Volume 12, No. 4 15 © 2016 Association of Enterprise Architects
S.H. Spewak, S.C. Hill: Enterprise Architecture Planning:
Developing a Blueprint for Data, Applications, and Technology,
New York, NY: Wiley (1992).

S.H. Spewak, M. Tiemann: Updating the Enterprise

Architecture Planning Model, Journal of Enterprise Architecture
(2:2), pp.11-19 (2006).
®
TOGAF Version 9.1, an Open Group Standard; refer to:
www.opengroup.org/togaf.

B. van der Raadt, R. Slot, H. van Vliet: Experience Report:

Assessing a Global Financial Services Company on its
Enterprise Architecture Effectiveness Using NAOMI, in
Proceedings of the 40th Hawaii International Conference on
System Sciences, R.H. Sprague (Ed.), Big Island, HI: IEEE,
pp.1-10 (2007).

R. Wagter, M. van den Berg, J. Luijpers, M. van Steenbergen:

Dynamic Enterprise Architecture: How to Make it Work,
Hoboken, NJ: Wiley (2005).

P. Weill, J.W. Ross: IT Governance: How Top Performers

Manage IT Decision Rights for Superior Results, Boston, MA:
Harvard Business School Press (2004).

Journal of Enterprise Architecture – Volume 12, No. 4 16 © 2016 Association of Enterprise Architects

View publication stats