This glossary defines the terms used in the book. Because the scope of this book covers multiple architecture frameworks, the same term appears more than once with the definition that is taken from the appropriate framework. The context citation at the end of each entry contains the context to be used for interpreting the description.

actionable   Architecture analysis and documentation that is used by executives, managers, and staff to support resource planning, decision-making, and management. (Context: Common Approach/FEAF2)

activity

Work, not specific to a single organization, weapon system, or individual, that transforms inputs (resources) into outputs (resources) or changes their state. (Context: DoDAF 2.02)

Work that may comprise an entire business process or a task within a business process. (Context: TOGAF 9)

activity-based costing   Analysis process that determines the costs of a specific business process, including personnel, equipment, and facility costs. (Context: General)

actor   A person, organization, or system whose role initiates or interacts with activities—for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization. In the automotive industry, an original equipment manufacturer would be considered an actor by an automotive dealership that interacts with its supply chain activities. (Context: TOGAF 9)

actor/role matrix   A matrix that shows which specific actors perform which abstract roles, in support of the definition of security and skills requirements. (Context: TOGAF 9)

Actual Resources Structure (Ar-Sr) domain   The analysis (evaluation of different alternatives, what-ifs, trade-offs, verification, and validation) of the actual resource configurations. It illustrates the expected or achieved actual resource configuration. (Context: Unified Architecture Framework)

ADM phase   A phase of the Architecture Development Methodology/Method (ADM); the TOGAF-recommended approach to developing enterprise architectures. (Context: TOGAF 9)

agency   Any executive or military department, bureau, government corporation, government-controlled corporation, independent regulatory agency, or other organization in the Executive Branch of the United States government. (Context: Common Approach/FEAF2)

agency level   A level of architecture that provides an overview of the entire department/agency and consistent, decomposable views of all subagencies/bureaus, business units, programs, systems, networks, and mission or support services. The depth of documentation in any particular area of an agency’s architecture is determined by the need to support planning and decision-making, prioritized in the context of the agency’s strategic goals and business operating plans. Drill-down is accomplished through the completion of segment-, system-, and application-level architectures. (Context: Common Approach/FEAF2)

agreement   A consent among parties regarding the terms and conditions of activities that said parties participate in. (Context: DoDAF 2.02)

airfield   The portion of an airport that contains the facilities necessary for the operation of aircraft. (Context: RMN Airport Case Study)

airport authority   A quasi-governmental public organization responsible for setting the policies governing the management and operation of an airport or system of airports under its jurisdiction. (Context: RMN Airport Case Study)

airport layout plan   A scaled drawing of the existing and planned land and facilities necessary for the operation and development of an airport. (Context: RMN Airport Case Study)

airport master plan   The airport’s concept of the long-term development and use of an airport’s land and facilities. (Context: RMN Airport Case Study)

airport sponsor   The entity that is legally responsible for the management and operation of an airport, including the fulfillment of the requirements of laws and regulations related thereto. (Context: RMN Airport Case Study)

airside   The portion of an airport that contains the facilities necessary for the operation of aircraft. (Context: RMN Airport Case Study)

alignment

Conformance to a policy, standard, and/or goal. (Context: Common Approach/FEAF2)

The enterprise word for “quality.” The definition of quality is “producing products that meet the requirements as defined by the customer.” In enterprise terms, “producing Enterprise implementations (Row 6) that meet the requirements (Row 1/2) as defined by Management.” (Context: Zachman)

All Viewpoint (AV)   Describes the overarching aspects of the architecture context that relate to all DoDAF viewpoints. (Context: DoDAF 2.02)

application

A level of architecture that focuses on the development, update, or integration of one or more software applications that are part of one or more system(s)/service(s) in one or more organization(s). This includes web sites, databases, e-mail, and other mission or support applications. (Context: Common Approach/FEAF2)

A deployed and operational IT system that supports business functions and services—for example, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application. (Context: TOGAF 9)

application and user location diagram   A diagram that shows the geographical distribution of applications that can be used to show where applications are used by the end user; the distribution of where the host application is executed and/or delivered in thin client scenarios; the distribution of where applications are developed, tested, and released; and so on. (Context: TOGAF 9)

application architecture   A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets. (Context: TOGAF 9)

application communication diagram   A diagram that depicts all models and mappings related to communication among applications in the metamodel entity. (Context: TOGAF 9)

Application Communication Diagram (A-2)   The means by which resource flows between applications occur. Equivalent to the DoDAF SV-2: Systems Resource Flow Description and SvcV-2: Services Resource Flow Description. (Context: Common Approach/FEAF2)

application component   An encapsulation of application functionality aligned to implementation structure—for example, a purchase request processing application. (Context: TOGAF 9) See also logical application component and physical application component.

Application Data Exchange Matrix (A-4)   The details of resource flows among systems, the activities performed, the resources exchanged, and the attributes (rules and measures) associated with these exchanges. Similar to the DoDAF SV-6: Systems Resource Flow Matrix and SvcV-6: Services Resource Flow Matrix. (Context: Common Approach/FEAF2)

application/data matrix   Depicts the relationship between applications (application components) and the data entities that are accessed and updated by them. (Context: TOGAF 9)

application/function matrix   Depicts the relationship between applications and business functions within the enterprise. (Context: TOGAF 9)

application interaction matrix   Represents dependencies between two applications. This artifact is identical to the SV-3: Systems-Systems Matrix and serves a similar purpose in analyzing system dependencies. (Context: TOGAF 9)

Application Interface Diagram (A-1)   The identification of application resource flows and their composition. Similar to the DoDAF SV-1: Systems Context Description. (Context: Common Approach/FEAF2)

Application Interface Matrix (A-3)   The interface relationships among systems DoDAF. Equivalent to the DoDAF SvcV-3a: Systems-Services Matrix and SvcV-3b: Services-Services Matrix. (Context: Common Approach/FEAF2)

Application Inventory (A-10)   A registry of applications and services, the system functions, or the service activities they perform, which are optionally prioritized or ranked. (Context: Common Approach/FEAF2)

Application Maintenance Procedure (A-9)   Describes how to modify software to provide error corrections, enhancements of capabilities, deletion of obsolete capabilities, and optimization of behaviors and structures. (Context: Common Approach/FEAF2)

application migration diagram   Identifies application migration from baseline to target application components. It enables a more accurate estimation of migration costs by showing precisely which applications and interfaces need to be mapped between migration stages. (Context: TOGAF 9)

application/organization matrix   Depicts the relationship between applications and organizational units within the enterprise. (Context: TOGAF 9)

Application Performance Matrix (A-6)   A table of measures is associated with an application’s performance. These measures are used as specifications to plan or benchmark an application in terms of desirable properties such as availability and latency of user response to application response. This artifact is equivalent to the DoDAF SV-7: Systems Measures Matrix and SvcV-7: Services Measures Matrix. (Context: Common Approach/FEAF2)

application portfolio catalog   Identifies and maintains a list of all the applications in the enterprise, which helps to define the horizontal scope of change initiatives that may impact particular kinds of applications. An agreed-upon application portfolio enables a standard set of applications to be defined and governed. (Context: TOGAF 9)

application reference model (ARM)   Categorizes the system- and application-related standards and technologies that support the delivery of service capabilities, enabling agencies to share and reuse common solutions and benefit from economies of scale. (Context: Common Approach/FEAF2)

Application Service Matrix (A-5)   Interface relationships between services and applications. Similar to DoDAF SvcV-3a: Systems-Services Matrix and SvcV-3b: Services-Services Matrix. (Context: Common Approach/FEAF2)

application/technology matrix   Documents the mapping of applications to technology platform. This matrix should be aligned with and complement one or more platform decomposition diagrams. (Context: TOGAF 9)

application use-case diagram   Displays the relationships between consumers and providers of application services. Application services are consumed by actors or other application services, and the diagram provides added richness in describing application functionality by illustrating how and when that functionality is used. (Context: TOGAF 9)

Applications subarchitecture domain   In the applications subarchitecture domain of the EA framework asks the following questions: Which systems and applications will be needed to generate, share, and store the data, information, and knowledge that the business services need? How can multiple types of IT systems, services, applications, databases, and web sites be made to work together where needed? How can configuration management help to create a cost-effective and operationally efficient common operating environment (COE) for systems and applications? What are the workforce, standards, and security issues in this subarchitecture view? What are the workforce, standards, and security issues in this domain? (Context: Common Approach/FEAF2)

apron   A specified portion of the airfield used for passenger, cargo, or freight loading and unloading, aircraft parking, and the refueling, maintenance, and servicing of aircraft. (Context: RMN Airport Case Study)

architectural description (AD)

Information describing an architecture. (Context: DoDAF 2.02)

A collection of products to document an architecture. (Context: IEEE Std 1471-2000)

architectural model   A view may comprise one or more architectural models, each of which is developed using the methods established by its associated architectural viewpoint. An architectural model may be included in more than one view. (Context: IEEE Std 1471-2000)

architecture

A systematic approach that organizes and guides design, analysis, planning, and documentation activities. (Context: Common Approach/FEAF2)

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. (Context: IEEE Std 1471-2000 and ISO/IEC 42010:2007)

A formal description of a system, or a detailed plan of the system at component level, to guide its implementation. (Source: ISO/IEC 42010: 2007) (Context: TOGAF 9)

The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. (Context: TOGAF 9)

A structured set of descriptive representations relevant to describing an object and being employed 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. (Context: Zachman)

architecture building blocks   A constituent of the architecture model that describes a single aspect of the overall model. (Context: TOGAF 9)

architecture capability   Defines the parameters, structures, and processes that support governance of the architecture repository. (Context: TOGAF 9)

Architecture Continuum   Part of the Enterprise Continuum, this repository of architectural elements offers increasing detail and specialization. This continuum begins with foundational definitions such as reference models, core strategies, and basic building blocks. From there it spans industry architectures all the way to an organization’s specific architecture. (Context: TOGAF 9)

architecture definition document   A deliverable container for the core architectural artifacts created during a project. It spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, interim state(s), and target). (Context: TOGAF 9)

Architecture Development Method/Methodology (ADM)   The core of TOGAF, this is a step-by-step approach to develop and use an enterprise architecture for developing architectures, which includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures. All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that enables organizations to transform their enterprises in a controlled manner in response to business goals and opportunities. (Context: TOGAF 9)

architecture domain   The architectural area being considered. Within TOGAF, there are four architecture domains: business, data, application, and technology. (Context: TOGAF 9)

architecture framework   A conceptual structure used to develop, implement, and sustain an architecture. (Context: TOGAF 9)

architecture landscape   The architectural representation of assets deployed within the operating enterprise at a particular point in time. The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives. (Context: TOGAF 9)

architecture levels of scope   The Common Approach to Federal Enterprise Architecture (FEA) defines eight levels of scope that describe the span and coverage of the architecture: international, national, federal, sector, agency, segment, system. and application. (Context: Common Approach/FEAF2)

architecture maturity assessment   Determines the level of maturity of the architecture development effort and identifies gaps in scope (depth and breadth) and coverage as well as in the use and dissemination. (Context: TOGAF 9)

architecture metamodel   Describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content. (Context: TOGAF 9)

architecture principles

A specific class of normative principles that direct the design of an enterprise, from the definition of its business to its supporting IT. (Context: General)

A qualitative statement of intent that should be met by the architecture, which has at least a supporting rationale and a measure of importance. (Context: TOGAF 9)

architecture program maturity assessment    A tool developed by the Gartner Group to measure architecture scope and authority, stakeholder involvement, and the architecture definition process of the EA program through surveys. (Context: Gartner)

architecture repository   In support of the Enterprise Continuum, can be used to store different classes of architectural output at different levels of abstraction, created by the Architecture Development Methodology (ADM). In this way, TOGAF facilitates understanding and cooperation between stakeholders and practitioners at different levels. (Context: TOGAF 9)

architecture requirements specification   Provides a set of quantitative statements that outline what an implementation project must do to comply with the architecture. Typically forms a major component of an implementation contract or contract for more detailed architecture definition. (Context: TOGAF 9)

architecture roadmap   Lists individual increments of change and lays them out on a timeline to show progression from the baseline architecture to the target architecture. (Context: TOGAF 9)

architecture segment   A part of the overall EA that documents one or more lines of business, including all levels and threads. (Context: Common Approach/FEAF2)

architecture vision   A succinct description of the target architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development. (Context: TOGAF 9)

artifact

A documentation product, such as a text document, diagram, spreadsheet, briefing slides, or video clip. (Context: Common Approach/FEAF2)

An architectural work product that describes an aspect of the architecture. (Context: TOGAF 9)

A descriptive representation, usually used for engineering design—primitive models in the context of the Zachman Framework. An artifact could be a descriptive formalism for any object including buildings, airplanes, computers, or any Industrial Age products. (Context: Zachman)

as-is architecture   An architecture that represents the current state of the enterprise. Sometimes this is the as-planned architecture that includes any changes that are funded in the current budget. (Context: General)

asset inventory   A list of assets with details about each (installation date, original cost, condition, and such) asset register. (Context: Common Approach/FEAF2)

assumption   A statement of probable fact that has not been fully validated because of external constraints. For example, it may be assumed that an existing application will support a certain set of functional requirements, although those requirements may not yet have been individually validated. (Context: TOGAF 9)

authoritative reference   Like building blueprints, this reference provides an integrated, consistent view of strategic goals, mission and support services, data, and enabling technologies across the entire organization, including programs, services, and systems. When the EA is recognized as the authoritative reference for the design and documentation of systems and services, issues of ownership, management, resourcing, and performance goals can be resolved in a consistent and effective manner. EA also serves as a reference to promote the achievement and maintenance of desired levels of security and trust in an agency’s business and technology operating environment. EA’s contribution to security protection is accomplished through the integrated use of federal methods during process or resource design activities to identify and implement controls to address potential vulnerabilities with users, processes, systems, applications, and networks. (Context: Common Approach/FEAF2)

balanced score card (BSC)   A strategic planning and management system used extensively in business and industry, government, and nonprofit organizations worldwide to align business activities to the vision and strategy of the organization, improve internal and external communications, and monitor organization performance against strategic goals. (Context: Common Approach/FEAF2)

baseline architecture   The set of products that portray the existing enterprise, the current business practices, and the technical infrastructure. Commonly referred to as the as-is architecture. (Context: Common Approach/FEAF2)

benefits diagram   Shows opportunities identified in an architecture definition, classified according to their relative size, benefit, and complexity. Can be used by stakeholders to make selection, prioritization, and sequencing decisions on identified opportunities. (Context: TOGAF 9)

building block   Represents a (potentially reusable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to architectures or solutions. (Context: TOGAF 9)

business architecture   A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs. (Context: TOGAF 9)

business capability assessment   Identifies baseline capabilities, capability gaps, and future capability needs from a business perspective. (Context: TOGAF 9)

business case   A collection of descriptive and analytic information about an investment in resource(s) and/or capabilities. (Context: Common Approach/FEAF2)

business case/alternatives analysis (B-6)   A summary of the planning, budgeting, acquisition, and management of federal capital assets sufficient to determine whether investment funding should be recommended or continued. Equivalent to OMB Exhibit 300: Capital Asset Plan and Business Case Summary. (Context: Common Approach/FEAF2)

business case analysis   Analysis process or resulting report that provides the business case for a specific proposed investment or project; exact format may vary by business organization. (Context: Common Approach/FEAF2)

business concepts   The set of Row 2 models of the Zachman Framework that constitute management’s perceptions of the design and operation of the enterprise. (Context: Zachman)

business footprint diagram   Describes the links between business goals, organizational units, business functions, and services, and maps these functions to the technical components delivering the required capability. (Context: TOGAF 9)

business function   Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. (Context: TOGAF 9)

business interaction matrix   Depicts the relationship interactions between organizations and business functions across the enterprise. (Context: TOGAF 9)

business model   Answers the question, “In what ways do we plan to make money or achieve the reasons why our enterprise is in existence?” (Context: General)

business operating model   The combination of roles, skills, structures, processes, assets, and technologies that an organization uses to deliver products and services to its customers. (Context: General)

business operating plan (B-2)   Describes, from a timeline perspective, the changes to the business service catalog, organizational chart, and business process model to transition from the current state to the objective state. Similar to DoDAF PV-2: Project Timelines, Business Transition Plan. (Context: Common Approach/FEAF2)

business problem statement   The conglomeration of key elements into one expression to convey the issue at hand. After the business has decided a problem is worth pursuing in its analysis, the business analyst creates a problem statement. (Context: General)

business process diagram (B-1)   Presents the hierarchical structure of organizational activities and activities performed by organizational performers to consume and produce resources DoDAF OV-5a: Operational Activity Decomposition Tree, Operational Activity Diagram, and OV-5b: Operational Activity Decomposition Model, Business Process Model. (Context: Common Approach/FEAF2)

Business Process Modeling Notation (BPMN)   A graphical notation that depicts the steps and the end-to-end flow of a business process. Processes can be coordinated from behind, within, and over organizations natural boundaries. (Context: BPMN Organization)

business process reengineering (BPR)   A business management strategy originally pioneered in the early 1990s that focuses on the analysis and design of workflows and business processes within an organization. BPR aims to help organizations fundamentally rethink how they do their work to improve customer service, cut operational costs, and become world-class competitors. (Context: General)

business reference model (BRM)   A classification taxonomy used to describe the type of business functions and services that are performed in the federal government. By describing the government using standard business functions rather than an organizational view, the BRM promotes cross-government collaboration. (Context: Common Approach/FEAF2)

business service   Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization. (Context: TOGAF 9)

business service catalog (B-3)   Presents the business services, taken from the BRM, that are provided within the scope of the architecture, and may also indicate business services that are consumed or used internally within the architecture. Included in DoDAF SvcV-1: Services Context Description. (Context: Common Approach/FEAF2)

business service/function catalog   Provides a functional decomposition in a form that can be filtered, reported on, and queried as a supplement to graphical functional decomposition diagrams. (Context: TOGAF 9)

business service/information diagram   Shows the information needed to support one or more business services, shows what data is consumed by or produced by a business service, may also show the source of information. (Context: TOGAF 9)

Business subarchitecture domain   Represents elements of the operating model for the enterprise, such as the key business units or organizational players, key locations, key business processes, and the mission and support services used within a business unit and between business units. Corresponds to the Operational Viewpoint in the DoDAF. Provides answers for the following questions: What is the business plan (operating plan)? How does this relate to the strategic plan’s goals and metrics? What are the business units (usually depicted in the organization chart)? What are the mission and support services within and between the business units? How do we measure the effectiveness and efficiency of the line of business processes (input/output measures) and their contribution to strategic goals (outcome measures)? Do any of these business services or manufacturing processes need to be reengineered/improved before they are made to be part of the future architecture? (Context: Common Approach/FEAF2)

business transformation capability assessment   Determines the capabilities needed as well as the readiness of the enterprise in undertaking transformations. (Context: TOGAF 9)

business use case diagram   Displays the relationships between consumers and providers of business services, which are consumed by actors or other business services. The diagram provides added richness in describing business capability by illustrating how and when that capability is used. (Context: TOGAF 9)

cable plant diagram (I-5)   Diagrams the wires and connectors used to tie a network together. (Context: Common Approach/FEAF2)

capability

The ability to achieve a desired effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities. (Context: DoDAF 2.02)

A business-focused outcome that is delivered by the completion of one or more work packages. Using a capability-based planning approach, change activities can be sequenced and grouped to provide continuous and incremental business value. (Context: TOGAF 9)

The ability to perform a desired business function that creates business value. (Context: TOGAF 9)

An ability that an organization, person, or system possesses, typically expressed in general and high-level terms and typically requiring a combination of organization, people, processes, and technology to achieve—for example, marketing, customer contact, or outbound telemarketing. (Context: TOGAF 9)

capability architecture   A highly detailed description of the architectural approach to realize a particular solution or solution aspect. (Context: TOGAF 9)

capability assessment   An articulation of baseline and target capability levels of the enterprise on several levels, which is created before embarking upon a detailed architecture definition. (Context: TOGAF 9)

capability configuration   A collection of systems or services that, together with operational processes and human and other organizational resources, delivers a capability. (Context: MODAF)

Capability Dependencies (CV-4)   The dependencies between planned capabilities and the definition of logical groupings of capabilities. (Context: DoDAF 2.02)

capability increment   A discrete portion of a capability architecture that delivers specific value. When all increments have been completed, the capability has been realized. (Context: TOGAF 9)

Capability Phasing (CV-3)   The planned achievement of capability at different points in time or during specific periods of time. The CV-3 shows the capability phasing in terms of the activities, conditions, desired effects, rules complied with, resource consumption and production, and measures, without regard to the performer and location solutions. (Context: DoDAF 2.02)

capability roadmap   Alternative name for the Capability Phasing view. (Context: DoDAF 2.02)

Capability Taxonomy (CV-2)   Used to decompose a complex capability need into smaller granularity, simpler capability needs that can then be mapped to a capability development timeline. (Context: DoDAF 2.02)

Capability to Operational Activities Mapping (CV-6)   Establishes mappings between a capability configuration and the set of operational activities (business processes) that will harness the capability. (Context: DoDAF 2.02)

Capability to Organizational Development Mapping (CV-5)   The fulfillment of capability requirements shows the planned capability deployment and interconnection for a particular capability phase. The CV-5 shows the planned solution for the phase in terms of performers and locations and their associated concepts. (Context: DoDAF 2.02)

Capability to Services Mapping (CV-7)   Provides traceability of service-based solutions back to the capabilities they implement. (Context: DoDAF 2.02)

Capability Viewpoint (CV)   Articulates the capability requirements, the delivery timing, and the deployed capability. (Context: DoDAF 2.02)

capital improvement plan   In the RMN Airport Case Study, the airport sponsor’s plan for the capital needs of the airport, typically including its planned capital funding sources. This is separate and distinct from the FAA’s Airports Capital Improvement Plan (ACIP), which indicates how to allocate AIP funds. (Context: RMN Airport Case Study)

capital planning and investment control (CPIC)   Also known as capital programming. A decision-making process for ensuring IT investments integrate strategic planning, budgeting, procurement, and the management of IT in support of agency missions and business needs. The term comes from the Clinger-Cohen Act of 1996 and generally is used in relationship to IT management issues. CPIC includes a management process for ongoing identification, selection, control, and evaluation of investments in IT. The CPIC process links budget formulation and execution, and is focused on agency missions and achieving specific program outcomes. (Context: Common Approach/FEAF2)

catalog   A list of building blocks of a specific type, or of related types, that is used for governance or reference purposes (for example, an organization chart, showing locations and actors). As with building blocks, catalogs carry metadata according to the metamodel, which supports query and analysis. (Context: TOGAF 9)

cell   According to the Zachman Framework, the intersection between two classifications that have been used by humanity for thousands of years, the six primitive interrogatives, and the six stages of transformation of reification. The cell is one category, one classification of facts relevant to the existence of the enterprise. Each cell is a single-variable—that is, it contains only one and only one type of enterprise component and the relationships with all other components of the same type in the enterprise. (Context: Zachman)

change management   The process of setting expectations and involving stakeholders in how a process or activity will be changed, so that the stakeholders have some control over the change and therefore may be more accepting of the change. (Context: Common Approach/FEAF2)

chief architect   The leader and manager of the enterprise architecture effort, who reports to the CIO. (Context: TOGAF 9)

chief information officer (CIO)   Also known as the chief digital information officer (CDIO) or information technology (IT) director. A job title commonly given to the most senior executive in an enterprise responsible for the IT and computer systems that support enterprise goals. (Context: General)

Chief Information Officers Council (CIO Council)   The principal interagency forum for improving practices in the design, modernization, use, sharing, and performance of federal government agency information resources; established in the E-Government Act of 2002. (Context: Common Approach/FEAF2)

chief technology officer (CTO)   Sometimes known as a chief technical officer. An executive-level position in a company or other entity whose occupation is focused on scientific and technological issues within the organization. (Context: General)

Collaborative Planning Methodology (CPM)   A simple, repeatable process that consists of integrated, multidisciplinary analysis that results in recommendations formed in collaboration with leaders, stakeholders, planners, and implementers. (Context: Common Approach/FEAF2)

commercial-off-the-shelf (COTS)   Commercially available technology that can be purchased and utilized directly without modifications. (Context: General)

Common Approach   The Common Approach to Federal Enterprise Architecture accelerates agency business transformation and new technology enablement by providing standardization, design principles, scalability, an enterprise roadmap, and a repeatable architecture project method that is more agile and useful and will produce more authoritative information for intra- and interagency planning, decision-making, and management. (Context: Common Approach/FEAF2)

common operating picture (COP)   A single identical display of relevant (operational) information (such as position of own troops and enemy troops, position and status of important infrastructure such as bridges, roads, and so on) shared by more than one command. (Context: General)

communications engineering diagram   Describes the means of communication—the method of sending and receiving information—between assets in the technology architecture, insofar as the selection of package solutions in the preceding architectures put specific requirements on the communications between the applications. (Context: TOGAF 9)

community of interest (COI)   A gathering (potentially virtual) of people assembled around a topic of common interest. (Context: General)

community of practice (COP)   A group of people who share a craft or a profession. (Context: General)

complex systems   Any system featuring a large number of interacting components (agents, processes, and so on), whose aggregate activity is nonlinear (not derivable from the summations of the activity of individual components) and typically exhibits hierarchical self-organization under selective pressures. (Context: Indiana University)

complicated systems   A system comprising many components that may interact with each other and that are related not only to the scale of the problem, but also to increased requirements around coordination or specialized expertise. Even though complicated systems have many moving parts, their output or outcome can be calculated and predicted with success. (Context: General)

component   In the Zachman Framework, one member of a set of components that constitute a primitive model, a single cell. (Context: Zachman)

composite

An artifact that uses several documentation modeling techniques and/or represents several types of EA components. (Context: Common Approach/FEAF2)

A descriptive representation (model) comprising different types of components from at least two different primitive cells of the Zachman Framework. Used for manufacturing, implementations. Any implementation must, by definition, be a composite, multivariable model. (Context: Zachman)

concept of operations (CONOPS) scenarios (S-3)   A document that organizes business process sequences into scenarios. Similar to DoDAF OV-6c: Event-Trace Description. (Context: Common Approach/FEAF2)

concept overview diagram (S-1)   The high-level graphical/textual description of the operational concept. Similar to DoDAF OV-1: High-Level Operational Concept Graphic. (Context: Common Approach/FEAF2)

conceptual data diagram   Developed to address the concerns of business stakeholders, it depicts the relationships between critical data entities within the enterprise. (Context: TOGAF 9)

Conceptual Data Model (DIV-1)   The required high-level data concepts and their relationships. (Context: DoDAF 2.02)

concerns

The key interests that are crucially important to the stakeholders in a system and that determine the acceptability of the system. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability. (Context: TOGAF 9)

Interests that pertain to the system’s development, its operation, or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability. (Context: IEEE Std 1471-2000)

condition   The state of an environment or a situation in which a performer performs. (Context: DoDAF 2.02)

configuration control board (CCB)   Also known as a configuration management board. A group that should play an essential role in an organization’s overall EA strategy. Typically chaired by the CIO, it usually includes voting representatives from every department in the company. (Context: General)

configuration management (CM)

The process of managing updates to business and technology resources (such as processes, systems, applications, and networks) to ensure that security controls are operating effectively and that standards are being followed. (Context: Common Approach/FEAF2)

A systems engineering process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its lifetime. Applied to architecture, the process of keeping the artifacts up to date to reflect a given state of the enterprise architecture. (Context: General)

connection   A route of path over which some enterprise inventory is transported from location to location. (Context: Zachman)

connectivity view type (Cn)   Describes the connections, relationships, and interactions between the different elements. (Context: Unified Architecture Framework)

Consolidated Reference Model (CRM)   Part of the Federal Enterprise Architecture Framework (FEAF), it equips Office of Management and Budget and federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated reference models designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of federal agency operations in a common and consistent way. Through the use of the FEAF and its vocabulary, IT portfolios can be better managed and leveraged across the federal government, enhancing collaboration and ultimately transforming the federal government. (Context: Common Approach/FEAF2)

constraint   An external factor that prevents an organization from pursuing particular approaches to meet its goals. For example, if customer data is not harmonized within the organization, regionally or nationally, it constrains the organization’s ability to offer effective customer service. (Context: TOGAF 9)

constraints view type (Ct)   Details the measurements that set performance requirements constraining capabilities. Also defines the rules governing behavior and structure. (Context: Unified Architecture Framework)

continuity of operations plan (SP-6)   A plan that describes all aspects of recovery from an incident that temporarily disables the operational capabilities of the enterprise and requires relocation. (Context: Common Approach/FEAF2)

continuous monitoring plan (SP-4)   Describes the organization’s process of monitoring and analyzing the security controls and reporting on their effectiveness. (Context: Common Approach/FEAF2)

contract   An agreement between a service consumer and a service provider that establishes functional and nonfunctional parameters for interaction. (Context: TOGAF 9)

contract/measure catalog   Provides a list of all agreed-upon service contracts and (optionally) the measures attached to those contracts. It forms the master list of service levels agreed to across the enterprise. (Context: TOGAF 9)

control   A decision-making step with accompanying decision logic used to determine execution approach for a process or to ensure that a process complies with governance criteria—for example, a sign-off control on a purchase request processing process that checks whether the total value of the request is within the sign-off limits of the requester, or whether it needs escalating to higher authority. (Context: TOGAF 9)

core views   The DoDAF views that are recommended by the authors for Enterprise Level, Segment Level, and Solution Level architectures. (Context: General)

crosscutting segment   Serves several lines of business within or between agencies. Examples include e-mail systems that serve the whole enterprise and financial systems that serve several lines of business. (Context: Common Approach/FEAF2)

CRUD matrix (D-6)   Create, Read, Update or Delete. Presents resources that are consumed and produced by activities performed by organizational performers. Similar to DoDAF OV-3: Operational Resource Flow Matrix, Business Data Mapped to Key Business Processes (CRUD). (Context: Common Approach/FEAF2)

culture   The beliefs, customs, values, structure, normative rules, and material traits of a social organization. Evident in many aspects of how an organization functions. (Context: Common Approach/FEAF2)

current view   A collection of artifacts that represent processes and technologies that currently exist in the enterprise. (Context: Common Approach/FEAF2)

data

Refers to an elementary description of things, events, activities, and transactions that are recorded, classified, and stored, but not organized to convey any specific meaning. Data items can be numeric, alphabetic, figures, sounds, or images. A database consists of stored data items organized for retrieval. (Context: Common Approach/FEAF2)

Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. (Context: DoDAF 2.02)

Data and Information Viewpoint (DIV)   Articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services. (Context: DoDAF 2.02)

data architecture   A description of the structure and interaction of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources. (Context: TOGAF 9)

data center/server room diagram (I-8)   Diagrams the layout and contents of a data center or server room. (Context: Common Approach/FEAF2)

data dictionary (D-9)   A centralized repository of information about data such as name, type, range of values, source, and authorization for access for each data element in the organization’s files and databases. (Context: Common Approach/FEAF2)

data dissemination diagram   Shows the relationships between data entities, business services, and application components; shows how the logical entities are to be physically realized by application components. This enables effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. (Context: TOGAF 9)

data entity   An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations. (Context: TOGAF 9)

data entity/business function matrix   Depicts the relationship between data entities and business functions within the enterprise. Business functions are supported by business services with explicitly defined boundaries and will be supported and realized by business processes. (Context: TOGAF 9)

data entity/data component catalog   Identifies and maintains a list of all the data use across the enterprise, including data entities and also the data components where data entities are stored. Supports the definition and application of information management and data governance policies and also encourages effective data sharing and reuse. (Context: TOGAF 9)

data flow diagram (D-4)   The functions (activities) performed by systems or services, their hierarchical structure, and their resource flows. Similar to DoDAF SV-4: Systems Functionality Description and SvcV-4: Services Functionality Description. (Context: Common Approach/FEAF2)

data life cycle diagram   An essential part of managing business data throughout its life cycle from conception until disposal within the constraints of the business process. The data is considered as an entity in its own right, decoupled from business process and activity. Each change in state is represented on the diagram, which may include the event or rules that trigger that change in state. The separation of data from process enables common data requirements to be identified, which enables resource sharing to be achieved more effectively. (Context: TOGAF 9)

data migration diagram   Shows the flow of data from the source to the target applications, provides a visual representation of the spread of sources/targets, and serves as a tool for data auditing and establishing traceability. This diagram can be elaborated or enhanced as necessary. For example, the diagram can contain an overall layout of migration landscape or could go into the individual application metadata element–level of detail. (Context: TOGAF 9)

data model   An abstract model that organizes elements of data and standardizes how they relate to one another and to properties of the real world entities. (Context: General)

data quality plan (D-3)   A systematic approach to data quality assurance. (Context: Common Approach/FEAF2)

data reference model (DRM)   One of six reference models of the Federal Enterprise Architecture (FEA) version 2.0, DRM is a classification taxonomy used to describe the context for information exchanges and the type of data entities and attributes in a particular solution architecture at the system, segment, agency, sector, federal, national, or international level. (Context: Common Approach/FEAF2)

data security diagram   Depicts which actor (person, organization, or system) can access which enterprise data. This relationship can be shown in a matrix form between two objects or can be shown as a mapping. Data is considered an asset to the enterprise and data security ensures that enterprise data is not compromised and that access to it is suitably controlled. (Context: TOGAF 9)

Data subarchitecture domain   After the lines of business and specific business services have been identified, it is important to ask the following: What are the flows of information that will be required within and between service areas in order to make them successful? How can these flows of information be harmonized, standardized, and protected to promote sharing that is efficient, accurate, and secure? How will the data underlying the information flows be formatted, generated, shared, and stored? What are the workforce, standards, and security issues in this domain? (Context: Common Approach/FEAF2)

Defense Architecture Framework (DAF), Australia   A DoDAF-related defense architecture framework in Australia. (Context: General)

Defense Discovery Metadata Specification (DDMS)   Created in support of the DoD Net-Centric Data Strategy (May 9, 2003), which specifies a set of information fields that are to be used to describe any data or service asset that is made known to the DoD enterprise. The elements in the DDMS are designed to be platform-, language-, and implementation-independent, and the specification is described with an XML schema. (Context: General)

deliverable   An architectural work product that is contractually specified and in turn formally reviewed, agreed upon, and signed off by the stakeholders. Deliverables represent the output of projects, and deliverables in documentation form will typically be archived at completion of a project, or transitioned into an architecture repository as a reference model, standard, or snapshot of the architecture landscape. (Context: TOGAF 9)

Department of National Defense Architecture Framework (DNDAF), Canada   Department of National Defense/Canadian Armed Forces architecture framework started with the DoDAF that has extended it to include security-related issues. (Context: General)

desired effect   A desired state of a resource. (Context: DoDAF 2.02)

diagram   A rendering of architectural content in a graphical format that enables stakeholders to retrieve the required information. Can also be used as a technique for graphically populating architecture content or for checking the completeness of information that has been collected. TOGAF defines a set of architecture diagrams to be created (such as an organization chart). Each may be created several times for an architecture with different styles or content coverage to suit stakeholder concerns. (Context: TOGAF 9)

dictionary   See Integrated Dictionary (AV-2). (Context: Unified Architecture Framework)

disaster recovery plan (SP-5)   A plan that describes all aspects of recovery from an incident that temporarily disables the operational capabilities of the enterprise but does not entail relocation. (Context: Common Approach/FEAF2)

distribution networks   The Column 3 models of the Zachman Framework descriptive of the locations from which and to which the enterprise acquires, stores, and disposes of its various inventories. At Row 6, the locations and connections instances will have latitudes and longitudes. (Context: Zachman)

DoD Architecture Framework (DoDAF)   An architecture framework developed by the U.S. Department of Defense that serves as the basis for many other defense frameworks. DoDAF Version 2.0 is the overarching, comprehensive framework and conceptual model that enables the development of architectures to facilitate the ability of DoD managers at all levels to make key decisions more effectively through organized information sharing across the department, Joint Capability Areas (JCAs), and mission, component, and program boundaries. (Context: DoDAF 2.02)

DoD Architecture Registry System (DARS)   A DoD repository for Overview and Summary Information (AV-1) documents. (Context: DoDAF 2.02)

DoD Core Data Center reference architecture   Defines the DoD cloud architecture as a reference model to deploy military applications to support net-centric operations. (Context: DIEA)

DoD Joint Capabilities Integration and Development System (JCIDS)   A U.S. DoD business process to identify capability needs across the military services, prioritize and aggregate these needs, and sponsor the development of military capabilities in support of joint operations. (Context: General)

DoD Joint Information Enterprise reference architecture   An overarching view of how DoD information, IT, and cyber environment will be transformed for the future through a collection of a vision, reference architectures, and ways forward. (Context: DIEA)

DoDAF Metamodel (DM2)   Defines all the types of DoDAF architecture elements and their intended relationships. (Context: DoDAF 2.02)

DoDAF viewpoints   To assist decision-makers, DoDAF provides the means of abstracting essential information from the underlying complexity and presenting it in a way that maintains coherence and consistency. One of the principal objectives is to present this information in a way that is understandable to the many stakeholder communities involved in developing, delivering, and sustaining capabilities in support of the stakeholder’s mission. It does so by dividing the problem space into manageable pieces, according to the stakeholder’s viewpoint, further defined as DoDAF-described models. (Context: DoDAF 2.02)

DoDAF views   Specific representations of the architecture contained as a subset within a viewpoint that provides communication and analytical value to stakeholders whose concerns are addressed by a particular view. (Context: General)

DOTMLPF   An acronym that stands for Doctrine, Organization, Training, Materiel, Leadership, Personnel, and Facility, sometimes with a suffix -P signifying Policy. These are used as elements for military planning, equipping, and organizing resources. (Context: DoDAF 2.02)

driver   An external or internal condition that motivates the organization to define its goals. An example of an external driver is a change in regulation or compliance rules that require changes to the way an organization operates (such as Sarbanes-Oxley). (Context: TOGAF 9)

driver/goal/objective catalog   Provides a cross-organizational reference of how an organization meets its drivers in practical terms through goals, objectives, and (optionally) measures. (Context: TOGAF 9)

EA basic program elements   Eight basic elements must be present and be designed to work together in each agency EA program: governance, principles, method, tools, standards, use, reporting, and audit. These elements ensure that agency EA programs are complete and can be effective in developing solutions that support planning and decision-making. (Context: Common Approach/FEAF2)

EA governance   The first basic (Program EA Basic) element that identifies the planning, decision-making, and oversight processes and groups that will determine how the EA is developed, verified, versioned, used, and sustained over time with respect to measures of completeness, consistency, coherence, and accuracy from the perspectives of all stakeholders. (Context: Common Approach/FEAF2)

EA principles   Provide a basis for decision-making throughout an enterprise and inform how the organization sets about fulfilling its mission. Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems. (Context: TOGAF 9)

EA program office   An organization with a charter, budget, and mission to provide enterprise architecting services to the enterprise. Can be run as a project or as a standing organization. (Context: General)

electronic government   The use by the federal government of Internet applications and other information technologies, combined with processes that implement these technologies, to enhance the access to and delivery of government information and services to the public, other agencies, and other government entities; or to bring about improvements in government operations that may include effectiveness, efficiency, service quality, or transformation. (Context: Common Approach/FEAF2)

end   A goal or objective that is significant for motivating the design or operation of the enterprise. (Context: Zachman)

enterprise

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). (Context: CIO Council 1999)

An area of common activity and goals within an organization or between several organizations, where information and other resources are exchanged. (Context: Common Approach/FEAF2)

A complex, (adaptive) sociotechnical system that comprises interdependent resources of people, processes, information, and technology that must interact with each other and their environment in support of a common mission. (Context: Ronald Giachetti, Design of Enterprise Systems: Theory, Architecture, and Methods, CRC Press, 2010)

One or more organizations sharing a definite mission, goals, and objectives to offer an output such as a product or service. (Context: ISO 2000)

An entity that is tightly bounded and directed by a single executive function, or 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. (Context: MODAF 2004)

A purposeful combination (such as a network) of interdependent resources (such as people, processes, organizations, supporting technologies, and funding) that interact with each other to coordinate functions, share information, allocate funding, create workflows, and make decisions; and their environment(s) to achieve business and operational goals through a complex web of interactions distributed across geography and time. (Context: Rebovich and White, Enterprise Systems Engineering: Advances in the Theory and Practice, CRC Press, 2010)

A collection of organizations that has a common set of goals. Or the highest level (typically) of description of an organization that typically covers all missions and functions. An enterprise will often span multiple organizations. (Context: TOGAF 9)

enterprise architecture

A strategic information asset base that defines the mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to changing mission needs. It includes a baseline architecture, a target architecture, and a sequencing plan. (Context: Common Approach/FEAF2)

A structured set of descriptive representations relevant for describing an enterprise and being employed such that an instance of the enterprise can be created and such that the descriptive representations serve as a baseline for changing the instantiated enterprise. (Context: Zachman)

enterprise architecture executive steering committee (EAESC)   A committee of business and executive managers that make the key decisions regarding the enterprise architecture. This group can act as the configuration control board (CCB) for the enterprise architecture. (Context: TOGAF 9)

Enterprise Continuum   A categorization mechanism useful for classifying architecture and solution artifacts, both internal and external to the architecture repository, as they evolve from generic foundation architectures to organization-specific architectures. (Context: TOGAF 9)

enterprise diagnosis   The process of analyzing enterprise problems to determine their “root” causes based on the enterprise ontology (the Zachman Framework) to prescribe enduring solutions as opposed to putting “band aids” on symptomatic anomalies by trial and error or gut feel. (Context: Zachman)

enterprise engineering   The process of creating the single-variable, “primitive” descriptive representations of an enterprise such that they can be used (reused) in producing enterprise implementation “composites” such that the enterprise can be integrated, flexible, interoperable, reusable, aligned, and so on, to accommodate extreme complexity and extreme rates of change. (Context: Zachman)

Enterprise Level architecture   An enterprise architecture focused on the executive management-level concerns such as strategy, acquisition, planning, and projects. (Context: Common Approach/FEAF2)

enterprise manageability diagram   Shows how one or more applications interact with application and technology components that support operational management of a solution. (Context: TOGAF 9)

enterprise manufacturing   The process of creating enterprise implementations, systems, manual or automated, “composites.” If components of “primitive” models are employed in the process of creating the implementation composites, the enterprise will be architected. If components of primitive models are not used in creating the implementation “composites,” the enterprise will be implemented, but not architected. (Context: Zachman)

enterprise resource planning (ERP)   A process by which a company (often a manufacturer) manages and integrates the important parts of its business. An ERP management information system integrates areas such as planning, purchasing, inventory, sales, marketing, finance, and human resources. (Context: Investopedia)

enterprise roadmap   A document produced at least annually by the organization responsible for the enterprise (usually a federal agency) that describes the current and future views of the enterprise-wide architecture, how changes occur, and how the EA program functions. (Context: Common Approach/FEAF2)

enterprise service bus diagram (A-8)   Describes the interaction and communication between mutually interacting software applications in service-oriented architecture (SOA). (Context: Common Approach/FEAF2)

enterprise systems engineering (ESE)   The application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise. To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at as a system, rather than as a collection of functions connected solely by information systems and shared facilities. Although a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers. (Context: Systems Engineering)

Enterprise Transition Plan (ETP)   A roadmap for the DoD business systems that are new or being modernized, and the governance and strategic framework DoD uses to manage its investments. It describes how those investments are part of the department’s overarching management reform efforts, outlines key improvement initiatives for the current fiscal year, and provides specific information regarding each of its business system investments. The ETP is now incorporated into functional strategies, component organizational execution plans, and data in the DoD Information Technology Portfolio Repository (DITPR), Select and Native Programming Data Input Systems for Information Technology (SNaP-IT), Integrated Business Framework Data Alignment Portal (IBF-DAP), and the DoD Information Technology Investment Portal (DITIP). (Context: DoD Change Management Office)

entity   A collection of like objects that have identical characteristics but are unique individuals. For example, apples have identical characteristics but each member of the set of apples is a unique individual. There could never be an entity called “apples” that is made up of apples and oranges because apples have completely different characteristics than do oranges. (Context: Zachman)

environmental impact assessment   A document required of federal agencies by the National Environmental Policy Act for major projects or legislative proposals affecting the environment. It is a tool for decision-making describing the positive and negative effects of a proposed action and citing alternative actions. (Context: FAA AMP)

environments and locations diagram   Depicts which locations host which applications, identifies what technologies and/or applications are used at which locations, and identifies the locations from which business users typically interact with the applications. (Context: TOGAF 9)

event

An organizational state change that triggers processing events. It may originate from inside or outside the organization and may be resolved inside or outside the organization. (Context: TOGAF 9)

Something that happens at a given place and time; in architecture, a discrete event that causes some action to take place such as an information exchange or a change in state. (Context: General)

event diagram   Depicts the relationship between events and process. (Context: TOGAF 9)

event sequence diagram (D-8)   A sequence of triggering events associated with resource flows and systems. Similar to DoDAF SV-10c: Systems Event-Trace Description and SvcV-10c: Services Event-Trace Description. (Context: Common Approach/FEAF2)

Event-Trace Description (OV-6c)   One of three views used to describe activity (operational activity). It traces actions in a scenario or sequence of events. (Context: DoDAF 2.02)

executive agency   The agency defined in section 4(1) of the Office of Federal Procurement Policy Act (41 U.S.C. 403(1)). (Context: Common Approach/FEAF2)

explicit knowledge   Knowledge that can be written down or incorporated in computer codes. (Context: Systems Engineering)

extended enterprise   A wider organization representing all associated entities—customers, employees, suppliers, distributors, and so on—who directly or indirectly, formally or informally, collaborate in the design, development, production, and delivery of a product (or service) to the end user. (Context: www.businessdictionary.com)

facility blueprints (I-12)   Technical drawings of the facility. (Context: Common Approach/FEAF2)

Family of Systems (FoS)   A set of separate systems that can be integrated in different ways to provide a variety of mission-related capabilities. (Context: Systems Engineering)

federal   This level of architecture focuses on services (and associated systems) that serve the entire Executive Branch of the U.S. government. These federal-wide mission and support services are channeled through OMB-designated “Line of Business” providers, wherein the roles of provider and consumer are detailed and a comprehensive business model for each federal-wide service generates requirements for that architecture. (Context: Common Approach/FEAF2)

Federal Aviation Administration (FAA)   A national authority with powers to regulate all aspects of civil aviation in the United States. These include the construction and operation of airports, air traffic management, the certification of personnel and aircraft, and the protection of U.S. assets during the launch or reentry of commercial space vehicles. (Context: General)

Federal Enterprise Architecture (FEA)   A business-based documentation and analysis framework for government-wide improvement that enables agencies to use standardized methods to describe the relationship between an agency’s strategic goals, business functions, and enabling technologies at various levels of scope and complexity. The FEA comprises a framework for documentation in six domain areas (strategic goals, business services, data and information, systems and applications, infrastructure, and security) and six reference models areas that are designed to facilitate standardized analysis, reporting, and the identification of duplicative investments, gaps, and opportunities for collaboration within and across federal agencies. The FEA method is based on a five-step repeatable method for solution architecture that can be used at various levels of scope and provides current views, future views, and a transition (sequencing) plan. (Context: Common Approach/FEAF2)

Federal Enterprise Architecture Framework (FEAF) v2   Describes a suite of tools to help government planners implement the Common Approach. At its core is the consolidated reference model (CRM) that equips OMB and federal agencies with a common language and framework to describe and analyze investments. (Context: Common Approach/FEAF2)

Federal Information Security Management Act (FISMA)   U.S. legislation that defines a comprehensive framework to protect government information, operations, and assets against natural or manmade threats. FISMA was signed into law part of the Electronic Government Act of 2002. (Context: General)

Federal Information Technology Acquisition Reform Act (FITARA)   Passed by Congress in December 2014, a historic law that represents the first major overhaul of federal IT in almost 20 years. (Context: General)

Federal IT Dashboard   A web site enabling federal agencies, industry, the general public, and other stakeholders to view details including performance for federal information technology investments. (Context: Common Approach/FEAF2)

federated architecture (FA)   A pattern in enterprise architecture that enables interoperability and information sharing between semiautonomous, decentrally organized lines of business, information technology systems, and applications. (Context: General)

Fit-for-Purpose (FFP) views   Customized views included in DoDAF architectures for the purpose of documenting issues not addressed by standardized DoDAF views or communicating with specific stakeholder groups; must be integrated with some set of standard DoDAF views. (Context: DoDAF 2.02)

foundation architecture   Generic building blocks and their interrelationships with other building blocks, combined with the principles and guidelines that provide a foundation on which more specific architectures can be built. (Context: TOGAF 9)

framework

A structure for organizing information that defines the scope of the architecture (what will be documented) and how the areas of the architecture are related. (Context: Common Approach/FEAF2)

A conceptual framework, or frame of reference, for architectural description, that establishes terms and concepts pertaining to the content and use of architectural descriptions. (Context: IEEE Std 1471-2000)

A structure for content or process that can be used as a tool to structure thinking, ensure consistency, and ensure completeness. (Context: TOGAF 9)

A structure, a classification, that is typically misapplied as something generic, abstract, or of imprecise definition rather than a structure. (Context: Zachman)

function   Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as business function. (Context: TOGAF 9)

functional decomposition diagram   Shows on a single page the capabilities of an organization that are relevant to the consideration of an architecture. By examining the capabilities of an organization from a functional perspective, it is possible to develop models of what the organization does without being dragged into extended debate on how the organization does it. (Context: TOGAF 9)

functional integration   Interoperability among programs, systems, and services, which requires a metacontext and standards to be successful. Program, systems, and services interoperability is foundational for federal government organizations to be able to partner successfully in new shared service models that may involve outside providers and new roles for participation (such as consumer, developer, or provider). (Context: Common Approach/FEAF2)

future view   A collection of artifacts that represent processes and technologies that do not yet exist in the enterprise. (Context: Common Approach/FEAF2)

GAO EA Management Maturity Assessment Framework (EAMMF)   A classic five-stage maturity model, with the stages ranging from Stage 1, Creating EA Awareness, to Stage 5, Leveraging the EA to Manage Change. (Context: Common Approach/FEAF2)

gap   A statement of difference between two states. Used in the context of gap analysis, where the difference between the baseline and target architecture is identified. See gap analysis. (Context: TOGAF 9)

gap analysis   Involves the comparison of actual performance with potential or desired performance, the gap between capability needs and current capabilities. If an organization does not make the best use of current resources or forgoes investment in capital or technology, it may produce or perform below its potential. (Context: General)

general aviation   The segment of aviation that encompasses all aspects of civil aviation except certified air carriers and other commercial operators such as airfreight carriers. (Context: FAA AMP)

goal   A high-level statement of intent or direction for an organization. Typically used to measure success of an organization. (Context: TOGAF 9)

goal/objective/service diagram   Defines the ways in which a service contributes to the achievement of a business vision or strategy. TOGAF alternative view of CV-7: Capability to Services Mapping. (Context: TOGAF 9)

governance

A group of policies, decision-making procedures, and management processes that work together to enable the effective planning and oversight of activities and resources. (Context: Common Approach/FEAF2)

The practice by which enterprise architectures are managed and controlled. (Context: TOGAF 9)

governance log   Provides a record of governance activity across the enterprise. (Context: TOGAF 9)

Government Accountability Office (GAO)   This U.S. federal agency that reviews the status of various government projects at congressional request and provides reports on observed status and problems. (Context: Common Approach/FEAF2)

government publication   Information published as an individual document at government expense, or as required by law. (44 U.S.C. 1901). (Context: Common Approach/FEAF2)

guidance   An authoritative statement intended to lead or steer the execution of actions. (Context: DoDAF 2.02)

High-Level Operational Concept Graphic (OV-1)   The high-level graphical/textual description of the operational concept. (Context: DoDAF 2.02)

horizontal segment   A crosscutting process, program, or resource that serves several lines of business. (Context: Common Approach/FEAF2)

hosting concept of operations (I-2)   Presents the high-level functional architecture, organization, roles, responsibilities, processes, metrics, and strategic plan for hosting and use of hosting services. (Context: Common Approach/FEAF2)

IDEF (Integration Definition for Information Modeling)   A family of modeling languages in the field of systems and software engineering; each of these modeling languages is standalone. (Context: General)

IDEF0   The IDEF modeling language and methodology for process modeling. (Context: General)

IDEF1X   The IDEF modeling language and methodology for data modeling. (Context: General)

Identity and Access Management (IdAM) reference architecture   Specifies a standard architecture for identification and access management across the U.S. Army. (Context: U.S. Army)

implementations   Usually a running system, manual or automated, that is, in Zachman Framework terms, a Row 6 instantiation. However, any composite, whether it is architected within any row of the Zachman Framework or not architected as an ad hoc or random composite that exists can be an implementation. (Context: Zachman)

information

Any communication or representation of knowledge such as facts, data, or opinions in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audiovisual forms. (Context: Common Approach/FEAF2)

The state of a something of interest that is materialized—in any medium or form—and communicated or received. (Context: DoDAF 2.02)

information life cycle   The stages through which information passes, typically characterized as creation or collection, processing, dissemination, use, storage, and disposition. (Context: Common Approach/FEAF2)

information management   The planning, budgeting, manipulating, and controlling of information throughout its life cycle. (Context: Common Approach/FEAF2)

information resource catalog   Up-to-date inventory of information assets. (Context: TOGAF 9)

information resource management (IRM) strategic plan   A strategic document that addresses all information resources management of the agency. Agencies must develop and maintain the agency’s IRM strategic plan as required by 44 U.S.C. 3506(b) (2). IRM strategic plans should conform to guidance provided annually in OMB Circular A–11, provide a description of how IT management activities help accomplish agency missions delivery area and program decision, and ensure that decisions are integrated with management support areas including organizational planning, budget, procurement, financial management, and HR. (Context: Common Approach/FEAF2)

information resources   Resources that include both government information and IT. (Context: Common Approach/FEAF2)

information resources management   The process of managing information resources to accomplish agency missions. The term encompasses both information itself and the related resources, such as personnel, equipment, funds, and IT. (Context: Common Approach/FEAF2)

information security   Involves all functions necessary to meet federal information security policy requirements. It includes the development, implementation, and maintenance of security policies, procedures, and controls across the entire information life cycle. This includes implementation and activities associated with NIST SP-800-37 Revision 1: Guide for Applying the Risk Management Framework to Federal Information Systems, Security Awareness Training; SP-800-39: Managing Risk from Information Systems; SP-800-53A Revision 4: Assessing Security and Privacy Controls in Federal Information Systems and Organizations; and FISMA compliance reporting, development of security policy, security audits, and testing. (Context: Common Approach/FEAF2)

information system   A discrete set of IT, data, and related resources, such as personnel, hardware, software, and associated information technology services organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information in accordance with defined procedures, whether automated or manual. (Context: Common Approach/FEAF2)

information system life cycle   The phases through which an information system passes, typically characterized as initiation, development, operation, and termination. (Context: Common Approach/FEAF2)

information system service   The automated elements of a business service that may deliver or support part or all of one or more business services. (Context: TOGAF 9)

information technology (IT)

1. The life cycle management of information and related technology used by an organization. 2. An umbrella term that includes all or some of the subject areas relating to the computer industry, such as business continuity, business IT interface, business process modeling and management, communication, compliance and legislation, computers, content management, hardware, information management, Internet, offshoring, networking, programming and software, professional issues, project management, security, standards, storage, voice and data communications. Various countries and industries employ other umbrella terms to describe this same collection. 3. Term commonly assigned to a department within an organization tasked with provisioning some or all of the domains described in definition 2. 4. Alternate names commonly adopted include information services, information management, and so on. (Context: TOGAF 9)

Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by an executive agency. IT is related to the terms capital asset, IT investment, program, project, subproject, service, and system. (Context: Common Approach/FEAF2)

information technology governance   Provides the framework and structure that links IT resources and information to enterprise goals and strategies. Institutionalizes best practices for planning, acquiring, implementing, and monitoring IT performance, to ensure that the enterprise’s IT assets support its business objectives. (Context: TOGAF 9)

information technology investment   The expenditure of IT resources to address mission delivery and management support. May include a project or projects for the development, modernization, enhancement, or maintenance of a single IT asset or group of IT assets with related functionality and the subsequent operation of those assets in a production environment. While each asset or project would have a defined life cycle, an investment that covers a collection of assets intended to support an ongoing business mission may not. (Context: Common Approach/FEAF2)

information view type (If)   Addresses the information perspective on operational, service, and resource architectures. Allows analysis of an architecture’s information and data definition aspect, without consideration of implementation-specific issues. (Context: Unified Architecture Framework)

infrastructure reference model (IRM)   Categorizes the network/cloud–related standards and technologies to support and enable the delivery of voice, data, video, and mobile service components and capabilities. (Context: Common Approach/FEAF2)

Infrastructure subarchitecture domain   In the EA framework. it is important to ask the following: What types of voice, data, mobile, and video networks will be required to host the IT systems/applications and to transport associate, data, images, and conversations? What type of physical infrastructure is needed to support the networks (such as buildings, server rooms, points of presence, and other equipment)? Will highly scalable cloud computing environments be needed, and, if so, will the organization be a provider or consumer? How can these networks be integrated to create a cost-effective and operationally efficient hosting environment? Will these networks extend beyond the enterprise? What are the physical space and utility support requirements for the networks? Will cloud-based concepts be used (virtualization, scaling, metering)? What are the workforce, standards, and security issues in this subarchitecture domain? (Context: Common Approach/FEAF2)

input

The raw material and/or energy that is transformed by some process into some product or service. (Context: Zachman)

Resources (human, employee time, funding) used to conduct activities and provide services. (Context: ECA)

Integrated Dictionary (AV-2)   An authoritative and integrated dictionary for all architecture elements or terms used in all views that support all viewpoints. (Context: DoDAF 2.02)

integrated product teams (IPTs)   Temporary teams composed of personnel from various organizations or roles within the enterprise that are established to develop a specific product. In the architecture case, this product would be a part of the architecture. (Context: General)

integration

In the context of an architecture, an assurance that the same architecture element is modeled consistently across multiple views. Integration avoids creating multiple representations for a common object that can lead to flaws in analysis and interpretation. (Context: General)

The characteristic of any formalism in which there are no anomalies, no discontinuities, and elements perfectly fit together. (Context: Zachman)

intelligence community   The collection of federal and military agencies that collaborate and cooperate in national intelligence–related activities. (Context: General)

Intelligence, Surveillance, and Reconnaissance (ISR)   The coordinated and integrated acquisition, processing, and provision of timely, accurate, relevant, coherent, and assured information and intelligence to support a commander’s conduct of activities. (Context: General)

interaction scenarios view type (Is)   Expresses a time-ordered examination of the exchanges as a result of a particular scenario or between participating elements as a result of a particular scenario. (Context: Unified Architecture Framework)

interface catalog   Scopes and documents the interfaces between applications to enable the overall dependencies between applications to be scoped as early as possible. (Context: TOGAF 9)

international   The level of architecture that focuses on international partnerships of the U.S. government with other governments, global industries, non-profits, and other groups. International-level architectures often center on the enablement of shared services, wherein the roles of provider and consumer need to be detailed and a comprehensive business model for the service provides the requirements for the architecture. (Context: Common Approach/FEAF2)

International Defense Enterprise Architecture Specification (IDEAS)   A formal ontology foundation developed by the defense departments and ministries of the United States, United Kingdom, Canada, Australia, and Sweden in coordination with NATO. (Context: DoDAF 2.02)

interoperability   The ability of different operating and software systems, applications, and services to communicate and exchange data in an accurate, effective, and consistent manner. (Context: Common Approach/FEAF2)

interval   A length of time of significance to the enterprise such that its duration in clock time will be recorded at Row 6 of the Zachman Framework. (Context: Zachman)

inventory   The enterprise (business) name for an entity, a set, things the enterprise counts. Inventories typically have a serial numbers on the instances at Row 6. (Context: Zachman)

inventory sets   The Column 1 models of the Zachman Framework, descriptive of the inventories that the enterprise manages. At Row 6 the inventory instances likely have serial numbers associated. (Context: Zachman)

IT capability assessment (TOGAF 9)   Identifies baseline capabilities, capability gaps, and future capability needs from the IT perspective. (Context: TOGAF 9)

joint asset visibility   Refers to supplies (expendable items) and equipment (nonexpendable items)—on order, in transit, in storage, or on hand—that are owned or destined for the military services, DoD agencies, or coalition partners. (Context: U.S. Army)

Joint Capability Area (JCA)   Collections of similar DoD capabilities functionally grouped to support capability analysis, strategy development, investment decision-making, capability portfolio management, and capabilities-based force development and operational planning. JCAs are aligned with functional configuration boards (FCBs). (Context: Defense Acquisition)

joint mission thread (JMT)   An operational and technical description of the end-to-end set of activities and systems that accomplish the execution of a joint mission. (Context: Joint Instruction)

Joint Requirements Oversight Council (JROC)   Part of the U.S. DoD acquisition process that reviews programs designated as JROC interest and supports the acquisition review process in accordance with law. (Context: General)

joint task force   A joint (multiservice) ad hoc military formation. (Context: General)

knowledge   Data or information that has been organized and processed to convey understanding, experience, accumulated learning, and expertise as it applies to a current problem or activity. Data that is processed to extract critical implications and to reflect past experience and expertise provides the recipient with organizational knowledge, which has a very high potential value. (Context: Common Approach/FEAF2)

knowledge management plan (D-2)   Provides a detailed description of how knowledge, information, and data are shared across the enterprise between systems, applications, knowledge warehouses, and databases. (Context: Common Approach/FEAF2)

landside   The portion of an airport that provides the facilities necessary for the processing of passengers, cargo, freight, and ground transportation vehicles. (Context: FAA AMP)

legacy systems   In computing, an old method, technology, computer system, or application program of, relating to, or being a previous or outdated computer system. Often a pejorative term, referencing a system as “legacy” means that it paved the way for the standards that would follow it. (Context: General)

level of effort (LOE)   Any particular support type activity that customarily does not lend itself to the ultimate establishment via measure of the sum total of discrete accomplishment. (Context: PMBOK)

life cycle model   A framework containing the processes, activities, and tasks involved in the development, operation, and maintenance of a software product, which spans the life of the system from the definition of its requirements to the termination of its use. (Context: IEEE Std 1471-2000)

line of business (LOB)

A specific operating unit or shared service that exists within or between agencies. LOBs are also OMB-authorized service providers for the federal government, managed by designated executive agencies. (Context: Common Approach/FEAF2)

A general term that refers to a product or a set of related products that serve a particular customer transaction or business need. (Context: General)

line of sight (LOS)   Aligning employee goals with a firm’s larger strategic goals is critical if organizations hope to manage their human capital effectively and ultimately attain strategic success. An important component of attaining and sustaining this alignment is for employees to have a line of sight with their organization’s strategic objectives. (Context: Harvard Business Review)

location

A point or extent in space that may be referred to physically or logically. (Context: DoDAF 2.02)

A place where business activity takes place and that can be hierarchically decomposed. (Context: TOGAF 9)

A geographic position of significance to the enterprise. At Row 6 of the Zachman Framework, a location would have a latitude and longitude. (Context: Zachman)

location catalog   Provides a listing of all locations where an enterprise carries out business operations or houses architecturally relevant assets, such as data centers or end user computing equipment. (Context: TOGAF 9)

logical application component   An encapsulation of application functionality that is independent of a particular implementation—for example, the classification of all purchase request processing applications implemented in an enterprise. (Context: TOGAF 9)

logical data component   A boundary zone that encapsulates related data entities to form a logical location to be held—for example, external procurement information. (Context: TOGAF 9)

logical data diagram   Shows logical views of the relationships between critical data entities within the enterprise. (Context: TOGAF 9)

logical data model (D-1)   Presents data requirements that reify the information concepts identified by corresponding conceptual information models. Similar to DoDAF DIV-2: Logical Data Model. (Context: Common Approach/FEAF2)

Logical Data Model (DIV-2)   The documentation of the data requirements and structural business process (activity) rules. In DoDAF V1.5, this was the OV-7. (Context: DoDAF 2.02)

logical technology component   An encapsulation of technology infrastructure that is independent of a particular product. A class of technology product—for example, supply chain management software as part of an enterprise resource planning (ERP) suite, or a commercial off-the-shelf (COTS) purchase request processing enterprise service. (Context: TOGAF 9)

major investment   A program requiring special management attention because of its importance to the mission or function of the agency, a component of the agency, or another organization; has significant program or policy implications; has high executive visibility; has high development, operating, or maintenance costs; is funded through other than direct appropriations; or is defined as major by the agency’s capital planning and investment control process. Office of Management and Budget may work with the agency to declare other investments as major investments. Agencies should consult with the respective OMB agency budget officer or analyst about what investments to consider as “major” and “non-major.” (Context: Common Approach/FEAF2)

managing partner   The agency designated as the lead agency responsible for coordinating the implementation of the E-Gov or line of business initiative; also responsible for coordinating and submitting the Exhibit 300 for the initiative, and the Exhibit 300 will be represented as part of the managing partner’s budget portfolio. (Context: Common Approach/FEAF2)

materiel   Equipment, apparatus, or supplies that are of interest, without distinction as to their application for administrative or combat purposes. (Context: DoDAF 2.02)

matrix/matrices   Grids that show relationships between two or more model entities that are used to represent relationships that are list-based rather than graphical in their usage (for example, a CRUD matrix showing which applications Create, Read, Update, and Delete a particular type of data is difficult to represent visually). (Context: TOGAF 9)

measure

The magnitude of some attribute of an individual. (Context: DoDAF 2.02)

An indicator or factor that can be tracked, usually on an ongoing basis, to determine success or alignment with objectives and goals. (Context: TOGAF 9)

measure type   A category of measures. (Context: DoDAF 2.02)

meta   Something of a higher or second order form. In a modeling context, a model of something—a model of a model would be a metamodel. Or a concept model that constitutes the basis for the database design of a repository product, a database for storing models, would be a metamodel. (Context: Zachman)

meta context   The highest level context for understanding an idea, design, enterprise. (Context: Common Approach/FEAF2)

meta framework   A classification of the descriptive representations relevant to the existence of an enterprise. The Row 2 models of one framework can be meta relative to another framework—that is, they are of a higher or second order in that they operate relative to all the models of the fundamental framework. For example, there is a set of models that are meta relative to the enterprise framework (enterprise architecture), which would constitute the Row 2 models of another complete framework of models. This meta framework of models is descriptive of the community of people who are designing and building the enterprise framework models (enterprise architecture). By the same token, the Row 2 models of the enterprise framework are meta relative to the product framework, and therefore the enterprise framework is a meta framework relative to the product framework. (Context: Zachman)

metadata domain (Md)   Captures metadata relevant to the entire architecture. Provides information pertinent to the entire architecture. Presents supporting information rather than architectural models. (Context: Unified Architecture Framework)

metamodel   A model that describes how and with what the architecture will be described in a structured way. (Context: TOGAF 9)

methodology

Sometimes called approach, refers to 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. (Context: Common Approach/FEAF2)

A defined, repeatable series of steps to address a particular type of problem, which typically centers on a defined process, but may also include definition of content. (Context: TOGAF 9)

A series of steps that if correctly employed result in a definable result, a process that is typically associated with producing a system or an implementation. The inputs and outputs of a methodology for producing systems or implementations are “composites.” (Context: Zachman)

military services   The U.S. Military Services include the U.S. Army, the U.S. Navy, the U.S. Air Force, the U.S. Marine Corps, and the U.S. Coast Guard. (Context: General)

Ministry of Defense Architecture Framework (MODAF)   An architecture framework that defines a standardized way of conducting enterprise architecture, originally developed by the UK Ministry of Defence. (Context: General)

mission   A use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. (Context: IEEE Std 1471-2000)

mission statement   A succinct description of why the enterprise exists. (Context: Common Approach/FEAF2)

MODAF   See Ministry of Defense Architecture Framework (MODAF).

model   A representation of a subject of interest that provides a smaller scale, simplified, and/or abstract representation of the subject matter. Constructed as a means to an end. In the context of EA, the subject matter is a whole or part of the enterprise and the end is the ability to construct views that address the concerns of particular stakeholders—their viewpoints in relation to the subject matter. (Context: TOGAF 9)

moment   A point in time of significance to the enterprise, sufficiently significant that the clock time at Row 6 of the Zachman Framework is recorded. (Context: Zachman)

motivation   The reason or rationale for choices that are made in the design and operation of an enterprise. (Context: Zachman)

motivation intentions   The Column 6 models of the Zachman Framework descriptive of the ends and means, the objectives and strategies of the enterprise. At Row 6 the ends will have measurements associated and the means will have constraints (“rules”) associated for mitigating risk in the event of conflicting objectives. (Context: Zachman)

national level   A level of architecture that includes all federal, state, tribal, and local government agencies within the United States and its territories. These architectures are very important to the coordination of nationwide capabilities, such as first-responder coordination, disaster notification, telecommunications, and transportation infrastructure. (Context: Common Approach/FEAF2)

national security system   Any telecommunications or information system operated by the United States government, the function, operation, or use of which involves intelligence activities, involves cryptologic activities related to national security, involves command and control of military forces, involves equipment that is an integral part of a weapon or weapons system, or is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be administrative and business applications (including payroll, finance, logistics, and personnel management applications). (Context: Common Approach/FEAF2)

NATO Architecture Framework (NAF)   North Atlantic Treaty Organization Architecture Framework, another DoDAF-related defense architecture framework. (Context: General)

network   An interconnected set of locations from and to which various inventories are transported for storage or disposition. (Context: Zachman)

network diagram (I-1)   Describes the means by which resource flows between systems occur. Similar to DoDAF SV-2: Systems Resource Flow Description and SvcV-2: Services Resource Flow Description. (Context: Common Approach/FEAF2)

network security enterprise reference architecture   Specifies an overall U.S. Army approach to providing network security. (Context: Defense Information Enterprise Architecture)

networked computing/hardware diagram   Shows the “as deployed” logical view of logical application components in a distributed network computing environment. (Context: TOGAF 9)

new IT investment   An IT investment and its associated projects newly proposed by the agency that has not been previously funded by the OMB. This does not include investments existing within the agency that have not previously been reported to OMB. (Context: Common Approach/FEAF2)

Next Generation Air Traffic System (NGATS)   An ongoing multibillion dollar modernization of the National Airspace System (NAS). The Federal Aviation Administration (FAA) started working on NextGen improvements in 2007 and plans to have all major components in place by 2025. (Context: RMN Airport Case Study)

non-major investment   An IT investment not meeting the definition of major as defined in this glossary, but that is part of the agency’s IT portfolio. All non-major investments are reported on the agency IT portfolios (Exhibit 53). (Context: Common Approach/FEAF2)

object library (D-10)   A collection of computer programs in the form of relocatable instructions, which reside on, and may be read from, a mass storage device. (Context: Common Approach/FEAF2)

Object Management Group (OMG)   A standards group comprising industrial, government, and academic participants. (Context: General)

objective   A timebound milestone for an organization used to demonstrate progress toward a goal—for example, “Increase capacity utilization by 30 percent by the end of 2021 to support the planned increase in market share.” (Context: TOGAF 9)

Office of Management and Budget (OMB)   A U.S. executive branch agency that controls budgets for the other executive agencies and uses architecture information to decide which proposed projects get funding or which continuing projects get additional funding. (Context: General)

OMB Circular A-130   A memo issued by the OMB that establishes general policy for the planning, budgeting, governance, acquisition, and management of federal information, personnel, equipment, funds, IT resources, and supporting infrastructure and services. (Context: Common Approach/FEAF2)

OMB Enterprise Architecture Assessment Framework (EAAF)   Identifies the measurement areas and criteria by which agencies are expected to use the EA to drive performance improvements. (Context: Common Approach/FEAF2)

ongoing investment   An investment and its associated assets, including both maintenance projects and operations, that have been through a complete budget cycle with OMB with respect to the president’s budget for the current year. (Context: Common Approach/FEAF2)

ontology

In computer science and information science, a formal naming and definition of the types, properties, and interrelationships of the entities that really exist in a particular domain of discourse. (Context: General)

A theory of the existence of a structured set of essential components of an object for which explicit expression is necessary for designing, operating, and changing the object, the object being an enterprise, a department, a value chain, a solution, a project, an airplane, a building, a bathtub, and so on. (Context: Zachman)

operating model   Answers the question, What are the processes, activities, roles, controls, governances, and other factors that will be brought to bear to produce these goods, services, or value propositions to customers and markets? (Context: General)

Operational Activity Decomposition Tree (OV-5a)   The capabilities and activities (operational activities) organized in a hierarchical structure. (Context: DoDAF 2.02)

Operational Activity Model (OV-5b)   The context of capabilities and activities (operational activities) and their relationships among activities, inputs, and outputs. Additional data can show cost, performers, or other pertinent information. (Context: DoDAF 2.02)

Operational Activity to Services Traceability Matrix (SvcV-5)   A mapping of services (activities) back to operational activities (activities). (Context: DoDAF 2.02)

Operational Activity to Systems Function Traceability Matrix (SV-5a)   A mapping of system functions (activities) back to operational activities (activities). (Context: DoDAF 2.02)

Operational Activity to Systems Traceability Matrix (SV-5b)   A mapping of systems back to capabilities or operational activities (activities). (Context: DoDAF 2.02)

operational concept   A user-oriented document that describes systems characteristics for a proposed system from a user’s perspective, also known as a concept of operations (CONOPS). A CONOPS also describes the user organization, mission, and objectives from an integrated systems point of view and is used to communicate overall quantitative and qualitative system characteristics to stakeholders. (Context: Systems Engineering)

operational domain (Op)   Illustrates the logical architecture of the enterprise. Describes the requirements, operational behavior, structure, and exchanges required to support (exhibit) capabilities. Defines all operational elements in an implementation/solution independent manner. (Context: Unified Architecture Framework)

operational level agreement (OLA)   Defines the interdependent relationships in support of a service-level agreement (SLA). The agreement describes the responsibilities of each internal support group toward other support groups, including the process and time frame for delivery of their services. (Context: General)

Operational Resource Flow Description (OV-2)   A description of the Resource Flows exchanged between operational activities. (Context: DoDAF 2.02)

Operational Resource Flow Matrix (OV-3)   A description of the resources exchanged and the relevant attributes of the exchanges. (Context: DoDAF 2.02)

Operational Rules Model (OV-6a)   One of three models used to describe activity (operational activity). It identifies business rules that constrain operations. (Context: DoDAF 2.02)

Operational Viewpoint (OV)

Includes the operational scenarios, activities, and requirements that support capabilities. (Context: DoDAF 2.02)

Both a DoDAF and a UAF viewpoint. (Context: Unified Architecture Framework)

operations   The day-to-day management of an asset in the production environment, including activities involved in operating data centers, help desks, data centers, telecommunication centers, and end user support services. Operational costs include the expenses associated with an IT asset that is in the production environment to sustain an IT asset at the current capability and performance levels including federal and contracted labor costs, and costs for the disposal of an asset. (Context: Common Approach/FEAF2)

operations and maintenance (O&M)   The phase of an asset in which the asset is in operations and produces the same product or provides a repetitive service. O&M is the same as steady state. (Context: Common Approach/FEAF2)

operations instances   The Zachman Framework, Row 6 enterprise implementations. The “as built” instantiations of the enterprise. This is the actual enterprise, not architectural abstractions. (Context: Zachman)

Organisation for Economic Cooperation and Development (OECD)   An intergovernmental economic organization with 35 member countries, founded in 1960 to stimulate economic progress and world trade. (Context: General)

organization   A specific real-world assemblage of people and other resources organized for an ongoing purpose. (Context: DoDAF 2.02)

organization/actor catalog   Captures a definitive listing of all participants who interact with IT, including users and owners of IT systems. (Context: TOGAF 9)

organization chart (B-4)   Presents the composition and relationships among organizational performers. Equivalent to DoDAF OV-4: Organizational Relationships Chart. (Context: Common Approach/FEAF2)

organization decomposition diagram   Describes the links between actor, roles, and location within an organization tree. (Context: TOGAF 9)

organization-specific architecture   An architecture representation that is unique to each type of organization and does not generalize across organizations. (Context: TOGAF 9)

organization unit   A self-contained unit of resources with goals, objectives, and measures. Organization units may include external parties and business partner organizations. (Context: TOGAF 9)

Organizational Relationships Chart (OV-4)   The organizational context, role, or other relationships among organizations. (Context: DoDAF 2.02)

output   The product or service that is the result of some transformation. (Context: Zachman)

Overview and Summary Information (AV-1)   A living document that contains an overview of the architecture form and contents. It describes a project’s visions, goals, objectives, plans, activities, events, conditions, measures, effects (outcomes), and produced objects. (Context: DoDAF 2.02)

partner agency   The agency for an E-Gov or line of business (LOB) initiative designated as an agency that should provide resources (such as funding, FTEs, in-kind) to the management, development, deployment, or maintenance of a common solution. The partner agency is also responsible for including the appropriate line items in its Exhibit 53, reflecting the amount of the contribution for each of the E-Gov or LOB initiatives to which it is providing resources. (Context: Common Approach/FEAF2)

patterns   A technique for putting building blocks into context—for example, to describe a reusable solution to a problem. Building blocks are what you use, and patterns can tell you how you use them—when, why, and what tradeoffs you have to make in doing so. (Context: TOGAF 9)

performance gap   An identified activity or capability that is lacking within the enterprise, which causes the enterprise to perform below desired levels or not to achieve strategic or tactical goals. (Context: Common Approach/FEAF2)

performance measurement   Regular measurement of outcomes and results, which generates reliable data on the effectiveness and efficiency of programs. (Context: ECA)

performance measures scorecard (S-5)   A strategic performance management tool that can be used by managers to keep track of the performance metrics associated with the execution of activities by the staff within their control and to identify the performance gaps and consequences arising from these gaps. A balanced scorecard (BSC) is a performance measures scorecard. (Context: Common Approach/FEAF2)

performance reference model (PRM)   Links agency strategy, internal business components, and investments, providing a means to measure the impact of those investments on strategic outcomes. (Context: Common Approach/FEAF2)

performer   Any entity—human, automated, or any aggregation of human and/or automated—that performs an activity and provides a capability. (Context: DoDAF 2.02)

person type   A category of persons defined by the role or roles they share that are relevant to an architecture. (Context: DoDAF 2.02)

personally identifying information (PII)   Any data that could potentially identify a specific individual. Any information that can be used to distinguish one person from another. (Context: General)

personnel domain (Pr)   Defines and explores organizational resource types. Shows the taxonomy of types of organizational resources as well as connections, interaction, and growth over time. (Context: Unified Architecture Framework)

Phase A: Architecture Vision   Describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the architecture vision, and obtaining approval to proceed with the architecture development. (Context: TOGAF 9)

Phase B: Business Architecture   Describes the development of a business architecture to support the architecture vision. (Context: TOGAF 9)

Phase C: Information Systems Architecture   Describes the development of information systems architectures to support the architecture vision. (Context: TOGAF 9)

Phase D: Technology Architecture   Describes the development of the technology architecture to support the architecture vision. (Context: TOGAF 9)

Phase E: Opportunities & Solutions   Conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. (Context: TOGAF 9)

Phase F: Migration Planning   Addresses how to move from the baseline to the target architectures by finalizing a detailed implementation and migration plan. (Context: TOGAF 9)

Phase G: Implementation Governance   Provides an architectural oversight of the implementation. (Context: TOGAF 9)

Phase H: Architecture Change Management   Establishes procedures for managing change to the new architecture. (Context: TOGAF 9)

physical application component   An application, application module, application service, or other deployable component of functionality—for example, a configured and deployed instance of a COTS enterprise resource planning (ERP) supply chain management application. (Context: TOGAF 9)

physical data component   A boundary zone that encapsulates related data entities to form a physical location to be held—for example, a purchase order business object comprising purchase order header and item business object nodes. (Context: TOGAF 9)

physical data model (D-5)   Presents data elements and data structures that reify the data requirements specified by corresponding logical data models Equivalent to DoDAF DIV-3: Physical Data Model. (Context: Common Approach/FEAF2)

Physical Data Model (DIV-3)   The physical implementation format of the logical data model entities, such as message formats, file structures, physical schema. In DoDAF V1.5, this was the SV-11. (Context: DoDAF 2.02)

physical technology component   A specific technology infrastructure product or technology infrastructure product instance—for example, a particular product version of a COTS solution, or a specific brand and version of server. (Context: TOGAF 9)

platform decomposition diagram   Diagram that depicts the technology platform that supports the operations of the information systems architecture. It covers all aspects of the infrastructure platform and provides an overview of the enterprise’s technology platform. It can be expanded to map the technology platform to appropriate application components within a specific functional or process area. This diagram may show details of specification, such as product versions, number of CPUs, and so on, or simply could be an informal “eye-chart” providing an overview of the technical environment. (Context: TOGAF 9)

platform service   A technical capability required to provide enabling infrastructure that supports the delivery of applications. (Context: TOGAF 9)

point of presence (PoP) diagram (I-10)   An artificial demarcation point or interface point between communicating entities that describes communications inside the enterprise from the PoP of external communications agents. (Context: General)

policy

a: a definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions; b: a high-level overall plan embracing the general goals and acceptable procedures especially of a governmental body. (Context: Merriam Webster Dictionary and Thesaurus)

A guiding principle that is measurable in terms of compliance and enforceable. (Context: General)

port authority   In Canada and the United States, a governmental or quasi-governmental public authority for a special-purpose district usually formed by a legislative body (or bodies) to operate ports and other transportation infrastructure. Sometimes known as port district. (Context: General)

portfolio of investments   A collection of assets owned by an enterprise. (Context: General)

post-implementation review (PIR)   A management review of an installed system that assesses whether the system still meets its proposed purpose and achieves its desired goals or if it should be retired or replaced. PIRs should be held periodically for all installed systems. (Context: DoD Acquisition)

preliminary phase   Describes the preparation and initiation activities required to create an architecture capability including customization of TOGAF and definition of architecture principles. (Context: TOGAF 9)

primary outcomes   Though there are many positive outcomes to which EA contributes, four outcomes are considered primary, in that they represent areas of direct, positive impact that architectures can make within and between agencies and with customers and partners external to government. These outcomes are service delivery, functional integration, authoritative reference and resource optimization. (Context: Common Approach/FEAF2)

primitive

An artifact that uses one modeling technique to describe one type of EA component. (Context: Common Approach/FEAF2)

A descriptive representation (model) depicting “normalized” instances and their interrelationships of a single type of component of an enterprise, an ontologically defined set of components. Used for engineering. The contents of single cell of the Zachman Framework. (Context: Zachman)

principle

A comprehensive and fundamental law, doctrine, or assumption. (Context: Merriam Webster Dictionary and Thesaurus)

A guiding tenet that is enduring and establishes the fundamental backbone of the EA program in an enterprise. (Context: General)

A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance. Note that a sample set of architecture principles is defined in Chapter 23. (Context: TOGAF 9)

principles catalog (TOGAF)   Lists the guiding principles for architecture development. (Context: TOGAF 9)

privacy impact assessment (PIA)   A process for examining the risks and ramifications of using information technology to collect, maintain, and disseminate information in identifiable form from or about members of the public, and for identifying and evaluating protections and alternative processes to mitigate the impact to privacy of collecting such information. Consistent with OMB M–03–22, implementing the privacy provisions of the E-Government Act, agencies must conduct and make publicly available PIAs for all new or significantly altered IT investments administering information in identifiable form collected from or about members of the public. (Context: Common Approach/FEAF2)

process

The flow of control between or within functions and/or services (depends on the granularity of definition). Processes represent a sequence of activities that together achieve a specified outcome, can be decomposed into subprocesses, and can show operation of a function or service (at next level of detail). Processes may also be used to link or compose organizations, functions, services, and processes. (Context: TOGAF 9)

A transformation—you take something in, do something to it (process), and send something different out. (Context: Zachman)

process/application realization diagram   Depicts the sequence of events when multiple applications are involved in executing a business process. It enhances the application communication diagram. (Context: TOGAF 9)

process/event/control/product catalog   Provides a hierarchy of processes, events that trigger processes, outputs from processes, and controls applied to the execution of processes. This catalog provides a supplement to any process flow diagrams that are created and enables an enterprise to filter, report, and query across organizations and processes to identify scope, commonality, or impact. (Context: TOGAF 9)

process flow diagram (TOGAF)   Depicts all models and mappings related to the process metamodel entity and shows the sequential flow of control between activities; may utilize swim lane techniques to represent ownership and realization of process steps—for example, the application that supports a process step may be shown as a swim lane. In addition to showing a sequence of activity, process flows can also be used to detail the controls that apply to a process, the events that trigger or result from completion of a process, and the products that are generated from process execution. (Context: TOGAF 9)

process flows   The Column 2 models of the Zachman Framework descriptive of the process transformations the enterprise performs. At Row 6 the instances will be actual transformations performed by a person or a machine. (Context: Zachman)

processes view type (Pr)   Captures activity-based behavior and flows. It describes activities, their inputs/outputs, activity actions, and flows between them. (Context: Unified Architecture Framework)

processing diagram   Focuses on deployable units of code/configuration and how these are deployed onto the technology platform. A deployment unit represents grouping of business function, service, or application components. (Context: TOGAF 9)

product framework   The classification of all the descriptive representations that are relevant to the existence of the product—that is, any Industrial Age product. (Context: Zachman)

product life cycle diagram   Assists in understanding the life cycles of key entities within the enterprise. Understanding product life cycles is becoming increasingly important with respect to environmental concerns, legislation, and regulation where products must be tracked from manufacture to disposal. Equally, organizations that create products that involve personal or sensitive information must have a detailed understanding of the product life cycle during the development of business architecture to ensure rigor in design of controls, processes, and procedures. Examples of this would include credit cards, debit cards, store/loyalty cards, smart cards, and user identity credentials (identity cards, passports, and so on). (Context: TOGAF 9)

product output   The business product of the execution of a process generated by the business. (Context: TOGAF 9)

program   An ongoing set of activities and projects managed in a coordinated way. (Context: Common Approach/FEAF2)

program management office   A group or department entrusted with delivering the solution of the project. (Context: Systems Engineering)

program management review (PMR)   A structured program review that is conducted by the program manager (PM) with all key stakeholders. A PMR might be conducted at a specific milestone on a program or on a predictable scheduled (monthly, quarterly, or semiannually). (Context: Defense Acquisition)

program or acquisition program   An initiative that includes a grouping of projects that deliver capabilities. (Context: Defense Acquisition)

project

A temporary activity to create a unique product, service, or result. (Context: Common Approach/FEAF2)

A temporary endeavor undertaken to create resources or desired effects. (Context: DoDAF 2.02)

project and program   The term “program” is used in various ways in different domains. In some domains a team can be called a program (a customer support team is the business’s customer relationship program). In others, an entire business is called a program (a wireless communications business unit program), and in others the whole enterprise is called a program (the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms “project” and “program” are used interchangeably with no discernible distinction in their meaning or scope. (Context: Systems Engineering)

project context diagram   Shows the scope of a work package to be implemented as a part of a broader transformation roadmap. The project context diagram links a work package to the organizations, functions, services, processes, applications, data, and technology that will be added, removed, or impacted by the project. (Context: TOGAF 9)

project management plan (PMP)   A formal, approved document used to manage project execution. The PMP documents the actions necessary to define, prepare, integrate, and coordinate the various planning activities and defines how the project is executed, monitored and controlled, and closed. (Context: Project Management)

Project Portfolio Relationships (PV-1)   It describes the dependency relationships between the organizations and projects and the organizational structures needed to manage a portfolio of projects. (Context: DoDAF 2.02)

Project Timelines (PV-2)   Acts like an aggregated Gantt chart for a portfolio of projects and provides a very quick view of the various timelines of the component projects and their dependencies. (Context: DoDAF 2.02)

Project to Capability Mapping (PV-3)   A mapping of programs and projects to capabilities to show how the specific projects and program elements help to achieve a capability. (Context: DoDAF 2.02)

Project Viewpoint (PV)   Describes the relationships between operational and capability requirements and the various projects being implemented. Also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process. (Context: DoDAF 2.02)

projects domain (Pj)   Describes projects and project milestones, how those projects deliver capabilities, the organizations contributing to the projects, and dependencies between projects. (Context: Unified Architecture Framework)

quality assurance (QA)   The systematic monitoring and evaluation of the various aspects of a project, service, or facility to maximize the probability that standards of quality are being attained by the production process. (Context: Common Approach/FEAF2)

rack elevation diagram (I-7)   Two-dimensional elevations (both of front and back) drawn to scale and showing everything that needs to be placed in a certain area to describe the organization of specific equipment on a rack. (Context: Common Approach/FEAF2)

records   Includes all books, papers, maps, photographs, machine-readable materials, or other documentary materials, regardless of physical form or characteristics, made or received by an agency of the United States government under federal law or in connection with the transaction of public business and preserved or appropriate for preservation by that agency or its legitimate successor as evidence of the organization, functions, policies, decisions, procedures, operations, or other activities of the government or because of the informational value of data in them. Library and museum materials made or acquired and preserved solely for reference or exhibition purposes, extra copies of documents preserved only for convenience of reference, and stocks of publications and of processed documents are not included. (Context: Common Approach/FEAF2)

records management   The planning, controlling, directing, organizing, training, promoting, and other managerial activities involved with respect to records creation, maintenance and use, and disposition in order to achieve adequate and proper documentation of the policies and transactions of the federal government and effective and economical management of agency operations. (44 U.S.C. 2901(2)). (Context: Common Approach/FEAF2)

reference architecture   An authoritative source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and solutions. (Context: Common Approach/FEAF2 and Reference Architecture OASD 2010)

reference library   Provides guidelines, templates, patterns, and other forms of reference material that can be leveraged to accelerate the creation of new architectures for the enterprise. (Context: TOGAF 9)

reference model   An abstract framework for understanding significant relationships among the entities of an environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a nonspecialist. A reference model is not directly tied to any standards, technologies, or other concrete implementation details, but it does seek to provide common semantics that can be used unambiguously across and between different implementations. (Context: TOGAF 9)

reference models (FEA)   There are six reference models in the common approach to federal EA: performance reference model (PRM), business reference model (BRM), data reference model (DRM), application reference model (ARM), infrastructure reference model (IRM), and security reference model (SRM). These taxonomies provide standardized categorization for strategic, business, and technology models and information and support analysis and reporting across agency EAs and each of the documentation domains. (Context: Common Approach/FEAF2)

relationship   In a modeling context, the logical connector between two entities. In the Zachman Framework, the relationship between the two meta-entities in each of the cells of Rows 2–6 is not simply a logical connector but an entity in its own right as it has contents. Two meta-entities describe each cell: an entity and a relationship entity. (Context: Zachman)

repository   A storage system that manages all of the data of an enterprise, including data and process models and other enterprise information. Hence, the data in a repository is much more extensive than that in a data dictionary, which generally defines only the data making up a database. (Context: TOGAF 9)

request for architecture work   A statement of work that defines the scope and approach that will be used to complete an architecture project. (Context: TOGAF 9)

request for proposal (RFP)   A document that solicits a proposal, often made through a bidding process, by an agency or company interested in procurement of a commodity, service, or valuable asset, to potential suppliers to submit business proposals. (Context: General)

requirement   A quantitative statement of business need that must be met by a particular architecture or work package. (Context: TOGAF 9)

requirements catalog   Captures things that the enterprise needs to do to meet its objectives. Requirements generated from architecture engagements are typically implemented through change initiatives identified and scoped during Phase E (Opportunities & Solutions). Requirements can also be used as a quality assurance tool to ensure that a particular architecture is fit-for-purpose (that is, can the architecture meet all identified requirements). (Context: TOGAF 9)

requirements management   Examines the process of managing architecture requirements throughout the Architecture Development Methodology (ADM). (Context: TOGAF 9)

Requirements Viewpoint   One of the UAF viewpoints. (Context: Unified Architecture Framework)

resource   Data, information, performers, materiel, or personnel types that are produced or consumed. (Context: DoDAF 2.02)

resource optimization

As custodians of public funds, federal sector organizations have a special responsibility to optimize their use of resources. Additionally, because of a variety of factors that cannot be anticipated or controlled (such as new laws, policies, and regulations; growing/evolving customer needs; new technologies; natural disasters) federal government organizations must often accomplish their mission with less resources than anticipated. (Context: Common Approach/FEAF2)

A means to achieve the goal of maximizing value for the enterprise and its stakeholders. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. (Context: Jeanne Ross, Peter Weill, and David C. Robertson, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, 2006)

resources domain (Rs)   Captures a solution architecture consisting of resources, such as organizational, software, artifacts, capability configurations, and natural resources, that implement the operational requirements. Further design of a resource is typically detailed in SysML or UML. (Context: Unified Architecture Framework)

responsibility assignments   The Column 4 models of the Zachman Framework descriptive of the roles and responsibilities of the enterprise’s people for managing performance. At Row 6 the individual instances will likely have standard industrial classification codes and the work products assigned have physical manifestations. (Context: Zachman)

return on investment (ROI)   The analysis process or resulting report that compares the expected investment costs versus the expected business value (the improvement in outcomes) of the investment over time. (Context: General)

roadmap   An abstracted plan for business or technology change, typically operating across multiple disciplines over multiple years (for example, technology roadmap, architecture roadmap, and so on). (Context: TOGAF 9)

roadmap view type (Rm)   Addresses how elements in the architecture change over time, at different points in time, or at different periods of time. (Context: Unified Architecture Framework)

role

The usual or expected function of an actor, or the part somebody or something plays in a particular action or event. An actor may have a number of roles. (Context: TOGAF 9) See also actor.

An innate educational or genetic ability possessed by someone to which responsibility for an enterprise work product is assigned. Typically possessing a standard industrial classification code (SIC code) designation. (Context: Zachman)

role/application matrix   Depicts the relationship between applications and the business roles that use them within the enterprise. (Context: TOGAF 9)

role catalog   Provides a listing of all authorization levels or zones within an enterprise. Frequently, application security or behavior is defined against locally understood concepts of authorization that create complex and unexpected consequences when combined on the user desktop. (Context: TOGAF 9)

rule   A principle or condition that governs behavior; a prescribed guide for conduct or action. (Context: DoDAF 2.02)

runway   A defined rectangular area at an airport designated for the landing and takeoff of an aircraft. (Context: FAA AMP)

scenario   A set of circumstances, events, players, and activities that provide a setting and context for a model or simulation. (Context: General)

scope context   The set of Row 1 Lists of the Zachman Framework that constitute the boundary or limit of the enterprise relative to the columnar abstractions. (Context: Zachman)

sector   A level of architecture that focuses on a system or service in one particular mission sector of the Executive Branch of the U.S. government. These interagency architectures often include the enablement of mission and/or support shared services, wherein the roles of provider and consumer need to be detailed and a comprehensive business model for the service provides the requirements for the architecture. These architectures may also include private sector participants. (Context: Common Approach/FEAF2)

security and privacy plan (SP-2)   A description of the enterprise security and privacy programs, policies, and procedures for the agency. (Context: Common Approach/FEAF2)

security authorization documentation (SP-3)   Compilation of security documents relevant to each system, such as system security plan, risk analysis, security requirements traceability matrix, system security authorization agreement, authority to operate, and so on. (Context: Common Approach/FEAF2)

security controls catalog (SP-1)   Describes the total set of security controls from which the developer may choose, which are applicable for the effort. (Context: Common Approach/FEAF2)

security domain (Sc)   Defines the hierarchy of security assets and asset owners, security constraints (policy, laws, and guidance) and details where they are located (security enclaves). (Context: Unified Architecture Framework)

security reference model (SRM)   Provides a common language and methodology for discussing security and privacy in the context of federal agencies’ business and performance goals. (Context: Common Approach/FEAF2)

Security subarchitecture domain   Pervades all of the other five areas of the EA framework, because security and privacy controls, to be most effective, need to be built into service workflows, data flows, systems, applications, and host networks. This is also true for standards and workforce skills. (Context: Common Approach/FEAF2)

segment   A level of architecture that focuses on a particular service area or business unit within an agency or between agencies that is not federal-, sector-, or agency-wide. Each segment is defined either organizationally (for example, as a business unit and per the organization chart) or functionally (as a vertical or crosscutting mission or support service). Segments are individual elements of the enterprise describing core mission areas and common or shared business services and enterprise services. They provide the core linkage of the IT investment portfolio to the agency’s performance management system. As such, segments are designed to be common across programs that support the same mission area. Increasingly, shared segments will be common across the government and agencies should plan to use approved government-wide shared segments as their target architecture. (Context: Common Approach/FEAF2)

segment architecture

A detailed, results-oriented architecture (baseline and target) and a transition strategy for a portion or segment of the enterprise. (Context: Common Approach/FEAF2)

A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity. (Context: TOGAF 9)

Segment Level architecture   One of an integratable component architectures that together make up the decomposition of an Enterprise Level architecture. (Context: Common Approach/FEAF2)

service

A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. (Context: DoDAF 2.02)

An element of behavior that provides specific functionality in response to requests from actors or other services. A service delivers or supports business capabilities, has an explicitly defined interface, and is explicitly governed. Services are defined for business, information systems, and platforms. (Context: TOGAF 9)

service consumer   An agency or business unit that receives business or technology service(s) from a line-of-business provider. A service consumer may be either internal or external to the organization responsible for providing services. (Context: Common Approach/FEAF2)

service delivery   Federal agencies exist to perform a wide spectrum of missions that meet the nation’s ongoing needs through a variety of programs and services. These missions, programs, and services are provided in law, administration policy, and agency policy. Increasingly, these mission and support programs/services/systems require joint management and execution by multiple agencies that are enabled through an IT shared service strategy and various embedded information-related technologies. (Context: Common Approach/FEAF2)

service implementation   An actual implementation of an abstract service. (Context: Common Approach/FEAF2)

service level agreement (SLA)   A document that spells out such items as the performance characteristics promised by the service provider. (Context: Common Approach/FEAF2)

service-oriented architecture (SOA)

An architectural style that supports service orientation. (Context: TOGAF 9)

A set of principles and methodologies for designing and developing software in the form of interoperable services. (Context: Common Approach/FEAF2)

service provider   An agency or business unit that provides business or technology service(s) as a line-of-business consumer(s). This includes a discrete set of personnel, IT, and support equipment with the primary function of providing service(s) to more one or more other agencies or business units on a reimbursable basis. (Context: Common Approach/FEAF2)

service quality   A preset configuration of nonfunctional attributes that may be assigned to a service or service contract. (Context: TOGAF 9)

Services Context Description (SvcV-1)   The identification of services, service items, and their interconnections. (Context: DoDAF 2.02)

services domain (Sv)   The service-orientated view (SOV)—a description of services needed to support the operational domain as described in the operational view. A service within MODAF is understood in its broadest sense as a unit of work through which a provider provides a useful result to a consumer. In DoDAF, the service views within the Services Viewpoint describe the design for service-based solutions to support operational development processes and defense acquisition system or capability development within the joint capability areas. (Context: Unified Architecture Framework)

Services Event-Trace Description (SvcV-10c)   One of three models used to describe service functionality. It identifies service-specific refinements of critical sequences of events described in the Operational Viewpoint. (Context: DoDAF 2.02)

Services Evolution Description (SvcV-8)   The planned incremental steps toward migrating a suite of services to a more efficient suite or toward evolving current services to a future implementation. (Context: DoDAF 2.02)

Services Functionality Description (SvcV-4)   The functions performed by services and the service data flows among service functions (activities). (Context: DoDAF 2.02)

Services Measures Matrix (SvcV-7)   The measures (metrics) of Services Viewpoint elements for the appropriate time frame(s). (Context: DoDAF 2.02)

Services Resource Flow Description (SvcV-2)   A description of resource flows exchanged between services. (Context: DoDAF 2.02)

Services Resource Flow Matrix (SvcV-6)   Provides details of service resource flow elements being exchanged between services and the attributes of that exchange. (Context: DoDAF 2.02)

Services Rules Model (SvcV-10a)   One of three models used to describe service functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation. (Context: DoDAF 2.02)

Services State Transition Description (SvcV-10b)   One of three models used to describe service functionality. It identifies responses of services to events. (Context: DoDAF 2.02)

Services Technology and Skills Forecast (SvcV-9)   The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future service development. (Context: DoDAF 2.02)

Services Viewpoint (SvcV)   The design for solutions articulating the performers, activities, services, and their exchanges, providing for or supporting operational and capability functions. (Context: DoDAF 2.02)

Services-Services Matrix (SvcV-3b)   The relationships among services in a given architectural description. It can be designed to show relationships of interest (such as service-type interfaces, planned versus existing interfaces). (Context: DoDAF 2.02)

shared service   A mission or support function provided by one business unit to other business units within or between organizations. (Context: Common Approach/FEAF2)

single-variable   Components of a single type, normalized—a primitive. Antonym is multivariable (apples and oranges). (Context: Zachman)

Six-Step Process   The DoDAF meta-process for architecture development. (Context: DoDAF 2.02)

skill   The ability, coming from one’s knowledge, practice, aptitude, and so on, to do something well. (Context: DoDAF 2.02)

software distribution diagram   Shows how application software is structured and distributed across the estate. It is useful in systems upgrade or application consolidation projects. (Context: TOGAF 9)

software engineering diagram   Divides applications into packages, modules, services, and operations from a development perspective. (Context: TOGAF 9)

software license inventory (A-11)   A list of COTS and open source software assets with details about each (installation date, original cost, condition, and so on). (Context: Common Approach/FEAF2)

solution architecture

A standardized method of identifying business requirements and viable technology solutions within the context of a single agency’s enterprise architecture or a multiagency sector or government-wide/international architecture. Solution architecture includes current and future views as well as transition plans at a number of levels of scope including applications, systems, segments, enterprise, sector, government-wide, national, and international. The Federal Solution Architecture Methodology (FSAM) is the repeatable process for creating solution architecture through projects at various levels of scope in the federal sector. (Context: Common Approach/FEAF2)

A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A solution architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks. (Context: TOGAF 9)

solution building block   A candidate solution that conforms to the specification of an architecture building block (ABB). (Context: TOGAF 9)

solution concept diagram   A high-level orientation of the solution that is envisaged to meet the objectives of the architecture engagement. In contrast to more formal and detailed architecture diagrams developed in later phases, the solution concept represents a “pencil sketch” of the expected solution at the outset of the engagement. (Context: TOGAF 9)

Solution Level architecture   An architecture level focused on a specific business/mission process solution involving a system or service or set of systems or services. (Context: Common Approach/FEAF2)

solutions continuum   A part of the enterprise continuum. A repository of reusable solutions for future implementation efforts that contains implementations of the corresponding definitions in the architecture continuum. (Context: TOGAF 9)

stakeholder

One who is or will be affected by a program, activity, or resource. (Context: Common Approach/FEAF2)

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. (Context: TOGAF 9)

stakeholder map matrix (TOGAF)   Depicts the stakeholders and their roles in the architecture. (Context: TOGAF 9)

standard

A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel. (Context: DoDAF 2.02)

A de jure standard is developed and published by a standards development group such as ISO, ANSI, IEEE, or OMG. A de facto standard is an interface or proprietary product that has become a standard in the marketplace. (Context: TOGAF 9)

standard protocol   Protocol implemented by a system port. (Context: General)

standards domain (Sd)   In MODAF, technical standards views are extended from the core DoDAF views to include nontechnical standards such as operational doctrine, industry process standards, and so on. In DoDAF, the standards views within the Standards Viewpoint are the set of rules governing the arrangement, interaction, and interdependence of solution parts or elements. (Context: Unified Architecture Framework)

Standards Forecast (StdV-2)   The description of emerging standards and potential impact on current solution elements, within a set of time frames. (Context: DoDAF 2.02)

standards information base   A database of standards that can be used to define the particular services and other components of an organization-specific architecture. (Context: TOGAF 9)

Standards Profile (StdV-1)   The listing of standards that apply to solution elements. (Context: DoDAF 2.02)

Standards Viewpoint (StdV)   Articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services. (Context: DoDAF 2.02)

state   The status of some architecture element such as a data element, performer, or system, that changes based on events caused by activities. (Context: DoDAF 2.02)

State Transition Description (OV-6b)   One of three models used to describe operational activity (activity). It identifies business process (activity) responses to events (usually, very short activities). (Context: DoDAF 2.02)

statement of work (SOW)   Created as a deliverable of Phase A, an architecture contract between the architecting organization and the sponsor of the enterprise architecture (or the IT governance function, on behalf of the enterprise). (Context: TOGAF 9)

states view type (St)   A graphical representation of states of a structural element and how it responds to various events and actions. It captures state-based behavior of an element. (Context: Unified Architecture Framework)

State-Transition Diagram (D-7)   Indicates the states systems transition to in response to events. Equivalent to DoDAF SV-10b: Systems State Transition Description and SvcV-10b: Services State Transition Description. (Context: Common Approach/FEAF2)

strategic architecture   A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting. (Context: TOGAF 9)

strategic domain (St)   Capability management process. Describes the capability taxonomy, composition, dependencies, and evolution. (Context: Unified Architecture Framework)

strategic plan (S-2)   A description of the organization’s vision and strategic objectives, a prioritization of the desired outcomes from achieving those objectives, the measurements that will demonstrate achievement, and the resources to be used to achieve them. Included in DoDAF CV-1: Vision, CV-2: Capability Taxonomy, CV-3: Capability Phasing, CV-5: Capability to Organizational Development Mapping, and CV-6: Capability to Operational Activities Mapping. (Context: Common Approach/FEAF2)

Strategic Viewpoint   Defines the desired business outcome and the capabilities that are required to achieve it. It provides a means to align an enterprise’s strategy with the capabilities required to deliver that strategy, identifying any capability gaps that may exist. (Context: MODAF)

strategy (business)   The enterprise’s working plan for achieving its vision, prioritizing objectives, competing successfully, and optimizing financial performance with its business model. (Context: General)

Strategy subarchitecture domain   Identifies the mission, vision, and goals of the enterprise being documented. (Context: Common Approach/FEAF2)

structure view type (Sr)   Describes the definitions of the dependencies, connections, and relationships between the different elements. (Context: Unified Architecture Framework)

structured analysis and design technique (SADT)   A systems engineering and software engineering methodology for describing systems as a hierarchy of functions. SADT is a structured analysis modelling language that uses two types of diagrams: activity models and data models. (Context: General)

subarchitecture domain   Represents a specific area of the overall framework. The type and depth of documentation should be guided by the need for detail and answers to questions about requirements, applicable standards, time frames, and available resources. (Context: Common Approach/FEAF2)

subject matter expert   Personnel with enterprise business or technical expertise, usually operators or performers of enterprise activities. (Context: General)

Summary and Overview   UAF viewpoint. (Context: Unified Architecture Framework)

SWOT analysis (S-4)   Presents the strengths, weaknesses/limitations, opportunities, and threats (SWOT) involved in a project or in a business venture, including risks and impacts. (Context: Common Approach/FEAF2)

system

A tangible IT asset that comprises hardware devices, software applications, databases, users, processes, and security controls. (Context: Common Approach/FEAF2)

A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements. (Context: DoDAF 2.02)

A collection of components organized to accomplish a specific function or set of functions. (Context: IEEE Std 1471-2000)

A set of things working together as parts of a mechanism. In the context of the Zachman Framework, the Row 3 models are a set of things working together that formalize a mechanism to realize the Row 2 enterprise concepts as one stage of reification, transforming the ideas of the enterprise, management’s perceptions, into an operational realities. (Context: Zachman)

system/application evolution diagram (A-7)   The planned incremental steps toward migrating a suite of systems and/or applications to a more efficient suite, or toward evolving a current system or application to a future implementation. Equivalent to DoDAF SV-8: Systems Evolution Description and SvcV-8: Services Evolution Description. (Context: Common Approach/FEAF2)

system environment   The environment, or context, that determines the setting and circumstances of developmental, operational, political, and other influences upon that system. The environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. The environment determines the boundaries that define the scope of the system of interest relative to other systems. (Context: IEEE Std 1471-2000)

System Level architecture   A level of architecture that focuses on one particular information technology system that supports the delivery of one or more services within or between segments and agencies. All aspects of a system’s functionality and configuration should be documented, including strategic drivers, business requirements, applicable standards, workflow processes, information exchanges, software applications, host infrastructure, remote access, and security/privacy controls. (Context: Common Approach/FEAF2)

System of Systems (SoS)   A set of systems that are the components of a more complex system that shows emergent properties. (Context: General)

system ports   Used by a system to send data to external systems. (Context: General)

system stakeholder   An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. (Context: IEEE Std 1471-2000)

systems development life cycle (SDLC)   Guidance, policies, and procedures for developing systems throughout their life cycle, including requirements, design, implementation testing, deployment, operations, and maintenance. (Context: Common Approach/FEAF2)

Systems Event-Trace Description (SV-10c)   One of three models used to describe system functionality. It identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint. (Context: DoDAF 2.02)

Systems Evolution Description (SV-8)   The planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation. (Context: DoDAF 2.02)

Systems Functionality Description (SV-4)   The functions (activities) performed by systems and the system data flows among system functions (activities). (Context: DoDAF 2.02)

Systems Interface Description (SV-1)   The identification of systems, system items, and their interconnections. (Context: DoDAF 2.02)

Systems Measures Matrix (SV-7)   The measures (metrics) of systems model elements for the appropriate time frame(s). (Context: DoDAF 2.02)

Systems Resource Flow Description (SV-2)   A description of resource flows exchanged between systems. (Context: DoDAF 2.02)

Systems Resource Flow Matrix (SV-6)   Provides details of system resource flow elements being exchanged between systems and the attributes of that exchange. (Context: DoDAF 2.02)

Systems Rules Model (SV-10a)   One of three models used to describe system functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation. (Context: DoDAF 2.02)

Systems State Transition Description (SV-10b)   One of three models used to describe system functionality. It identifies responses of systems to events. (Context: DoDAF 2.02)

Systems Technology and Skills Forecast (SV-9)   The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames that will affect future system development. (Context: DoDAF 2.02)

Systems Viewpoint (SV)   For legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions. (Context: DoDAF 2.02)

Systems-Services Matrix (SvcV-3a)   The relationships among or between systems and services in a given architectural description. (Context: DoDAF 2.02)

Systems-Systems Matrix (SV-3)   The relationships among systems in a given Architectural description. It can be designed to show relationships of interest (such as system-type interfaces, planned versus existing interfaces). (Context: DoDAF 2.02)

tacit knowledge   Much of the relevant knowledge that exists in people’s heads and in the context of relationships that people form with each other (such as team, project, and business level knowledge). The ability of an organization to create value is critically dependent on its employees’ tacit knowledge—what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose. (Context: Systems Engineering)

target architecture   The representation of a desired future state or “to be built” for the enterprise within the context of the strategic direction. (Context: Common Approach/FEAF2)

taxonomy   The study of the general principles of scientific classification. (Context: Merriam Webster Dictionary and Thesaurus)

taxonomy of architecture views   The organized collection of all views pertinent to an architecture. (Context: TOGAF 9)

taxonomy view type (Tx)   Presents all the elements as a standalone structure. Presents all the elements as a specialization hierarchy and provides a text definition for each one and references the source of the element. (Context: Unified Architecture Framework)

technical reference model (TRM)   As part of TOGAF, the TRM provides a model and taxonomy of generic platform services. (Context: TOGAF 9)

technical review board or committee (TRB/TRC)   A committee that ensures the technology choices made by the organization are the best options for all groups and departments. Although many organizations lack an established TRB or review process, establishing and maintaining a TRB process does not need to be overly complicated. (Context: General)

technical standards profile (I-3)   Collects the various systems standards rules that implement and sometimes constrain the choices that can be made in the design and implementation of an architecture. Equivalent to DoDAF StdV-1: Standards Profile. (Context: Common Approach/FEAF2)

technology and infrastructure model   A set of technologies including IT as well as the infrastructure of services, networks, and transport mechanisms to enable and create new revenues in the business model, and to support current operations in the operating model. (Context: General)

technology architecture   A description of the structure and interaction of the platform services, and logical and physical technology components. (Context: TOGAF 9)

technology component   An encapsulation of technology infrastructure that represents a class of technology product or specific technology product. (Context: TOGAF 9)

technology forecast (I-4)   The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future infrastructure development. Equivalent to DoDAF SV-9: Systems Technology and Skills Forecast and SvcV-9: Services Technology and Skills Forecast. (Context: Common Approach/FEAF2)

technology portfolio catalog   Identifies and maintains a list of all the technology in use across the enterprise, including hardware, infrastructure software, and application software. The technology portfolio supports life cycle management of technology products and versions and also forms the basis for definition of technology standards. (Context: TOGAF 9)

technology standards catalog   Documents the standards for technology across the enterprise covering technologies, and versions, the technology life cycle, and the refresh cycles for the technology. (Context: TOGAF 9)

The Open Group Architecture Framework (TOGAF)   An architecture framework that provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a reusable set of existing architecture assets. (Context: TOGAF 9)

to-be architecture   Represents the planned state of the enterprise at a specific date in the future. This is sometimes called the vision or target architecture. (Context: General)

TOGAF   See The Open Group Architecture Framework (TOGAF).

traceability view type (Tr)   Describes the mapping between elements in the architecture—between different viewpoints within domains, between domains, or between structure and behaviors. (Context: Unified Architecture Framework)

transition architecture   A formal description of one state of the architecture at an architecturally significant point in time. One or more transition architectures may be used to describe the progression in time from the baseline to the target architecture. (Context: TOGAF 9)

UDDI (Universal Description, Discovery, and Integration) registry   An XML-based registry for businesses worldwide to list themselves on the Internet. Its ultimate goal is to streamline online transactions by enabling companies to find one another on the Web and make their systems interoperable for e-commerce. (Context: General)

Unified Architecture Framework (UAF)   An ontology that provides a unified ontology for the defense architecture frameworks as well as for commercial enterprise frameworks. UAF is defined in Unified Modeling Language (UML). (Context: Unified Architecture Framework)

Unified Architecture Framework Profile (UAFP)   A profile for SysML that can be used to customize a UML-based tool for development of DoDAF architecture descriptions. (Context: Unified Architecture Framework)

Unified Capabilities Reference Architecture   A framework intended to guide and align DoD component instantiation of respective unified capabilities implementation plans and solutions. (Context: Joint Instruction)

Unified Modeling Language (UML)   A notation used to represent models that is not based on a specific methodology. UML is based on the object-oriented paradigm and is capable of supporting profiles for a variety of metamodels. (Context: Unified Architecture Framework)

Universal Profile for DoDAF and MODAF    A profile that adapts a UML-based tool to support both DoDAF and MODAF. Unified Architecture Framework is superseding this profile. (Context: Unified Architecture Framework)

use case narrative and diagram (B-5)   Describes a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. (Context: Common Approach/FEAF2)

value chain diagram   Provides a high-level orientation view of an enterprise and how it interacts with the outside world. In contrast to the more formal functional decomposition diagram developed within Phase B (Business Architecture), the value chain diagram focuses on presentational impact. The purpose of this diagram is to on-board and align stakeholders for a particular change initiative, so that all participants understand the high-level functional and organizational context of the architecture engagement. (Context: TOGAF 9)

value creation   The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. (Context: Systems Engineering)

verification and validation (V&V)   In software project management, software testing, and software engineering, the process of checking that a software system meets specifications and that it fulfills its intended purpose. It may also be referred to as software quality control. (Context: General)

view

A representation of a whole system from the perspective of a related set of concerns. (Context: IEEE Std 1471-2000)

The representation of a related set of concerns, as part of a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature. (Context: TOGAF 9)

viewpoint

A pattern or template for representing one set of concerns relative to an architecture. A viewpoint provides the formalization of the groupings of models. (Context: IEEE Std 1471-2000)

A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from—the vantage point or perspective that determines what you see. (Context: TOGAF 9)

vision   An end that describes the future state of the enterprise, without regard to how it is to be achieved; a mental image of what the future will or could be like. (Context: DoDAF 2.02)

Vision (CV-1)   In the Capability Viewpoint, a view that addresses the enterprise concerns associated with the overall vision for transformational endeavors and thus defines the strategic context for a group of capabilities. (Context: DoDAF 2.02)

vision statement   The part of a strategic plan that succinctly describes the competitive strategy of the enterprise. (Context: Common Approach/FEAF2)

web-enabled   Applications and services that are accessed through a web browser and function through an internal and/or external Internet-protocol based collaboration environment such as the Internet, or local area network, wide area network, public cloud, private cloud, and hybrid cloud). (Context: Common Approach/FEAF2)

wireless connectivity diagram (I-6)   Diagrams a communications network that provides connectivity to wireless devices. (Context: Common Approach/FEAF2)

wiring closet diagram (I-9)   Diagrams the layout and contents of a wiring closet. (Context: Common Approach/FEAF2)

work breakdown structure (WBS)   A key project deliverable that organizes the team’s work into manageable sections. (Context: General)

work package   A set of actions identified to achieve one or more objectives for the business; can be a part of a project, a complete project, or a program. (Context: TOGAF 9)

Zachman Framework   An enterprise ontology and a fundamental structure for EA, which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two-dimensional classification schema that reflects the intersection between two historical classifications. (Context: General)