Enterprise architecture framework

An enterprise architecture framework (EA framework)

defines how to create and use an enterprise architecture. An
architecture framework provides principles and practices for
creating and using the architecture description of a system. It
structures architects' thinking by dividing the architecture
description into domains, layers, or views, and offers models -
typically matrices and diagrams - for documenting each view.
This allows for making systemic design decisions on all the
components of the system and making long-term decisions
around new design requirements, sustainability, and support.[2]

Overview
Enterprise architecture regards the enterprise as a large and
complex system or system of systems.[3] To manage the scale NIST Enterprise Architecture Model
and complexity of this system, an architectural framework initiated in 1989, one of the earliest
provides tools and approaches that help architects abstract from frameworks for enterprise architecture.[1]
the level of detail at which builders work, to bring enterprise
design tasks into focus and produce valuable architecture
description documentation.

The components of an architecture framework provide structured guidance that is divided into three main
areas:[4]

Descriptions of architecture: how to document the enterprise as a system, from several

viewpoints. Each view describes one slice of the architecture; it includes those entities and
relationships that address particular concerns of interest to particular stakeholders; it may
take the form of a list, a table, a diagram, or a higher level of composite of such.
Methods for designing architecture: processes that architects follow. Usually, an overarching
enterprise architecture process, composed of phases, broken into lower-level processes
composed of finer grained activities. A process is defined by its objectives, inputs, phases
(steps or activities) and outputs. It may be supported by approaches, techniques, tools,
principles, rules, and practices.
Organization of architects: guidance on the team structure and the governance of the team,
including the skills, experience, and training needed.

History
The earliest rudiments of the step-wise planning methodology currently advocated by The Open Group
Architecture Framework (TOGAF) and other EA frameworks can be traced back to the article of Marshall
K. Evans and Lou R. Hague titled "Master Plan for Information Systems"[7] published in 1962 in Harvard
Business Review.[8]
Since the 1970s people working in IS/IT have looked for ways
to engage business people – to enable business roles and
processes - and to influence investment in business information
systems and technologies – with a view to the wide and long
term benefits of the enterprise. Many of the aims, principles,
concepts and methods now employed in EA frameworks were
established in the 1980s, and can be found in IS and IT
architecture frameworks published in that decade and the
next.[9]
Overview of Enterprise Architecture
By 1980, IBM's Business Systems Planning (BSP) was
Frameworks evolution (1987–2003).[4][5]
promoted as a method for analyzing and designing an
On the left: The Zachman Framework
organization's information architecture, with the following goals:
1987, NIST Enterprise Architecture
1989, EAP 1992, TISAF 1997, FEAF
1. understand the issues and opportunities with the
1999 and TEAF 2000. On the right:
current applications and technical architecture;
TAFIM influenced by POSIX, JTA,
2. develop a future state and migration path for the
JTAA, TOGAF 1995, DoD TRM[6] and
technology that supports the enterprise;
C4ISR 1996, and DoDAF 2003.
3. provide business executives with a direction and
decision making framework for IT capital
expenditures;
4. provide the information system (IS) with a blueprint for development.

In 1982, when working for IBM and with BSP, John Zachman outlined his framework for enterprise-level
"Information Systems Architecture". Then and in later papers, Zachman used the word enterprise as a
synonym for business. "Although many popular information systems planning methodologies, design
approaches, and various tools and techniques do not preclude or are not inconsistent with enterprise-level
analysis, few of them explicitly address or attempt to define enterprise architectures."[10] However, in this
article the term "Enterprise Architecture" was mentioned only once without any specific definition and all
subsequent works of Zachman used the term "Information Systems Architecture".[11][12]

In 1986, the PRISM architecture framework was developed as a result of the research project sponsored by
a group of companies, including IBM, which was seemingly the first published EA framework.[13]

In 1987, John Zachman, who was a marketing specialist at IBM, published the paper, A Framework for
Information Systems Architecture.[11] The paper provided a classification scheme for artifacts that describe
(at several levels of abstraction) the what, how, where, who, when and why of information systems. Given
IBM already employed BSP, Zachman had no need to provide planning process. The paper did not
mention enterprise architecture.

In 1989, the National Institute of Standards and Technology (NIST) published the NIST Enterprise
Architecture Model.[14] This was a five-layer reference model that illustrates the interrelationship of
business, information system, and technology domains. It was promoted within the U.S. federal
government. It was not an EA framework as we see it now, but it helped to establish the notion of dividing
EA into architecture domains or layers. The NIST Enterprise Architecture Model seemingly was the first
publication that consistently used the term "Enterprise Architecture".[13]

In 1990, the term "Enterprise Architecture" was formally defined for the first time as an architecture that
"defines and interrelates data, hardware, software, and communications resources, as well as the supporting
organization required to maintain the overall physical structure required by the architecture".[13][15]
In 1992, a paper by Zachman and Sowa[12] started thus "John Zachman introduced a framework for
information systems architecture (ISA) that has been widely adopted by systems analysts and database
designers." The term enterprise architecture did not appear. The paper was about using the ISA framework
to describe, “...the overall information system and how it relates to the enterprise and its surrounding
environment.” The word enterprise was used as a synonym for business.

In 1993, Stephen Spewak's book Enterprise Architecture Planning (EAP) defined a process for defining
architectures for the use of information in support of the business and the plan for implementing those
architectures. The business mission is the primary driver. Then the data required to satisfy the mission. Then
the applications built to store and provide that data. Finally the technology to implement the applications.
Enterprise Architecture Planning is a data-centric approach to architecture planning. An aim is to improve
data quality, access to data, adaptability to changing requirements, data interoperability and sharing, and
cost containment. EAP has its roots in IBM's Business Systems Planning (BSP).[13]

In 1994, the Open Group selected TAFIM from the US DoD as a basis for development of TOGAF, where
architecture meant IT architecture. TOGAF started out taking a strategic and enterprise-wide, but
technology-oriented, view. It emerged from the desire to rationalize a messy IT estate. Right up to version
7, TOGAF was still focused on defining and using a Technical Reference Model (or foundation
architecture) to define the platform services required from the technologies that an entire enterprise uses to
support business applications.[9]

In 1996, the US IT Management Reform Act, more commonly known as the Clinger-Cohen Act,
repeatedly directed that a US federal government agency's investment in IT must be mapped to identifiable
business benefits. In addition, it made the agency CIO responsible for, “...developing, maintaining and
facilitating the implementation of a sound and integrated IT architecture for the executive agency.”

By 1997, Zachman had renamed and refocused his ISA framework as an EA framework; it remained a
classification scheme for descriptive artifacts, not a process for planning systems or changes to systems.

In 1998, The Federal CIO Council began developing the Federal Enterprise Architecture Framework
(FEAF) in accordance with the priorities enunciated in Clinger-Cohen and issued it in 1999. FEAF was a
process much like TOGAF's ADM, in which “The architecture team generates a sequencing plan for the
transition of systems, applications, and associated business practices predicated upon a detailed gap analysis
[between baseline and target architectures].”

In 2001, the US Chief CIO council published A practical guide to Federal Enterprise Architecture, which
starts, “An enterprise architecture (EA) establishes the Agency-wide roadmap to achieve an Agency's
mission through optimal performance of its core business processes within an efficient information
technology (IT) environment." At that point, the processes in TOGAF, FEAF, EAP and BSP were clearly
related.

In 2002/3, in its Enterprise Edition, TOGAF 8 shifted focus from the technology architecture layer to the
higher business, data and application layers. It introduced structured analysis, after information technology
engineering, which features, for example, mappings of organization units to business functions and data
entities to business functions. Today, business functions are often called business capabilities. And many
enterprise architects regard their business function/capability hierarchy/map as the fundamental Enterprise
Architecture artifact. They relate data entities, use cases, applications and technologies to the
functions/capabilities.

In 2006, the popular book Enterprise Architecture As Strategy[16] reported the results of work by MIT's
Center for Information System Research. This book emphasises the need for enterprise architects to focus
on core business processes ("Companies excel because they've [decided] which processes they must
execute well, and have implemented the IT systems to digitise those processes.") and to engage business
managers with the benefits that strategic cross-organisational process integration and/or standardisation
could provide.

A 2008 research project for the development of professional certificates in enterprise and solution
architecture by the British Computer Society (BCS) showed that enterprise architecture has always been
inseparable from information system architecture, which is natural, since business people need information
to make decisions and carry out business processes.[9]

In 2011, the TOGAF 9.1. specification says: "Business planning at the strategy level provides the initial
direction to enterprise architecture."[17] Normally, the business principles, business goals, and strategic
drivers of the organization are defined elsewhere.[9] In other words, Enterprise Architecture is not a
business strategy, planning or management methodology. Enterprise Architecture strives to align business
information systems technology with given business strategy, goals and drivers. The TOGAF 9.1
specification clarified, that, "A complete enterprise architecture description should contain all four
architecture domains (business, data, application, technology), but the realities of resource and time
constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive
architecture description encompassing all four architecture domains, even if the enterprise scope is [...] less
than the full extent of the overall enterprise."[18]

In 2013, TOGAF[19] is the most popular Architecture framework (judged by published certification
numbers) that some assume it defines EA.[9] However, some still use the term Enterprise Architecture as a
synonym for Business Architecture, rather than covering all four architecture domains - business, data,
applications and technology.

EA framework topics

Architecture domain

Since Stephen Spewak's Enterprise Architecture

Planning (EAP) in 1993 – and perhaps before then
– it has been normal to divide enterprises
architecture into four architecture domains.

Business architecture,
Data architecture,
Applications architecture,
Technology architecture. Layers of the enterprise architecture.[20]

Note that the applications architecture is about the

choice of and relationships between applications in the enterprise's application portfolio, not about the
internal architecture of a single application (which is often called application architecture).

Many EA frameworks combine data and application domains into a single (digitized) information system
layer, sitting below the business (usually a human activity system) and above the technology (the platform
IT infrastructure).

Layers of the enterprise architecture

For many years, it has been common to
regard the architecture domains as layers,
with the idea that each layer contains
components that execute processes and offer
services to the layer above. This way of
looking at the architecture domains was
evident in TOGAF v1 (1996), which
Example of the federal enterprise architecture, which has
encapsulated the technology component
defined five architectural layers.[21]
layer behind the platform services defined in
the "Technical Reference Model" - very
much according to the philosophy of TAFIM
and POSIX.

The view of architecture domains as layers can be presented thus:

Environment (the external entities and activities monitored, supported or directed by the
business).
Business Layer (business functions offering services to each other and to external entities).
Data Layer (Business information and other valuable stored data)
Information System Layer (business applications offering information services to each other
and to business functions)
Technology Layer (generic hardware, network and platform applications offering platform
services to each other and to business applications).

Each layer delegates work to the layer below. In each layer, the components, the processes and the services
can be defined at a coarse-grained level and decomposed into finer-grained components, processes and
services. The graphic shows a variation on this theme.

Components of enterprise architecture framework

In addition to three major framework components discussed above.

1. Description advice: some kind of Architecture Artifacts Map or Viewpoint Library

2. Process advice: some kind of Architecture Development Method, with supporting guidance.
3. Organization advice: including an EA Governance Model

An ideal EA framework should feature:

1. Business value measurement metrics

2. EA initiative model
3. EA maturity model
4. Enterprise communication model

Most modern EA frameworks (e.g. TOGAF, ASSIMPLER, EAF) include most of the above. Zachman has
always focused on architecture description advice.

Enterprise architecture domains and subdomains

The application and technology domains (not to be
confused with business domains) are characterized
by domain capabilities and domain services. The
capabilities are supported by the services. The
application services are also referred to in service-
oriented architecture (SOA). The technical services
are typically supported by software products.

The data view starts with the data classes which

can be decomposed into data subjects which can be
further decomposed into data entities. The basic
data model type which is most commonly used is
called merda (master entity relationship diagrams
Enterprise architecture reference architecture with sub
assessment, see entity-relationship model). The
domains
Class, subject and entity forms a hierarchical view
of data. Enterprises may have millions of instances
of data entities.

The Enterprise Architecture Reference Traditional Model offers a clear distinction between the architecture
domains (business, information/data, application/integration and technical/infrastructure). These domains
can be further divided into Sub domain disciplines. An example of the EA domain and subdomains is in the
image on the right.

Many enterprise architecture teams consist of Individuals with Skills aligned with the Enterprise
Architecture Domains and sub-domain disciplines. Here are some examples: enterprise business architect,
enterprise documentational architect, enterprise application architect, enterprise infrastructure architect,
enterprise information architect, etc.

An example of the list of reference architecture patterns in the application and information architecture
domains are available at Architectural pattern (computer science).

View model

A view model is a framework that defines the

set of views or approaches used in systems
analysis, systems design, or the construction
of an enterprise architecture.

Since the early 1990s, there have been a

number of efforts to define standard
approaches for describing and analyzing
system architectures. Many of the recent
Enterprise Architecture frameworks have
some kind of set of views defined, but these
sets are not always called view models.
Illustration of the 4+1 view model of architecture.

Standardization

Perhaps the best-known standard in the field of software architecture and system architecture started life as
IEEE 1471, an IEEE Standard for describing the architecture of a software-intensive system approved in
2000.
In its latest version, the standard is published as ISO/IEC/IEEE  42010:2011. The standard defines an
architecture framework as conventions, principles and practices for the description of architectures
established within a specific domain of application and/or community of stakeholders, and proposes an
architecture framework is specified by:

1. the relevant stakeholders in the domain,

2. the types of concerns arising in that domain,
3. architecture viewpoints framing those concerns and
4. correspondence rules integrating those viewpoints cited before.

Architecture frameworks conforming to the standard can include additional methods, tools, definitions, and
practices beyond those specified.

Types of enterprise architecture framework

Nowadays there are now countless EA frameworks, many more
than in the following listing.

Consortia-developed frameworks
ARCON – A Reference Architecture for Collaborative
Networks – not focused on a single enterprise but
rather on networks of enterprises[23][24] Just a few of the Enterprise Architecture
The Cloud Security Alliance (Trusted Cloud Initiative) frameworks utilized today, 2011[22]
TCI reference architecture. [25]

Generalised Enterprise Reference Architecture and

Methodology (GERAM)
RM-ODP – the Reference Model of Open Distributed Processing (ITU-T Rec. X.901-X.904 |
ISO/IEC 10746) defines an enterprise architecture framework for structuring the
specifications of open distributed systems.
IDEAS Group – a four-nation effort to develop a common ontology for architecture
interoperability
ISO 19439 Framework for enterprise modelling
TOGAF – The Open Group Architecture Framework – a widely used framework including an
architectural Development Method and standards for describing various types of
architecture.

Defense industry frameworks

AGATE – the France DGA Architecture Framework
DNDAF[26] – the DND/CF Architecture Framework (CAN)
DoDAF – the US Department of Defense Architecture Framework
MODAF – the UK Ministry of Defence Architecture Framework
 NAF – the NATO Architecture Framework

Government frameworks
European Space Agency Architectural Framework (ESAAF) - a framework for European
space-based Systems of Systems[27]
FDIC Enterprise Architecture Framework
Federal Enterprise Architecture Framework (FEAF) – a framework produced in 1999 by the
US Federal CIO Council for use within the US Government (not to be confused with the
2002 Federal Enterprise Architecture (FEA) guidance on categorizing and grouping IT
investments, issued by the US Federal Office of Management and Budget)
Government Enterprise Architecture (GEA) – a common framework legislated for use by
departments of the Queensland Government
Nederlandse Overheid Referentie Architectuur (NORA) – a reference framework from the
Dutch Government E-overheid NORA (https://web.archive.org/web/20090708035937/http://w
ww.e-overheid.nl/atlas/referentiearchitectuur/nora/nora.html)
NIST Enterprise Architecture Model
Treasury Enterprise Architecture Framework (TEAF) – a framework for treasury, published
by the US Department of the Treasury in July 2000.[28]
Colombian Enterprise Architecture Framework - MRAE - Marco de Referencia de
Arquitectura Empresarial (https://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-811
4.html) a framework for all the Colombian Public Agencies
India Enterprise Architecture (IndEA) framework - IndEA (https://negd.gov.in/india-enterprise-
architecture) is a reference framework from Government of India.

Open-source frameworks

Enterprise architecture frameworks that are released as open source:

Lean Architecture Framework (LAF)[29] is a collection of good practices thanks to which the
IT environment will respond consistently and quickly to a changing business situation while
maintaining its consistent form.
MEGAF[30] is an infrastructure for realizing architecture frameworks that conform to the
definition of architecture framework provided in ISO/IEC/IEEE 42010.
Praxeme, an open enterprise methodology, contains an enterprise architecture framework
called the Enterprise System Topology (EST)
TRAK – a general systems-oriented framework based on MODAF 1.2 and released under
GPL/GFDL.
Sherwood Applied Business Security Architecture (SABSA)[31] is an open framework and
methodology for Enterprise Security Architecture and Service Management, that is risk
based and focuses on integrating security into business and IT management.

Proprietary frameworks
ASSIMPLER Framework – an architecture framework, based on the work of Mandar
Vanarse at Wipro in 2002
Avancier Methods (AM)[32] Processes and documentation advice for enterprise and solution
architects, supported by training and certification.
 BRM (Build-Run-Manage) Framework - an architecture framework created by Sanjeev
"Sunny" Mishra during his early days at IBM in 2000.
Capgemini Integrated Architecture Framework (IAF) – from Capgemini company in 1993
Dragon1 - An open Visual Enterprise Architecture Method recently recognized by The Open
Group as Architecture Framework
DYA framework developed by Sogeti since 2004.
Dynamic Enterprise Enterprise architecture concept based on Web 2.0 technology
Extended Enterprise Architecture Framework - from Institute For Enterprise Architecture
Developments in 2003
EACOE Framework [3] (http://www.eacoe.org) – an Enterprise Architecture framework, as an
elaboration of the work of John Zachman
IBM Information FrameWork (IFW) – conceived by Roger Evernden in 1996
Infomet - conceived by Pieter Viljoen in 1990
Labnaf [33] - Unified Framework for Driving Enterprise Transformations
Pragmatic Enterprise Architecture Framework (PEAF)[34] - part of Pragmatic Family of
Frameworks developed by Kevin Lee Smith, Pragmatic EA, from 2008
Purdue Enterprise Reference Architecture developed by Theodore J. Williams at the Purdue
University early 1990s.
Risk- and Cost-Driven Architecture (https://www.cgi.com/en/solutions/RCDA-agile-architectu
re) (RCDA), developed by CGI since 2015.
SAP Enterprise Architecture Framework
Service-oriented modeling framework (SOMF), based on the work of Michael Bell
Solution Architecting Mechanism (SAM)[35] – A coherent architecture framework consisting
of a set of integral modules.[36]
Zachman Framework – an architecture framework, based on the work of John Zachman at
IBM in the 1980s

See also
Architecture patterns (EA reference architecture)
EABOK (The Guide to the Enterprise Architecture Body of Knowledge)
Enterprise architecture
Enterprise architecture artifacts
Enterprise architecture planning
Enterprise engineering
ISO/IEC/IEEE 42010
Reference architecture

References
1. The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework
Version 1.1 (https://www.cio.gov/documents/fedarch1.pdf) Archived (https://web.archive.org/
web/20120213215829/http://www.cio.gov/Documents/fedarch1.pdf) 2012-02-13 at the
Wayback Machine. September 1999.
2. "Tech Target" (http://searchcio.techtarget.com/definition/enterprise-architecture). SearchCIO.
3. The Open Group (2008) TOGAF Version 9. Van Haren Publishing, 1 nov. 2008.p. 73
 4. Stephen Marley (2003). Architectural Framework (https://web.archive.org/web/20090320230
522/http://aiwg.gsfc.nasa.gov/esappdocs/RPC/RPC_Workshop_Architecture_Framework.pp
t). NASA /SCI. At Webarchive.org, retrieved 3-04-2015.
5. Jaap Schekkerman (2004) How to Survive in the Jungle of Enterprise Architecture
Frameworks. p.89 gives a similar scheme.
6. US Department of Defense (2001) Department of Defense Technical Reference Model (htt
p://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.196.5206&rep=rep1&type=pdf).
Version 2.0. 9 April 2001. p. 11, mentioned that also the DoD TRM is influenced by POSIX.
7. Evans, M. K. and Hague, L. R. (1962) Master Plan for Information Systems, Harvard
Business Review, Vol. 40, No. 1, pp. 92-103.
8. Kotusev, Svyatoslav (2021) The Practice of Enterprise Architecture: A Modern Approach to
Business and IT Alignment (2nd Edition). Melbourne, Australia: SK Publishing.
9. Graham Berrisford (2008-13) "A brief history of EA: what is in it and what is not (http://graham
berrisford.com/A%20brief%20history%20of%20EA.htm) Archived (https://web.archive.org/we
b/20130918061630/http://grahamberrisford.com/A%20brief%20history%20of%20EA.htm)
2013-09-18 at the Wayback Machine" on grahamberrisford.com, last update 16/07/2013.
Accessed 16/07?2003
10. John Zachman (1982) Business Systems Planning and Business Information Control Study:
A comparison in IBM Systems Journal 21(1). p32.
11. John A. Zachman (1987). A Framework for Information Systems Architecture. In: IBM
Systems Journal, vol 26, no 3. IBM Publication G321-5298.
12. Zachman and Sowa (1992) Extending and formalising the framework of information systems
architecture IBM Systems Journal, Vol 31, No 3
13. Svyatoslav Kotusev (2016). The History of Enterprise Architecture: An Evidence-Based
Review. In: Journal of Enterprise Architecture, vol. 12, no. 1, pp. 29-37.
14. W.B. Rigdon (1989). Architectures and Standards. In Information Management Directions:
The Integration Challenge (NIST Special Publication 500-167), E.N. Fong, A.H. Goldfine
(Eds.), Gaithersburg, MD: National Institute of Standards and Technology (NIST), pp.135-
150.
15. Richardson, G.L.; Jackson, B.M.; Dickson, G.W. (1990). "A Principles-Based Enterprise
Architecture: Lessons from Texaco and Star Enterprise". MIS Quarterly. 14 (4): 385–403.
doi:10.2307/249787 (https://doi.org/10.2307%2F249787). JSTOR 249787 (https://www.jstor.
org/stable/249787).
16. Jeanne W. Ross, Peter Weill, and David C. Robertson (2006) Enterprise Architecture As
Strategy: Creating a Foundation for Business Execution. Harvard Business Review Press
17. The Open Group (2011) TOGAF® 9.1 > Part II: Architecture Development Method (ADM) >
Preliminary Phase (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html).
Accessed July 16, 2013
18. The Open Group (2011) TOGAF® 9.1 > Part II: Architecture Development Method (ADM) >
Introduction to the ADM (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.htm
l). Accessed July 16, 2013
19. TOGAF 9.1 White Paper An Introduction to TOGAF Version 9.1
http://www.opengroup.org/togaf/
20. Niles E Hewlett (2006), The USDA Enterprise Architecture Program (https://www.ocio.usda.g
ov/p_mgnt/doc/PM_Class_EA_NEH_012506_Final.ppt) Archived (https://web.archive.org/w
eb/20070508175931/http://www.ocio.usda.gov/p_mgnt/doc/PM_Class_EA_NEH_012506_F
inal.ppt) 2007-05-08 at the Wayback Machine. PMP CEA, Enterprise Architecture Team,
USDA-OCIO. January 25, 2006.
21. FEA Consolidated Reference Model Document (https://georgewbush-whitehouse.archives.g
ov/omb/egov/documents/CRM.PDF) Archived (https://web.archive.org/web/2010070504062
8/http://georgewbush-whitehouse.archives.gov/omb/egov/documents/CRM.PDF) 2010-07-
05 at the Wayback Machine. whitehouse.gov May 2005.
22. Dennis E. Wisnosky (2011) Engineering Enterprise Architecture: Call to Action (http://dcmo.d
efense.gov/products-and-services/business-enterprise-architecture/8.1/products/BusOpsTra
nsformation_EA_BI/7_cdq_issue9_january2011.pdf). in: Common Defense Quarterly.
January 2011, p. 9
23. L.M. Camarinha-Matos, H. Afsarmanesh, Collaborative Networks: Reference Modeling,
Springer, 2008.
24. Camarinha-Matos, L.M.; Afsarmanesh, H. (2008). "On reference models for collaborative
networked organizations". International Journal Production Research. 46 (9): 2453–2469.
doi:10.1080/00207540701737666 (https://doi.org/10.1080%2F00207540701737666).
S2CID 51802872 (https://api.semanticscholar.org/CorpusID:51802872).
25. "The CSA TCI reference architecture" (https://web.archive.org/web/20161106161638/https://
downloads.cloudsecurityalliance.org/initiatives/tci/TCI_Reference_Architecture_v2.0.pdf)
(PDF). Cloud Security Alliance. Archived from the original (https://ea.cloudsecurityalliance.or
g/) on 11 June 2016. Retrieved 7 July 2020.
26. DNDAF (http://www.img-ggi.forces.gc.ca/pub/af-ca/index-eng.asp) Archived (https://web.arch
ive.org/web/20110424131138/http://www.img-ggi.forces.gc.ca/pub/af-ca/index-eng.asp)
2011-04-24 at the Wayback Machine
27. Gianni, Daniele; Lindman, Niklas; Fuchs, Joachim; Suzic, Robert (2012). "Introducing the
European Space Agency Architectural Framework for Space-Based Systems of Systems
Engineering". Complex Systems Design & Management. Proceedings of the Second
International Conference on Complex Systems Design & Management CSDM 2011.
Springer. pp. 335–346. CiteSeerX 10.1.1.214.9671 (https://citeseerx.ist.psu.edu/viewdoc/su
mmary?doi=10.1.1.214.9671). doi:10.1007/978-3-642-25203-7_24 (https://doi.org/10.1007%
2F978-3-642-25203-7_24). ISBN 978-3-642-25202-0.
28. US Department of the Treasury Chief Information Officer Council (2000). Treasury Enterprise
Architecture Framework (http://www.eaframeworks.com/TEAF/teaf.doc) Archived (https://we
b.archive.org/web/20090318003653/http://www.eaframeworks.com/TEAF/teaf.doc) 2009-03-
18 at the Wayback Machine. Version 1, July 2000.
29. https://lafinstitute.org/
30. MEGAF (http://megaf.di.univaq.it/)
31. SABSA (http://www.sabsa-institute.org/)
32. Avancier Methods (AM) (http://avancier.co.uk)
33. Labnaf [1] (http://www.labnaf.one/)
34. Pragmatic EA [2] (http://www.pragmaticea.com/)
35. Solution Architecting Mechanism (SAM) (http://doi.ieeecomputersociety.org/10.1109/EDOC.
2006.54)
36. Tony Shan and Winnie Hua (2006). Solution Architecting Mechanism (http://doi.ieeecompute
rsociety.org/10.1109/EDOC.2006.54). Proceedings of the 10th IEEE International EDOC
Enterprise Computing Conference (EDOC 2006), October 2006, p23-32.

External links
Enterprise Architecture Frameworks: The Fad of the Century (https://www.bcs.org/articles-op
inion-and-research/enterprise-architecture-frameworks-the-fad-of-the-century/) (July 2016)
 A Comparison of the Top Four Enterprise Architecture Frameworks (https://www.bcs.org/artic
les-opinion-and-research/a-comparison-of-the-top-four-enterprise-architecture-frameworks/)
(July 2021)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Enterprise_architecture_framework&oldid=1155318306"