An enterprise architecture framework (EAF) 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.
Overview Enterprise architecture regards the enterprise as a large and complex system or system of systems.The Open Group (2008) TOGAF Version 9. Van Haren Publishing, 1 nov. 2008.p. 73 To manage the scale and complexity of this system, an architectural framework provides tools and approaches that help architects abstract from 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:Stephen Marley (2003). Architectural Framework. NASA /SCI. At Webarchive.org, retrieved 3-04-2015. 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"Evans, M. K. and Hague, L. R. (1962) Master Plan for Information Systems, Harvard Business Review, Vol. 40, No. 1, pp. 92-103. published in 1962 in Harvard Business Review.
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.Graham Berrisford (2008-13) "A brief history of EA: what is in it and what is not " on grahamberrisford.com, last update 16/07/2013. Accessed 16/07?2003
By 1980, IBM's Business Systems Planning (BSP) was promoted as a method for analyzing and designing an organization's information architecture, with the following goals: understand the issues and opportunities with the current applications and technical architecture; develop a future state and migration path for the technology that supports the enterprise; provide business executives with a direction and decision making framework for IT capital expenditures; 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."John Zachman (1982) Business Systems Planning and Business Information Control Study: A comparison in IBM Systems Journal 21(1). p32. 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".
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.
In 1987, John Zachman, who was a marketing specialist at IBM, published the paper, A Framework for Information Systems Architecture.John A. Zachman (1987). A Framework for Information Systems Architecture. In: IBM Systems Journal, vol 26, no 3. IBM Publication G321-5298. 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.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. 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".
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".
In 1992, a paper by Zachman and SowaZachman and Sowa (1992) Extending and formalising the framework of information systems architecture IBM Systems Journal, Vol 31, No 3 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).
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.
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 StrategyJeanne W. Ross, Peter Weill, and David C. Robertson (2006) Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Harvard Business Review Press 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.