Chapter 3. Enterprise Architecture
It is clear that the design and operation of campus networks need to be changed to facilitate all those forces mentioned as trends in Chapter 2. In the past, creating and adopting for these forces where needed was a common approach, although it often led to increased complexity and decreased manageability. This is not uncommon for other parts of the IT industry or business in general as well. It is better, in the end, to design and operate a network using a structured methodology toward design and integration. This is commonly referred to as working with architecture frameworks.
This chapter provides an overview of why architecture frameworks are beneficial and where technology, currently and in the future, is in relation to the enterprise itself. To facilitate this overview, The Open Group Architecture Framework (TOGAF®) standard is used as an example architecture framework.
This chapter covers the following topics:
Why architecture frameworks and working with architecture frameworks is beneficial
A brief overview of the TOGAF® architecture framework
A summary of other enterprise architecture frameworks
A description of where networking and IT fit in these frameworks
What Is an Architecture Framework?
According to the Oxford dictionary the noun architect is defined as a person who designs buildings and in many cases also supervises their construction. A subsection describes the term as a person who is responsible for inventing or realizing a particular idea or project.
The latter definition of the term architect is used not only in buildings but has become a very common approach in many industries where design and production require a certain methodology of working.
For example, in car manufacturing the architect role is responsible for translating the design of a car into modular components that can be reused across different models. The Volvo models XC60, V60, V90, XC90, S90, and S60 all use the same SPA chassis. Other car manufacturers use the same principle. The goal of reusing components is twofold: to reduce cost of design and to decrease time to market. Why reinvent the wheel for a second or third time if the first time is right?
Another example using the architectural role is within manufacturing of computers and specifically the combination of standard computers and built-to-order systems. The computer manufacturer has designed the casing, the logic board, possible drive configurations, and other options. The consumer can choose to either order a prefabricated computer (e.g., off stock) or modify some options on the computer, and this computer will be built to order. The production lines where the systems are produced are the same and only vary with easily adjustable options, such as CPU, memory configuration, disk configuration, or keyboards that can be changed.
Many similar examples exist. All environments with an architectural role have a common ground: a layered approach that uses modularization. In other words, a large design is divided up into smaller logical and functional modules. Each function of a module is described, including its interdependencies, input, and output.
Because the modules are small and logically contained, they are easier to understand and implement. These (most often) implementations in technology provide another benefit as well—longevity of the design. If a technological implementation becomes obsolete, only that specific module needs to be implemented with a new technology as long as all functional requirements are met. The larger design remains valid and in place.
These modules are also called architecture building blocks (functional) and solution building blocks (technical), or building blocks in general. Does this sound familiar? It should. Many IT systems are designed in a similar way, whether it is an application, operating system, or even an enterprise network (comprised of components like campus LAN, WAN, datacenter, or cloud).
There are several methodologies to design, implement, and support a system that is built under architecture. These methodologies, including guidelines and principles, are usually combined in architecture frameworks. All frameworks aim to provide the following benefits when used:
Flexibility: As a specific module can be replaced by another module, as long as it meets the requirements, the system as a whole is more flexible. To relate to the computer manufacturing example, the amount of memory in a system is in essence a module, and by implementing three or four different modules, flexibility for the end user is created.
Reusability: Once a module is designed and implemented, it can be reused more than once. This reusability results in lower costs for the module and the complete system. As an example, most car companies use the same engine type across different models. The engine is designed only once and reused in many different models.
Faster implementation: If a system already has an existing set of designed and tested modules, it is easier to design a new system or new approach based on existing modules. As a result, systems can be designed and built faster.
Serviceability: When every system is divided into logical correct modules, it is easier to troubleshoot a specific problem once the module that behaves erroneously is found. Only that module needs to be fixed instead of a complete system.
Possibility of change: If a system needs to behave differently due to changes in organization or business demands, it is now possible to reorder existing modules, reuse them, and (if needed) design and build only the required changed modules. The generic system is still available and applicable.
A common pitfall though is that the creation of the enterprise architecture becomes leading in the process, instead of being supportive and providing concrete results to the enterprise. This results in less performance of the enterprise and thus the lack of support and usability of an enterprise architecture. This pitfall is often part of the discussion whether an enterprise architecture is actually beneficial to the enterprise. The TOGAF® standard (explained in the next section) is one of the generic frameworks that is focused on removing that pitfall.
The TOGAF® Standard
The Open Group Architecture Framework (TOGAF®) standard (currently at version 9.2) describes a generic framework for developing enterprise architectures. It is one of the more common frameworks to facilitate the development of such architectures, and in a sense can also be used to develop other architectures. The TOGAF® standard and its related standards are published and managed by The Open Group.
The TOGAF® standard consists of several components, such as a methodology to develop the enterprise architecture, a method to functionally (abstract) describe an enterprise, its inner relationships at different levels, a process on how to manage and operate an architecture, and many other aspects related to the enterprise architecture. The following paragraphs provide more information about some of these components. More information can be found on the website of The Open Group (https://www.opengroup.com).
As with any standard or framework, it is of utmost importance that both the authors and readers (consumers) have the same understanding of the definitions used in the specific standard. Over time, quite a few meetings ended in very intense discussions, with interventions and possibly even escalations just because members had different understandings or interpretations of the same definition or described process.
In this sense it is important to know which definitions and contexts are used within a specific framework. The TOGAF® standard uses the ISO/IEC 42010:2007 definition of “architecture,” which is
The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
And although the TOGAF® standard adheres to this definition, it also provides two more specific meanings toward this definition upon which the TOGAF® framework is modeled:
A formal description of a system, or a detailed plan of the system at component level to guide its implementation
The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time
With these two extra meanings, TOGAF® uses this definition to see an enterprise as a system and therefore as the basis for the TOGAF® standard.
Aspects of the TOGAF®
Three key aspects to the TOGAF® standard make it one of the more common frameworks used to develop architectures in the enterprise as described in the following sections.
Framework, Tool, and Methodology
The TOGAF® standard is not only a generic framework, but a tool that you use to implement an (enterprise) architecture. The TOGAF® standard contains all the elements, methodologies, and sample elements based on best practices to develop a successful enterprise architecture.
Pragmatic Approach
The TOGAF® standard takes a pragmatic approach to the development and maintenance of an enterprise architecture. It’s not only based on open standards and best practices, but based upon client requirement. This pragmatic approach is reflected in the fact that one of the targets of the framework is concrete and usable results. And by focusing on usable and concrete results, there is always an added value to the enterprise by describing the use case in the architecture.
Another display of being pragmatic is the “just-enough” architecture approach. The TOGAF® standard states that the architecture must not be over-specified, but just enough to move the enterprise forward.
Iterative
The TOGAF® standard takes an iterative approach to the enterprise architecture. This means that developing and maintaining an enterprise architecture is not a one-time project but is a continual process with repeatable steps to improve and integrate the architecture within the enterprise. This iterative process facilitates the required integration and adoption.
To implement this iterative approach, the Architecture Development Method (ADM) is an integral part of the TOGAF® standard. ADM describes different steps and stages that need to be executed and/or organized for the successful creation of an enterprise architecture. The different ADM steps are described in more detail later in the chapter.
These three aspects underlie every part of the TOGAF® standard. And although these aspects are usually overseen in (large) projects to develop and integrate an (enterprise) architecture, these key aspects can make or break the adoption and usability of any enterprise architecture, or in general any architecture.
Four Types of Architectures
Within the TOGAF® standard, the enterprise (as a system) can be described via four types of architectures:
Business
Data
Application
Technology
These architectures describe in a functional and abstract way how the enterprise works. Within the TOGAF® standard, these four architectures only provide the functional (and abstract) descriptions and requirements and do not provide solutions or implementations to those descriptions and/or requirements.
These four architecture types are, in the approach, similar to the layered approach within the OSI model. (The OSI model is widely used within the networking industry and is a conceptual model that describes, using a layered approach with distinct functions, how applications can communicate with each other over a computer network.) The technology architecture provides the necessary requirements and capabilities needed to enable the application architecture to successfully be implemented. The application architecture is used to set the requirements to successfully implement the data architecture and in a sense the business architecture.
Business Architecture
In general, the business architecture defines the strategy, governance, organization, and key business processes. The business architecture attempts to describe, without specifying persons, tools, or other implementations, how the business itself is organized and what the enterprise provides to the outside world. The business architecture should also provide the necessary information and support the way to implement the enterprise’s vision. In other words, the business architecture is a translation of the enterprise’s vision into several components required to accomplish the vision.
For example, the business architecture of a manufacturing company would contain the business processes such as procurement, sales, quality and development, and logistics. These four business processes would be described functionally, for example:
Procurement is responsible for procuring the necessary ingredients in a just-in-time method with the highest quality standards.
Sales is responsible for selling the goods with the responsibility to keep the available stock to an absolute minimum.
Quality and Development is responsible for monitoring current quality standards and developing new products based on feedback from customers.
Logistics is responsible to ensure proper and timely delivery of the goods sold via Sales.
In this architecture, there is no description of any technology or ingredients specified.
Data Architecture
The data architecture describes which data assets (both physical and logical) are available within the enterprise and how that data is used by the different processes of the enterprise. The data architecture also describes how the data is structured within the enterprise and how data is managed. Although not downplaying the data architecture, it can be seen as a collection of data models of database servers together with the organization and structure of the data inside file servers.
Application Architecture
The application architecture defines the kind of application systems needed to process the data and support the business. It defines the major applications used within the enterprise, the requirements that those applications must meet, as well as the way application lifecycle management is being managed.
Again, this architecture is only functional and would describe applications such as an order and invoice management system to register orders and generate invoices for products sold to customers, a product quality application to monitor and manage the quality process, and so on.
Another example, for the manufacturing company, is that a warehouse management application must be used to keep information about the available stock. This application is also used to provide logistics with sufficient information to pick up products for a sales order and prepare for them shipping. The application also provides the necessary information to the order and invoice system to generate invoices after orders have been shipped and to facilitate the process of order picking by logistics.
Technology Architecture
The technology architecture describes the logical software and hardware capabilities required to support the deployment of the business, data, and application services. The technology architecture is traditionally where IT meets the business and where the primary interaction takes place. It commonly includes the IT infrastructure, required middleware, (application) gateways to external partners, networks, communication, used standards, and processes required to operate the IT to facilitate the business as well.
Again, within the same manufacturing company, the logistics department would have set forth a few requirements for successful operation. This could include the requirement for a wireless technology so that order picking devices can connect directly to the warehouse management system to optimize the order picking and stock management processes. The wireless network availability should meet the operating hours of the warehouse with critical times between 4:00 a.m. and 6:00 a.m. because that is the busiest time for order picking.
ADM
The Architecture Development Method (ADM) is the core of the TOGAF® standard and is a methodology used to develop and implement an enterprise architecture. The ADM is based on an iterative approach and describes the different phases that need to be executed for the development and maintenance of an enterprise architecture.
The ADM is modeled in a circle of eight distinct processes and a single central process. Figure 3-1 displays the phases of the ADM, and the following sections describe the phases in more detail.
Figure 3-1 The Architecture Development Method Phases (Courtesy of The Open Group)
Preliminary Phase
The preliminary phase is the exception of the iterative aspect of ADM. It is executed only once to start all necessary preparations activities, and initiatives to have a directive to implement a new enterprise architecture. This directive is the output of the preliminary phase and is used as the basis for subsequent phases.
Phase A. Architecture Vision
The architecture vision is the first phase of ADM. It describes the initial phase of the architecture development cycle. It also provides the necessary information about stakeholders, scope of the architectural work to be executed, and support (via approvals and mandate) from executive management to define a new or refine the existing enterprise architecture. The products (output) of this phase are stored and managed via the requirements management process.
As in many organizations the only constant is change. The last phase—Architecture Change Management (ACM)—can also be the initiator to restart this phase to define and implement small improvements. This is a key part of the iterative process within TOGAF®.
Phase B. Business Architecture
Business architecture describes the development of a business architecture within the scope set in the Architecture Vision phase. The output contains process descriptions, process models, responsibilities, organizational diagrams, and other business-related artifacts. (An artifact is an element of the enterprise architecture.)
Phase C. Information Systems Architecture
This phase describes the development of an Information Systems Architecture that includes the development (or adjustment) of Data and Application Architectures. The phase can also result in a project required to develop such architectures.
Phase D. Technology Architecture
This phase describes the processes and development of a technology architecture. The output, based on the output of earlier phases as well as existing artifacts, is a technology architecture within the scope of the architecture vision that supports the architectures from phase B and phase C.
Phase E. Opportunities and Solutions
This is the first phase where the functional architectures are to be implemented using products and solutions. This phase encompasses several processes to globally identify opportunities and possible solutions. These opportunities and solutions can also be seen as target architectures, describing the future architecture the enterprise will adopt. The identified opportunities and solutions are grouped into different delivery methods, such as projects or programs. These groups of opportunities are assessed on priority and dependency so the proper priority can be defined.
Phase F. Migration Planning
The output of the previous phase is used to set up a detailed implementation plan as well as an architecture roadmap based on priorities, cost/benefit analysis, and risk assessments. The output of this phase can be seen as the initiation of projects to implement the earlier defined target or solution architectures. The implementation project itself is outside the scope of ADM.
Phase G. Implementation Governance
The ADM including the enterprise architecture needs to be managed and maintained. This phase describes the methods used to develop the governance rules on how the architecture (and its artifacts) is to be managed and changed. This also includes information about its authority structure and the way decisions are made, and it provides answers to responsibility, accountability, and involvement.
Part of this governance is also the way the architects validate and approve the result of the implementation projects. The governance is built upon the mandate and approval of the executive board described in the Architecture Vision phase.
Phase H. Architecture Change Management
This phase describes the methods for continual monitoring of new developments or changes in the enterprise. This phase ensures that all changes made to the architecture are executed in a cohesive and architected way. It is common that new iterations through the ADM are initiated based on triggers from this phase.
Requirements Management
The requirements management process is the central axle in the ADM. It receives and provides all necessary requirements within the enterprise architecture itself. It also provides the necessary steps to take through ADM.
In general, before an enterprise architecture exists, a full cycle around the ADM phases is executed. That first cycle results in an initial enterprise architecture that might not be completely detailed or worked out. But there is a tangible result as an enterprise architecture. In the next iterations of the ADM, only a specific set of phases can be executed, depending on business drivers or specific triggers. An example could be that the governance needs to be changed because of changing rules and regulations, or the data architecture needs to be changed because the regulation on data has changed (GDPR). The ability to specifically select a subset of phases provides the power, flexibility, and possibility to continuously adapt and improve the enterprise architecture.
Guidelines and Principles
Every design is based on requirements and a number of design principles. This is also applicable for an enterprise architecture. Within the TOGAF® standard, these architecture and design principles are managed via the requirements phase of ADM. Architecture principles provide a common set of principles that every aspect of the enterprise architecture must meet. The same is applicable for design guidelines. Although design guidelines are less strict, they also make sure that the different components of the architecture are designed in a consistent way. This consistency increases the transparency and usability of the architecture.
These architecture and design principles must be generic in focus, so that they can be applied to every aspect of the architecture. In general, a design principle commonly consists of a name, the statement, a rationale, and the implications of the principle.
Sometimes external rules and regulations provide the necessary architecture principles upon which the architecture is modeled and designed. This could be an applicable law or specific rules for specific industries.
A few examples of architecture principles common across an enterprise are as follows:
Non-proliferation of technology: Technical diversity will be controlled to reduce complexity in the environment.
Compliance with law: The solution is compliant with all relevant laws and regulations.
Business aligned: Every IT project must be aligned with business goals and strategy.
Common use solutions: Cross-silo solutions are preferred over duplicative silo-specific applications, systems, and tools. This prevents silo solutions as much as possible.
Simple solutions: IT will be as simple as possible. Where complexity is required it will be encapsulated and hidden behind an interface that is as simple as possible.
Shared resources: Solutions will seek to have maximum sharing of resources such as network, computing, storage, and data.
Security: Security should be an integral part of any design to reduce the risk of leaking potential sensitive data to unauthorized devices and persons.
As you can see, these principles are generic and provide a framework within a design is to be implemented. These architecture principles are, of course, also applicable for a network designer or architect when a new network infrastructure is designed.
Building Blocks
Building blocks are common in any methodology to design or develop a framework, whether within a software framework or a campus network design. The TOGAF® standard is no different; the most common artifact is the building block.
In TOGAF®, the building block represents a (potential reusable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. The building block describes, in a clear and concise way, its functions and relationship with other building blocks.
A building block can be as large as the description of a complete system (with its relationship to other systems) or as small as a building block describing the way NTP or syslog is configured on all network devices. It is common to model a building block using other building blocks. One of the benefits of reusing building blocks in a larger design is that it eliminates the need to reinvent a solution twice or even more times. A building block improves on standardization, and it also improves the efficiency of the enterprise in case a building block is updated with a new solution. It is therefore very important to define building blocks in a clear and concise method, including a clear description of its relationships to others.
Within TOGAF® there are two kinds of building blocks:
The Architecture Building Block (ABB) describes on a functional level the requirements and usage of the building block.
The Solution Building Block (SBB) in turn describes how the requirements and functional description of an ABB is translated into a solution.
An example of an ABB is that an enterprise has the requirement for a wireless network infrastructure in all its warehouses to facilitate the requirement that order-pick equipment can communicate with the warehouse management system. The wireless network needs to be highly available and adhere to the latest industry standards and amendments in wireless networking. The coverage of the wireless network needs to be implemented in such a way that there can be no loss of connectivity.
An example of an SBB that translated the wireless network ABB would be a Cisco Wireless LAN Controller (WLC) setup, using the IEEE 802.11ac amendment in conjunction with wireless site surveys that are designed for balanced capacity and coverage with near-overlapping cells.
Repository
The different artifacts—parts of the enterprise architecture, such as an architecture principle, a building block, a catalogue (list of things), use case specifications, or diagrams—need to have a location where they can easily be stored and retrieved. This is the architecture repository. It is a central location, with versioning, where every aspect of the enterprise architecture is stored. The process of defining versions and releases of the elements inside the repository is defined within the governance phase of ADM.
When the items of this repository are combined and ordered in a specific way, so-called architecture deliverables are created. A deliverable can be a target architecture, a solution architecture, or a solution building block.
The architecture repository can easily be compared with a code repository used by software engineers to share and commit their work to, such as GitHub. Its output in turn is an application. For network designers, the output would be a configuration template for a specific network device type in the enterprise.
In summary, the TOGAF® standard itself contains many more elements, definitions, reference models, stakeholder management, and other information. Different books have been written on the topic of the TOGAF® standard as well as enterprise architecture. As mentioned, more information can be found on the website of The Open Group.
Enterprise Architectures
The TOGAF® standard is not the only enterprise architecture framework. Different frameworks are available—some for specific industries or specific purposes, some more generic. In general they follow a similar pattern of abstracting requirements and processes into layers to create abstractions on design and implementation. They all aim to provide added value to the enterprise in one way or another.
Table 3-1 lists some more enterprise architecture frameworks related to specific industries.
Table 3-1 Overview of More Enterprise Architecture Frameworks for Specific Purposes
Type |
Name |
Description |
Generic |
ARCON |
A reference architecture for collaborative networks, not directly focusing on a single enterprise but on how to collaborate |
Generic |
GERAM |
Generalized Enterprise Reference Architecture and Methodology |
Generic |
RM-ODP |
The reference model for Open Distributed Processing (ITU-T recommendation X.901-X.904, ISO/IEC 10746 standard) defining specifications for open distributed systems |
Generic |
IDEAS Group |
A four-nation effort to develop a common approach for architecture interoperability |
Generic |
ISO 19439 |
ISO framework for enterprise modeling |
Defense |
AGATE |
The France DGA Architecture Framework |
Defense |
DNDAF |
The Canadian DND/CF Architecture Framework |
Defense |
DoDAF |
The US Department of Defense Architecture Framework |
Defense |
MODAF |
The UK Ministry of Defense Architecture Framework |
Defense |
NAF |
The NATO Architecture Framework |
Government |
ESAAF |
European Space Agency Architectural Framework |
Government |
GEA |
Government Enterprise Architecture by the Queensland Government |
Government |
NORA |
Dutch Government E-government Architecture |
Government |
NIST |
NIST Enterprise Architecture Framework |
Use Case: DIY Architecture
Although FinTech Ltd. did not follow an existing architecture design framework such as TOGAF®, IT noticed a requirement for a more structured approach toward IT, implementation projects, and the network infrastructure. FinTech Ltd. decided to take small steps and to describe several of its processes (besides quality processes) in a technical design as well. The technical principles and designs were based on where the network was going to be in a number of years–in essence a roadmap. They then defined projects to reach that goal.
Within the Windows server environment a similar process was taking place to more easily manage their server environment and optimize the workflow. A separate track was started to model the information flowing over the network, as one of their customers was demanding that such information be made available. Over time, these tracks grew together and started to collaborate on a shared architectural approach upon which projects were also implemented. A shared group was established to share experiences and information about relationships. This group eventually became the architecture board.
Although FinTech Ltd. didn’t adopt a formally acknowledged architecture standard, they organically grew into working with architectures, roadmaps, and projects. This method of building and defining your own architecture is not faulty; for some specific situations it might actually be the best solution. The purpose of working with an architecture is to provide a consistent and concise method of describing the environment at both the design and the solutions levels. Its purpose is to improve the enterprise as a whole, and a custom self-designed architecture using a bottom-up approach can be as valid as a top-down approach.
Summary
Although the TOGAF® standard itself is a tool aimed to design and deploy a full enterprise architecture, the components described in this chapter, including the ADM, are common for any IT-related design and implementation process.
The mechanisms described, such as a building block for modularity, reusability, and scalability, are a common practice and the basis for almost any network design. By defining clear distinct principles and following those rules, the network design will increase in visibility and usability as well. When a new network product is to be used, only a new solution building block needs to be developed, instead of a complete new network design.
There are quite a few benefits for network engineers or architects to follow these same principles to also create more understanding of other IT-related architects or the business as a whole.
For a network architect, or network engineer, it is important to be aware that the network design itself is critical for the enterprise, but its design and implementation only play a “smaller” part of the complete enterprise architecture. From that perspective it is important to also be aware that when changing a network infrastructure design, this change can have dire consequences for the rest of the enterprise architecture and even the enterprise itself.