• DIEA Mission
  • Executive Summary
  • Introduction
  • Transformation Context
  • Customers of Enterprise Architectures
  • DIEA 1.0 Overview
  • DIEA 1.0 Products and Evolution
• DIEA Priorites
  • Data and Services Deployment (DSD)
  • Secured Availability (SA)
  • Shared Infrastructure Environment
  • Computing Infrastructure Readiness (CIR)
  • Communications Readiness (CR)
  • NetOps Agility (NOA)
• Contact Us

Transformation Context

Tiered Accountability and Federation

The Secretary of Defense sets the strategy, provides oversight, and manages capability integration across all DoD Components (hereafter, simply Components). Recognizing the each Component has its own way of doing business, its own constituencies and its own appropriations, it is essential that Components maintain responsibility for executing their assigned missions, conducting joint operations and ensuring information flows freely across the enterprise.

The Department’s approach to net-centric transformation in this environment is guided by the concepts of Tiered Accountability and Federation. Tiered Accountability aligns responsibility for decision making and execution across the tiers of the Department – DoD Enterprise, Component, and Program. Federation ensures decision makers and implementers understand and align programs and capabilities across tiers. A federated approach allows each tier (in accordance with its Title authority) to leverage the decisions and services of other tiers. Each tier governs the areas for which it is responsible, and should acknowledge and maintain consistency with the guidance from higher tiers. To improve understanding across all tiers, DoD enterprise-level architectures depict department-wide rules and constraints while Component-level architectures depict mission-specific services and capabilities and program-level architectures depict solutions that conform to higher tier rules and constraints.

DoD Enterprise-level Architectures: Purpose and Scope

At the Enterprise level, DoD’s Federated Enterprise Architecture is a set of architectures depicting slices of capability and function that provide guidance to decision makers regarding:

• “What we must do” – a common set of principles, rules, constraints, and best practices that must be followed to meet enterprise goals.
• “How we must operate” – the operational context of the aforementioned principles, rules, constraints, and best practices.
• “When we will transition” - a roadmap (a transition plan) with priorities and strategies for achieving them, as well as milestones, metrics, and resources needed to execute the strategies.

DoD enterprise level architectures typically do not provide implementation guidance or design details for individual systems/solutions, and are not a substitute for management decisions; they simply inform enterprise-wide decisions, and portray the results.

Enterprise architectures focus on three sets of customers:

• Investment Review Boards (IRBs), Capability Portfolio Managers (CPMs), CIOs, and others managing IT investments. In addition to providing investment criteria, architecture information can help identify key business processes to enable with a solution, and help determine whether to deliver capability via enterprise-wide services or with Component-specific services.
• IT architects across capability portfolios, Federal Agencies and DoD Components. They use the architectures to align touchpoints and boundaries as well as to identify interoperability gaps and the requirements for federation. The DoD federated set of architectures is collectively known as the federated DoD Enterprise Architecture (DoD EA). The DoD EA is in turn federated with the Federal Enterprise Architecture (FEA) and other external architectures.
• DoD and Component Program Executive Officers (PEOs), Program Managers (PMs) and their corresponding functional requirements managers. Enterprise architectures provide these customers design principles by enabling each program to filter the applicable laws, regulations, policies, standards and frameworks imposed from internal and external sources.

Enterprise architectures present a “To Be” vision intended to influence how future systems are designed and built. They do not affect existing, deployed systems, except to the extent that they receive investment dollars for modernization. In other words, enterprise architectures do not require a forced retrofitting of existing systems, services, or capabilities.

While the DIEA guides the implementation of solutions that make information more accessible, decisions as to who has access to specific information elements remain within the Department’s leadership and command structure.