Produced by

Abstraction

TOGAF: Abstraction

The technique of providing summarized or generalized descriptions of detailed and complex content.

Abstraction, as in "level of abstraction", can also mean providing a focus for analysis that is concerned with a consistent and common level of detail or abstraction. Abstraction in this sense is typically used in architecture to allow a consistent level of definition and understanding to be achieved in each area of the architecture in order to support effective communication and decision-making. It is especially useful when dealing with large and complex architectures as it allows relevant issues to be identified before further detail is attempted.

Activity

ISO 42020: Activity

Actor

TOGAF: Actor

A person, organization, or system that has a role that 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.

Agency

FEAF-II: Agency

Any executive department, military department, bureau, government corporation, government-controlled corporation, independent regulatory agency, or other organization in the Executive Branch of the United States Federal Government.

Alignment

FEAF-II: Alignment

Application

TOGAF: Application

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.

Application Platform Interface (API)

TOGAF: Application Platform Interface (API)

Application Reference Model (ARM)

FEAF-II: Application Reference Model (ARM)

ARM version 1.0 is one of six reference models of the Federal Enterprise Architecture (FEA) version 2.0. It is a classification taxonomy used to describe the type of software applications in a particular architecture at the system, segment, agency, sector, federal, national, or international level. The ARM can help to identify opportunities for collaboration, shared services, and solution reuse in agency IT portfolios and inter-agency Lines of Business.

Architecting

ISO 42020: Architecting

conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout the life cycle for an architecture entity

SOURCE: ISO/IEC/IEEE 42010:2011, modified – the word “system” has been replaced with “architecture entity”. Notes 1 and 2 have been added.

Note 1 to entry: The entity to be architected can be of several kinds, as illustrated in the following examples: system, enterprise, solution, business, data, application, information technology, mission, product, service, software, etc. See Annex E.4 for more information on this topic.

Note 2 to entry: Certifying the proper implementation of an architecture is sometimes captured as a formal statement by the architect to the client or user that the system, as built, meets the criteria as ready for use.

Architectural Style

TOGAF: Architectural Style

Architecture

FEAF-II and EA3: Architecture

A systematic approach that organizes and guides design, analysis, planning, and documentation activities.

ISO 42020: Architecture

fundamental concepts or properties of an architecture entity in its environment embodied in its elements, relationships, and in the principles of its design and evolution

SOURCE: ISO/IEC/IEEE 42010:2011, modified to – The word replace “system” has been replaced with “architecture entity”. Notes 1, 2 and 3 have been added to allow for a more generalized usage of architecture when the processes in this document are applied.
Note 1 to entry: The concept of architecture used in this document goes beyond the conventional use where the architecture entity is a system. This allows for a more generalized usage of architecture when the processes in this document are applied.
Note 2 to entry: The architectures being dealt with can be of several kinds, as illustrated in the following examples: system architecture, enterprise architecture, solution architecture, business architecture, data architecture, application architecture, technical architecture, information technology architecture, mission architecture, product architecture, service architecture, software architecture, etc. See Annex E.4 for more information on this topic.
Note 3 to entry: Architecting can address a wide range of concerns expressed through architecture views and models, as illustrated in the following examples: security architecture, functional architecture, physical architecture, resilience architecture, etc. See Annex E for more information on this topic.

TOGAF: Architecture

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).

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

Architecture Building Block (ABB)

TOGAF: Architecture Building Block (ABB)

A constituent of the architecture model that describes a single aspect of the overall model.

Building Block: Represents a (potentially re-usable) 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".

Architecture Ccollection

ISO 42020: Architecture Ccollection

Architecture Continuum

TOGAF: Architecture Continuum

A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization. This Continuum begins with foundational definitions like reference models, core strategies, and basic building blocks. From there it spans to Industry Architectures and all the way to an organization's specific architecture.

Architecture Entity

ISO 42020: Architecture Entity

EXAMPLES The following are kinds of architecture entities that can be dealt with by the architecture processes of this document: enterprise, organization, solution, system, subsystem, business, data (as a data element or data structure), application, information technology (as a collection), mission, product, service, software item, hardware item, etc. The kind of entity can also be a product line, family of systems, system of systems, collection of systems, collection of applications, etc.
Note 1 to entry: When referring to the architecture itself of these architecture entities, it is common practice to place the name of the kind of entity in front of the word architecture. For example, the phrase system architecture is used when the thing being dealt with during the architecting effort is a system. Likewise for the other kinds of entities that are being dealt with during the architecting effort.

Note 1 to entry: The concept of architecture framework has been expanded in this document beyond the way this term is used in the ISO/IEC/IEEE 42010 standard where it is used strictly with regard to the “description of architectures”.

Note 2 to entry: An architecture framework often specifies viewpoints and views. An architecture framework should be developed using ISO/IEC/IEEE 42010.

TOGAF: Architecture Framework

A conceptual structure used to develop, implement, and sustain an architecture.

Architecture Governance

TOGAF: Architecture Governance

The practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It is concerned with change processes (design governance) and operation of product systems (operational governance).

FEAF-II: Architecture Segment

Architecture View

ISO 42020: Architecture View

Information item expressing the architecture from the perspective of specific concerns about the architecture entity.

Note 1 to entry: When the term view is used without any qualifier it refers to the general case. When a qualifier is prepended to the word view, this indicates that the architecture view is specific to a particular viewpoint, such as illustrated in these examples:
– Operational view: when the associated viewpoint is dealing with operations.
– Service view: when the associated viewpoint is dealing with services.

Note 2 to entry: ISO/IEC/IEEE 42010 considers architecture view as a work product contained in an architecture description. This standard goes beyond this specific usage of architecture view to the general case where a view is a perspective of the architecture.

ISO 42010: Architecture View

Work product expressing the architecture of a system from the perspective of specific system concerns

TOGAF

The representation of a related set of concerns. A view is what is seen from 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.

Architecture Viewpoint

ISO 42020: Architecture Viewpoint

Conventions for the construction, interpretation and use of architecture views to frame specific concerns about the architecture entity.

Note 1 to entry: When the word viewpoint is used without any qualifier it refers to the general case. When a qualifier is prepended to the word viewpoint, this indicates that the viewpoint applies to a specific set of concerns, such as in the following examples: operational viewpoint, capability viewpoint, services viewpoint.

Note 2 to entry: ISO/IEC/IEEE 42010 considers architecture viewpoint as a work product contained in an architecture description or an architecture framework. This standard goes beyond this specific usage of architecture viewpoint to the general case where the viewpoint corresponds to the conventions for the different architecture views.

Note 3 to entry: ISO/IEC/IEEE 42010 specifies that an architecture view shall be governed by its viewpoint and a view shall be composed of one or more architecture models.

ISO 42010: Architecture Viewpoint

Work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns.

TOGAF

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.

Architecture Vision

TOGAF: 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.

FEAF-II: Artifact

TOGAF 9

Baseline

TOGAF: Baseline

A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.

FEAF-II: Baseline Architecture

Boundaryless Information Flow

TOGAF: Boundaryless Information Flow

A trademark of The Open Group.

A shorthand representation of "access to integrated information to support business process improvements" representing a desired state of an enterprise's infrastructure specific to the business needs of the organization.

An infrastructure that provides Boundaryless Information Flow has open standard components that provide services in a customer's extended enterprise that:

Combine multiple sources of information

Securely deliver the information whenever and wherever it is needed, in the right context for the people or systems using that information.

Business Reference Model

FEAF-II: Business Reference Model

Business Reference Model (BRM) version 3.0 is one of six reference models of the Federal Enterprise Architecture (FEA) version 3.0. It is a classification taxonomy used to describe the type of business functions and service types in a particular solution architecture at the system, segment, agency, sector, federal, national, or international level. The taxonomy identifies business function and sub-function areas as well as related services that are performed within and between federal agencies and with external partners. The BRM can help to identify opportunities for collaboration, shared services, and solution reuse in agency IT portfolios and inter-agency Lines of Business.

Business Service

TOGA: Business Service

Capability

TOGAF: Capability

An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.

Capability Increment

TOGAF: Capability Increment

Capital Planning

EA3: Capital Planning

The management and decision-making process associated with the planning, selection, control, and evaluation of investments in resources, including EA components such as systems, networks, knowledge warehouses, and support services for the enterprise.

Capital Planning and Investment Control

FEAF-II: Capital Planning and Investment Control

Capital Planning and Investment Control (CPIC) means the same as capital programming and is 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.

Change Management

FEAF-II and EA3: 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.

Chief Information Officers Council

FEAF-II: Chief Information Officers Council

Chief Information Officers Council (CIO Council) refers to the Federal CIO Council that was established in the E-Government Act of 2002.
documentation that is used by executives, managers, and staff to support resource planning, decision-making, and management.

Communications and Stakeholder Management

TOGAF: Communications and Stakeholder Management

The management of needs of stakeholders of the enterprise architecture practice. It also manages the execution of communication between the practice and the stakeholders and the practice and the consumers of its services.

FEAF-II: Composite

Concern

ISO 42020: Concern

Interest in an entity relevant to one or more of its stakeholders.

SOURCE: ISO/IEC/IEEE 42010:2011, modified – The word “system” has been replaced with “entity”. Notes 1 and Example have been added.

Note 1 to entry: In some cultures like French, being interested in an entity means that existence of this entity provides some impacts for concerned stakeholders. This does not necessary mean that the stakeholders have interest for this entity to exist.

EXAMPLE Generally people are concerned by the construction of an airport close to their home; but they do not want this.

ISO 42010

〈system〉 interest in a system relevant to one or more of its stakeholders.
NOTE A concern pertains to any influence on a system in its environment including: developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.

TOGAF

The key interests that are crucially important to the stakeholders in a system, and 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.

Configuration Management

EA3: Configuration Management

The process of managing updates to EA components and artifacts, ensuring that standards are being followed.

FEAF-II: Configuration Management

the process of managing updates to business and technology resources (e.g., processes, systems, applications, and networks) to ensure that security controls are operating effectively and that standards are being followed.

Constraint

TOGAF: Constraint

An external factor that prevents an organization from pursuing particular approaches to meet its goals. For example, customer data is not harmonized within the organization, regionally or nationally, constraining the organization's ability to offer effective customer service.

FEAF-II: Current View

Data

EA3: Data

Data items refer 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.

FEAF-II: Data

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.

Data Architecture

TOGAF

Data Reference Model

FEAF-II: Data Reference Model

Data Reference Model (DRM) version 2.0 is one of six reference models of the Federal Enterprise Architecture (FEA) version 2.0. It 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. The DRM can help to identify opportunities for collaboration, shared services, and solution reuse in agency IT portfolios and inter-agency Lines of Business.

Deliverable

TOGAF: Deliverable

An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are 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 at a point in time.

Electronic Government

FEAF-II: Electronic Government

means the use by the Federal Government of web-based Internet applications and other information technologies, combined with processes that implement these technologies, to (a) enhance the access to and delivery of Government information and services to the public, other agencies, and other Government entities, or (b) bring about improvements in Government operations that may include effectiveness, efficiency, service quality, or transformation.

Enterprise

EA3: Enterprise

An organization or sub-activity whose boundary is defined by commonly-held goals, processes, and resources. This includes whole organizations in the public, private, or non-profit sectors, part(s) of an organization such as business units. programs, and systems, or part(s) of multiple organizations such as consortia and supply chains.

2005: An area of common activity and goals within an organization or between several organizations, where information and other resources are exchanged.

FEAF-II: Enterprise

means an area of common activity and goals within an organization or between several organizations, where information and other resources are exchanged.

TOGAF

The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.

Enterprise Architecture

EA3: Enterprise Architecture

The analysis and documentation of an enterprise in its current and future states from an integrated strategy, business, and technology perspective.

FEAF-II: Enterprise Architecture

means a strategic information asset base, which 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; and includes a baseline architecture, a target architecture, and a sequencing plan.

Enterprise Continuum

TOGAF

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.

ISO 15704: Enterprise Model

Enterprise Roadmap

FEAF-II: Enterprise Roadmap

refers to the document that is produced at least annually by the organization responsible for the enterprise (usually a Federal Agency) and which describes the current and future views of the enterprise-wide architecture, how changes occur, and how the EA program functions.

Entity

ISO 15704: Entity

Environment

ISO 15704: Environment

Context that determines the setting and circumstances of technological, business, operational, organizational, political, regulatory, social, and other critical influences and constraints upon an enterprise that affect its development and behaviour but are not controllable by the enterprise itself.

SOURCE: adapted from ISO/CEN 19439:2006 and ISO/IEC/IEEE 42010:2007

ISO 42010: Environment

〈system〉 Context determining the setting and circumstances of all influences upon a system.
NOTE The environment of a system includes developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences.

Executive Sponsor

EA3: Executive Sponsor

Federal Enterprise Architecture

FEAF-II: Federal Enterprise Architecture

Federal Enterprise Architecture (FEA) is a business-based documentation and analysis framework for government-wide improvement. The FEA allows 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 is comprised of 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 5-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.

Note 1 to entry: The concept of architecture framework has been expanded in this document beyond the way this term is used in the ISO/IEC/IEEE 42010 standard where it is used strictly with regard to the “description of architectures”.

Note 2 to entry: An architecture framework often specifies viewpoints and views. An architecture framework should be developed using ISO/IEC/IEEE 42010.

ISO 15704

Structure expressed in diagrams, text and formal rules, which relates the components of a conceptual enterprise architecture to each other.

SOURCE: adapted from ISO/CEN 19439:2006

EA3: Framework

The EA framework is a structure for organizing information that defines the scope of the architecture – what the EA program will document and the relationship of various areas of the architecture.

FEAF-II: 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.

ISO 42010: Architecture framework

Deprecated, see 42020. Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders

TOGAF

A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness.

Government Publication

FEAF-II: Government Publication

Horizontal Component

EA3: Horizontal Component

A horizontal (or crosscutting) component is a changeable goal, process, program, or resource that serves several lines of business. Examples include email and administrative support systems that serve the whole enterprise.

Information Resource Management Strategic Plan

FEAF-II: Information Resource Management Strategic Plan

Information Resource Management Strategic Plan is strategic in nature and 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 decisions are integrated with management support areas including organizational planning, budget, procurement, financial management, and HR.

Information Security

FEAF-II: Information Security

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 lifecycle. This includes implementation and activities associated with NIST SP-800-37, Security Awareness training, SP-800-39 regarding the implementation of a Risk Management Framework and continuous monitoring, SP-800-53A security controls, and FISMA compliance reporting, development of security policy, and security audits and testing.

Information System

FEAF-II: Information System

Information System means 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.

Information System Life Cycle

FEAF-II: Information System Life Cycle

Information Technology

EA3

A type of resource that supports the creation, analysis, sharing, archiving, and/or deletion of data and information throughout an enterprise.

FEAF-II: Information Technology

Information Technology (IT) means 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, Sub-project, Service, and System.

TOGAF

The lifecycle management of information and related technology used by an organization.

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.

A term commonly assigned to a department within an organization tasked with provisioning some or all of the domains described in (2) above.

Information Technology Investment

FEAF-II: Information Technology Investment

means the expenditure of IT resources to address mission delivery and management support. An IT investment 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.

Infrastructure Reference Model

FEAF-II: Infrastructure Reference Model

Infrastructure Reference Model (IRM) version 1.0 is one of six reference models of the Federal Enterprise Architecture (FEA) version 2.0. It is a classification taxonomy used to describe the type of voice, data, video, cloud, and mobile host environments in a particular solution architecture at the system, segment, agency, sector, federal, national, or international level. The IRM can help to identify opportunities for collaboration, shared services, and solution reuse in agency IT portfolios and inter-agency Lines of Business.

Knowledge

FEAF-II and EA3: Knowledge

Knowledge consists of data or information that have been organized and processed to convey understanding, experience, accumulated learning, and expertise as they apply to a current problem or activity. Data that are processed to extract critical implications and to reflect past experience and expertise provide the recipient with organizational knowledge, which has a very high potential value.

Life history

ISO 15704: Life history

Line of Business

EA3: Line of Business

A distinct area of activity within the enterprise. It may involve the manufacture of certain products, the provision of services, or internal administrative functions.

FEAF-II: Line of Business (LOB)

means 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.

Logical

TOGAF: Logical

An implementation-independent definition of the architecture, often grouping related physical entities according to their purpose and structure. For example, the products from multiple infrastructure software vendors can all be logically grouped as Java application server platforms.

Major Investment

FEAF-II: Major Investment

means 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. OMB 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 for those an OMB Circular A-11 Exhibit 300 annual submission is required. IT investments not considered “major” are categorized in the annual Exhibit 53 IT budget request submission as “non-major.”

Managing Partner

FEAF-II: Managing Partner

Managing Partner represents the agency designated as the lead agency responsible for coordinating the implementation of the E-Gov or Line of Business (LoB) initiative. The managing partner is 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. Please refer to the OMB MAX portal for additional information on managing partner reporting requirements for IT investments.

Method

TOGAF: Method

Methodology

EA3: Methodology

The EA methodology defines how EA documentation will be developed, archived, and used; including the selection of a framework, modeling tools, and on-line repository.

FEAF-II: Methodology

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.

TOGAF

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.

Mission Statement

FEAF-II and EA3: Mission Statement

Model

ISO 42020: Model

Abstracted representation of an entity or collection of entities that provides the ability to portray, understand or predict the properties or characteristics of the entity or collection under conditions or situations of interest.

Note 1 to entry: A model can use a formalism that could be based on mathematical or scientific principles and concepts. A model can be generated using an established metamodel. Metamodels are often used to facilitate development of accurate, complete, consistent and understandable models.

Note 2 to entry: A model can be used to construct or express architecture views of the entity. Descriptive models and analytic models are two kinds of models. A model that is used to generate an architecture view should be governed by a model kind specified in the viewpoint for that view in accordance with ISO/IEC/IEEE 42010.

Note 3 to entry: A reference model can be used to capture a general case that is used as the basis for creating special case models for particular conditions or situations. A reference model can be used to encourage and enforce uniformity of architectures and architecture elements.

TOGAF

A representation of a subject of interest. A model provides a smaller scale, simplified, and/or abstract representation of the subject matter. A model is constructed as a "means to an end". In the context of enterprise architecture, 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; i.e., their "viewpoints" in relation to the subject matter.

New IT Investment

FEAF-II: New IT Investment

means an IT investment and its associated projects newly proposed by the agency that has not been previously funded by OMB. This does not include investments existing within the agency that have not previously been reported to OMB.

National Security System

FEAF-II: National Security System

means any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) 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).

FEAF-II: Non-Major Investment

Objective

TOGAF: Objective

A time-bounded milestone for an organization used to demonstrate progress towards a goal; for example, "Increase Capacity Utilization by 30% by the end of 2009 to support the planned increase in market share".

On-Going Investment

FEAF-II: On-Going Investment

means 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.

Operations

FEAF-II: Operations

mean the day-to-day management of an asset in the production environment and include activities to operate data centers, help desks, data centers, telecommunication centers, and end user support services. Operational activities for major IT investments are reported through Section C of the Exhibit 300B. 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.

Organization

ISO 42020: Organization

EXAMPLE: Company, corporation, firm, enterprise, institution, charity, sole trader, association, or parts or combination thereof. Note 1 to entry: An identified part of an organization (even as small as a single individual) or an identified group of organizations can be regarded as an organization if it has explicitly stated responsibilities, authorities and relationships. A body of persons organized for some specific purpose, such as a club, union, corporation, or society, can be an organization. Note 2 to entry: One or more organizations will participate in an enterprise. In case of multi-organization enterprises, each of the organizations brings various resources forward for use in the enterprise and they participate to the extent that they benefit from their involvement. The purpose of the enterprise is to address some challenges that these participating organizations cannot readily address on their own. Within a single organization, an enterprise may refer to a subset of the organization which is typically addressing particularly challenging or complex issues, often over a defined duration, and may undertake this with certain relaxations, tightening or otherwise authorized modifications of standard corporate processes and practices. (See definition of enterprise).

Partner Agency

FEAF-II: Partner Agency

represents the agency for an E-Gov or LOB initiative designated as an agency that should provide resources (e.g., 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.

Patterns

TOGAF: Patterns

A technique for putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

Performance Management

TOGAF: Performance Management

Performance Reference Model

FEAF-II: Performance Reference Model

Performance Reference Model (PRM) ) supports architectural analysis and reporting in the strategy sub-architecture view of the overall EA. The PRM allows agencies to better manage the business of government at a strategic level, by providing a means for using the EA to measure the success of investments and their impact on strategic outcomes. The PRM shows the linkage between internal business components and the achievement of business and customer-centric outputs and outcomes. This line of sight is articulated through the PRM’s hierarchical taxonomy and the use of “Measurement Area”, “Category”, “Grouping”, and “Indicator” information areas.

Primitive

EA3: Primitive

FEAF-II: Primitive

Privacy Impact Assessment

FEAF-II: Privacy Impact Assessment

Privacy Impact Assessment (PIA) is 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.

EA3: Project

FEAF-II: Project

Quality Assurance

FEAF-II: Quality Assurance

Quality Assurance is 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.

Records

FEAF-II: Records

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 material 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.

Records Management

FEAF-II: Records Management

means the planning, controlling, directing, organizing, training, promoting, and other managerial activities involved with respect to records creation, records maintenance and use, and records 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))

Reference-base

ISO 15704: Reference-base

Reference Model (RM)

TOGAF: Reference Model (RM)

A reference model is 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 non-specialist. 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. Note: The source of this definition is OASIS; refer to www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

Repository

ISO 42020: Repository

Place where work products and the associated information items are or can be stored for preservation and retrieval.

Note 1 to entry: Repository items should be under configuration control.

Note 2 to entry: In a repository, work products and other items are preserved for future retrieval when needed, whereas in a library, working data is temporarily stored and retrieved as necessary.

TOGAF

A 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.

Requirement

TOGAF: Requirement

Resource

ISO 15704: Resource

(enterprise) entity that provides some or all of the capabilities required to execute an enterprise activity

SOURCE: ISO 19439:2006

Note 1 to entry: In this IS, resource is used in the system theory sense of entities that provide capabilities required by the enterprise and are an essential part of the enterprise itself. The resource description includes the identification and description of consumables (such as energy, air, coolant) that are required to be present in sufficient quantities to operate the resource. In contrast, material is reserved for process inputs that are required by the various processes such as raw materials, parts and assemblies. These inputs are identified in the function view, described in the information view, and have the associated management responsibilities identified in the organization view.

Security Reference Model

FEAF-II: Security Reference Model

Security Reference Model (SRM) version 1.0 is one of six reference models of the Federal Enterprise Architecture (FEA) version 2.0. It is a classification taxonomy used to describe the type of security controls in a particular architecture at the system, segment, agency, sector, federal, national, or international level. The SRM can help to identify opportunities for collaboration, shared services, and solution reuse in agency IT portfolios and inter-agency Lines of Business.

Segment Architecture

FEAF-II: Segment Architecture

Segment Architecture is a detailed, results-oriented architecture (baseline and target) and a transition strategy for a portion or segment of the enterprise. 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.

TOGAF

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

Service Consumer

FEAF-II: Service Consumer

means 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.

Service Orientation

TOGAF

Service Oriented Architecture

FEAF-II: Service Oriented Architecture

TOGAF

An architectural style that supports service orientation. It has the following distinctive features:

It is based on the design of the services - which mirror real-world business activities - comprising the enterprise (or inter-enterprise) business processes.

Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.

It places unique requirements on the infrastructure - it is recommended that implementations use open standards to realize interoperability and location transparency.

Implementations are environment-specific - they are constrained or enabled by context and must be described within that context.

It requires strong governance of service representation and implementation.

Service Provider

FEAF-II: Service Provider

Service Provider means 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.

Shared Service

FEAF-II: Shared Service

Solution Architecture

FEAF-II: Solution Architecture

Solution Architecture is a standardized method of identifying business requirements and viable technology solutions within the context of a single agency’s enterprise architecture or a multi-agency 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 doing solution architecture through projects at various levels of scope in the federal sector.

TOGAF

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.

Stakeholder

ISO 42020: Stakeholder

Individual or organization having a right, share, claim, or interest in an architecture or in its possession of characteristics that meet their needs and expectations.

SOURCE: ISO/IEC/IEEE 15288:2015, modified – The word “system” has been replaced with “architecture”.

FEAF-II and EA3: Stakeholder

means those who are or will be affected by a program, activity, or resource. EA3: Stakeholders for the EA program include sponsors, architects, program managers, users, and support staff.

ISO 42010: Stakeholder

〈system〉 Individual, team, organization, or classes thereof, having an interest in a system.

TOGAF

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.

System

ISO 42020: System

Combination of interacting elements organized to achieve one or more stated purposes.

SOURCE: ISO/IEC/IEEE 15288:2015, modified – in note 1 “the services it provides” is replaced by “a set of services”; note 3 is from ISO/IEC/IEEE 15288:2008.

Note 1 to entry: A system is sometimes considered as a product or as a set of services. Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g., aircraft system. Alternatively, the word “system” is substituted simply by a context-dependent synonym, e.g., aircraft, though this potentially obscures a system principles perspective. Note 3 to entry: A system element is a discrete part of a system that can be implemented to fulfill specified requirements. A system element can be hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, minerals), or any combination.

EA3: System

A type of EA component that is comprised of hardware, and software, and activities that has inputs and outputs.

2005: A type of EA component that is comprised of technology and activities that has inputs and outputs.

FEAF-II: System

means a tangible IT asset that is comprised of hardware devices, software applications, databases, users, processes, and security controls.

Systems Development Life Cycle

FEAF-II: Systems Development Life Cycle

Systems Development Life Cycle (SDLC) is guidance, policies, and procedures, for developing systems throughout their life cycle, including requirements, design, implementation testing, deployment, operations, and maintenance.

Target Architecture

FEAF-II: Target Architecture

Target Architecture is the representation of a desired future state or “to be built” for the enterprise within the context of the strategic direction.

TOGAF:

The description of a future state of the architecture being developed for an organization. There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.

Technology Architecture

TOGAF

Transition Architecture

TOGAF: 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.

Vision Statement

FEAF-II and EA3: Vision Statement

Web-enabled

FEAF-II: Web-enabled

Web-enabled means applications and services that are accessed through a web browser and function through an internal and/or external Internet-protocol based collaboration environment (e.g., Internet, local area network, wide area network, public cloud, private cloud, and hybrid cloud).

Work product

ISO 42020: Work product

Dialog

Popup

I have an id of "popup" on my page container and only look like a dialog because the link to me had a data-rel="dialog" attribute which gives me this inset look and a data-transition="pop" attribute to change the transition to pop. Without this, I'd be styled as a normal page.