Enterprise architecture

The term enterprise can be defined as an organizational unit, organization, or collection of organizations that share a set of common goals and collaborate to provide specific products or services to customers.[8] 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,[9] including people, information, processes, and technologies. Enterprise as 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.[10] 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, 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 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,[10] 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.[11]

The first use of the term "enterprise architecture" is often incorrectly attributed to John Zachman's 1987 A framework for information systems architecture.[12] The first publication to use it was instead a National Institute of Standards (NIST) Special Publication[13] on the challenges of information system integration. The NIST article describes EA as consisting of several levels. Business unit architecture is 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 the organization's mission.[13]

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 the interfaces and... [i]ntegration of all the components of a system" is necessary. Zachman in particular urged for a "strategic planning methodology."[12]

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 the means of achieving it, the skills needed to conduct it, and the locus of responsibility for conducting it.[14]

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 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 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.[15] Notable benefits include support in the areas related to design and re-design of the organizational structures during mergers, acquisitions, or general organizational change;[16][17][18][19] enforcement of discipline and business process standardization, and enablement of process consolidation, reuse, and integration;[20][21] support for investment decision-making and work prioritization;[17][22][18] enhancement of collaboration and communication between project stakeholders and contribution to efficient project scoping and to defining more complete and consistent project deliverabless;[19][20] and an increase in the timeliness of requirements elicitation and the accuracy of requirement definitions through publishing of the EA documentation.[23]

Other benefits include contribution to optimal system designs and efficient resource allocation during system development and testing;[17][18] enforcement of discipline and standardization of IT planning activities and contribution to a reduction in time for technology-related decision making;[18][21] reduction of the system's implementation and operational costs, and minimization of replicate infrastructure services across business units;[21][24] reduction in IT complexity, consolidation of data and applications, and improvement of interoperability of the systems;[20][21][24] more open and responsive IT as reflected through increased accessibility of data for regulatory compliance, and increased transparency of infrastructure changes;[21][25] and a reduction of business risks from system failures and security breaches. EA also helps reduce risks of project delivery.[21][26] 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.[27]

A key concern about EA has been the difficulty in arriving at metrics of success because of the broad-brush and often opaque nature of EA projects.[28] Additionally, there have been a number of reports, including those written by Ivar Jacobson,[29] Gartner,[30] Erasmus University Rotterdam and IDS Scheer,[31] Dion Hinchcliffe,[32] and Stanley Gaver,[33] that argue that the frequent failure of EA initiatives makes the concept not worth the effort and that the methodology will fade out quickly.