The purpose of this chapter is to lay the groundwork of terminology that is used throughout the book and to provide a grasp of the fundamentals of enterprise architecture (EA). This chapter informally introduces the concepts through the prism of a hypothetical airport. Chapter 3 elaborates on Richard M. Nixon Municipal Airport, the primary case study used throughout this book.

This chapter provides a general discussion of the terms used in enterprise architecture. Specific architecture frameworks may use additional or variants of terminology unique to their scope. The terms presented here are a direct reflection of the current state of practice of enterprise architecture. Understanding of the foundational concepts is essential before you tackle the actual process of planning, developing, using, and sustaining architecture representations in subsequent chapters.

High-Level Concepts

The high-level concepts are enterprise, architecture, and enterprise architecture.

Enterprise

The term enterprise can be defined in several ways. Here are some examples:

• “One or more organizations sharing a definite mission, goals, and objectives to offer an output such as a product or service.” [ISO 2000–06]

• “Any collection of organizations that has a common set of goals. (Also) The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.” [The Open Group 2009]

• “An organization (or cross organizational entity) supporting a defined business scope and mission that includes interdependent resources (people, organizations and technologies) that must coordinate their functions and share information in support of a common mission (or set of related missions).” [CIO Council 1999]

• “The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organizational boundaries are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes.” [OMB 2012]

An enterprise, informally, is a group of people engaged in purposeful activities with a common motive. All the definitions associate the people who form an enterprise into one or more organizational structures. The motive or purpose of the enterprise is defined in terms of the mission, goals, objectives, or vision, and the achievement of such motives enables the enterprise to continue to operate. This broad definition includes large corporations, such as IBM and AT&T, small businesses, the Executive Branch of the United States government, and small municipal entities such as an airport. In a viable enterprise, the motivation must be common and the activities must be collaborative in support of the common purpose.

The Merriam-Webster dictionary defines enterprise as “a project or undertaking that is especially difficult, complicated or risky.” Transformations of large corporations or organizations involve several difficult, complicated, and risky projects. Each of these individual projects as well as the collection of projects may be deemed to be enterprises in their own right.

Why is the enterprise concept important? The enterprise concept raises the collaboration and common motivation aspects that people tend to forget in their preoccupation with daily activities. An enterprise exists for a purpose larger than the output of daily activities. Threads link the activity and output of one person or organization with the activity and output of others. Understanding these linkages is a very important aspect of streamlining the collection of activities that together fulfill the purpose of the enterprise. Linkages between people and activities involve handshakes, sequencing, orchestration, and the flow of resources.

Enterprises can be defined at any level of abstraction. As an enterprise, General Motors, for example, supplies automotive products and solutions to the world. But a manufacturer that supplies General Motors with transmission assemblies for automobile manufacturing is also an enterprise. The supplier that provides hardware parts to the transmission manufacturer is also an enterprise. The first order of business, therefore, is to describe carefully the scope or extent of the enterprise that is being analyzed. It is important that you understand the relationships among the component enterprises of a larger enterprise as well as relationships among partner enterprises. These relationships may be of a command and control (directive) nature, as in the case of reporting organizations, or they may be based on agreements and contracts for organizations that do not have formal direct reporting relationships. Some of the issues related to culture are discussed in Chapter 2, as well as styles of influencing that may be brought to bear in managing these interenterprise relationships.

Airport Example

An airport is an enterprise. At a minimum, it must provide a capability for repeatable and safe aircraft landings and takeoffs. It must also provide capabilities for loading and unloading aircraft cargo, passengers, and crew; for staging them prior to takeoff; and for processing them after landing. Optionally, the airport may provide capabilities for refreshments and food, automobile parking, vending, shopping, and many other possibilities. On the organization side, a major airport may have an airport authority managing the operations, an air traffic management managing traffic, and multiple airline operations centers where the airlines using the airport stage their operations, to cite a few examples.

Architecture

Simply put, an architecture—or, more correctly, an architecture description—is a representation of the elements and the relationships among those elements as well as the rules that guide the behavior of those elements. Formally, an architecture is defined by the ANSI/IEEE Standard 1471-2000 as “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.”

An architecture includes the following:

• Components that form a whole, including structural and/or behavioral elements, which are both types of architectural components

• Relationships among the components

• Principles that govern the design of the components

• Principles that govern the evolution of the components and their relationships in the context of the system they create

John Zachman argues that “Architecture” IS the set of descriptive representations relevant for describing a complex object (actually, any object) such that an instance of the object can be created and such that the descriptive representations serve as the baseline for changing an object instance (assuming that the descriptive representations are maintained consistent with the instantiation).” [Zachman 2015]

Many of the things around us, such as buildings, the highway system, and airports, have implicit architectures that we can observe, at least in terms of components and relationships. However, some components may be hidden, some relationships may be unclear to the casual observer, and the principles that govern the design and evolution of the components and their relationships may be entirely unclear. For example, when I was working for a large commercial building HVAC-control supplier, a local joke was that the Empire State Building was being held up by all the copper wiring inside! Each succeeding contractor ran their own wires because they did not have the wiring plans (that is, an explicit electrical architecture description) and simply cut off the end points of the old wire, leaving the old wire in the building. Anyone who watches the remodeling shows on HGTV knows that house remodelers, who must work from the implicit—that is, the externally observable—architecture of a house, often find unexpected and expensive problems when they open walls and find the hidden components and relationships of the house’s architecture. In the same way, implicit architectures are not very useful to people who have to remodel all or part of an enterprise. Thus, we focus on explicit architectures, or architecture descriptions.

Architecture Descriptions

An architectural description is an electronic or paper representation of all aspects of an architecture. This book will use the term “architecture description” synonymously with the word “architecture” from this point on. The DoD Architecture Framework Version 2.0 defines an architectural description as “a strategic information asset that describes the current and/or desired relationships between an organization’s business, mission and management processes, and the supporting infrastructure.” [DoD 2007] Other sources go farther and include aspects of transformation in the definition of architecture descriptions:

• Architectural descriptions may include a strategy for managing change, along with transitional processes needed to evolve the state of a business or mission to one that is more efficient, effective, current, and capable of providing those actions needed to fulfill its goals and objectives.

• Architectural descriptions may illustrate an organization, or a part of it, as it presently exists; any changes desired (whether operational or technology driven); and the strategies and projects employed to achieve the desired transformation.

• An architectural description also defines principles and goals and sets direction on issues that facilitate enterprise decisions, such as the promotion of interoperability, intra- and interagency information sharing, and improved processes.

• Architecture descriptions represent structural aspects of the enterprise, such as organization structures, physical locations, and equipment and systems, as well as behavioral aspects, such as activities, events, and changes of state of structural elements in the face of such activities and events.

Benefits of an Explicit Architecture Description   Why is an explicit architecture concept so important? An architecture (description) is an explicit representation of the elements of an enterprise or part of an enterprise and the relationships among them. Without this explicit representation, the enterprise is unable, for example, to do the following:

• Prioritize resource allocations among the various competing demands for resources.

• Determine the viability of transformation in terms of the impact, the need for resources and change, and the ability to achieve the desired end states.

• Govern the expenditure of current resources and determine whether they are being correctly applied in achieving the enterprise’s mission.

• Organize the transformational objectives crisply into initiatives (and projects that follow) that focus on aspects of the enterprise for change.

• Develop roadmaps for modernization.

• Develop roadmaps for orderly replacement of obsolete technology and infrastructure.

• Develop roadmaps for acquiring skills and specialties in the workforce required to operate the enterprise for the future.

Enterprise Architecture

Informally, an enterprise architecture is the concept of “architecture” applied to the concept of “enterprise.” There are many competing formal definitions for enterprise architecture, depending on the interest and viewpoint of the defining organizations:

• An enterprise architecture provides a clear and comprehensive picture of the structure of an entity, whether an organization or a functional or mission area. It is an essential tool for effectively and efficiently engineering business processes and for implementing and evolving supporting systems. [GAO 2003] The interest of the Government Accountability Office (GAO) is accountability in terms of effectiveness of investments.

• Simply stated, enterprise architectures are “blueprints” for systematically and completely defining an organization’s current (baseline) or desired (target) environment. Enterprise architectures are essential for evolving information systems, developing new systems, and inserting emerging technologies that optimize their mission value. [CIO Council 2001] The interest of the Federal Chief Information Officer (CIO) is Information Technology and information processing systems.

• Enterprise architecture is a management practice to maximize the contribution of an agency’s resources, IT investments, and system development activities to achieve its performance goals. Architecture describes clear relationships from strategic goals and objectives through investments to measurable performance improvements for the entire enterprise or a portion (or segment) of the enterprise. [OMB 2012] The interest of the Office of Budget and Management (OMB) is management and financial governance.

• Enterprise architecture is the principle structural mechanism for establishing a basis for assimilating high rates of change, advancing the state of the art in enterprise design, managing the knowledgebase of the enterprise, and integrating the technology into the fabric of the enterprise. Enterprise architecture is cross-disciplinary, requiring diverse skills, methods, and tools within and beyond the technology community. [FEAF 1999] The interest of the CIO council in this area is the need for a common Federal Enterprise Architecture Framework (FEAF).

• “Enterprise architecture is the organizing logic for business processes and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model.” [MIT CISR]

• “Enterprise Architecture is a management engineering discipline that presents a holistic, comprehensive view of the enterprise including strategic planning, organization, relationships, business process, information, and operations. The organization must be viewed as fluid—changing over time as necessary based on the environment and management’s response to that environment.” [NASCIO 2017] NASCIO’s definition is broader than simply the IT perspective and encompasses a more holistic view of the enterprise. This definition starts with the strategic plan as the foundation for the architecture.

As you can see, the many definitions of enterprise architecture stem from the concerns that make it useful rather than actually defining what it is! Here’s a new definition that borrows from the IEEE definition of architecture, adds the enterprise context, and removes the specificity of concerns: Enterprise architecture is a knowledgebase of the behavioral and structural elements of an enterprise, the relationships between these elements, and their evolution over time.” The knowledgebase that the enterprise architecture represents can be applied equally well to designing new, complex systems; planning technology insertion; incorporating innovations; or governing expensive investments.

As-Is and To-Be Architectures

An enterprise is constantly changing. An enterprise architecture description developed at one point in time may no longer be a valid representation of reality at some future point in time. We use the term “as-is,” or baseline, to describe the currently modeled representation of the enterprise. At the same time, we may also want to represent what we want the enterprise to look like at a future date using architecture representations as well. This representation of the enterprise architecture at a future date is called the “to-be,” or target, enterprise architecture.

The analysis of the differences between the as-is architecture and the to-be architecture is a form of gap analysis. The sum total of changes that need to be effected in various elements of the as-is architecture to achieve the state described by the to-be architecture represents the transformations that needs to be made to the enterprise. The identified gaps are therefore addressed by a transformation that is undertaken in steps. The step-by-step plan that describes the evolution of the enterprise from the baseline state to the target state is called an Enterprise Transition Roadmap. As discussed in later chapters, the roadmap may be broken down into different layers related to transformation in multiple aspects of architecture.

In enterprises whose charters are enduring, such as those of federal agencies established by law or the Department of Defense, where doctrine, policy, organization, and force structures and training determine the enterprise’s characteristics, the development of an as-is, the formulation of a to-be or target state, and an orderly transformational plan comprising initiatives and projects is a very viable strategy. For enterprises that are founded and based on laws, regulation, and policy, we sometimes talk about an idealized “should-be” state that is predicated on compliance of the laws, regulations, and policies. Such an enterprise state is arguably what is benchmarked during investigations by third-party investigators, such as the Office of Inspector General or the Government Accountability Office (GAO).

Transformation

Sometimes it is said that every act of construction must begin with an act of engineering analysis. It is only through such analysis, sometimes requiring destruction, that we can divine or verify original intent. We can determine if future intent differs from the original intent and make architectural changes accordingly. Analysis of current operations, systems, and technology infrastructure results in a baseline, or as-is architecture.

Considerable debate has occurred within the architecture community on the value of baselining enterprise states. The argument is that in a constantly changing world, the architecting enterprise gains more benefit from modeling and moving the enterprise to the target state rather than in spending large amounts of architecting resources in looking back at the current state of operations. Yet in areas such as civil engineering projects, any remodeling effort has to ride on the back of an understanding of the current construction. Any act of demolition requires an understanding of what and how to demolish in order to limit the impact of the demolition.

The fact of the matter is that many transformational initiatives in large organizations have failed by failing to take into account traumatic changes that may be imposed upon the enterprise or by failing to realize the inability to reach the target state from the current state within time and cost constraints. Cultural impacts may result in (often unwitting) sabotage of those initiatives by human beings who are unwilling to change. A lack of understanding of complexities of current business rules and processes has left some modernization efforts with failed transformation after exceeding the scheduled time frame by years and scheduled cost by millions. A successful transformation plan must reflect an understanding of the current state and cultural factors of the enterprise. It needs to set realistic transformational initiatives that are phased according to the enterprise’s ability to absorb and finance change.

Some recent documented and spectacular complex project failures such as the U.S. Air Force’s Expeditionary Combat Support System (ECSS)—a write-off of more than $1 billion—illustrate the need to represent and socialize architectural representations and impacts and anticipate problems before diving into implementation. ECSS represents a class of failed complex enterprise resource planning systems, where multiyear investments continued to flow into a large program plagued by failure to adhere to principles of business process reengineering, cultural resistance to change within the Air Force, and lack of leadership to implement needed changes. The replacement of existing systems or families of systems by new integrated enterprise resource planning (ERP) systems are especially prone to issues of organizational and cultural factors that need to be addressed as well as issues of understanding how the business currently operates.

The time needed to develop a baseline architecture is often perceived as a luxury in the commercial world, where the pace of change is often forced by competition and alternatives that are outside the control of the architecting enterprise. In this world, in situations where new products and services are offered, entire new enterprises are created by founding, mergers, or acquisitions. These new enterprises exhibit complex behaviors that must be factored into the transformation plan. Often, these new enterprises behave like startups—an area where traditional enterprise architecture study has not generally focused. They are driven by extreme financial goals under extreme time constraints, often with extreme resource constraints, and where common motivation for individual profit and reward outweigh all other cultural considerations, at least for a few years.

Here’s an example: Most airports are constantly in transition. They face pressures of increasing traffic of departures and arrivals, increasing passenger traffic through the airport, upgrading of technology to meet passenger and stakeholder expectations of performance, convenience and amenities—and all of these pressures drive the need for change. Once an airport is operational, it is essential that it make incremental transformations while staying open for business. A large transformation will therefore have to be broken down into small increments that disrupt the operations of the airport to the smallest extent possible. The airport master plan is the instrument for describing the planned transformation increments to the airport. It contains a sequence of to-be states that describe the intermediate steps within the planned transformation.

Emergence   There is one further complication for enterprise transformation: emergence. Because nothing stands still as the enterprise is being transformed, both external and internal forces may change enterprise elements in unplanned ways. Unexpected shifts in the marketplace, new competitors, and breakthrough technology may require changes to the transformation roadmap and change the enterprise’s strategic vision and target state. Workers may find that planned new processes don’t work well and may develop new ones on their own. In short, we must be ready for a new version of the enterprise to emerge from the old in response to unplanned, reactive evolution of the enterprise.

The approach to architecting for the emergent enterprise involves careful attention to the sustainment and maintenance of the architecture (discussed in Chapter 8). The enterprise architecture in such enterprises serves as a knowledgebase for option exposure and exploration rather than as a compass for transformation planning. Architecting is performed on the things that matter, rather than attempting a comprehensive representation of every aspect of the enterprise. In the airport, temporary emergent behavior occurs when a single or a few airlines have scheduling problems and passengers desperately try to reroute their travel via other airlines. The planning factors that have established the size of the check-in counters, the number of booking agents, and the ability to move passengers through the reservation, ticketing, and boarding processes are severely restricted by available capacity. If this is a normal occurrence, airlines will adapt over time to an unexpected rush of passengers with routine responses that are permanently built into their enterprise.

Reference Architectures

A reference architecture is a special form of enterprise architecture that provides a template architecture for enterprises or partitions of enterprises, such as segments, that have observed or desired similarities. For example, U.S. government agencies called “commissions” have organizational structures, functions, and processes dictated by law. Examples of these agencies are the Securities and Exchange Commission and the Nuclear Regulatory Commission. This means that you could build a reference architecture with template organization charts, template high-level activity models, and other template views that could be refined to provide at least a should-be architecture for a new commission. Similarly, if a company had a specific way it wanted a regional office to be set up and run, it could develop a reference architecture for regional offices that could be used to describe any regional office or to set up a new regional office.

Architecture Frameworks

One of the key decisions prior to developing an enterprise architecture is the selection of an architecture framework. In general, architecture frameworks provide guidance on what to include in an enterprise architecture and how to structure and organize the information. An architecture framework provides guidance and rules for structuring, classifying, and organizing architectures [DoD 2007].

Architecture frameworks use organizing concepts such as levels of enterprise, viewpoints and views, integrated metamodels, and methodologies and processes, each of which is discussed in general in the following sections. Not all frameworks use all of these concepts, but when they do use a concept, the terminology, organization, and structure may be very different from what is used in another framework. The concepts used in each of today’s four major frameworks are summarized in the chapter that addresses that specific framework: the Zachman Framework in Chapter 21, the U.S. Department of Defense Architecture Framework (DoDAF) and its related defense frameworks in Chapter 4, The Open Group Architecture Framework (TOGAF) in Chapter 22, and the Federal Enterprise Architecture Framework Version 2.0 (FEAF2) in Chapter 23.

Levels of Enterprise

As mentioned, the definition of enterprise is very flexible; enterprises come in many sizes and shapes. Because many enterprises are too large to be fully described in one document, there are ways of breaking them up into pieces that can be described separately and in such a way to be integrated or related to each other at a later time. One of the first steps in developing an enterprise architecture is to set the scope and level of detail of an architecture. Various levels of enterprise detail ranges from an extended enterprise down to solutions and initiatives.

Extended Enterprise

Few enterprises, if any, are self-sufficient or self-contained. One enterprise may have a network of partner enterprises that provides various capabilities and resources needed to run the first enterprise. The extended enterprise is a representation of this network of partnerships. Extended partners may include supplychain participants, information technology service providers, marketing and sales partners, and others.

Our airport example includes capabilities for security checks (provided by the Transportation Safety Agency and local law enforcement), capabilities for air traffic control (provided by the Federal Aviation Administration), and capabilities for refreshments, food, drinks, and sustenance of airport employees, passengers, crew members, and airline staff (provided by a food concessionaire corporation). As we extend the scope of capabilities that we want to include within an architecture, we see that the extended enterprise begins to proliferate!

Partitioning the Enterprise

How do we break up the complexity of enterprises into smaller units? In the commercial world, a large complex enterprise can be broken down into smaller business units, each responsible for some area of business or “product lines.” In the government, often this breakdown of the enterprise is in the form of functional organizations responsible for various business functions. In holding companies, each of the businesses that form a conglomerate is a smaller enterprise that has a financial (profit-and-loss) relationship with the parent enterprise.

Segments   In any case, governing a large enterprise involves partitioning the enterprise into smaller enterprises called enterprise segments, or segments in short. At each stage of the partitioning, one or more criteria may be used to determine the scope of the segments:

• Partitioning along business areas   Widely differing business areas are partitioned into widely different subenterprises. An area of business may therefore be an enterprise segment. If the business areas are large and complex, a further partitioning may be required.

• Partitioning along product lines or service areas   In product- or service-based enterprises, each product line or service area may have differing characteristics and therefore different “enterprise patterns” for fulfillment. An area of business, line of business, or product line or service area may be a legitimate segment of an enterprise architecture. If the product line is too broad or complex, further partitioning into smaller segments may be required.

• Partitioning along functional boundaries   Areas such as marketing, sales, engineering, and manufacturing may all be segments of the larger enterprise architecture. Functional architectures, without the integrating mechanism that unifies the functions and cross-thread processes that are performed by individual functions, results in stovepipe processes that may be optimized for the function but not for the enterprise. For example, if the process producing hubcaps efficiently produces 200 hubcaps a minute for an assembly line assembling one car per minute that consumes only four of the hubcaps, producing more hubcaps faster will not improve the overall throughput of cars coming off the assembly line.

• Partitioning along physical boundaries   Large and complex organizations that are geographically distributed can be partitioned into subsets that are physically colocated as independent partitions that are connected by collaboration and coordination.

• Partitioning along subpatterns   In enterprises that have undergone standardization efforts such as the military or the federal government, parts of the enterprise are built along some common architecture pattern. For example, Air Force bases are constructed and staffed using a common pattern as are Navy bases and Army bases. Field offices in certain federal agencies such as the one for the Securities and Exchange Commission exhibit the same four functions of corporation finance, market regulation, investment management, and enforcement. Regulatory enterprises that are regulated by laws, such as the Federal Administrative Procedures Act, for example, are forced to have a common organizational structure and apply high-level processes such as rulemaking in a common way. Recognizing these subpatterns enables us to decompose the larger complex enterprise into smaller subenterprises that can be individually modeled for analysis. These architecture patterns can also be translated into reference architectures.

Why is partitioning complex enterprises into segments useful? Decomposition is a common technique to address complexity analysis. By decomposing a large enterprise into segments, the architecture development and the analysis become easier. Also, the large, complex enterprise is an abstract concept for most stakeholders involved in the day-to-day operations of the enterprise. Decomposing an enterprise into something smaller also brings closeness of the issues and architecture elements to such stakeholders. Arguably, the enterprise stakeholder pyramid has a small but very influential group at the top, for which the enterprise vantage point is both important and useful. But a larger group of stakeholders in the middle and at the bottom of the stakeholder pyramid have a stake in the daily operations of the enterprise. Without bringing the detail down to their level of abstraction, the enterprise architecture simply becomes a theoretical exercise targeted solely for upper management.

Segments also provide direct visibility of operations that can be tied to specific projects and initiatives. This direct tie-in enables portfolio managers who are balancing the investments in projects and initiatives to make a more accurate impact assessment of the project or initiative on the specific operational activities undertaken within an enterprise segment.

Solutions   A solution architecture is the lowest level of enterprise architecture, or the finest partition of an enterprise. What is a solution? A solution is a system that provides automated or nonautomated support for business processes. We use the word “system” in the general sense as a set of components that together provide the functionality support and desired outputs for a business process. A system may comprise smaller systems, called a system of systems, or cooperate and collaborate with other systems in a family of systems.

An initiative or a project is responsible for delivering a single solution, a family of solutions, or some aspect of a solution. An initiative is a collection of resources aimed at achieving an explicit purpose or outcome. A project is a schedule of activities that will implement an initiative and expend the resources allocated to that initiative. Together, initiatives and projects are used to transform an enterprise to a desired end state. Enterprise architecture provides the knowledgebase for planning this transformation in an orderly manner, recognizing dependencies, risks, and issues before actual transformation projects are undertaken.

An example initiative that is currently being implemented at larger airports everywhere is the rapid processing of prescreened passengers through security checkpoints. The scope of the solution for each airport is restricted to processing prescreened passengers with credentials that are validated before rapid processing commences. TSA Pre is an example of this type of prescreening. This initiative divides the current single long queues at airport security checkpoints into two groups: one that contains only prescreened passengers and another for the general traveling public.

Airport Example   In our airport example, following are some of the levels of architecting that we could potentially undertake, given the needs of the sponsor and the scope of the problem set being addressed:

• The entire extended airport enterprise

• The airport enterprise for core functions of the airport performed internally without partners

• Vertical segment architectures for capability groups such as passenger management, aircraft maintenance, air-traffic control, and concession management

• Horizontal segments such as financial management and human resource management

• Solutions for specific problems such as passenger or employee identification, concession revenue improvement, and airport expansion planning

Federated Architectures

Federated architectures are enterprise architectures assembled or made up from the separately developed architectures of the enterprise’s component parts. A federated architecture could be an architecture for an extended enterprise, where the independent architectures have been developed by a large enterprise and its various partners. Or it could be an enterprise architecture for a very large enterprise, such as the U.S. Executive Departments, assembled from the architectures developed by the set of partitions of the enterprise. Clearly, there would have to be detailed guidance provided to each architecture development group in order for these subarchitectures to be compatible enough to assemble into a coherent whole. For example, all the component architectures would have to use the same framework and interfaces, or relationships between elements in different subarchitectures would have to be agreed upon. Terms and vocabularies would also have to be agreed upon. This is a place where reference models (see the “Reference Models” section later in the chapter) are useful.

Viewpoints

One of the organizing structures that most architecture frameworks provide is called a viewpoint. Viewpoints are key to connecting the people who need to see the architecture to those parts of the architecture in which they are most interested.

Stakeholders

Who is an enterprise architecture stakeholder? Informally, an architecture stakeholder is any organization, role, or group that uses the architecture to support decision-making or understanding. One definition of enterprise architecture stakeholder is “an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture. Different stakeholders with different roles will have different concerns.” [TOGAF 2009]

One of the first tasks while architecting the enterprise, after defining the purpose and scope of the architecting exercise, is to identify the stakeholders and their concerns related to the architecture. What are the issues that they want to solve through understanding the architecture representation and the connections between the architecture elements?

Airport Example   In the airport, there are multiple stakeholders, as is usual in most enterprises. When the airport is being constructed or expanded, stakeholders may include those who are involved in the land acquisition, financing, environmental impact analysis, municipal and local government, airport management, construction companies and contractors, and many others.

After the airport is operational, some of these initial stakeholders’ roles are diminished or irrelevant, and the architect has to deal with many new stakeholders such as passengers, airlines, airline employees, airport employees, airline crew members, concession owners and operators, cargo and baggage handlers, parking ramp operators, medical service providers, and many others.

Depending on the scope of the architecting effort, not all stakeholders of the enterprise need to be considered as factors. Solution architectures, for example, will involve a subset of stakeholders. Automation architectures such as a system for automated baggage handling will introduce stakeholders who must operate and sustain the automation.

Chapter 5 includes a more thorough discussion of stakeholders.

Stakeholders and Viewpoints

The difficulty in representing architecture descriptions in a universal format stems from the fact that different stakeholders of the enterprise have different viewpoints and interests. The need to support multiple viewpoints is fundamental for architecture. During architecture development, the architect must determine which viewpoints will be supported by architecture representations. In general, architecture frameworks have tried to codify the types of viewpoints that are supported by the framework. Due to the traditional evolution of enterprise architecting, these viewpoints, such as applications, data, and infrastructure and technology tend to be IT-centric. However, the concept of a viewpoint is very general and can be used to describe the common concerns of any group of stakeholders.

Here are some examples of typical viewpoints:

• A viewpoint for enterprise management, strategy, and planning

• A viewpoint for business process designers, managers, and operators

• A viewpoint for IT/automation designers, managers, developers, and maintainers

• A viewpoint for data managers and users

Viewpoints are very useful in architecture work:

• Viewpoints provide visibility of architecture elements that are important from that viewpoint; however, architecture elements that are of no concern are invisible from that viewpoint!

• Viewpoints reduce the scope of architecting by restricting the architect only to elements that are important from that viewpoint.

• Viewpoints generally reflect common concerns from a specialized group of stakeholders who have well-established models, artifacts, and techniques. The stakeholders’ familiarity with the terms and definitions of these representations makes it easy to communicate with these stakeholders.

• Viewpoints that are codified by an architecture framework provide a standardized way to represent architectures. Implementing standardized ways to represent the architecture for specific groups of stakeholders makes it possible to aggregate, compare, and analyze architectures using common methods.

Views

A view is used to address a subset of the concerns of a specific viewpoint and is specific to a single viewpoint. In the world of buildings, architecture is represented in several standardized views, including a floor plan that describes the layout of various parts of the building and a front elevation drawing that describes how the building looks from the front. Each of these methods of representation uses symbols for denoting architectural elements. For example, in a floor plan, walls and openings are drawn in a consistent manner that is comprehensible to any architect who is trying to understand the building design.

Views may be represented informally as pictures and unstructured documents, formally as mathematical models, or semiformally as relationship matrices and timeline charts. Though the definition of a model is quite rigorous in the mathematical and computer science domains, frameworks may refer to views of any form as a model or to views in general as architecture artifacts or products. A viewpoint is defined using one or more views.

Artifacts

Artifact is a general term that describes any type of architecture representation in document form. The TOGAF 9 Standard describes an artifact as “an architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a use-case diagram. An architectural deliverable may contain many artifacts.” [The Open Group 2009]

Multiple views may be required to represent all aspects of the viewpoint. For example, a business process model, a resources flow model, and an organizational chart might be included to represent a business operational viewpoint.

Pictures   A picture is an informal graphical representation that is not governed by any specific rules of construction. The primary criterion for a picture is that it “convey the information that the architect is trying to convey.” Because of the variety of architects and audiences alike, the effectiveness of the picture in conveying information is also varied. Different architects could draw different pictures of the same object they are architecting, resulting in no consistency in communicating understanding. Understanding the representation becomes a hit-or-miss exercise!

Semiformal Views   Structured documents (that is, documents that have a prescribed outline or content requirements), matrices, and graphics with limited syntax and semantic rules are all examples of semiformal views. Syntaxes are rules for physical representation that tell when a view is properly formed or, in technical terms, well-formed. For example, structured documents such as reports have outlines that specify required section headings and their order. Such a report will be rejected if it is not in the correct format. However, it takes a human to decide whether the content of the sections actually makes sense—that is, whether it has meaningful semantics.

Formal Models   Models are formal representations, graphical or otherwise, that are constructed according to a set of specific syntax and semantics rules. These rules determine, for example, which symbol can be connected to which other symbol and describe what the meaning of the links and symbols are in a consistent manner. By controlling the construction (syntax) as well as the meaning (semantics) of model objects and interconnections through a set of well-established and agreed-upon rules, architects can use the models to communicate with one another in a consistent manner. By formalizing the semantics and structures of the models, formal models can be used to perform mathematical analyses and drive simulations used to estimate measures of performance and the effectiveness of the architecture in the face of requirements that drove that architecture’s design.

Architecture models are electronic or paper representations of some aspect of an architecture for some specific audience. Models comprise model elements, which are also architecture elements. Model elements have relationships based on some defined semantics—that is, they are not haphazard assemblies of architecture elements but follow constraints described by a methodology or an accepted set of practices. These semantics may be driven by the laws of nature, existential relationships, human creations, or abstractions. Architecture models are therefore pictorial or other representations that have structure and meaning to specific audiences. The organization of the types of elements and their relationships contained within a model or a set of models is called a metamodel. The metamodel controls what elements and relationships are valid in the context of a model or a set of models. It acts as a rulebook for a modeler.

Models are also blueprints for audiences who understand what they are trying to communicate. Just as a floor plan conveys the layout of various parts of a building to a number of audiences, from the homeowner to the architect to the city inspector, a carefully constructed model that is compliant with conventions and well laid out conveys a wealth of meaning in an unambiguous manner to the right people.

Reference Models

Reference models are taxonomies that are associated with frameworks and usually serve to control vocabularies so that architectures developed by different organizations can be federated or more easily compared. Examples are taxonomies of business functions and standards. At the enterprise level, reference models may stand in for viewpoint views. For example, at the highest enterprise level, the business process view may simply consist of a reference model containing the taxonomy of business functions for the enterprise rather than any detailed view of actual business processes or activities.

Integration

We encounter two problems when we are looking at an architectural description or representation organized into a set of viewpoints and views. We need to ensure that the description provides both a complete and a consistent description of reality or target vision. We also need to ensure that the views are integrated both within and across the viewpoints. That is, we need to know that all the architectural elements needed appear in some view and that these architectural elements appear in all the views and viewpoints where they are appropriate. Each architectural element must be identified by the same name in all the views in which it appears and all of the relevant aspects of the architectural element must be described. The views should not be disjoint. That is, a view should always contain some elements that also appear in or are easily related to elements in other views. Achieving this integration leads us to a topic in the next section: integrated metamodels.

Repositories and Metamodels

Frameworks may provide two additional related structuring and organizing concepts: repositories and metamodels.

Repositories

Frameworks may have explicit or implicit requirements for architecture repositories. These repositories contain information about the architecture elements and views. Some frameworks, such as TOGAF, may require several different types of repositories for different types of architecture components, as described in Chapter 22.

There may be a special view called a dictionary that contains the definitions and other relevant information about all of the terms and architecture elements used in the architecture. The “other relevant information” may include relationships between architecture elements or information about views or elements that does not appear on relevant view diagrams or graphics. This information may be omitted from the view diagrams or graphics because of space and readability considerations, or it may reflect relationships between views or view elements that are only implied by the diagrams or graphics. Formal models often have requirements for what information should be provided about elements of the model. For example, the ICAM Definition for Functional Modeling (IDEF0) has specific requirements about what must be documented.

The need for a repository is implicit, because the difficulty of developing and maintaining a non-trivial architecture without some form of a dictionary and repository management system makes such an approach impractical. Repository concepts are discussed further in Part II.

Metamodels

The organization of the types of elements and their relationships contained within a view or a set of views is called a metamodel. The metamodel controls what elements and relationships are valid in the context of a view or a set of views. It acts as a rulebook for the architect. An integrated metamodel recognizes that all the views are describing different facets of a single reality.

The biggest risk with a large set of viewpoints and views is the risk of defining the same architecture elements differently in different viewpoints and views and thereby creating multiple versions of reality. Without a unifying framework and an integrated metamodel that is defined by the framework, this is a very real risk. The integrated metamodel provides a schema for any dictionary and ensures that if an element appears in more than one architecture representation, it must be defined in the same way. The flaws in nonintegrated architecture representations become very obvious during the analysis and use phase of the architecture, as different analyses of the representation can bring up conflicting answers.

This chapter has discussed the concept of views as architecture representations that have symbols and linkages between symbols. Each of the symbols represents a certain type of architecture element. For example, if the model represents the logical organization of a database as one aspect of the architecture, the symbols on the diagram represent database entity types. The links between the entity type symbols represent the allowable types of relationships between the participating entity types. The collection of symbol types and linkage types allowable in a specific view are considered the metamodel for that type of view. Each formal modeling technique is usually associated with a metamodel, usually defined by a standards body such as American National Standards Institute (ANSI), Federal Information Processing Standards (FIPS), Object Management Group (OMG), or the Institution for Electrical and Electronics Engineers (IEEE), to cite a few examples, or in the mathematical literature. The metamodel is, in effect, the language with which the model speaks to its audience.

As illustrated in later chapters, architecting a complex entity such as an enterprise requires the development of many types of views. Many of these views are formal models developed using their own methodologies and associated metamodels. If the metamodels of the various models are not integrated—that is, are not compatible in their languages—the models developed will be disjointed. Like the reports of the five unsighted men attempting to describe an elephant, the models, when taken together, will not provide a coherent picture of the enterprise. Many frameworks have recognized this issue and resolved metamodel inconsistencies in their collection of views by using an ontological approach to describe how architecture element types are defined as well as the types of relationships they can participate in.

Ontology

Ontology is the study of existence or reality: what kinds of things exist (in our case, types of architectural elements) and the types of relationships between them. Ontology is associated with a domain of discourse. Terms that describe objects that exist are commonly understood within a domain of discourse, although they may have synonyms and antonyms outside that domain of discourse. Architecture frameworks may include an ontology to support their integrated metamodel.

For example, in the domain of discourse of defense architecture descriptions, the Department of Defense Architecture Framework (DoDAF) and Ministry of Defense (United Kingdom) Architecture Framework (MODAF) have established a joint set of standard ontological concepts and relationships, such as activity, performer, and resource flows, that are abstract and can encompass the terms of specific modeling methodologies such as IDEF0. Thus, an IDEF0 mechanism is interpreted as a performer in the ontology, since the mechanism performs/enables an activity. Ontology is used as semantic shorthand in describing large numbers of concrete relationships compactly using a few specifications and enables the integration of metamodels.

Methodologies and Process

Architecture frameworks may include a methodology or process to guide the development and evolution of architecture. A 2012 Office of Management and Budget report defines architecture methodology as “the repeatable process by which architecture documentation will be developed, archived, and used; including the selection of principles, a framework, modeling tools, artifacts, repository, reporting, and auditing.” [OMB 2012] However, the process included with a framework may be a detailed, phased, or step-by-step methodology to developing and evolving architecture, or it may be something simpler. Some frameworks do not supply any process advice. The discussions of the major architecture frameworks in Chapters 4, 21, 22, and 23 provide details of the methodology or process features of these frameworks.

Summary

In this, the first chapter of this book, we introduce concepts of the enterprise and the description of its architecture that we call the enterprise architecture. We have introduced an understanding that the architecture is a basis for planning for change. We have introduced the concept of viewpoints that show different people in the enterprise, different views of the enterprise based on their own motivations, languages, background knowledge, and skill sets. We have also introduced the concept of architecture frameworks to show how diverse architecture descriptions can be normalized through a set of constructs that force commonality of description while preserving the diversity of viewpoints. We have introduced modeling as a fundamental practice in architecting as a way to represent architecture descriptions using pictorial, both structured and unstructured, representations as well as formal methods both to capture an understanding of the architecture as well as to provide a platform for performing analyses.

We want to stress that this book is intended to capture the overall concepts of enterprise architecting that are common to all EA frameworks in much the same way a book on Relational Database Management captures salient features of commercially available vendor products. We stress the commonality of EA concepts, techniques, and procedures.

Questions

1. What is an enterprise? What are the fundamental characteristics of an enterprise? How would you describe the scope of your specific enterprise? Based on the narratives of the levels of architecture scope, which level of scope does your enterprise fall into?

2. What are some methods to reduce the complexity of analyzing a large and complex enterprise?

3. What is enterprise transformation? What are initiatives and projects in the context of enterprise transformation? What is an enterprise transformation roadmap? Why is it useful in guiding the transformation process?

4. A forecast is a prediction of the state of something at a particular point in time. How does the enterprise transformation roadmap align with anticipated business forecasts, technology forecasts? What viewpoints are needed to ensure such an alignment?

5. What is the definition of architecture? Discuss, using your definition, various characteristics of architecture that are related to the quality of an architecture. What are some of the architecture attributes that are needed to understand the context of the architecture such as creation, modification, ownership, duration, cost, and so on?

6. What is an architecture description? Discuss the existence of implicit and explicit architecture representations inside your specific enterprise. What is the usefulness of having explicit architecture descriptions? How can architecture descriptions be kept up to date? Discuss the differences in frequency of change of different types of architecture descriptions.

7. What is the purpose of building or representing the as-is state of an enterprise? How would you justify the building of an as-is architecture description for your own enterprise? What information would you need to build the as-is architecture representation of your enterprise?

8. What is the purpose of building a target or to-be state of an enterprise? How would you go about building a to-be state of your enterprise? Where would you start and what information would you need? How would you address architecting a constantly changing enterprise?

9. What are the viewpoints that are important to your enterprise? What stakeholders’ needs are addressed by those viewpoints? What views within those viewpoints will address the challenges of the stakeholders for that viewpoint?

References

Architecture Working Group (AWG). 1997. “C4ISR Architecture Framework Version 2.0.” www.afcea.org/education/courses/archfwk2.pdf.

CIO Council. 2001. “A Practical Guide to Federal Enterprise Architecture, Version 1.0.” www.gao.gov/assets/590/588407.pdf.

CIO Council. 1999. “Federal Enterprise Architecture Framework, Version 1.1.” www.bettergovernment.jp/diki?files_download&filename=fedarch1.pdf.

Department of Defense. 2007. DoD Architecture Framework Version 1.5. “Volume I: Definitions and Guidelines.” dodcio.defense.gov/Portals/0/Documents/DoDaF/DoDAF_Volume_I.pdf.

Department of Defense. 2007. DoD Architecture Framework Version 1.5. “Volume II: Product Descriptions.” dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_Volume_II.pdf.

Department of Defense. 2007. DoD Architecture Framework Version 1.5. “Volume III: Architecture Data Description.” dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_Volume_III.pdf.

Department of Defense. 2010. “DoD Architecture Framework 2.02—DoD Deputy Chief Information Officer.” http://dodcio.defense.gov/Library/DoD-Architecture-Framework/

FEA Program Office, U.S. Office of Management and Budget. 2007. “FEA Practice Guidance.” www.fsa.usda.gov/Assets/USDA-FSA-Public/usdafiles/SDLC-non-secure/Enterprise-Architecture-Program-/Training/Docs/FEA_Practice_Guidance_Nov_2007.pdf.

Federal Enterprise Architecture Program Management Office. 2007. “FEA Consolidated Reference Model Document Version 2.3.” www.reginfo.gov/public/jsp/Utilities/FEA_CRM_v23_Final_Oct_2007_Revised.pdf.

Federal Segment Architecture Methodology (FSAM), Version 1.0. 2008. http://bettergovernment.jp/resources/FSAMv1.pdf.

Government Accountability Office. 2003. “Information Technology. A Framework for Assessing and Improving Enterprise Architecture Management. Version 1.1.” (GAO-03-584G)

Greefhorst, Danny, and Erik Proper. 2011. Architecture Principles: The Cornerstones of Enterprise Architecture. New York: Springer.

Harrison, Rachel. 2016. TOGAF 9 Foundation Study Guide, 3rd Ed. The Netherlands: Van Haren Publishing.

International Organization for Standardization (ISO). 2000–06. “15704:2000: Industrial automation systems: Requirements for enterprise-reference architectures and methodologies.”

Merriam-Webster Dictionary online. nd. www.merriam-webster.com/dictionary/enterprise.

MIT Center or Information Systems Research (CISR). nd. “Enterprise Architecture.” https://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/.

MODAF—United Kingdom Ministry of Defense Architecture Framework. https://www.gov.uk/guidance/mod-architecture-framework.

National Association of State Chief Information Officers (NASCIO). 2007. “Building Better Government through Enterprise Architecture.” www.nascio.org/Publications/ArtMID/485/ArticleID/218/Building-Better-Government-through-Enterprise-Architecture.

Office of Management and Budget. 2012. “The Common Approach to Federal Enterprise Architecture.” https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/common_approach_to_federal_ea.pdf.

Office of the DoD CIO. Office of the Assistant Secretary of Defense, Networks and Information Integration (OASD/NII). 2010. “Reference Architecture Description. dodcio.defense.gov/Portals/0/Documents/DIEA/Ref_Archi_Description_Final_v1_18Jun10.pdf.

Permanent Subcommittee on Investigations of the Committee on Homeland Security and Governmental Affairs, United States Senate. 2014. “The Air Force’s Expeditionary Combat Support System (ECSS): A Cautionary Tale on the Need for Business Process Reengineering and Complying with Acquisition Best Practices.” www.gpo.gov/fdsys/pkg/CPRT-113SPRT89869/pdf/CPRT-113SPRT89869.pdf.

Spewak, Steven H. 1993. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. New York: Wiley.

The Open Group. 2006. “The Open Group Architecture Framework Version 8.1.1, Enterprise Edition.” pubs.opengroup.org/architecture/togaf8-doc/arch/.

The Open Group. 2009. “TOGAF Version 9: An Open Group Standard.” pubs.opengroup.org/architecture/togaf9-doc/arch/index.html.

Zachman, John A. 2015. “Enterprise Physics 101.” Zachman International blog. www.zachman.com/resources/zblog/item/enterprise-physics-101.