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.
|
History |
References |
|
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.