EA history reference list

This page is published under the terms of the licence summarized in the footnote.


Before computers, operational systems analysts engaged stakeholders and analysed business scenarios to understand and define business processes.

The architects of business systems have always been concerned with:

·         contextual information (business drivers, principles, goals, visions and plans; system stakeholders and their concerns).

·         descriptions of systems (including architectural drawings, for detailed designers and builders to follow)

·         operational systems.


Enterprise architecture frameworks like FEAF and TOGAF were developed to help architects work in a future that (after the PRISM report) can be characterised as:

·         the information age

·         increasingly distributed systems

·         increasing integration and standardisation of systems.


Information processing, rather than information technology (IT), is central to EA,

EA principles, concepts and techniques can be found in methods and frameworks that predate IT.

However, IT has strengthened the ability of a business to systemise its processes.

And since the 1970s, IT people have looked to engage business people with how to better enable and support business processes.

They have also sought to influence investment in business information systems and technologies – to the wide and long term benefit of the enterprise.


Our EA history slide show takes you through history the below, with graphics.




In 1980: Business System Planning was a methodology used by IBM

1980? “Business Systems Planning” see the Wikipedia entry, and

the web site of Robinson College of Business, Georgia State University.

In 1982, Zachman spoke of the need to raise Business System Planning to the “enterprise level”.

1982 "Business Systems Planning and Business Information Control Study: A comparison"”John Zachman, in IBM Systems Journal 21(1). p32.

In 1986, enterprise-level architecture was divided into business, data, applications and infrastructure technology domains.

1986  Dispersion and Interconnection: Approaches to Distributed Systems Architecture  the PRISM report, from a consortium including IBM, DEC and others

In 1987, Zachman introduced an enterprise-wide Framework for Information System Architecture.

1987 "A Framework for Information Systems Architecture". 

John A. Zachman in IBM Systems Journal, vol 26, no 3. IBM Publication G321-5298.

In 1989, The NIST Enterprise Architecture Model was a five-layer reference model that related business, information system, and technology domains.

1989 “Enterprise Architecture Model” National Institute of Standards and Technology

In 1992, Sowa and Zachman proposed how to describe “the overall information system and how it relates to the enterprise and its surrounding environment.”

1992 “Extending and formalising the information systems architecture framework”.

Sowa and Zachman in IBM Systems Journal, Vol 31, No 3

In 1993, Spewak defined a data-centric planning process “defining architectures for the use of information in support of the business and the plan for implementing those architectures”.

1993 “EA Planning  by Stephen Spewak

See entry in Wikipedia for references.

In 1996, Each federal agency’s CIO was made responsible for “developing, maintaining and facilitating the implementation of a sound and integrated IT architecture for the executive agency.”

1996 “IT Management Reform Act” (Clinger Cohen Act)

Around 1997, Zachman recast his Framework for Information System Architecture as a Framework for Enterprise Architecture

1997? For references to his EA Framework, see Zachman’s entry in Wikipedia

In 1998, FEAF said “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].”

1999 “Federal EA Framework

Federal CIO Council

In 2001, “A practical guide to Federal Enterprise Architecture” started: “An enterprise architecture establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient information technology environment.”

2001 “A practical guide to Federal Enterprise Architecture

Chief CIO council

In 2003, Zachman listed 10 key points for EA, emphasising that without a documented architecture, you are implementing, not architecting.

2003 “The Zachman Framework For Enterprise Architecture: Primer for Enterprise Engineering and Manufacturing.” By John A. Zachman. Zachman International

By 2005, many EA frameworks existed, including the “Integrated Architecture Framework” (IAF) from Cap Gemini

???? “Integrated Architecture Framework” (IAF) Cap Gemini

In 2006, Findings from MIT’s Center for Information System Research were interpreted thus "companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." The business process operating model concept was defined.

2006 “EA as Strategy

Ross, Weill and Robertson (out of MIT CISR)

In 2011, TOGAF version 9.1 was published by The Open Group as an Architecture Framework that promotes and encourages EA, referring to operating model concept.

2009 “TOGAF 9.1” free to read at www.opengroup.org

In 2013 The British Computer Society updated their reference model for enterprise and solution architecture.

2013 The British Computer Society’s reference model for enterprise and solution architecture downloadable from www.BCS.org.

Current: Avancier Methods.



All sources above place information system architecture at the heart of EA, and emphasise the breadth of scope.

Today, EA is supposed to take a holistic view of the whole enterprise – all its core business processes and information needs.

EA is not anything that a business management consultant might do to implement a business decision.

EA is more than business analysis to address a given problem or requirement.

EA is cross-organisational business system planning, with a view to standardisation and integration of systems.


Systemisation involves defining core business processes and the resources needed to perform them.

Resources include the roles and information needed to support and enable business processes.

You can't integrate business processes without passing business data between roles and activities.

And you can't standardise business processes unless the actors in those processes are monitored and/or directed by systems.


The PRISM report says: “No one, to our knowledge, has ever explicitly and formally employed this complete approach to architecture.”

Today, has anybody standardised and integrated their systems to the extent that might be envisaged by an EA team?

Probably not, but tidying up the mess of business systems remains an ambition.


Published under the Creative Commons Attribution-No Derivative Works Licence 2.0                                      06/12/2014 12:58

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” at the start and include this footnote on each page.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this paper, not derivative works based upon it – unless you have permission from the author.

For more about the licence, see http://creativecommons.org.