The performance architecture aims to align strategic goals and objectives with specific metrics that can be applied to processes, systems, and technology in order to evaluate success against those goals. The goal of performance architecture is to provide the ability to take corrective action on performance results, the capability to measure resource contributions to specific mission value, and the ability to influence strategic objectives. Improved performance is realized through greater focus on mission, agreement on goals and objectives, and timely reporting of results.
The ICAM performance architecture consists of the following components:
Business Challenges Analysis. Provides an overview of the challenges within the current ICAM environment. Business challenges often represent strategic improvement opportunities for the target state architecture.
Business Drivers, Goals, and Objectives. Describes the goals, drivers, and objectives for ICAM. The drivers show a direct link to the policies and other guidance documents impacting ICAM implementation.
Performance Metrics. Create a reporting framework to measure the activities and investments within the ICAM segment.
Although the performance architecture is typically listed first among the segment layers, it frequently “book ends” the architectural development process, with the definition of strategic goals and objectives occurring in the earliest stages and the refinement and acceptance of performance metrics occurring as one of the last steps in creating the transition plan. The placement of the components of the performance architecture in the Roadmap reflects this split development of the layer.
In order to develop the performance metrics, the development team reviewed many as-is performance metrics that agencies use to track against individual ICAM investments through the OMB Exhibit 300. Analysis of the as-is metrics revealed that agencies are not tracking consistent metrics. Additionally, the majority of the agencies surveyed currently track metrics by one or more of the following individual, rather than integrated initiatives: PKI, PIV, and E- Authentication.
The business architecture is a functional perspective of the operations conducted within the ICAM segment. Segment architecture is driven by business management and delivers products that improve the delivery of business services to citizens and agency staff. As such, the business architecture provides the main viewpoint for the analysis of data, service components, and technology at the lower layers of the architecture.
The ICAM business architecture consists of the following components:
- Business Value Chain Analysis. Identifies the high-level logical ordering of the chain of processes that deliver value. This output has been modified from the FSAM template in order to gain applicability at the federal level.
- As-is and Target Use Cases. Provides the high-level common business processes that support ICAM functionality. The use cases provide the structure for the detailed architectural information at the Data, Service, and Technology layers of the architecture.
Business Value Chain Analysis
From an architectural perspective, the business processes for ICAM include multiple actions that are chained together. The achievement of the final outcome of the process relies on the completion of each action within the established chain. In developing a preliminary list of business processes within ICAM, the development team determined that each of the ICAM business process chains deliver value through a link back to one or more of the E-Government service sectors. The sectors are:
- Government to Citizen (G2C). Aims to facilitate interaction between government and the American public.
- Government to Business (G2B). Drives interaction between agencies and the private sector.
- Government to Government (G2G). Fosters the development of inter-agency relationships and information sharing across all levels of government (Federal, state, local and tribal).
- Internal Efficiency and Effectiveness (IEE). Drives internal agency processes and activities to become more friendly, convenient, transparent, and cost-effective.
The E-Government sectors are used as a framework in the development of each of the layers of the architecture. In the use cases, certain business functions are categorized separately because the processes varied depending on the sector addressed (e.g., the processes for creating and maintaining identity data for internal employees versus citizens or business partners). Likewise, at the data and technology layers, different data repositories or technologies may fulfill the same business process for different sectors (e.g., business partners and other government entities may use a PIV-interoperable (PIV-I) credential to access Federal Government resources, whereas a citizen may use an alternate third-party credential).
The following figure provides a summary of some of the common user populations within each E-Government sector and the respective credential types that support ICAM transactions.
Use Cases Overview
As the main component of the ICAM business architecture, the Roadmap Development Team (RDT) identified common use cases that capture the main ICAM business processes. The use cases are not agency specific and instead are intended to capture the common set of activities and challenges facing agencies today in the current state and the ways in which those challenges can be addressed in a desired target state. Agencies are expected to tailor these use cases for their own ICAM segment architectures, which should align with this document.
The architecture analysis sections of each use case additionally provide the following details specific to the use case that support the business architecture layer:
- E-government Alignment. Mapping to one of the ICAM E-Government sectors.
- Trigger. Event that initiates the process; may be more than one trigger in a use case.
- Actors. Individuals, systems or organizations involved in the specific processes described for each use case.
- Endpoints. Termination points in the process flow where a specific outcome is achieved or a specific output is produced.
Data architecture is the planning and implementation of data assets including the set of data, the processes that use that data and the technologies selected for the creation and operation of information systems. From an enterprise architecture (EA) perspective, data architecture is not the set of detailed models of individual systems; instead, it provides the “big picture” including the information/data stored across the enterprise, the information that needs to be shared, and the ways in which that information should be shared through the use of exchange standards.
The ICAM data architecture consists of the following components:
- Inventory of Government-wide Data Sources and Data Elements. Lists and describes the major cross-government ICAM data repositories, the information contained in them, and the E-Government sectors they service.
- Target Information Flow Diagrams. Depicts the key information flows found in the business processes and assists in discovery of opportunities for re-use of information in the form of information-sharing services.
Inventory of Government-wide Data Sources and Elements
Cross-government repositories are those that are used between one or more agencies and include systems and data stores. Agency-specific systems are unique to a particular agency and do not serve as an authoritative source outside of that agency.
Use Case Data Details Overview
Each use case identifies the following data architecture-related details:
- Data Repositories and Systems. A central place where data is stored and maintained; a place where multiple databases or files are located for distribution over a network. For each use case, the identified data repositories may be cross-government or agency specific. Wherever possible, repositories or systems that possess data elements identified as authoritative have themselves been identified as authoritative.
- Data Elements. An individual data field stored within a repository or transmitted as part of a transaction. The data elements identified in the use cases are typically identity attributes, such as address, first name, biometric sample, etc. For agency or mission specific elements, different additional elements will be identified.
- Data Standards. The required content and format in which particular types of data are to be presented and exchanged such as the National Information Exchange Model (NIEM). Data standards are normally tied to a specific mission or business context and are governed by a group of stewards.
The service architecture provides a functional framework for identifying and evaluating government-wide opportunities to leverage IT investments and assets from a service perspective. This model helps understand the services delivered by the government and assess whether there is an opportunity to group like services and create opportunities for reuse or shared services. The ICAM service architecture consists of the Services Framework, a functional framework that classifies ICAM service components with respect to how they support business and/or performance objectives.
In order to develop the ICAM Services Framework, existing service frameworks from a number of sources were reviewed, including:
- FEA Service Component Reference Model (SRM)
- HSPD-12 Shared Component Architecture v0.1.6
- International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) JTC 1/SC27 N7237 – IT Security Techniques
- OneVA Identity Services Segment Architecture
- DoD Net-Centric Enterprise Services (NCES)
- DoD Enterprise Services Security Framework (ESSF)
Following the review, several working sessions were conducted to define and gain consensus on the service types and components necessary to support the ICAM segment.
The figure represents two main layers of the Services Framework:
- Service Type. Provides a layer of categorization that defines the context of a specific set of service components. The service types in the diagram are represented by the darker blue, outer boxes.
- Service Component. A self-contained business process or service with predetermined and well-defined functionality that may be exposed through a well-defined and documented business or technology interface. The service components in the diagram are represented by the lighter blue, inner boxes.
It is important to note that while the ICAM Services Framework seeks to provide a common set of services to support common needs across agencies, it is not intended to preclude an agency for augmenting or customizing the framework to provide services to support agency-specific scenarios and to incorporate their mission needs and existing infrastructure.
The technical architecture provides the foundation for the components of the Services Framework, which in turn support the business layer and business-driven approach of the use cases. Specifically, the technical architecture is used to describe proposed technical solutions using a standard vocabulary and categorization scheme. As agencies propose solutions to fulfill the ICAM segment, the technical architecture allows those solutions to be analyzed for their fit with the desired target state, for duplication with other efforts, and for the architectural gaps they might fill. In addition, it facilitates the re-use of technology across agencies.
The ICAM technical architecture consists of the following components:
- As-is System Interface Diagrams. Provide a depiction of the as-is “conceptual solution architecture”, which shows the existing systems and services in the as-is state and identifies the relationships between them.
- Target System Interface Diagrams. Provide a depiction of the target “conceptual solution architecture”, which shows the proposed systems and services in the target state and identifies the relationships between them.
Technical standards provide the types of product specifications needed, network protocols, or other technical components of the architecture.
In order to maintain government-wide applicability, the ICAM technical architecture is provided at a higher level than would typically be expected for a segment. As each agency aligns with the ICAM segment, the technical architecture may be translated to a more detailed level as needed by an agency to map the specific products and standards supporting ICAM systems to the overarching framework.
System Interface Diagrams
Today agencies are employing myriad processes for implementing ICAM capabilities as well as different types of technologies and standards to support these processes. There is such a discrepancy between the ways in which agencies perform ICAM functions that agency systems are not interoperable, stove-pipes abound, processes are duplicated, and authoritative sources are in many cases unknown. These differences pose a significant challenge in trying to define a single, common as-is system interface diagram at the agency level. In order to overcome that challenge, the following figure depicts an example that is common in many agencies.
The figure above shows ICAM functions performed independently by Physical Access Control Systems (PACS), networks, and other applications. The systems each have ICAM related functions inside their system boundaries with no shared services. Users are forced to contend with multiple incompatible credentialing, authentication, and access control paradigms. Each system also has a separate administrative interface used for enrollment and privilege management. While the diagram has been streamlined to show three different applications, this structure is generally replicated many times over in each agency, creating considerable redundancies and inefficiencies in agency management of ICAM functions. When establishing functionality for use across federal applications, the net result is the same – the user must be re-credentialed, identity proofed, and provisioned in each system across the federal enterprise.
When attempting to represent the government-wide system interfaces, a pattern arose similar to the findings at the agency level; established ICAM architectures are managed in different silos.
Target Conceptual Diagrams
In order to achieve the ICAM goals and objectives identified for the Federal Government, system changes must be made at both the agency and government-wide levels to create increased automation and interoperability within and across ICAM systems.
This example depicts agency networks, PACS, and other applications plugged into a shared agency infrastructure. ICAM functions are handled in the shared infrastructure rather than independently in each system. Authoritative data sources such as Human Resources (HR) systems are also integrated into the shared infrastructure so that enrollment and provisioning can be automated rather than manually entered through various application specific administrative interfaces. The shared infrastructure also exposes user interfaces so that the end user can authenticate to the shared infrastructure once, then access various systems without the need to e-authenticate.
The key transition between the current agency architecture and the target state is the introduction of a shared agency infrastructure providing ICAM functions in place of independent functionality in every system.
The infrastructure should have the following characteristics:
- The shared infrastructure should provide identity management related services to users, such as authentication, federation, and user self-service.
- Applications should access the shared infrastructure to leverage shared identity, credentialing, provisioning, authorization, and auditing services.
- An agency Authoritative Attribute Exchange Service (AAES) should be used to connect various authoritative data sources and share data with the shared infrastructure.
- Users authenticated into the shared infrastructure should have seamless access to all integrated applications for which they have permission to access.
- Authenticated users will have access to data within infrastructure based on attributes. In addition, the shared agency infrastructure will connect to a shared federal infrastructure that provides common, government-wide ICAM services.
The shared federal infrastructure will provide interfaces to PKI SSPs, Identity Providers, attribute repositories, and other services as needed. The integration between shared agency and federal infrastructures will help achieve the objectives of eliminating redundancies and enhancing interoperability across the government.
A key interoperability issue in the current state is a user from one agency being able to use his PIV credential to gain permitted access to facilities and applications at other agencies. Tying agency infrastructures into a shared federal infrastructure will help resolve this issue. The figure depicts the target concept for cross-agency access. A user issued a PIV credential from any agency can be used for access to various systems at other agencies that have integrated with the Shared Federal Infrastructure.
Similar to internal agency users, it is desired that external users in the target state may use a single, third-party credential to achieve a seamless interaction with services across multiple agencies in the Federal Government. The figure shows the scenario where an external user authenticates via an external Identity Provider in order to access services at several different agencies. The external Identity Provider is integrated with the Shared Federal Infrastructure, enabling access to multiple agencies.