An enterprise architecture framework ( EA framework ) defines how to create and use an enterprise architecture . An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.
69-553: The Open Group Architecture Framework ( TOGAF ) is the most used framework for enterprise architecture as of 2020 that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. TOGAF is a high-level approach to design. It is typically modeled at four levels: Business, Application, Data, and Technology. It relies heavily on modularization, standardization, and already existing, proven technologies and products. TOGAF began to be developed in 1995 by The Open Group , based on
138-491: 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,
207-544: 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
276-762: A clear distinction between the architecture domains (business, information/data, application/integration and technical/infrastructure). These domains can be further divided into Sub domain disciplines. An example of the EA domain and subdomains is in the image on the right. Many enterprise architecture teams consist of Individuals with Skills aligned with the Enterprise Architecture Domains and sub-domain disciplines. Here are some examples: enterprise business architect, enterprise documentational architect, enterprise application architect, enterprise infrastructure architect, enterprise information architect, etc. An example of
345-473: A paper by Zachman and Sowa 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
414-406: A particular style of application integration. Research points to EA promoting the use of SOA as an enterprise-wide integration pattern. The broad reach of EA has resulted in this business role being included in the information technology governance processes of many organizations. Analyst firm Real Story Group suggested that EA and the emerging concept of the digital workplace are "two sides to
483-417: A reduction of business risks from system failures and security breaches. EA also helps reduce risks of project delivery. Establishing EA as an accepted, recognized, functionally integrated and fully involved concept at operational and tactical levels is one of the biggest challenges facing Enterprise Architects today and one of the main reasons why many EA initiatives fail. A key concern about EA has been
552-401: A set of common goals and collaborate to provide specific products or services to customers. In that sense, the term enterprise covers various types of organizations, regardless of their size, ownership model, operational model, or geographical distribution. It includes those organizations' complete sociotechnical system , including people, information, processes, and technologies. Enterprise as
621-430: A sociotechnical system defines the scope of EA. The term architecture refers to fundamental concepts or properties of a system in its environment; and embodied in its elements, relationships, and in the principles of its design and evolution. A methodology for developing and using architecture to guide the transformation of a business from a baseline state to a target state, sometimes through several transition states,
690-521: A system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution". However TOGAF has its own view, which may be specified as either a "formal description of a system, or a detailed plan of the system at component level to guide its implementation", or as "the structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time". The Architecture Development Method (ADM)
759-464: 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. By 1980, IBM's Business Systems Planning (BSP) was promoted as a method for analyzing and designing an organization's information architecture, with
SECTION 10
#1732856135580828-431: Is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize
897-493: Is about the choice of and relationships between applications in the enterprise's application portfolio, not about the internal architecture of a single application (which is often called application architecture). Many EA frameworks combine data and application domains into a single (digitized) information system layer, sitting below the business (usually a human activity system) and above the technology (the platform IT infrastructure ). For many years, it has been common to regard
966-575: Is applied to both the Data Architecture and Application Architecture. The Enterprise Continuum is a way of classifying solutions and architectures on a continuum that range from generic foundation architectures through to tailored organization-specific both within and outside the Architecture Repository. These include architectural models, architectural patterns, architecture descriptions, and other artifacts. These artifacts may exist within
1035-402: Is based on four interrelated areas of specialization called architecture domains : The Architecture Development Method (ADM) is applied to develop an enterprise architecture which will meet the business and information technology needs of an organization. It may be tailored to the organization's needs and is then employed to manage the execution of architecture planning activities. The process
1104-688: Is divided into three main areas: 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" 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
1173-688: Is iterative and cyclic. Each step checks with Requirements. Phase C involves some combination of both Data Architecture and Applications Architecture. Additional clarity can be added between steps B and C in order to provide a complete information architecture . Performance engineering working practices are applied to the Requirements phase, and to the Business Architecture, Information System Architecture, and Technology architecture phases. Within Information System Architecture, it
1242-456: Is natural, since business people need information to make decisions and carry out business processes. In 2011, the TOGAF 9.1. specification says: "Business planning at the strategy level provides the initial direction to enterprise architecture." Normally, the business principles, business goals, and strategic drivers of the organization are defined elsewhere. In other words, Enterprise Architecture
1311-442: Is not a business strategy, planning or management methodology. Enterprise Architecture strives to align business information systems technology with given business strategy, goals and drivers. The TOGAF 9.1 specification clarified, that, "A complete enterprise architecture description should contain all four architecture domains (business, data, application, technology), but the realities of resource and time constraints often mean there
1380-402: Is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains, even if the enterprise scope is [...] less than the full extent of the overall enterprise." In 2013, TOGAF is the most popular Architecture framework (judged by published certification numbers) that some assume it defines EA. However, some still use
1449-527: Is published as ISO/IEC/IEEE 42010:2011 . The standard defines an architecture framework as conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders , and proposes an architecture framework is specified by: Architecture frameworks conforming to the standard can include additional methods, tools, definitions, and practices beyond those specified. Nowadays there are now countless EA frameworks, many more than in
SECTION 20
#17328561355801518-413: Is the core of TOGAF which describes a method for developing and managing the life-cycle of enterprise architecture. TOGAF was initiated in the early 1990s as methodology for the development of technical architecture, and has been developed by The Open Group into an extensive enterprise architecture framework . In 1995, the first version of TOGAF (TOGAF 1.0) was presented. This version was mainly based on
1587-455: Is too complex and extensive to document in its entirety, so knowledge management techniques provide a way to explore and analyze these hidden, tacit, or implicit areas. In return, EA provides a way of documenting the components of an organization and their interaction in a systemic and holistic way that complements knowledge management. In various venues, EA has been discussed as having a relationship with Service Oriented Architecture (SOA),
1656-467: Is usually known as an enterprise architecture framework . A framework provides a structured collection of processes, techniques, artifact descriptions , reference models, and guidance for the production and use of an enterprise-specific architecture description. Paramount to changing the EA is the identification of a sponsor . Their mission, vision , strategy, and the governance framework define all roles, responsibilities, and relationships involved in
1725-542: The Federal Enterprise Architecture 's reference guide aids federal agencies in the development of their architectures. As a discipline, EA "proactively and holistically lead[s] enterprise responses to disruptive forces by identifying and analyzing the execution of change" towards organizational goals. EA gives business and IT leaders recommendations for policy adjustments and provides best strategies to support and enable business development and change within
1794-612: The Technical Architecture Framework for Information Management (TAFIM), development started in the late 1980s by the US Department of Defense . In December 2001 TOGAF 7, the "Technical Edition", was published. TOGAF 8 ("Enterprise Edition") was first published in December 2002 and republished in updated form as TOGAF 8.1 in December 2003. Around 2005 TOGAF became a registered trademark of The Open Group . In November 2006
1863-591: The United States Department of Defense 's TAFIM and Capgemini 's Integrated Architecture Framework (IAF). As of 2016, The Open Group claims that TOGAF is employed by 80% of Global 50 companies and 60% of Fortune 500 companies. An architecture framework is a set of tools that can be used for developing a broad range of different architectures. It should: The ANSI / IEEE Standard 1471-2000 specification of architecture (of software-intensive systems) may be stated as: "the fundamental organization of
1932-802: The Architecture Continuum by defining reusable Solution Building Blocks (SBBs). TOGAF 9.2 recognizes the following roles: Whilst also adding "And many others ..." at the end of this list. TOGAF provides certifications for tools and people. Certified TOGAF 9 tools are listed in the following table. For the latest register of certified tools refer The Open Group register. The Open Group oversees formal qualifications in TOGAF at two levels, which can be taken following formal training or self-study. Learners can undertake these qualifications through training companies. (Level I) Ensures that an individual understands Enterprise Architecture along with core concepts and terminology of TOGAF. (Level II) Further to
2001-543: The Foundation qualification, this establishes that the candidate is able to analyse and apply their knowledge to business problems. Gaining TOGAF Certified status automatically confers free membership of the Association of Enterprise Architects. Despite TOGAF being considered as the de facto standard in an EA practice, it is not without its critics: Enterprise Architecture framework Enterprise architecture regards
2070-563: 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
2139-497: The IT/IS aspects of the enterprise and other aspects service only as inputs. The Enterprise Integrating school believes that the purpose of EA is to create a greater coherency between the various concerns of an enterprise (HR, IT, Operations, etc.), including the link between strategy formulation and execution. Architecture proposals and decisions here encompass all aspects of the enterprise. The Enterprise Ecosystem Adaption school states that
The Open Group Architecture Framework - Misplaced Pages Continue
2208-617: The National Institute of Standards and Technology (NIST) published the NIST Enterprise Architecture Model . 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
2277-573: The Open Group released TOGAF 8.1.1. According to The Open Group, as of February 2011, over 15,000 individuals are TOGAF Certified. As of April 2018 the official register has over 77,500 certifications. An evolutionary development from TOGAF 8, TOGAF 9 includes many new features such as: Additional guidelines and techniques include: The latest version is TOGAF 10, launched on 25 April 2022. The Open Group provides TOGAF free of charge to organizations for their own internal noncommercial purposes. TOGAF
2346-617: 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
2415-452: The above. Zachman has always focused on architecture description advice. The application and technology domains (not to be confused with business domains) are characterized by domain capabilities and domain services. The capabilities are supported by the services. The application services are also referred to in service-oriented architecture (SOA). The technical services are typically supported by software products. The data view starts with
2484-404: The anticipated transformation. Changes considered by enterprise architects typically include innovations in the structure or processes of an organization; innovations in the use of information systems or technologies; the integration and/or standardization of business processes; and improvement of the quality and timeliness of business information. According to the standard ISO/IEC/IEEE 42010 ,
2553-510: The architecture domains as layers, with the idea that each layer contains components that execute processes and offer services to the layer above. This way of looking at the architecture domains was evident in TOGAF v1 (1996), which encapsulated the technology component layer behind the platform services defined in the "Technical Reference Model" - very much according to the philosophy of TAFIM and POSIX. The view of architecture domains as layers can be presented thus: Each layer delegates work to
2622-559: The areas related to design and re-design of the organizational structures during mergers, acquisitions, or general organizational change; enforcement of discipline and business process standardization, and enablement of process consolidation, reuse, and integration ; support for investment decision-making and work prioritization; enhancement of collaboration and communication between project stakeholders and contribution to efficient project scoping and to defining more complete and consistent project deliverabless ; and an increase in
2691-455: The data classes which can be decomposed into data subjects which can be further decomposed into data entities. The basic data model type which is most commonly used is called merda (master entity relationship diagrams assessment, see entity-relationship model ). The Class, subject and entity forms a hierarchical view of data. Enterprises may have millions of instances of data entities. The Enterprise Architecture Reference Traditional Model offers
2760-402: The difficulty in arriving at metrics of success because of the broad-brush and often opaque nature of EA projects. Additionally, there have been a number of reports, including those written by Ivar Jacobson , Gartner , Erasmus University Rotterdam and IDS Scheer , Dion Hinchcliffe , and Stanley Gaver , that argue that the frequent failure of EA initiatives makes the concept not worth
2829-673: The effort and that the methodology will fade out quickly. According to the Federation of Enterprise Architecture Professional Organizations (FEAPO), EA interacts with a wide array of other disciplines commonly found in business settings such as performance engineering and management , process engineering and management , IT and enterprise portfolio management , governance and compliance , IT strategic planning, risk analysis , information management , metadata management , organization development , design thinking , systems thinking , and user experience design . The EA of an organization
The Open Group Architecture Framework - Misplaced Pages Continue
2898-466: The enterprise and also in the IT industry at large. The Enterprise Continuum consists of both the Architecture Continuum and the Solutions Continuum. The Architecture Continuum specifies the structuring of reusable architecture assets and includes rules, representations, and relationships of the information systems available to the enterprise. The Solutions Continuum describes the implementation of
2967-440: The enterprise as a large and complex system or system of systems . 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
3036-1089: The enterprise." Important players within EA include enterprise architects and solutions architects. Enterprise architects are at the top level of the architect hierarchy, meaning they have more responsibilities than solutions architects. While solutions architects focus on their own relevant solutions, enterprise architects focus on solutions for and the impact on the whole organization. Enterprise architects oversee many solution architects and business functions. As practitioners of EA, enterprise architects support an organization's strategic vision by acting to align people, process, and technology decisions with actionable goals and objectives that result in quantifiable improvements toward achieving that vision. The practice of EA "analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology." The term enterprise can be defined as an organizational unit , organization , or collection of organizations that share
3105-541: The following goals: 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." However, in this article
3174-435: The following listing. Enterprise architecture frameworks that are released as open source : Enterprise architecture Enterprise architecture ( EA ) is a business function concerned with the structures and behaviours of a business, especially business roles and processes that create and use business data . The international definition according to the Federation of Enterprise Architecture Professional Organizations
3243-490: The fundamental Enterprise Architecture artifact. They relate data entities, use cases, applications and technologies to the functions/capabilities. In 2006, the popular book Enterprise Architecture As Strategy 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
3312-442: The information systems the business depends on. EA provides a guide for decision making towards these objectives. The National Computing Centre 's EA best practice guidance states that an EA typically "takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise. The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about
3381-417: The interfaces and... [i]ntegration of all the components of a system" is necessary. Zachman in particular urged for a " strategic planning methodology ." Within the field of enterprise architecture, there are three overarching schools: Enterprise IT Design, Enterprise Integrating, and Enterprise Ecosystem Adaption. Which school one subscribes to will impact how they see the EA's purpose and scope, as well as
3450-415: The layer below. In each layer, the components, the processes and the services can be defined at a coarse-grained level and decomposed into finer-grained components, processes and services. The graphic shows a variation on this theme. In addition to three major framework components discussed above. An ideal EA framework should feature: Most modern EA frameworks (e.g. TOGAF, ASSIMPLER, EAF) include most of
3519-485: The list of reference architecture patterns in the application and information architecture domains are available at Architectural pattern (computer science) . A view model is a framework that defines the set of views or approaches used in systems analysis , systems design , or the construction of an enterprise architecture . Since the early 1990s, there have been a number of efforts to define standard approaches for describing and analyzing system architectures. Many of
SECTION 50
#17328561355803588-416: The means of achieving it, the skills needed to conduct it, and the locus of responsibility for conducting it. Under Enterprise IT Design, the main purpose of EA is to guide the process of planning and designing an enterprise's IT / IS capabilities to meet the desired organizational objectives, often by greater alignment between IT/IS and business concerns. Architecture proposals and decisions are limited to
3657-493: The organization's mission. The main difference between these two definitions is that Zachman's concept was the creation of individual information systems optimized for business, while NIST's described the management of all information systems within a business unit. The definitions in both publications, however, agreed that due to the "increasing size and complexity of the [i]mplementations of [i]nformation systems... logical construct[s] (or architecture) for defining and controlling
3726-577: 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
3795-551: The product used to describe the architecture of a system is called an architectural description . In practice, an architectural description contains a variety of lists, tables, and diagrams. These are models known as views . In the case of EA, these models describe the logical business functions or capabilities, business processes , human roles and actors, the physical organization structure, data flows and data stores , business applications and platform applications, hardware, and communications infrastructure. The first use of
3864-504: The purpose of EA is to foster and maintain the learning capabilities of enterprises so they may be sustainable. Consequently, a great deal of emphasis is put on improving the capabilities of the enterprise to improve itself, to innovate, and to coevolve with its environment. Typically, proposals and decisions encompass both the enterprise and its environment. The benefits of EA are achieved through its direct and indirect contributions to organizational goals. Notable benefits include support in
3933-406: The recent Enterprise Architecture frameworks have some kind of set of views defined, but these sets are not always called view models . Perhaps the best-known standard in the field of software architecture and system architecture started life as IEEE 1471 , an IEEE Standard for describing the architecture of a software-intensive system approved in 2000. In its latest version, the standard
4002-428: The system's implementation and operational costs, and minimization of replicate infrastructure services across business units; reduction in IT complexity, consolidation of data and applications, and improvement of interoperability of the systems; more open and responsive IT as reflected through increased accessibility of data for regulatory compliance , and increased transparency of infrastructure changes; and
4071-498: 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
4140-455: 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
4209-401: The term "enterprise architecture" is often incorrectly attributed to John Zachman 's 1987 A framework for information systems architecture . The first publication to use it was instead a National Institute of Standards (NIST) Special Publication on the challenges of information system integration. The NIST article describes EA as consisting of several levels. Business unit architecture is
SECTION 60
#17328561355804278-402: The term Enterprise Architecture as a synonym for Business Architecture, rather than covering all four architecture domains - business, data, applications and technology. Since Stephen Spewak's Enterprise Architecture Planning (EAP) in 1993 – and perhaps before then – it has been normal to divide enterprises architecture into four architecture domains . Note that the applications architecture
4347-441: The timeliness of requirements elicitation and the accuracy of requirement definitions through publishing of the EA documentation. Other benefits include contribution to optimal system designs and efficient resource allocation during system development and testing; enforcement of discipline and standardization of IT planning activities and contribution to a reduction in time for technology-related decision making; reduction of
4416-571: The top level and might be a total corporate entity or a sub-unit. It establishes for the whole organization necessary frameworks for "satisfying both internal information needs" as well as the needs of external entities, which include cooperating organizations , customers , and federal agencies . The lower levels of the EA that provide information to higher levels are more attentive to detail on behalf of their superiors. In addition to this structure, business unit architecture establishes standards , policies , and procedures that either enhance or stymie
4485-621: 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,
4554-497: The various aspects of an enterprise to identify, motivate, and achieve these changes." The United States Federal Government is an example of an organization that practices EA, in this case with its Capital Planning and Investment Control processes. Companies such as Independence Blue Cross , Intel , Volkswagen AG , and InterContinental Hotels Group also use EA to improve their business architectures as well as to improve business performance and productivity . Additionally,
4623-423: Was a marketing specialist at IBM, published the paper, A Framework for Information Systems Architecture . 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,
4692-412: 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,
4761-418: 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
#579420