History and development of enterprise architecture

Kotusev argues that EA's history can be divided into three distinct phases: Business Systems Planning (BSP), early EA, and modem EA.²’

According to Kotusev, the first EA phase featured BSP, a methodology initiated by IBM in the 1960s that lasted until the mid-1980s.²⁴ Kotusev argues that as a precursor, BSP resembled EA in several respects^-5:

• • First, BSP activities were carried out by a dedicated group of experts (BSP study team) whose responsibilities included collecting data by interviewing managers and developing information systems plans in a top-down manner.
• • Second, BSP information systems plans described the relationship between organization, business processes, data, and information systems using relationship matrices, information systems networks, flowcharts, and other techniques to model processes, systems, and data.
• • Third, BSP was implemented in a stepwise manner starting from identifying business objectives, defining business processes and data, analysing the existing IT landscape, and developing a desired future information systems plan.
• • Fourth, methodologies such as BSP used the notion of architecture as a “formal description of the relationship between business and IT,” even though this idea was discussed under different titles, such as data architecture and information architecture.^- ’

The second EA phase began in the mid-1980s with the emergence of the earliest EA frameworks.²⁷ By the time EA emerged, computer software developers and information system engineers had realized that they could only design suitable IT components if they "understood how the organisation works as defined by its processes, organisational structure and goals" within certain frameworks.²⁸ One such framework is Partnership for Research in Information Systems Management (PRISM), developed by a research project sponsored by about 60 global companies. A second framework is known as Zachman, developed by John Zachman, a marketing specialist at IBM.^- ' Other frameworks include the National Institute of Standards and Technology (NIST) EA model and the Technical Architecture Framework for Information Management (TAFIM) methodology, both developed in the U.S.³" The second EA phase lasted from the mid-1980s until the mid-1990s.

The third EA phase began in the mid-1990s and continues to this day with the development of numerous EA frameworks, including the following:

• • Enterprise-developed frameworks such as the Generalised Enterprise Reference Architecture and Methodology (GERAM), Guide to the Enterprise Architecture Body of Knowledge (EABOK), and Reference Model of Open Distributed Processing (RM-ODP);
• • Commercial frameworks such as the Architecture of Integrated Information Systems (ARIS), Integrated Architecture Framework (IAF), and Zachman Framework;
• • Defence industry frameworks such as the Department of Defence Architecture Framework (DoDAF), France DGA Architecture Framework (AGATE), International Defence Enterprise Architecture Specification (IDEAS), Joint

Technical Architecture (JTA), NATO Architecture Framework, Technical Architecture Framework for Information Management (TAFIM), Technical Reference Model (TRM), and UK Ministry of Defence Architecture Framework (MODAF);

• Government frameworks such as the European Interoperability Framework (EIF), Federal Enterprise Architecture Framework (FEAF), Government Enterprise Architecture (GEA), NIST Enterprise Architecture (NIST), Standards and Architecture of eGovemment Applications (SAGA), Treasury Enterprise Architecture Framework (TEAF), and Treasury Information System Architecture Framework (TISAF).³¹

Figure 7.1 illustrates a few EA frameworks and shows how they have influenced each other over the years.

The Open Croup Architectural Framework (TOCAF)

Researchers currently consider TOGAF to be the de facto industry standard for EA frameworks,'" a technology architecture methodology based on the technical architecture framework for information management (TAFIM), developed by the United States Department of Defense.³³ Over the years, TOGAF has become a

FIGURE 7.1 The development of EA frameworks in different domains

Source: Yiwei Gong & Marijn Janssen, 2019, ‘The value of and myths about enterprise architecture’. International Journal of Information Management, vol. 46, p. 3.

well-defined method for designing an information system in terms of building blocks and for showing how the building blocks fit and interact.³⁴

TOGAF has three main pillars:

• 1. Architecture Development Method (ADM): Describes a method for developing and managing the lifecycle of an enterprise architecture and forms the core of TOGAF.³⁵
• 2. Enterprise Continuum (EC): Provides methods for classifying architecture and solution artefacts, both internal and external to the Architecture Repository, as they evolve from generic foundation architectures to organization-specific architectures.³⁶
• 3. Enterprise Architecture Domains (EAD): These are the areas of specialization that are commonly accepted by EA practitioners as subsets of an overall enterprise architecture.’

TOGAF organizes EA artefacts according to four major domains (business, data, applications, and technology) and proposes a metamodel providing more detailed technical classification of these domains.’ Table 7.1 outlines the four interrelated areas of specialization, or architecture domains.

TABLE 7.1 Enterprise architecture domains

Sources: Pethuru Raj & Mohanavadivu Periasaniy, 2011, ‘The convergence of enterprise architecture (EA) and cloud computing’, in Zaigham Mahmood & Richard Hill (eds.). Cloud computing for enterprise architectures. Springer, London, pp. 61—87; David Basten & D. Brons, 2012, ‘EA frameworks, modeling and tools’, in Frederik Ahlemann et al. (eds.). Strategic enterprise architecture management: challenges, best practices, and future developments. Springer Science & Business Media, Dordrecht, pp. 201-227.

In order to provide uniform representation for architectural descriptions within the TOGAF framework, modelling languages and notations such as ArchiMate, Unified Modelling Language (UML), and Business Process Model and Notation (BPMN) have been used.³'¹ However, ArchiMate best fits into the TOGAF framework because it was also developed by The Open Group as an “open and independent modelling language that is supported by different tool vendors and consulting firms.”⁴⁰ ArchiMate provides concepts for creating a model that correlates to TOGAF’s three architectures (layers):

• 1. A business layer (products and services offered to customers, the business processes that helped create the offering, and the actors that played a part in the business processes);
• 2. An application layer (application services, which support the business layer); and
• 3. A technology layer (infrastructure services that support the applications).

ArchiMate provides a graphical representation of its language elements based on a UML class diagram, which could be quite complex but has been customized and limited to a small set of modelling constructs in the interest of simplicity of learning and use.^4- In this manner, ArchiMate provides a notation that enables enterprise architects to describe, analyse, and visualize the relationships among business domains in an unambiguous way.⁴³