Enterprise architecture

From Wikiquote
(Redirected from Enterprise Architecture)
Jump to navigation Jump to search
NIST Enterprise Architecture, one of the first EA models, 1989.

Enterprise architecture (EA) is the discipline of designing enterprises in order to rationalize its processes and organisation. In practice it is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution.


1.1 1980s
1.2 1990s : 1990 - 1991 - 1992 - 1993 - 1994 - 1995 - 1996 - 1997 - 1998 - 1999
1.3 2000s : 2000 - 2001 - 2002 - 2003 - 2004 - 2005 - 2006 - 2007 - 2008 - 2009
1.4 2010s : 2010 - 2011 - 2012 - 2013
2 See also
3 External links



  • 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). p. 32; Reprinted in: Ernest A. Kallman, Leon Reinharth (1984) Information systems for planning and decision making: the strategic and operational management of human resources, finance, manufacturing, and marketing through information. p. 95.
  • The state of the art in software design is the "enterprise architecture", where separate software components implement data processing (or other application specific-tasks), data storage, and user interface functionality. This approach enables, for example, the replacement of a database engine without changing the software components that process the data and those that support the interaction with the user.
    • Institute of Electrical and Electronics Engineers (1985) Symposium Proceedings. p. 130.
  • With increasing size and complexity of the implementations of information systems, it is necessary to use some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system.
    • John Zachman (1987) "A framework for information systems architecture". In: IBM Systems Journal, Vol 26, Issue 3, p. 276.
    • Comment : Many have considered this 1987 paper by Zachman as the article that defined the field of enterprise architecture, yet it doesn't actually uses the term.
  • Architecture discussions frequently focus on technology issues. This paper takes a broader view, and describes the need for an "enterprise architecture" that includes an emphasis on business and information requirements. These higher level issues impact data and technology architectures and decisions... There is not a single correct way to develop an architecture or implement standards for every enterprise; they must be customized to the environment.
  • Architecture is defined as a clear representation of a conceptual framework of components and their relationships at a point in time... a discussion of architecture must take into account different levels of architecture. These levels can be illustrated by a pyramid, with the business unit at the top and the delivery system at the base. An enterprise is composed of one or more Business Units that are responsible for a specific business area. The five levels of architecture are Business Unit, Information, Information System, Data and Delivery System. The levels are separate yet interrelated... The idea if an enterprise architecture reflects an awareness that the levels are logically connected and that a depiction at one level assumes or dictates that architectures at the higher level.
    • W. Bradford Rigdon (1989) "Architectures and Standards". In: Information Management Directions: The Integration Challenge E.N. Fong and A.H. Goldfine (eds). NIST Sept 1989. p. 137; Partly cited in: IT Governance Institute (2005) Governance of the Extended Enterprise. p. 89.
  • DOD will create a Department-wide blueprint (enterprise architecture) that will prescribe how the Department's financial and non-financial feeder systems and business processes interact. This architecture will guide the development of enterprise-level processes and systems throughout DOD.
    • US Army Logistics Management Center (1989). "News". In: Army logistician. p. 39.



Automatic control in manufacturing requires a very rigourous and well defined model of the operation to be controlled.
- Kurt Kosanke (1990)
  • Traditional manufactures tend to view human resources contained within highly segmented functions whereas integrated manufacturers view the entire organization as a series of resource centers. Integrated manufacturers allow and promote the sharing of critical skills on an as needed basis throughout the enterprise while Traditional manufacturers fall victim to resource hoarding.
    Given the breadth of change that new manufacturing technologies and operations philosophies will bring to many organizations, an assessment should be made as to how ready the organization and the various business functions are to accommodate these technology and non-technology changes.
    The recommended approach of course is to begin with corporate vision, objectives and strategies leading to a determination of the overall Enterprise Architecture in the areas of People, Management Practices, Support Structures and Corporate Cultures. This would ensure that all of the complementary shifts in the components of the Enterprise Architecture would be orchestrated under an overall plan of enterprise wide change.
    • American Production and Inventory Control Society. International Conference (1990) 33rd International Conference Proceedings, October 8-12, 1990, New , New Orleans, Louisiana. p. 42.
  • Automatic control in manufacturing requires a very rigourous and well defined model of the operation to be controlled. A model which on one hand reflects reality as closely as possible and on the other hand allows easy and fast modifications and updates to reflect the continuous changes in the real world. CIM-OSA provides the modelling concepts to describe and maintain the complete manufacturing systems. In addition, CIM-OSA aims to provide at providing consistent engineering and operational environments to model for execution as well as for real time operation control.
    Keywords: CIM; CIM architecture; enterprise architecture; enterprise modelling; enterprise optimisation; enterprise control; real time control;
    • Kurt Kosanke (1990) "CIM-OSA: Its role in Manufacturing Control" in: International Federation of Automatic Control, Ülo Jaaksoo eds. (1990) Proceedings of the IFAC World Congress; 11, 1990, IFAC World Congress; 11 (Tallinn/Estonia/USSR): 1990.08.13-17. Vol 5. p. 309.


  • Enterprise architectures are required to support and maximize the efforts of virtual teams within decentralized organizations. Vendor products exist today to start evolving towards a standards-based multi-vendor architecture. The underlying networking technology, 802.3/Ethemet, is robust and will provide for a cost-effective investment that will last for many years to come. Complimentary LAN technologies are already available to ensure transparent growth of networked systems. Combining human resources with information technology will be the key differentiating factor for successful manufacturing enterprises in the 1990s.
    • Instrument Society of America (1991) Proceedings of the Industrial Computing Conference, Volume 1. p. 647.
  • The Enterprise Architecture is a combination of the Business and Computing architectures. The Computing Architecture, at the least, identifies hardware, software and data communications.
    • From: Journal of Systems Management (1991) Vol. 42, Nr. 2-12. p. 29.
  • When one enterprise architecture dominates, Grumman plans to use it as a "manager of managers." This single, enterprise-wide network-management architecture will run over all other network-management systems being used: no existing scheme will be scrapped.
    • From Systems Integration (1991). Vol 24. p. 35.
  • For the IT department [the] change towards commodity products, open standards, end-user decision making and fundamental change in the Business platform, will imply substantial challenges. The role of the IS function will change.
    The formal IS budget in the US, according to Gartner Group Inc, is 2.4% of revenue in 1990, and will grow to 2.7% in 1995.
    End-user IT spending is estimated t0 2.4% in 1990, split 50/50 between budget and unseen expenses. This item is assumed to increase to 5.0% in 1995, bringing the total to 7.7%
    This total amount must be managed, and the rules must be set by the IS manager. Following the rule of "Least resistance", will lead to crisis and complete loss of control.
    IT resources must be managed. An Enterprise Architecture must be established and adhered to. Standards must be established, and partnerships between IT professionals and end-users formed.
    • Gunnar E. Wille (1991) "The information industry scenario in year 2000, trends and change of focus, for the it professional and for the end-user."


ARIS Model by A.W. Scheer, 1991.
Levels of Enterprise Architecture Planning, 1992.
PERA Decision-making and control hierarchy, 1992
  • A key ingredient to an enterprise architecture is the ability to link multiple and disparate systems into a coherent whole. Novell has been gradually putting together the technology that will enable it to offer enterprise LANs that are capable of supporting distributed applications running across a variety of computer Internetworking and multi- routing are essential building blocks.
  • The creation and implementation of integrated information systems involves a variety of collaborators including people from specialist departments, informatics, external advisers and manufacturers. They need clear rules and limits within which they can process their individual sub-tasks, in order to ensure the logical consistency of the entire project. Therefore, an architecture needs to be established to determine the components that make up the information system and the methods to be used to describe it. The ARIS architecture developed in this book is described in concrete terms as an information model within the entity-relationship approach. This information model provides the basis for the systematic and rational application of methods in the development of information systems. It also serves as the basis for a repository in which the enterprise's application - specific data, organization and function models can be stored. The ARIS architecture constitutes a framework in which integrated applications systems can be developed, optimized and converted into EDP - technical implementations. At the same time, it demonstrates how business economics can examine and analyze information systems in order to translate their contents into EDP-suitable form.
    • August-Wilhelm Scheer, I. Cameron (1992) Architecture of integrated information systems: foundations of enterprise modelling. Abstract
  • Enterprise Architecture Planning (EAP) results in a high-level blueprint of data, applications, and technology that is a cost-effective, long-term solution; not a quick fix. Management participation provides a business perspective, credibility, and de-mystifies the systems planning process. EAP can be labeled as business-driven or data -driven because
    • a stable business model (independent of organizational systems, and procedures) is the foundation for the architectures,
    • data is defined before applications, and
    • data dependency determines the sequence for implementing application systems...
Enterprise Architecture Planning is the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures. There are three important words in the above definition. The first is architectures — plural because there are three architectures: a data architecture, an applications architecture, and a technology architecture. Architectures, in this context, are like blueprints, drawings, or models. In EAP, architectures define and describe the data, applications, and technology needed to support the business. The second important word is defining. EAP defines the business and defines the architectures. EAP is defining, not designing.
  • Steven Spewak and S. C. Hill (1992) Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. Boston, QED Pub. Group. p. xxi- p. 1
  • This is an intermediate work that describes PERA, which is a general enterprise reference architecture model that is suited for manufacturing enterprises.
    The book explains PERA as a layered architecture, and within the context of an architectural life cycle. PERA at the conceptual level is focused on the integration of physical plant, human resources, and information systems. This approach is clearly suited to manufacturing, and in fact, the model has been adopted and adapted by Fluor Daniel Corporation (among others) and has been proven in practice...
    • Theodore J. Williams (1992) The Purdue enterprise reference architecture: a technical guide for CIM planning and implementation. Review from: The Purdue Enterprise Reference Architecture (Paperback)


  • The integration technology and infrastructure elements available today, in 1993, would enable an enterprise to develop a significant integration infrastructure. However, integration projects are constrained by cultural inertia, financial and resource limitations, and, significantly, risk management Thus, Enterprise Integration projects and their supporting integration infrastructures tend to be deployed in an incremental and evolutionary manner. Since each enterprise chooses its integration path based on particular business needs, the corporations visited in this study each presented a different road map of integration efforts to date and a unique snapshot of current integration infrastructure....
    DoD, in concert with leading companies, should formulate an R&D strategy to create a new generation of enterprise architectures, models, tools, and software systems, and to determine the potential for new business operations, engineering practices, and manufacturing concepts. To achieve potential functional and performance improvements, integrators should combine the leverage of several emerging threshold technologies, such as operational integration frameworks, object-based and knowledge-based product and process representations, application-oriented network services, near-term and mid-term solutions to database integration, and wide-area object brokerage and execution.-
    • Robert I. Winner (1993) Information Infrastructures for Integrated Enterprises p. 38 & p. 89-90.


  • A company's enterprise architecture is unique — neither good nor bad, but only appropriate or inappropriate in regard to management's vision of the future. The current enterprise architecture either supports the vision or it does not.
    • American Production and Inventory Control Society (1994) APICS, the Performance Advantage. Vol 4. p. 36.
  • An enterprise architecture can be thought of as a "blueprint" or "picture" which assists in the design of an enterprise. The enterprise architecture must define three things. First, what are the activities that an enterprise performs? Second, how should these activities be performed? And finally, how should the enterprise be constructed? Consequently, the architecture being developed will identify the essential processes performed by a virtual company, how the virtual company and the agile enterprises involved in the virtual company will perform these processes, and include a methodology for the rapid reconfiguration of the virtual enterprise.
    • William Barnett, Adrien Presley, Mary Johnson, and Donald H. Liles (1994) "An architecture for the virtual enterprise." Systems, Man, and Cybernetics, 1994.' Humans, Information and Technology'., 1994 IEEE International Conference on. Vol. 1. IEEE, 1994.
  • An enterprise architecture is an abstract summary of some organizational component's design. The organizational strategy is the basis for deciding where the organization wants to be in three to five years. When matched to the organizational strategy, the architectures provide the foundation for deciding priorities for implementing the strategy.
    • Sue A. Conger (1994) The new software engineering. p. 115.
  • It is within the purview of each context to define its own rules and techniques for deciding how the object-oriented mechanisms and principles are to be managed. And while the manager of a large information system might wish to impose some rules based on philosophical grounds, from the perspective of enterprise architecture, there is no reason to make decisions at this level. Each context should define its own objecttivity.
    • Rob Mattison, Michael J. Sipolt (1994) The object-oriented enterprise: making corporate information systems work. McGraw-Hill. p. 270.
  • Although the concept of an enterprise architecture (EA) has not been well defined and agreed upon, EAs are being developed to support information system development and enterprise reengineering. Most EAs differ in content and nature, and most are incomplete because they represent only data and process aspects of the enterprise. This paper defines an EA... An EA is a conceptual framework that describes how an enterprise is constructed by defining its primary components and the relationships among these components.
    • M.A. Roos (1994) "Enterprise architecture: definition, content, and utility" in: Enabling Technologies: Infrastructure for Collaborative Enterprises, 1994. Proceedings., Third Workshop on Date of Conference: 17-19 Apr 1994. p. 106-111.
  • Enterprise computing and open systems - what are the distinctions between the two. Open systems are oriented towards an environment where most or all of the computing technology that comprises that environment is based upon standards regardless of the scope of the environment - departmental or organization-wide. Enterprise computing, by contrast, encompasses not only open system concepts but, by virtue of existing environments that must be incorporated as well, a great deal of proprietary interfaces and interoperability mechanisms.
    In the early 1990s, as both movements were beginning to gain momentum, there was some degree of overlap between open systems and enterprise computing, the amount of which was hindered somewhat by the stage at which enterprise architectures and standards were. It was anticipated that over time, as the enterprise architectures, open standards, and products built on one or both evolved and matured, the gap between the two would narrow and a greater degree of overlap would occur. As it turns out, the two movements have converged...
    • Alan Simon (1994) Network re-engineering: Foundations of enterprise computing. p. 42.


The Different Architectures in the US DoD C4I Technical Architecture, 1995
Application Portability Profile of the US DoD C4I Technical Architecture, 1995
  • The Enterprise Project is collaborative work between AIAI at the University of Edinburgh, IBM UK, Lloyd's Register of Shipping, Logica and Unilever. The project is establishing a generic framework within which enterprise tools can be used to assist users in their tasks. It is based on an Enterprise ontology which establishes shared terminology for communication between users and tools... The core of the tool set will support user tasks via a workflow engine which will assist the user in performing a task, allow access to appropriate tools and methods, and make available suitable information resources. An abstraction of this central work ow within the tool set is provided in this paper. This acts to provide a framework for describing the various components integrated within the tool set and allowing them to be provided in a modular fashion.
  • An enterprise architecture is a snapshot of how an enterprise operates while performing its business processes. The recognition of the need for integration at all levels of an organisation points to a multi-dimensional framework that links both the business processes and the data requirements. Such a framework is provided by the Information Systems Architecture (ISA) developed by John Zachman.
    • John Murphy, Brian Stone eds. (1995) OOIS ...: … International Conference on Object Oriented Information Systems : Proceedings. p. 354.
  • The presence of an enterprise reference architecture aids an enterprise in its ability to understand its structure and processes. Similar to a computer architecture, the enterprise architecture is comprised of several views. The enterprise architecture should provide activity, organizational, business rule (information), resource, and process views of an organization.
    • Joseph Sarkis, Adrien Presley and Donald H. Liles (1995) "The management of technology within an enterprise engineering framework." in: Computers & industrial engineering.
  • There is no such thing as a standard enterprise architecture. Enterprise design is as unique as a human fingerprint, because enterprise differ in how they function. Adopting an enterprise architecture is therefore one of the most urgent tasks for top executive management. Fundamentally, and information framework is a political doctrine for specifying as to who will have what information to make timely decisions...
    Enterprise architecture [is] the Holy Grail of all systems people. Advanced systems textbooks tell you that every organization must have one. Several CIM program directors attempted to come up with this abstraction, only to fail. Only someone with a depth of understanding about how the Pentagon really works could come up with anything of use.
    • Paul A. Strassmann (1995). The politics of information management: policy guidelines. p. 53 & p. 422.
  • "Most enterprise architectures are obsolete," says Martin, and "most end-to-end processes are clumsy, slow, expensive, and even harmful; they need to be replaced with routines that are fast and focus on the needs of the customer."
    • The American Management Association (1995) Executive Forum. p. 3.


The Generic Enterprise Reference Architecture and Methodology is about those methods, models and tools which are needed to build the integrated enterprise.
- Peter Bernus, 1996
DoD Standards-Based Architecture Planning Process, 1996.
  • The Generic Enterprise Reference Architecture and Methodology is about those methods, models and tools which are needed to build the integrated enterprise. The architecture is generic because it applies to most, potentially all types of enterprise. The coverage of the framework spans Products, Enterprises, Enterprise Integration and Strategic Enterprise Management, with the emphasis being on the middle two. The proposal for the architecture follows the architecture itself improving the quality of the presentation and of the outcome. Definitions of Generic Enterprise Reference Architecture, Enterprise Engineering/ Integration Methodology, Enterprise Modelling Languages, Enterprise Models, and Enterprise Modules are given. It is proposed how the above could be developed on the basis of previously analysed architectures (and other results too), such as the Purdue Enterprise Reference Architecture, the GRAI Integrated Methodology, CIM-OSA, and TOVIE.
    • Peter Bernus and Laszlo Nemes (1996) "A framework to define a generic enterprise reference architecture and methodology." Computer Integrated Manufacturing Systems Vol 9 (3) p. 179.
  • The term "information technology architecture," with respect to an executive agency, means an integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the agency’s strategic goals and information resources management goals.
    • Clinger–Cohen Act (1996); Cited in: National Defense Authorization Act for Fiscal Year 2008 (Public Law 104–106—Feb. 10, 1996.
  • One could then consider the enterprise-reference architecture to be a meta model of the enterprise representation. The enterprise-architecture is a component of this meta model.
    • James G. Nell (1996) "Enterprise representation: an analysis of standards issues." Modelling and Methodologies for Enterprise Integration. Springer US. p. 56-68.
  • In the early '80's, there was little interest in the idea of Enterprise Reengineering or Enterprise Modeling and the use of formalisms and models was generally limited to some aspects of application development within the Information Systems community. The subject of "architecture" was acknowledged at that time, however, there was little definition to support the concept. This lack of definition precipitated the initial investigation that ultimately resulted in the "Framework for Information Systems Architecture." Although from the outset, it was clear that it should have been referred to as a "Framework for Enterprise Architecture," that enlarged perspective could only now begin to be generally understood as a result of the relatively recent and increased, world-wide focus on Enterprise "engineering."
    The Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise’s systems. It was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created over the process of designing and producing complex physical products (e.g. buildings or airplanes.)
    • John A. Zachman (1996) The Framework for Enterprise Architecture: Background, Description and Utility. Paper Zachman International.


TISAF Architectural views, 1997
  • The Enterprise Architecture is the explicit description of the current and desired relationships among business and management process and information technology. It describes the "target" situation which the agency wishes to create and maintain by managing its IT portfolio.
    The documentation of the Enterprise Architecture should include a discussion of principles and goals. For example, the agency's overall management environment, including the balance between centralization and decentralization and the pace of change within the agency, should be clearly understood when developing the Enterprise Architecture. Within that environment, principles and goals set direction on such issues as the promotion of interoperability, open systems, public access, end-user satisfaction, and security.
  • Architecture is that set of design artifacts, or descriptive representations, that are relevant for describing an object, such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change).
    • John A. Zachman (1997) "Enterprise architecture: The issue of the century." Database Programming and Design Vol 10 (3). p. 49.
  • A conceptual framework that links the Departmental and Programmatic missions, goals, and objectives, and provides a mapping of the current and future DOE business information required to support them.
  • Establishing an enterprise architecture is like reengineering an aircraft in flight.
    • Object magazine (1997). Vol 7 (7-12). p. 24.


US DOE Departemental Enterprise Vision, 1998.
  • CIMOSA provides a Reference Architecture (known as the CIMOSA cube) from which particular enterprise architectures can be derived. This Reference Architecture and the associated enterprise modelling framework are based on a set of modelling constructs, or generic building blocks, which altogether form the CIMOSA modelling languages.
    • Peter Bernus, Kai Mertins, Günter Schmidt (1998) Handbook on Architectures of Information Systems. p. 244.
  • GERAM (The Generalized Enterprise Reference Architecture Methodology) is a class of enterprise architectures and their associated methodologies as developed by the IFAC/IFIP Task Force on Architectures for Enterprise Integration in their work during the period 1990-1996
    • Arturo Molina, José M. Sánchez, Andrew Kusiak (1998) Handbook of Life Cycle Engineering: Concepts, Models and Technologies. p. 326.


  • Generically, an architecture is the description of the set of components and the relationships between them. Simple enough. The trouble starts when you tack on an adjective: There are software architectures, hardware architectures, network architectures, system architectures, and enterprise architectures. People have their own preconceived notions and experiences about “architecture.”
    A software architecture describes the layout of the software modules and the connections and relationships among them. A hardware architecture can describe how the hardware components are organized. However, both these definitions can apply to a single computer, a single information system, or a family of information systems. Thus “architecture” can have a range of meanings, goals, and abstraction levels, depending on who’s speaking.
    An information system architecture typically encompasses an overview of the entire information system—including the software, hardware, and information architectures (the structure of the data that systems will use). In this sense, the information system architecture is a meta-architecture. An enterprise architecture is also a meta-architecture in that it comprises many information systems and their relationships (technical infrastructure). However, because it can also contain other views of an enterprise—including work, function, and information—it is at the highest level in the architecture pyramid. It is important to begin any architecture development effort with a clear definition of what you mean by “architecture.”
  • This book... provides a formal notational system for drawing and maintaining IT architectures, which I call the Enterprise Information Technology Architecture Blueprinting (EAB for short). This methodology adresses the features required of any formal notational system... In short, EAB defines a communications system that allows a community of IT professionals to visualize architectures in a standard manner.
    • Bernard H. Boar (1999). Constructing Blueprints for Enterprise IT Architectures. John Wiley & son. p. xxiii.
  • Similar to a computer architecture, the enterprise architecture is comprised of several views, including activity view, organizational view, business rule (information) view, resource view, and process view. These views should be cross-referenced with each other to provide an integrated picture of the enterprise.
    • Zhen-Yu Chen eds. (1999) Low cost automation 1998: (LCA'98): a proceedings volume from the 5th IFAC Symposium, Shenyang, P.R. China, 8-10 September 1998. p. 200.
  • Enterprise architecture is a family of related architecture components. This include information architecture, organization and business process architecture, and information technology architecture. Each consists of architectural representations, definitions of architecture entities, their relationships, and specification of function and purpose. Enterprise architecture guides the construction and development of business organizations and business processes, and the construction and development of supporting information systems.
    Enterprise architecture is a holistic representation of all the components of the enterprise and the use of graphics and schemes are used to emphasize all parts of the enterprise, and how they are interrelated... Enterprise architectures are used to deal with intra-organizational processes, interorganizational cooperation and coordination, and their shared use of information and information technologies. Business developments, such as outsourcing, partnership, alliances and Electronic Data Interchange, extend the need for architecture across company boundaries.
    • Gordon Bitter Davis (1999) The Blackwell encyclopedic dictionary of management information systems‎. p. 72.


Structure of the US Federal Enterprise Architecture Framework components, 2001.


  • Architecture : The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
    • IEEE-SA (2000) IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (ANSI/IEEE Std 1471-2000). p. 9.
  • The use of Enterprise Architectures is becoming increasingly widespread in the private sector. Borrowing insights from enterprise reference architectures developed during the last decade, IT vendors and companies belonging to specific industries are establishing reference data and process models advancing the standardisation of their businesses and creating a more integrated environment for their activities. Although public administrations share the same problem of non-standardisation, which is being magnified rapidly in a changing and demanding environment, little has been done so far in the direction of integration...
    • Vassilios Peristeras and Konstantinos Tarabanis (2000). "Towards an enterprise architecture for public administration using a top-down approach." European Journal of Information Systems Vol 9 (4). p. 252 (abstract).


  • The concept of EAs dates back to the mid-1980s. At that time, John Zachman, widely recognized as a leader in the field, identified the need to use a logical construction blueprint (i.e., an architecture) for defining and controlling the integration of systems and their components. Accordingly, Zachman developed a “framework” or structure for logically defining and capturing an architecture. Drawing parallels to the field of classical architecture, and, later, to the aircraft manufacturing industry, in which different work products (e.g., architect plans, contractor plans, shop plans, bills of lading) represent different views of the planned building or aircraft, respectively, Zachman’s framework identified the kind of work products needed to understand and thus build a given system or entity. In short, this framework provides six perspectives or windows from which to view how a given entity operates. The perspectives are those of the (1) strategic planner, (2) system user, (3) system designer, (4) system developer, (5) subcontractor, and (6) system itself. Associated with each of these perspectives, Zachman also proposed six abstractions of the entity, or models covering (1) how the entity operates, (2) what the entity uses to operate, (3) where the entity operates, (4) who operates the entity, (5) when entity operations occur, and (6) why the entity operates. Zachman’s framework provides a way to identify and describe an entity’s existing and planned component parts and the parts’ relationships before the costly and time-consuming efforts associated with developing or transforming the entity begin.
  • Since the late 1980s, architecture frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology framework in 1989. Subsequently, we issued EA guidance, and our research of successful public and private sector organizations’ IT management practices identified the use of EAs as a factor critical to these organizations’ success. Since that time, other federal entities have issued EA frameworks, including the Department of Defense, Department of the Treasury, and the federal CIO Council. Although the various frameworks use different terminology and somewhat different structures, they are fundamentally consistent in purpose and content, and they are being used today to varying degrees by many federal agencies.
    The emergence of federal frameworks and guidance over the last 5 years owes largely to the Congress’s passage of the Clinger-Cohen Act in 1996. This act, among other things, requires the CIOs for major departments and agencies to develop, maintain, and facilitate the implementation of information technology architectures as a means of integrating business processes and agency goals with IT. In response to the act, OMB, in collaboration with us, issued guidance on the development and implementation of EAs...
  • An architecture framework is a tool which can be used for developing a broad range of different architectures [architecture descriptions]. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.


Evolution of Enterprise Architecture Frameworks from 1987 to 2003
  • Principal among the Strategic Systems Architectures is the so-called ‘Enterprise Architecture’. This is usually regarded as an ‘umbrella’ architecture that covers business, application, information and technical architectures too. This Best Practice Guide concentrates on the structure, construction and use of an Enterprise Architecture.
    An Enterprise Architecture is a dynamic and powerful tool that helps organisations understand their own structure and the way they work. It provides a ‘map’ of the enterprise and a ‘route planner’ for business and technology change. A well-constructed Enterprise Architecture provides a foundation for the ‘Agile’ business.
    Normally an EA takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise. An important use is in systematic IT planning and architecting, and in enhanced decision-making. The EA can be regarded as the ‘master architecture’ that contains all the subarchitectures for an enterprise.
    The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organisation; its systems and data; the technology used and any other relevant spheres of interest.
    • Jarvis, Bob (2003) Enterprise Architecture: Understanding the Bigger Picture - A Best Practice Guide for Decision Makers in IT, The UK National Computing Centre, Manchester, UK. p. 9.
  • Enterprise Architecture is a complete expression of the enterprise; a master plan which "acts as a collaboration force" between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business, such as computers, operating systems and networks
    • Jaap Schekkerman (2003/04) How to Survive in the Jungle of Enterprise Architecture. p. 13; as cited in: Peter Rittgen (2007) Enterprise Modeling and Computing with UML. p. 73.
  • Enterprise Architecture is the discipline whose purpose is to align more effectively the strategies of enterprises together with their processes and their resources (business and IT). Enterprise architecture is complex because it involves different types of practitioners with different goals and practices. Enterprise Architecture can be seen as an art; it is largely based on experience but does not have strong theoretical foundations. As a consequence, it is difficult to teach, to apply, and to support with computer-aided tools.
    • Alain Wegmann (2003) "On the systemic enterprise architecture methodology (SEAM)". Published at the International Conference on Enterprise Information Systems 2003 (ICEIS 2003).


  • [T]he average company’s enterprise system - i.e. the overall system of IT related entities - is today highly complex. Technically, large organizations possess hundreds or thousands of extensively interconnected and heterogeneous single IT systems performing tasks that varies from enterprise resource planning to real-time control and monitoring of industrial processes. Moreover are these systems storing a wide variety of sometimes redundant data, and typically they are deployed on several different platforms... Organizationally, the enterprise system embraces business processes and business units using as well as maintaining and acquiring the IT systems. The interplay between the organization and the IT systems are further determined by for instance business goals, ownership and governance structures, strategies, individual system users, documentation, and cost.
    Lately, Enterprise Architecture (EA) has evolved with the mission to take a holistic approach to managing the above depicted enterprise system. The discipline’s presumption is that architectural models are the key to succeed in understanding and administrating enterprise systems. Compared to many other engineering disciplines, EA is quite immature in many respects. This thesis identifies.. firstly, the lack of explicit purpose for architectural models... [A] company’s Chief Information Officer (CIO) should guide the rationale behind the development of EA models. In particular, distribution of IT related information and knowledge throughout the organization is emphasized as an important concern uncared for. Secondly, the lack of architectural theory is recognized...
  • An enterprise architecture framework
    • Identifies the types of information needed to portray an Enterprise Architecture
    • Organizes the types of information into a logical structure, and
    • Describes the relationships among the information types.
Often the information is categorized into architecture models and viewpoints.... The EA framework can also identify the product types, sometimes called models, needed to describe the EA and show how to portray linkages between different types of EA information such as mission needs, business processes, data, and IT capabilities.
  • The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds.
    • James McGovern, Scott W. Ambler and M. E Stevens (2004) A Practical Guide to Enterprise Architecture. p. 35.
  • The concept of enterprise architecture emerged in the mid-1980s as a means for optimizing integration and interoperability across organizations. In the early 1990s, GAO research of successful public and private sector organizations led it to identify enterprise architecture as a critical success factor for agencies that are attempting to modernize their information technology (IT) environments. Since then, GAO has repeatedly identified the lack of an enterprise architecture as a key management weakness in major modernization programs at a number of federal agencies. It has also collaborated with the Office of Management and Budget (OMB) and the federal Chief Information Officers (CIO) Council to develop architecture guidance. In 2002, OMB began developing the Federal Enterprise Architecture (FEA), an initiative intended to guide and constrain federal agencies’ enterprise architectures and IT investments.
  • During the mid-1980s, John Zachman... identified the need to use a logical construction blueprint (i.e., an architecture) for defining and controlling the integration of systems and their components... Since Zachman introduced his framework, a number of frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology (NIST) framework in 1989. Since that time, other federal entities have issued enterprise architecture frameworks, including the Department of Defense (DOD) and the Department of the Treasury. In September 1999, the federal CIO Council published the Federal Enterprise Architecture Framework, which was intended to provide federal agencies with a common construct for their architectures, thereby facilitating the coordination of common business processes, technology insertion, information flows, and system investments among federal agencies. The Federal Enterprise Architecture Framework describes an approach, including models and definitions, for developing and documenting architecture descriptions for multi-organizational functional segments of the federal government.
  • Since the late 1980s, EA Management Frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology framework in 1989. In 1992, the GAO issued EA guidance entitled Strategic Information Planning: Framework for Designing and Developing System Architecture. This EA Management Framework was intended to:
    • provide a basis for systematically determining information needs,
    • identify and analyze information and data needs and relationships,
    • identify and analyze alternative ways to satisfy information needs, and
    • provide factors to be considered in arriving at the best way to satisfy information needs.
Since 1992, other federal entities have issued EA Management Frameworks, including the Department of Defense, the Department of the Treasury, and the Federal Chief Information Officers Council (CIO Council). Although the various frameworks use different structures, the frameworks are fundamentally consistent in purpose and content, and are being used today to varying degrees by many federal agencies.
In April 2003, the GAO, in collaboration with the OMB and the CIO Council, published a new EA Management Framework. The new EA Management Framework provides measures for management to assess progress toward the desired end and to take corrective action to address unacceptable deviations.
The GAO EA Management Framework consists of three basic components: 1) five hierarchical stages of management maturity, 2) categories of attributes that are critical to the success in managing any endeavor, and 3) elements of EA management that form the core of the CIO Council's Practical Guide.


  • In the 1970s and 1980s, business processes were redesigned on average once every seven years. This rate of change was easy for the IT department to follow. The time needed to alter the information systems that supported new or changed business processes stayed within acceptable limits. In the 1990s, the rate of change began to increase and information systems began to lag behind. In 2000, a manager succinctly remarked: “We can completely redesign our business processes every three months and subsequently our IT department needs a year to catch up with the supporting information systems.”
    • Roel Wagter, Martin van den Berg, Joost Luijpers (2005) Dynamic Enterprise Architecture: How to Make It Wor. p. 15.


  • Enterprise ontology is a novel subject, and writing a book on this novel subject puts the author under the obligation to provide at least two kinds of explanation. One explanation regards the justification of presenting yet another point of view on enterprises. Why and how would enterprise ontology assist in coping with the current and future problems related to enterprises? The other explanation concerns the particular approach towards enterprise ontology that the author takes. Why would this approach be more appropriate and more effective than some other one? These are serious questions indeed, and anyone who takes the pain to study this book deserves satisfying answers. You will get the answers; however, not straight away. A first attempt is in this introductory chapter. Definite and fully satisfying answers can only emerge from a dedicated and thorough study of the book. The lasting reward of such a study is a novel and powerful insight into the essence of the operation of enterprises; by this we mean insight that is fully independent of the (current) realization and implementation.
    • Jan L.G. Dietz (2006) Enterprise Ontology. Springer Berlin Heidelberg. Abstract.
  • [T]his article presents the results of a survey in which Swedish CIOs have prioritized their most important concerns. The three most pertinent concerns are to decrease the cost related to the business organization, improve the quality of the interplay between the IT organization and the business organization, and provide new computer-aided support to the business organization.
    The survey also shows that CIOs in large companies have a more business-oriented focus than those in small companies... [and that] the foci of Enterprise Architecture frameworks should be aligned with the concerns of the CIO.
  • Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of a company's operation model... The key to effective enterprise architecture is to identify the processes, data, technology, and customer interfaces that take the operating model from vision to reality.
    • Jeanne W. Ross, Peter Weill, David Robertson (2006). Enterprise architecture as strategy: creating a foundation for business. p. 47.


Using Architectures for Analysis, 2007
  • Architecture has two meanings depending upon its contextual usage:
    (1) A formal description of a system, or a detailed plan of the system at component level to guide its implementation;
    (2) The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.
    • The Open Group (2007) TOGAF 2007 Edition: (incorporating 8.1.1). p. 5.
  • Most business-folk have probably never heard of enterprise architecture. Which is not surprising, because most of the literature in the field suggests it’s about IT, and only about IT. There might be a few throwaway references somewhere to some blurry notion of ‘business architecture’, but that’s about it. Hence of no relevance to everyday business, really. Which is a problem, because real enterprise-architecture isn’t much about IT at all. Or rather, although IT is significant, it’s only one small part. Turns out instead that that blurry ‘business architecture’ isn’t something that can be skipped in a headlong rush down to the technical minutiae: it’s actually the core of enterprise-architecture. Enterprise-architecture is about the architecture – the structure – of the whole of the enterprise:
Enterprise-architecture is the integration of everything the enterprise is and does.
Even the term ‘architecture’ is perhaps a little misleading. It’s on a much larger scale, the scale of the whole rather than of single subsystems: more akin to city-planning than to the architecture of a single building. In something this large, there are no simple states of ‘as-is’ versus ‘to-be’, because its world is dynamic, not static. And it has to find some way to manage the messy confusion of what is, rather than the ideal that we might like it to be.
  • Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers.
  • Enterprise architecture is a management practice to maximize the contribution of an agency’s resources, IT investments, and system development activities to achieve its performance goals. Architecture describes clear relationships from strategic goals and objectives through investments to measurable performance improvements for the entire enterprise or a portion (or segment) of the enterprise


  • In the case of Enterprise Architecture, the most widely read book ever published with this kind of subject or field of study is entitled Enterprise Architecture as Strategy. By reading this book, you will learn that every company has its own architecture, but unfortunately, some just do not have the right one.
    • Gerard Blokdijk (2008) Enterprise Architecture 100 Success Secrets. p. 37.
  • Enterprise Architecture is conceptually defined as the normative restriction of design freedom. Practically, it is a coherent and consistent set of principles that guide the design, engineering, and implementation of an enterprise. Any strategic initiative of an enterprise can only be made operational through transforming it into principles that guide the design, engineering, and implementation of the new enterprise. Only by applying this notion of Enterprise Architecture can consistency be achieved between the high-level policies (mission, strategies) and the operational business rules of an enterprise.
    • Jan Dietz and Jan Hoogervorst (2008) Advances in enterprise engineering I: 4th International Workshop CIAO! and 4th International Workshop EOMAS, held as CAiSE 2008, Montpellier, France, June 16-17, 2008 proceedings, Volume 1. p. ix.
  • Since the 1970's, organizations are spending more and more money building new information systems. The fast growing number of systems and in many cases the ad hoc manner in which the systems were integrated have exponentially increased the cost and complexity of information systems. At the same time organizations are finding it more and more difficult to keep these information systems in alignment with business need. Furthermore, the role of information systems has changed during the last two decades, from automation of routine administrative tasks to a strategic and competitive weapon. In light of this development, a new field of research and practice was born that soon came to be known as Enterprise Architecture.
    • Mats-Åke Hugoson, Thanos Magoulas, and Kalevi Pessi (2008) "Interoperability strategies for business agility." Advances in Enterprise Engineering I. Jan L.G. Dietz, Antonia Albani eds. Springer Berlin Heidelberg, 2008. p. 110.
  • Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them.
  • The goal of enterprise architecture is to create a unified IT environment (standardized hardware and software systems) across the firm or all of the firm's business units, with tight symbiotic links to the business side of the organization (which typically is 90% of the firm... at least by way of budget). More specifically, the goals are to promote alignment, standardization, reuse of existing IT assets, and the sharing of common methods for project management and software development across the organization.
    • Daniel Minoli (2008) "Enterprise architecture A to Z: frameworks, business process modeling, SOA". p. 9.
  • Enterprise Architecture (EA) is becoming an increasingly mature field of work, but many large organizations still struggle with implementing an integral and truly effective EA function. The literature provides a fragmented picture of the EA function, describing the various separate elements that make up the total package of activities, resources, skills, and competences of the EA delivery function. In our view, the EA function reaches beyond EA delivery and also includes the stakeholders, structures and processes involved with EA decision making and EA conformance. A holistic and integral view on the EA function is essential in order to properly assess an EA function on its performance, and to allow identifying the key points of improvement...
  • The dream of every CEO is to have one standardized, integrated, flexible and manageable landscape of aligned business and IT processes, systems and procedures. Having complete control over all projects implementing changes in that landscape so that they deliver solutions that perfectly fit the corporate and IT change strategies, makes this dream complete. The reality for many large organizations is quite the opposite. Many large organizations struggle to keep their operational and change costs in control. Key reasons are the inflexibility and enormous complexity of their business and IT structures, processes, systems, and procedures, often distributed across lines of business (LoB) and business divisions (BD) spread out over various regions, countries or even continents.., Over the last decade, Enterprise Architecture (EA) has been one of many instruments used by organizations in their attempt to get grip on the current operational environment and the implementation of changes. EA provides standardization, and sets a clear direction for the future to guide changes.


  • Enterprise Architecture is the description and visualization of the structure of a given area of contemplation, its elements and their collaborations and interrelations links vision, strategy and feasibility, focusing on usability durability and effectiveness. Architecture enables construction, defining principles, rules, standards and guidelines, expressing and communicating a vision.
    • Capgemini (2009); cited in: Martin Op 't Land, Erik Proper (2009) Enterprise Architecture: Creating Value by Informed Governance. p. 33.
  • When software applications became larger and larger, people such as Shaw and Garlan coined the term software architecture. This notion of architecture deals with the key design principles underlying software artefacts. In the 1980s and 1990s, people became aware that the development of information technology (IT) should be done in conjunction with the development of the context in which it was used. This led to the identification of the so-called business/IT alignment problem. Solving the business/IT alignment problem requires enterprises to align human, organizational, informational, and technological aspects of systems. Quite early on, the term architecture was also introduced as a means to further alignment, and thus analyzes and solves business?IT alignment problems, Recently, the awareness emerged that alignment between business an IT is not enough, there are many more aspects in the enterprise in need of alignment. This has led to the use of the term architecture at the enterprise level: enterprise architecture.
    • Martin Op 't Land, Erik Proper (2009) Enterprise Architecture: Creating Value by Informed Governance. p. 26-27.
  • Enterprise architecture {is] a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise's organisational structure, business processes, information systems, and infrastructure... The most important characteristic of an enterprise architecture is that it provides a holistic view of the enterprise... To achieve this quality in enterprise architecture, bringing together information from formerly unrelated domains necessitates an approach that is understood by all those involved from those different domains.
    • Marc Lankhorst (2009) Enterprise Architecture at Work: Modelling, Communication and Analysis. p. 3.
  • Methods for enterprise architecture, such as TOGAF, acknowledge the importance of requirements engineering in the development of enterprise architectures. Modelling support is needed to specify, document, communicate and reason about goals and requirements. Current modelling techniques for enterprise architecture focus on the products, services, processes and applications of an enterprise. In addition, techniques may be provided to describe structured requirements lists and use cases. Little support is available however for modelling the underlying motivation of enterprise architectures in terms of stakeholder concerns and the high-level goals that address these concerns
  • Since 2003, more and more authors using the term EA explicitly in their publications, Most of the newer contributions are coming from an academic background. Especially after 2005, a lot of consultancies and IT-companies are adopting their products and strategies to an extended architectural understanding hence Enterprise Architecture... After 2004-2005 a lot of companies started to use the term EA and since then have connected it somehow to their products and strategies a huge amount of superficial marketing material has been distributed.
    Consider the maturity and the focus of the contributions there is no topic or even a theory in the discipline of EA. Almost half of the approaches discussed in the papers are still coming from low maturity level (Concept Phase) in the context of readiness to be used in an organization. Only a third of the authors are delivering some kind of best practice (Implementation/Adoption). Differentiating the focus of EA-authors there are two specific topics only (EA-Frameworks and Enterprise Modeling) the majority is dealing with rather general aspects.
    • Marten Schöenherr (2009) "Towards a common terminology in the discipline of enterprise architecture." Service-Oriented Computing–ICSOC 2008 Workshops. Springer Berlin Heidelberg.



  • Enterprise modeling has been an area of significant research in the information systems discipline throughout the last decade. Mainly developed by IT-practitioners, enterprise architectures (EA) became a promising and comprehensive approach to model either the current or desired state of enterprises. Existing approaches are, however, often criticized for paying too little attention to the business side of enterprises. In this paper, we interpret an enterprise as socio-technical system and analyze from a systems theory perspective which features are necessary for a comprehensive model. From there, we deduce if, why and how additional aspects of enterprises should be included into EA. Amongst others, it becomes obvious that especially human actors, as most flexible and agile elements of enterprises, are not adequately included in current architectures.
    • Sebastian Kloeckner, Dominik Birkmeier (2010) "Something Is Missing: Enterprise Architecture from a Systems Theory Perspective]." in: Service-Oriented Computing. ICSOC/ServiceWave 2009 Workshops Lecture Notes in Computer Science Volume 6275, 2010, p. 22-34 Abstract.
  • In recent years, enterprise architecture (EA) management has emerged to one of the major challenges for enterprises. When looking for guidance in this field companies can choose from a variety of EA management approaches, which have been developed by scientists, practitioners, and governmental organizations. However, these approaches differ significantly in a number of characteristics and especially when it comes to methods for the EA management function. There is neither a common understanding of the scope and content of the main activities an EA management function consists of nor has a commonly accepted reference method been developed.


Just a few of the Enterprise Architecture frameworks utilized anno 2011
  • A literary review by Schöenherr (2009) clearly shows that the level of interest in Enterprise Architecture is indeed increasing. Although the term architecture was limited to information systems when originally adopted by John Zachman (1987), the concept has since then been expanded to encompass the entire enterprise and interpreted by academia as well as the private and public sectors. The different views on how to approach Enterprise Architecture are often documented and compiled into “guides” or “frameworks” which are intended to instruct practitioners in how to apply this concept to their organization. However, the numerous approaches all present disparate views on what exactly Enterprise Architecture entails and how it is best administered (Rood, 1994; Whitman, Ramachandran & Ketkar, 2001; Sessions, 2007; Schöenherr, 2009). This essentially leaves the practitioner in the dark as the approaches offer virtually no common ground, no common language and no common orientation on which to base a comparison.
    • Thanos Magoulas et al. (2011) "Alignment in Enterprise Architecture: Investigating the Aspects of Alignment in Architectural Approaches." Proceedings of the 5th European Conference on Information Management and Evaluation, Universitā Dell'Insubria, Como, Italy, 8-9 September 2011. Academic Conferences Limited.
  • EA originated from and is influenced by a number of business areas: The manufacturing industry, with Material Requirements Planning (MRP) and later Manufacturing Resource Planning (MRP II). These approaches developed into the so-called supply chain or value chain (Porter, et al). Not only the incoming logistics and internal operations were considered, but also the flow of material to customers and back.
    The second origin of EA growth was from Process Modelling and Design approaches, e.g. Business Process Re-engineering (Hammer, et al). These approaches seek to depict the enterprise in terms of business processes, leading to process improvements and “end-to-end” process integration. Corporate and process governance, organisational adaptability and IM/IT system integration were typical considerations. Organisations were consequently often restructured, to become “flatter” (less management layers) and coined process-centred or process-oriented organisations.
    A third development is a type of backward integration where software developers trie to better understand and serve the business world with “functioning and value-adding” software solutions (business applications). It is a well-known fact that enterprise integration software (ERP, etc.), according to business users and owners, are often considered to be failures.
    • Leon Pretorius (2011) "System Architecture and Enterprise Architecture: Competing Concepts." ISEM 2011. 2011. p. 3-5.
  • Enterprise architecture (EA) is the definition and representation of a high-level view of an enterprise‘s business processes and IT systems, their interrelationships, and the extent to which these processes and systems are shared by different parts of the enterprise. EA aims to define a suitable operating platform to support an organisation‘s future goals and the roadmap for moving towards this vision. Despite significant practitioner interest in the domain, understanding the value of EA remains a challenge. Although many studies make EA benefit claims, the explanations of why and how EA leads to these benefits are fragmented, incomplete, and not grounded in theory. This article aims to address this knowledge gap by focusing on the question: How does EA lead to organisational benefits? Through a careful review of EA literature, the paper consolidates the fragmented knowledge on EA benefits and presents the EA Benefits Model (EABM). The EABM proposes that EA leads to organisational benefits through its impact on four benefit enablers: Organisational Alignment, Information Availability, Resource Portfolio Optimisation, and Resource Complementarity.


  • What I wanted to do when I came in... was help the community turn a corner and become relevant in the key initiatives that we need in the federal government... make sure architecture was relevant, it became more agile, it continued to move to have a more business and more strategy focus.
  • The historical roots of enterprise architecture are well recorded and span a period that starts with the Zachman framework and continues to the present day. During these twenty years of productive activity many well-known frameworks and government level initiatives have seen the light. The aim of this section is to examine the history of enterprise architecture in an attempt to discover the tradition within which it stands. This tradition is explored in terms of diversity of definitions, the components of enterprise architecture, and enterprise architecture frameworks and methods:
    • A diversity of definitions: Various definitions of enterprise architecture have been proposed by researchers and practitioners. Although a precise and concise definition that is universally accepted is hard to attain some effort has been made towards the classification of enterprise architecture definitions...
    • The components of enterprise architecture: The components of enterprise architecture describe the parts that make the whole in an architecture work. A varied list of parts is proposed by the different enterprise architecture frameworks that range from sub architectures to artefacts...
Enterprise architecture research output has shown an increase over the twenty years of its existence. Research efforts such as the Finnish Enterprise Architecture Research (FEAR) project [46] shows an active international interest in the usage of enterprise architecture for governmental purposes (confirmed by survey results). The number of research publications have also grown over the last number of years. The proliferation of enterprise architecture frameworks over the same period in turn indicates an active practitioner interest in enterprise architecture.
  • Jan Mentz, Paula Kotzé and Alta van der Merwe (2012) "A comparison of practitioner and researcher definitions of enterprise architecture using an interpretation method." in: Advances in Enterprise Information Systems II. Charles Møller and Sohail Chaudhry eds. CRC Press 2012. p. 11–25.
  • The history of enterprise architecture as a management discipline has been marked by failure to live up to the promise it showed as a concept. The idea of an enterprise architecture and the explicit understanding of the relationships between the most critical forces, resources, and processes involved in the execution of an organization’s business is powerful. People can grasp on an intuitive level how powerful the reality of that concept would be if it could be put into practice and harnessed on behalf of the enterprise. Unfortunately, the conceptual enterprise architecture that enables the agile enterprise and informs executives in the midst of critical portfolio and execution decisions has given way to a morass of additional bureaucracy and expensive efforts to create enterprise models that are more often significant as records of organizational history than as blueprints for the future. The problems lie in three areas. The first of which is a lack of clear performance objectives for the EA effort... The second major failure stems from the belief that EA is somehow all about the process for developing content... Finally, there is far too little attention paid to helping the consumers of EA information...
  • Many companies are not driving significant business value from the digitized platforms they build as part of their enterprise architecture initiatives. Our 2011 survey of 146 senior IT leaders found that the companies that benefit from their platforms' efforts are consistently relying on four architecture-related practices that encourage organizational learning about the value of enterprise architecture: 1) making IT costs transparent, 2) debating architectural exceptions, 3) performing post-implementation reviews, and 4) making IT investments with enterprise architecture in mind.


  • Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. EA is used to steer decision making toward the evolution of the future state architecture.


  • Enterprise Architecture is not a method, principle or doctrine – It is a way of thinking enabled by patterns, frameworks, standards etc. essentially seeking to align both the technology ecosystem and landscape with the business trajectory driven by both the internal and external forces. Daljit R Banger
    • Source :Enterprise Systems Architecture:Aligning Organisational Business Operating Models to Technology Landscapes (ISBN-13:979-8625585187 )

See also[edit]

External links[edit]

Wikipedia has an article about: