I have been practicing Enterprise Architecture for over 15 years. During these years I have worked for several organizations. All of these organizations presented unique situations, each requiring a slightly different way of working.

     The organizations did have one thing in common: architecture maturity was either non-existent or at a low level. One of the main reasons for this is probably (because we never really know for sure) the difficulty an organization has in translating the available theoretical architecture frameworks into a practical application.

     Despite the good intentions of frameworks such as the TOGAF Standard [1], there still are a lot of organizations that have not yet been able to translate a framework into something that is usable. If an organization could easily use the tools provided by a framework, working with architecture would be more likely to get the attention it needs. An organization would be able to greatly benefit from the structure and coherence that a framework has to offer. In spite of the fact that the theory described in the frameworks has evolved and matured over the years, organizations have not yet found a way to put it to good use. I believe this is because theoretical frameworks do not pay enough attention to the pragmatic translation of their content into a practical application.

     In this book, I want to take the reader on a journey I call Getting Started with Enterprise Architecture. I have tried to take the theory from existing frameworks and translate it into a practical and pragmatic approach.

     The origins of Enterprise Architecture can be traced back to the 1960s and 1970s, when large organizations began to recognize the need for formal methods to manage and align their complex IT systems with business goals. During this time, there were various efforts to develop system architectures and information models.

     In the 1980s, the term Enterprise Architecture began to gain traction. The focus was primarily on defining and documenting the structure and components of an organization’s information systems. This decade saw the emergence of methodologies such as John Zachman’s Framework for Enterprise Architecture [2]. Enterprise Architecture emerged as a response to the increasing complexity of IT environments and business processes.

     The 1990s marked a period of increased interest and growth in the field of Enterprise Architecture. More and more organizations recognized the importance of aligning IT with business goals. The Open Group introduced the TOGAF Standard in 1995, providing a comprehensive approach to Enterprise Architecture.

     The early 2000s saw a greater focus on integrating IT and business strategies, leading to the adoption of Enterprise Architecture as a strategic management discipline. Enterprise Architecture frameworks and methodologies, such as the Zachman Framework and the TOGAF Standard, gained wider acceptance and use. In the mid to late 2000s, Enterprise Architecture evolved to address the complexities of globalized and networked enterprises. The focus shifted to a more holistic approach to Enterprise Architecture, encompassing not only IT systems but also business processes, people, and organizational structures. This broader perspective was necessary to adapt to rapidly changing market dynamics and technological innovations.

     The evolution of Enterprise Architecture brought a new focus to the strategic importance of IT within organizations. It provided a way to align IT infrastructure and business processes with business goals, thereby increasing the value of IT. Enterprise Architecture also offered a way to manage and reduce the complexity of IT environments, thereby reducing the cost and risk of IT projects.

     Ask someone to describe an apple. Nine times out of ten, the person will come up with something like it is a round piece of fruit with a stem (and a small leaf) that contains vitamins. Some will also add a color to the description. But the description could just as easily refer to a cherry, or a grape. Granted, cherries and grapes are also fruits, but they are not apples. To avoid comparing apples and oranges, definitions are used.

     To this day, there are different views on the definition of Enterprise Architecture. It seems that no single definition can be given to the field. It even happens that several definitions are used within the same framework, depending on the context [5].

     The TOGAF Standard adopts the ISO/IEC/IEEE 42010:2011 standard for defining Enterprise Architecture but leaves room for additional interpretation.

The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution [6].

     The Open Group’s framework has added the following to the above definition, which it says depends on the context.

The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time [7].

     Both definitions are obviously correct in content, but difficult to read and understand for an organization beginning to develop Enterprise Architecture. The following definition is self-conceived and uses simpler language to explain what the essence of Enterprise Architecture is and includes.

Enterprise Architecture is a framework for understanding and managing the overall structure and strategy of an organization.
Enterprise Architecture is about creating a holistic view of the organization's activities, including its business processes, information systems, and technology infrastructure.

The purpose of Enterprise Architecture is to align these various elements with the goals and objectives of the organization and to ensure that the elements work together effectively and efficiently.

Enterprise Architecture focuses on identifying and resolving inconsistencies in business operations and enables planning for future growth and development.

     This definition is a further and more comprehensive explanation of what the TOGAF Standard prescribes. Describing and articulating the definition more fully helps to understand exactly what is meant by Enterprise Architecture.

     The field of architecture has matured over the years. The evolution and application of architecture frameworks has contributed to this. Today, more and more organizations are recognizing the value of architecture. Many of these organizations have hired architects to bring structure, coherence, and consistency to the way information systems are deployed, business processes are executed, and strategy is implemented. However, hiring an architect does not mean that the rest will take care of itself.

     The Enterprise Architect plays a critical role in establishing, applying, and evolving Enterprise Architecture. However, the organization itself is not exempt from making a significant contribution. In fact, it is the organization’s responsibility, in many areas. It is up to the organization to define its strategy and to work with the architect to turn it into a realizable implementation. Chapter 8, Section 8.3.3, describes how Enterprise Architecture can help shape drivers, goals, objectives, and initiatives. Section 8.4.1 takes a closer look at translating strategy into execution. Both sections show that organizational participation in the architecture process is essential.

     Of course, the organization is not always involved at the level of translating strategy into execution. There are also situations and challenges that an Enterprise Architect can address on his or her own. In fact, there are many circumstances in which information must be gathered in order to take the first step toward implementing a basic Enterprise Architecture.

     Many of these scenarios touch on the various facets of an organization. They may involve organizational design, processes, and the information used. The application landscape (what applications does the organization use) is also important, as is the technology used. Gathering information on these topics is one of the primary tasks of the architect. These aspects, which interface with different parts of the organization, are called architecture domains.

     What began in Enterprise Architecture around the year 1990 – and was then still in the technology corner – has managed to evolve over the decades into a very mature field. A field that now covers all aspects of an organization. These aspects are referred to as architectures or architecture domains. For years it has been common to conflate architecture domains and layers, but the two are distinct enough.

     Architecture layers refer to the logical divisions of a software system or application based on the functionality they provide. Each layer is responsible for a specific aspect of the system and communicates with adjacent layers through predefined interfaces. Common layers in a typical software architecture include presentation (user interface), business logic, and data storage. Separating the system into layers promotes modularity, maintainability, and reusability.

     Architecture domains, on the other hand, are broader divisions that categorize different aspects of the overall system architecture. They represent the areas of concern or expertise that architects need to address while designing a complex system. Examples of architecture domains include Business and Information Architecture, Application Architecture, and Technology Architecture. Security Architecture is also considered tobe an architecture domain. Each domain focuses on specific concerns and constraints related to its area and contributes to the overall design of the system.

     Architecture layers focus on organizing the components and functionality of a system, while architecture domains categorize different concerns and perspectives that must be considered during the architectural design process. They are complementary concepts used to create well-structured and comprehensive software and system architectures.

     Within the field of architecture, there is still some confusion about the roles and functions of architects. For example, is a Technical Architect a role or a function? And what about an Application Architect or a Business Architect? And the Enterprise Architect, is that a role or a function, or maybe both? To end this ambiguity, it is helpful to take a look at the difference between roles and functions, and then classify the various names of architecture positions into the appropriate category.

     The difference between a role and a function can be described as follows. Roles are linked to the work processes that are performed, unlike functions, which are much more linked to the hierarchical structure of the organization. Staying in the context of architecture, an architect may be assigned the role of Domain Architect, where in practice the person performs the function of a Technical Architect (based on a more general job description) within the hierarchy of the organization.

     To clarify, the person assigned to the role of Domain Architect is responsible for all work processes related to a specific domain. The function assigned to this person, that of a Technical Architect, allows the organization to place this person hierarchically with the IT department. If the function assigned to the person were that of a Business Architect, the hierarchical position would not be with an IT department, but rather with another business unit. In both situations, the role assigned to the person would still be that of a Domain Architect.

     Within the field of architecture, there are several generic architecture roles. These roles are shown schematically in Figure 5-1 and provide a high-level overview.

Figure 5-1. Overview of generic architecture roles

     The roles differ in a number of ways. One is the scope of the system or environment to which the architecture applies (architecture breadth), and the other is the level of detail of the architecture (architecture depth). Four different roles exist [9]. In summary, Enterprise Architects design, specify, implement, and evaluate the architecture of the entire enterprise ecosystem. Domain Architects perform the same steps at their level, and Solution Architects do so at the solution level.

     When it comes to communicating with and about the organization, two things are important: unambiguous language and the use of visualizations.

     It is important to use a consistent and clear language when communicating the Enterprise Architecture to stakeholders. The organization’s key players must play an active role in implementing and evolving the Enterprise Architecture. To achieve good cooperation between the Enterprise Architect and the organization, it is essential to speak the same language so that both parties understand each other well.

     Visualizing the Enterprise Architecture also plays an important role in communicating to the organization and its stakeholders. It is especially important to be able to create architecture models that are easy to read and understand. A picture (or in the case of architecture, a diagram) is often worth a thousand words. There is a reason for this saying, as it holds a grain of truth. By using architecture diagrams that are easy to read, the Enterprise Architect can convey certain messages or make complex situations understandable. The use of a uniform modeling language is an absolute necessity to achieve this goal.

     In order to capture and visualize an organization from an architectural perspective, the use of a modeling language is indispensable. In the context of architecture, this language is called ArchiMate. ArchiMate is a globally accepted standard for the visualization of architectural products. It is a modeling language designed to support the visualization, analysis, and communication of Enterprise Architectures. It was born out of the need for a standardized language to model complex Enterprise Architectures and IT systems.

     The development of ArchiMate started in 2002 by a partnership of several Dutch public and private organizations, including the Dutch Tax Administration, Radboud University, and the Centrum Wiskunde & Informatica (CWI). These parties were responsible for the initial research into creating a general language for describing the development, maintenance, and operationalization of organizational structures, business processes, information flows and systems, and technical infrastructure. At that time, the language was based on IEEE standard 1471 [10]. This standard was adopted by the International Organization for Standardization (ISO) in 2007 as ISO/IEC 42010:2007. In 2011, it was superseded by the ISO/IEC/IEEE 42010.

     The management and further development of ArchiMate was transferred to The Open Group in 2008. Since then, they have been managing and supporting ArchiMate as an open standard. In 2009, the first version of ArchiMate was released, called ArchiMate 1.0. This version provided a set of symbols and notations to model various aspects of Enterprise Architecture and IT systems. ArchiMate 1.0 focused on modeling the structure, behavior, and coherence of systems. Since the introduction of ArchiMate 1.0, several updates and enhancements have been made. These updates were based on user feedback and the continuing evolution of the field. ArchiMate 2.0 was introduced in 2012 and added several new concepts, including the ability to model motivation and organizational strategies. Version 3.0 followed in 2016.

     The average organization that has little or no exposure to architecture will not immediately see the benefits of the structured approach that Enterprise Architecture has to offer. Despite the fact that such an organization has decided to hire an architect, it will not immediately see an Enterprise Architect as the go-to guy or girl. To dispel the illusion right away, no board of directors or management will see the added value of an Enterprise Architect out of the gate. Stripes have to be earned first.

     Those stripes can be earned by establishing a solid basic Enterprise Architecture: a foundation that consists of captured information about the organization, the processes and information concepts in use, the applications, and the information systems. This information can then be made available to stakeholders in the form of catalogs, matrices, diagrams, and maps. It is essential to identify who the key stakeholders are and what their concerns are. It is also important to determine how mature an organization is when it comes to working with architecture, and to have insight into what the strategic direction looks like.

     Creating a basic Enterprise Architecture allows the architect to use the information gathered to confirm or disconfirm assumptions made during projects. It enables the architect to establish and deploy frameworks that allow the organization to gain traction and control over project and program initiatives. By applying architectural skills and capabilities, the architect is able to translate the organization’s strategic direction into execution. Enterprise Architecture is thus a highly valuable tool for the organization. Getting this message across is critical to the continued growth of architecture skills and capabilities within the organization.

    The complexity of the field of architecture has been discussed in the previous chapters. The origins of architecture, the various architecture domains and roles, as well as the many different definitions that exist have been explained. Now, it is time to take a step-by-step approach to implementing Enterprise Architecture. The sequence of steps described in this book is based on experience gained over the years with a wide range of employers, large and small, and in a variety of industries.

    The use of architecture frameworks helps an architect to determine the steps of the topics that need to be covered to establish an Enterprise Architecture. However, the sequence of certain steps described in architecture frameworks may not always be implemented in that specific order in practice.

    In particular, it is this sequence that manifests itself differently in practice than in theory. The first phases described in an architecture framework involve setting and articulating goals and objectives. Practice shows, however, that when an Enterprise Architect starts a new job in an existing organization, many of these goals have already been determined. After all, it is safe to assume that the organization has been in existence for more than a few weeks or months. Of course, this is a bit different for a start-up or scale-up organization. Such an organization has not been in existence for very long, and it is likely that a start-up or scale-up organization would benefit from hiring an Enterprise Architect to help formulate the strategy and associated goals and objectives.

    An existing organization – and the form can vary greatly – often has a draft strategic direction consisting of drivers, goals, objectives, and intended outcomes. Not in every situation will these three elements be equally well and comprehensively described, but most likely they will not be missing.

With these experiences in mind, I have tried to provide a roadmap for implementing Enterprise Architecture in an existing organization.

I realize that there are additional areas and topics of interest when we talk about a complete Enterprise Architecture.
However, the focus of this book is on the initial implementation of Enterprise Architecture in an existing organization, and therefore does not describe the full content of an average architecture framework.

It is about providing tools that can help in establishing an Enterprise Architecture.

    Now that the dust has settled on the initial implementation of a basic Enterprise Architecture, it is time to look cautiously ahead. The gaze can be turned forward to determine what can be done to take the architecture effort to the next level. One of the tools that can be used is the Maturity model (see Section 8.3.1.1) described in the Define stage (stage two) of the Enterprise Architecture Implementation Wheel. For each topic in the model, one can look carefully at the next level. From this, it is possible to derive what initiatives are needed to further increase the maturity of working with architecture. All steps and activities to be taken must remain consistent with the strategic direction of the organization. When change occurs, the Enterprise Architecture should reflect that change.

    Processing or incorporating the changes begins by going through the stages of the Enterprise Architecture Implementation Wheel again. Like the ADM of the TOGAF Standard, the Implementation Wheel follows its iterative nature.

    In addition to changes in direction, it is also possible to bring the Enterprise Architecture itself to a more mature state. As stated at the beginning of this book, there is much more that can be accomplished in the area of Enterprise Architecture. This book has only described the basics.

    Now that all the stages of the Enterprise Architecture Implementation Wheel have been completed, a foundation has been laid upon which Enterprise Architecture issues can be executed. The creation of the various architecture deliverables has provided insight into the organizational structure, processes and information concepts, applications, and technology components in use. There is also an understanding of the strategic direction of the enterprise, and specific goals and measurable objectives are defined. Finally, there is a picture of how the progress of the implementation of the strategy can be visualized.

    Using a fictional scenario, this basic Enterprise Architecture can be used to achieve the goals of a non-existent company. The company Lemon-A-de is, of course, not comparable to an existing organization; the setup of Lemon-A-de is greatly simplified in this example. The fictitious company is used for illustration purposes only.

    The organization Lemon-A-de exists for about two years. As the name suggests, the company focuses on selling A-quality lemonade. The first year and a half of its existence was spent on writing a long-term strategy rather than on producing and selling lemonade. In the last 18 months, 22,500 bottles of lemonade have been produced. 1,000 bottles of lemonade were sold per month. Little profit has been made, just under 10%. The organization is relatively small, with six employees. Figure 10-1 shows the layout of the organization using a Business Roles Map.

Figure 10-1. Business Roles Map

    Over the past few months, Lemon-A-de has signed contracts with suppliers of limes, recyclable lemonade bottles, label makers, promotional material printers, and large event organizers. Lemon-A-de’s relationships are shown in an Organization Map (Figure 10-2).

Figure 10-2. Organization Map

     The purpose of this book is to provide insight into how a basic Enterprise Architecture can be established within an existing organization. I have tried to illustrate, substantiate, and entertain with the experiences I have had over the years with a variety of employers. Based on these experiences, I have developed my own view of how a basic Enterprise Architecture can be established within an existing organization.

     Architecture frameworks are a more than valuable tool in the voyage of discovery that is the implementation of an Enterprise Architecture. Although frameworks are theoretically correct in their construction and proposed sequential approach, practice proves to be more recalcitrant.

     Implementing Enterprise Architecture involves not only mapping the organization, processes, information concepts, application landscape, and technology in use, but also communicating architectural thinking. Many organizations are initially critical of this concept. Only when it becomes clear that working with architecture is different from changing the way they work, do most organizations change their minds. Working with architecture is complementary to what the organization is already doing.

     Using the challenges faced by the fictional company Lemon-A-de, I have tried to show how a basic Enterprise Architecture can be used to help an organization implement its intended strategy. Although Lemon-A-de is a relatively small organization, the power of applying Enterprise Architecture in translating strategy into execution becomes clear.

All works and content mentioned on this website are subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed.