BY ORDER OF THE SECRETARY OF THE AIR FORCE AIR FORCE INSTRUCTION 33-401 14 MARCH 2007 Communications and Information IMPLEMENTING AIR FORCE ARCHITECTURES ACCESSIBILITY: COMPLIANCE WITH THIS PUBLICATION IS MANDATORY Publications and forms are available for downloading or ordering on the e-publishing website at www.e-publishing.af.mil/. RELEASABILITY: There are no releasability restrictions on this publication. OPR: SAF/XCXA Certified by: SAF/XCX (Brig Gen Daniel R. Dinkins) Supersedes AFI 33-124, 1 May 2000 Pages: 33 and AFI 33-133, 1 July 2000. This Air Force instruction (AFI) implements Air Force Policy Directive (AFPD) 33-4, Enterprise Architecting. It describes the Air Force Enterprise Architecture (AF EA) and assigns responsibility for its federated architectures to specific organizations. It supports the architecture-related mandates of Department of Defense (DoD) Directive (DoDD) 4630.5, Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS); DoDD 5000.1, The Defense Acquisition System; DoDD 5101.7, DoD Executive Agent for Information Technology Standards; DoDD 8100.1, Global Information Grid (GIG) Overarching Policy; Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01D, Interoperability and Supportability of Information Technology and National Security Systems; Office of Management and Budget (OMB) Circular A-11, Preparation, Submission, and Execution of the Budget and OMB Circular A-130, Management of Federal Information Resources. This publication applies to all military and civilian Air Force personnel, members of the Air Force Reserve, Air National Guard, and individuals or activities as required by binding agreement with the Department of the Air Force. Field activities must send proposed supplements to this instruction to Secretary of the Air Force, Air Force Office of Warfighting Integration and Chief Information Officer (SAF/XC), 1800 Air Force Pentagon, Washington DC 20330-1800, for review and approval prior to publication. Send all recommendations for changes or comments to SAF/XCXA through appropriate channels, using AF Form 847, Recommendation for Change of Publication, with an information copy to Headquarters Air Force Communications Agency (HQ AFCA/EASD), 203 W. Losey St, Room 1100, Scott AFB IL 62225-5222. Ensure that all records created as a result of processes prescribed in this publication are maintained in accordance with Air Force Manual (AFMAN) 37-123, Management of Records, (will become AFMAN 33-363), and disposed of in accordance with the Air Force Records Information Management System (AFRIMS) Records Distribution Schedule (RDS) located at https://afrims.amc.af.mil/rds_series.cfm. See Attachment 1 for a glossary of references and supporting information. 1. The Air Force Enterprise Architecture (AF EA).... 3 Figure 1. Federal Enterprise Architecture Federation.... 4
2 AFI33-401 14 MARCH 2007 Figure 2. Air Force Enterprise Architecture Framework (AF EAF).... 6 2. Roles and Responsibilities.... 6 3. Governance.... 11 Figure 3. Certification and Approval Process for Domain, Major Command (MAJCOM), and Mission Area Architectures.... 14 Figure 4. Certification and Approval Process for Program Architectures.... 15 Figure 5. Information Technology (IT) Standards Addition/Change Process.... 17 Figure 6. Information Technology (IT) Standards Waiver Process.... 18 Table 1. Acquisition Coordination Authority by Acquisition Catetory (ACAT).... 19 4. Architecture Development, Standards, and Profiles.... 19 5. Using Architectures.... 21 6. Information Collections, Records, and Forms.... 22 Attachment 1 GLOSSARY OF REFERENCES AND SUPPORTING INFORMATION 23 Attachment 2 ARCHITECTURE ASSIGNMENTS BY ORGANIZATION 30 Attachment 3 ENTERPRISE AND SUB-ENTERPRISE GOVERNANCE ORGANIZATION 31
AFI33-401 14 MARCH 2007 3 1. The Air Force Enterprise Architecture (AF EA). 1.1. The Air Force Enterprise Architecture (AF EA), as defined in AFPD 33-4, is a strategic information resource that captures the current and desired capabilities of the Air Force in terms of its activities and the people, processes, information, and technologies that support them. It documents the Air Force enterprise, that encompasses all major commands (MAJCOM), Headquarters United States Air Force (HQ USAF) offices, agencies, installations, forces, and all operational mission and support activities that those organizations perform. Furthermore, at the enterprise-level, it relates the activities to the strategic vision, strategies, and plans of the Air Force and provides the framework to guide the development and alignment of all lower-level architectures. It supports the Air Force s key decision-making processes, including Capabilities-Based Planning and Requirements Development; Planning, Programming, Budgeting, and Execution (PPBE); Capabilities-Based Acquisition; Systems Engineering; and Portfolio Management. It reflects the current environment and capabilities and provides authoritative information to support future decisions addressing how the Air Force is organized, how it performs its mission, the information it produces and consumes, and the enabling systems and technologies. 1.2. The AF EA uses a federated approach that partitions the description of the Air Force enterprise into a hierarchy of smaller scope architectures developed and managed by designated Air Force organizations (Attachment 2). The layered nature of the architecture prevents duplication in developing, maintaining, and updating architectures, with each successive layer building on the one above. The intent is to leverage the subject matter expertise throughout the Air Force, to enable the development of architectures that directly support and are responsive to decision-makers at all levels, and to ensure a linkage between all tactical-level activities and the core, governing, and enabling activities of the Air Force. The AF EA does not exist in isolation, but is part of (and must conform to) the larger DoD and Federal Enterprise Architectures (FEA). Figure 1. shows the AF EA federated into the DoD Enterprise Architecture (i.e., the Global Information Grid [GIG] architecture), which is composed of four sub-enterprises: Business, Warfighting, Intelligence, and Enterprise Information Environment. The DoD Enterprise Architecture is federated into the FEA.
4 AFI33-401 14 MARCH 2007 Figure 1. Federal Enterprise Architecture Federation. NOTE: Acronyms in this figure are defined in Attachment 1. 1.2.1. The AF EA is based upon the AF EA Framework (AF EAF). The AF EAF provides the logical structure for classifying, organizing, and relating the breadth and depth of information that describes and documents the AF EA. The AF EAF does not define the AF EA content; rather it consists of various approaches, models, and definitions for communicating and facilitating the presentation of key architecture components (e.g., architecture vision, governance, principles, guidance, products, etc.) required for the development and integration of Air Force architectures. The AF EAF establishes a common foundation for understanding, comparing, federating, and integrating architectures and, as such, provides the overarching framework that enables architecture-based analysis through different perspectives. OMB Circular A-130 requires that each agency use an Enterprise Architecture Framework to document the linkages between its mission needs, information content, and information technology (IT) capabilities; the AF EAF fulfills this requirement. The AF EAF leverages both the DoD Architecture Framework (DoDAF) and the FEA Reference Models. 1.2.1.1. The DoDAF provides the guidance, rules, and product descriptions for developing and presenting architecture descriptions that ensure a common denominator for understanding, comparing, and integrating families of systems (FoS), systems of systems (SoS), and interop-
AFI33-401 14 MARCH 2007 5 erating and interacting architectures. DoDAF defines three views of an architecture description: Operational, Systems, and Technical Standards views. Each view is composed of sets of architecture data elements that are depicted via graphic, tabular, or textual products. These underlying data elements, called taxonomy types by DoDAF, also serve as the basis for the Air Force Reference Models that are a part of the enterprise perspective of the AF EAF. More information, including architecture view, product descriptions, and DoDAF taxonomy types can be found in the DoDAF Volume II, (http://www.dod.mil/cio-nii/docs/ DoDAF_v1_Volume_II.pdf). 1.2.1.2. Despite DODAF s capability to compare related architectures, it does not lend itself well to enterprise-level analysis. Thus, the AF EAF was developed to make this type of analysis easier. Figure 2. depicts the AF EAF, that is divided into three major parts, or columns. The first column identifies the architectural drivers and inputs. The third column identifies uses and intended impacts of the architectural efforts in the Air Force s key decision-making processes. Refer to the AF EAF for more information. The second column depicts the three architectural layers, or perspectives, that represent the hierarchy of architectures that collectively describe the Air Force enterprise. The top layer focuses on the enterprise and comprises the substance of the AF EA. Here, the Air Force s adaptation of the FEA reference models help facilitate an enterprise line of sight from the strategic goals and performance measures in the Performance Reference Model, through the processes, activities, and organizations that help achieve those goals in the Business Reference Model, the information and systems that support each Air Force process in the Data Reference Model and System and Service Component Reference Model, respectively, down to the standards that guide implementation of the supporting IT systems in the Technical Reference Model, for each part of the enterprise (see the AF EAF for a more detailed description of the Air Force reference models or the FEA Consolidated Reference Model Document [http://www.whitehouse.gov/omb/egov/documents/ FEA_CRM_v20_Final_June_2006.pdf] for a more detailed description of the FEA reference models). It also provides a common set of terms and definitions that can be used by all Air Force architects so that their separately-developed architectures can be related, compared, and reused (i.e., the same term or entity represents and means the same thing in each separately-developed architecture). At this layer, DODAF products do not lend themselves well to facilitating enterprise-level analysis. The middle layer focuses on an aggregation of architectures related by domain, MAJCOM, or mission area. At this layer, DoDAF view products can be used effectively to a certain degree, but also requires the reference models to facilitate higher-level analysis. The bottom layer, the Program-Level, focuses on individual program, FoS, and SoS architectures, and can be represented well using DoDAF view products.
6 AFI33-401 14 MARCH 2007 Figure 2. Air Force Enterprise Architecture Framework (AF EAF). NOTE: Acronyms in this figure are defined in Attachment 1. 1.2.2. For simplicity, the Air Force Enterprise is divided into three distinct sub-enterprises: Warfighting, Agile Combat Support, and IT Infrastructure as shown in Figure 1. and Figure 2. Architectures for these sub-enterprises encompass appropriate, but not necessarily mutually exclusive, portions of domain and MAJCOM architectures that are, in turn, composed of program architectures. Mission area architectures (to include, but not limited to, Air Force Concept of Operations [CONOPS] architectures) map across domain, MAJCOM, and sub-enterprise architectures, and are also composed of program architectures. (See Figure 1. for a graphical representation of this federation and Attachment 2 for a listing of architecture assignments by organization.) All Air Force architectures must be consistent with the AF EA and based upon the DoDAF. The Air Force has established a governance process to ensure this alignment (see paragraph 3. and Attachment 3). 2. Roles and Responsibilities. 2.1. Assistant Secretary of the Air Force (Acquisition) (SAF/AQ). As the Service Acquisition Executive for non-space programs, SAF/AQ will:
AFI33-401 14 MARCH 2007 7 2.1.1. In coordination with Under Secretary of the Air Force (SAF/US), establish policy and/or guidance on the use of architectures (to include the identification of architecture information and product requirements and acceptance criteria) to support the acquisition process. Note: SAF/AQ has the authority to establish architecture requirements more stringent than those established in CJCSI 6212.01D, if necessary to enhance the acquisition process and decision-making (e.g., overseeing Clinger-Cohen Act of 1996 compliance activities). 2.1.2. Establish policy and/or guidance to ensure compliance with applicable architectures within the Air Force Enterprise (including Air Force activities, IT standards, and profiles) throughout the non-space system acquisition and development process, and ensure satisfaction of the Joint Capabilities Integration and Development System (JCIDS) and Air Force Requirements for Operational Capabilities Council (AFROCC) architecture-related requirements for all Air Force programs regardless of acquisition category (ACAT). 2.1.3. Oversee compliance activities associated with Title 40 United States Code (USC) 11101-11704, as codified in DoDD 4630.5 and AFPD 33-4, as necessary to support major milestone reviews of all non-space acquisition programs, regardless of ACAT. 2.1.4. Ensure that non-space acquisition programs comply with documented GIG and AF EA requirements and architectures. 2.2. Under Secretary of the Air Force (SAF/US). As the Service Acquisition Executive for space programs, SAF/US will: 2.2.1. Coordinate with SAF/AQ on policy and/or guidance on the use of architectures (to include the identification of architecture information requirements and acceptance criteria) to support the acquisition process. Note: SAF/US has the authority to establish architecture requirements more stringent than those established in CJCSI 6212.01D, if necessary to enhance the space acquisition process and decision-making (e.g., overseeing the Clinger-Cohen Act of 1996 compliance activities). 2.2.2. Establish policy and/or guidance to ensure compliance with applicable architectures within the Air Force Enterprise (including Air Force activities, IT standards, and profiles) throughout the space system acquisition and development process, and ensure satisfaction of the JCIDS and AFROCC architecture-related requirements for all Air Force programs regardless of ACAT. 2.2.3. Oversee compliance activities associated with 40 USC 11101-11704, as codified in DoDD 4630.5 and AFPD 33-4, as necessary to support major milestone reviews of all space acquisition programs, regardless of ACAT. 2.2.4. Ensure that space acquisition programs comply with documented GIG and AF EA requirements and architectures. 2.3. The Secretary of the Air Force Chief of Warfighting Integration and Chief Information Officer (SAF/XC) will: 2.3.1. Ensure Air Force representation on Federal, DoD, Service, and Agency architecture and IT standards panels, as appropriate. 2.3.2. Through the Director of Policy, Planning, and Resources (SAF/XCX), who acts as the Air Force Chief Architect, provide overall AF EA direction, control, planning, coordination, and integration within and external to the Air Force. The Air Force Chief Architect will:
8 AFI33-401 14 MARCH 2007 2.3.2.1. Develop, maintain, and update the AF EA, including the five Air Force Reference Models. 2.3.2.2. Ensure horizontal alignment of the Air Force sub-enterprise architectures and the vertical alignment between the sub-enterprise architectures and the AF EA. 2.3.2.3. Publish and maintain an AF EAF that describes the Air Force architecture federation approach. 2.3.2.4. Coordinate and oversee the activities of Air Force-level architecture governance bodies. 2.3.2.5. Organize and coordinate architecture federation activities internal to the Air Force and external to the enterprise. 2.3.2.6. Facilitate the development and use of architectures throughout the Air Force, including, (but not limited to) establishing and designating any additional views not defined by the DoDAF that are required for architecture development (e.g., in support of determining Clinger-Cohen Act of 1996 compliance). 2.3.2.7. Coordinate with the Air Force Institute of Technology (AFIT) through Headquarters Air Education and Training Command (HQ AETC) on the establishment of an architecture education and training program, then oversee and support the development and maintenance of that program. 2.3.2.8. Develop, maintain, and provide the Air Force Architecture Repository (AFARS), accessible at https://rso.my.af.mil/afknprod/asps/cop/opencop.asp?filter=oo-ea. 2.3.3. Establish policy and/or guidance on the use of architectures (to include architecture information requirements, architecture product requirements, and acceptance criteria) to support information management, IT portfolio management, and warfighting integration. 2.3.4. Review JCIDS documents (e.g., Initial Capability Documents, Capability Development Documents, Capability Production Documents, and supporting architectures) and Information Support Plans (ISP) to ensure planned implementation of the Net-Ready Key Performance Parameter (NR-KPP) is sound. This includes a review of the architecture, alignment with DoD s Net-Centric Operations and Warfare Reference Model, review of the Information Assurance (IA) plan, and review of the Key Interface Profiles. 2.3.5. Ensure all acquisition programs, regardless of ACAT, comply with 40 USC 11101-11704, as codified in DoDD 4630.5 and AFPD 33-4, to support major milestone reviews. 2.3.6. Upon the recommendation of the Air Force Chief Architect, establish and designate a chair/ co-chair for Air Force-level architecture governance bodies. 2.3.7. Serve as the Air Force approval authority for waivers to DoD IT Standards Registry (DISR)-approved IT standards. 2.3.8. Ensure DoD system security engineering standards and processes, as described in the DoD Information Assurance Technical Framework, and information assurance considerations are properly complied with and integrated within architectural views and products. 2.3.9. Through the Directorate of Operations and Support Integration (SAF/XCO), develop, maintain, and update the Warfighting and Agile Combat Support sub-enterprise architectures.
AFI33-401 14 MARCH 2007 9 2.3.10. Through the Directorate of Information, Services, and Integration (SAF/XCI), develop, maintain, and update the IT Infrastructure sub-enterprise architecture and its underlying domain architectures. 2.3.11. As the Air Force representative to the Military Communications-Electronics Board, provide guidance and recommendations on the development of joint, allied, and coalition principles, technical standards, architecture, and procedures for obtaining interoperability, compatibility, and standardization of command, control, communications, and computer equipment, including communications-electronics standardization agreements of the North Atlantic Treaty Organization. SAF/XC will provide recommendations to develop a DoD position for negotiation with representatives of other nations on communications-electronics matters. 2.4. Headquarters United States Air Force, Deputy Chief of Staff, Air Space, and Information Operations, Plans and Requirements (HQ USAF/A3/5) will: 2.4.1. Establish guidance on the use of architectures (to include architecture information requirements) to support the Air Force Capabilities-Based Planning, Capabilities-Based Requirements Development, and Air Force Smart Operations 21 process re-engineering processes. 2.4.2. Use architectures as an authoritative decision-support tool to support capability-based planning and analysis of Air Force CONOPS, as appropriate. 2.4.3. Fully integrate Air Force Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) capabilities into the larger joint environment by ensuring requirements documents adhere to the architecture requirements established in CJCSI 6212.01D, including a validated NR-KPP, as appropriate. 2.4.4. Ensure interoperability requirement certifications have been issued by Joint Chiefs of Staff (JCS)/J6 prior to AFROCC review, as appropriate. 2.4.5. Support SAF/XC in the development of all Air Force sub-enterprise architectures by establishing and providing network defense requirements that should be incorporated. 2.5. Headquarters United States Air Force, Deputy Chief of Staff, Strategic Plans and Programs (HQ USAF/A8) will: 2.5.1. Establish or amend policy and/or guidance, as necessary, on the use of architectures (to include architecture information requirements and acceptance criteria) to support the Air Force planning and programming process. 2.5.2. Use architectures in conjunction with other authoritative decision-support tools that support planning and programming efforts. 2.6. Air Force Domain Owners (as specified in Attachment 2) will: 2.6.1. Establish policies, procedures, guidelines, and a governance structure to oversee domain and lower-level architecture activities, and to review and recommend certification of architectures developed by their lower-level architects or that fall within the purview of their assigned portion of the AF EA. 2.6.2. Appoint an architecture lead to oversee Air Force domain architecture development activities, ensure architecture compliance, and serve as lead for domain architecture governance bodies. 2.6.3. Facilitate the use of architecture products within the domain.
10 AFI33-401 14 MARCH 2007 2.6.4. Develop and maintain architectures for their designated portions of the AF EA (see Attachment 2) and use the architectures to support execution of Air Force processes. Air Force domain owners will ensure that the architectures are consistent with the AF EA (including Air Force activities, IT standards, and profiles). 2.6.5. Publish certified and under-development domain architecture metadata and contact information to AFARS. This ensures full lifecycle visibility of architectures from initial development, through certification, and subsequent evolution. 2.6.6. Represent their interests on all pertinent architectural matters before the applicable architecture governance bodies. 2.6.7. Plan for and provide financial, manpower, and other resources as needed to carry out their AF EA responsibilities. 2.6.8. Assist mission area and MAJCOM architects with their architectures to ensure that they accurately reflect existing domain capabilities and capture requirements for subsequent inclusion in their domain architecture. 2.7. MAJCOMs will: 2.7.1. Establish policies, procedures, guidelines, and a governance structure to oversee MAJCOM and lower-level architecture activities, and to review and recommend certification of architectures developed by their subordinate elements or that fall within the purview of their assigned portions of the AF EA. 2.7.2. Appoint an architect to oversee MAJCOM architecture development activities, ensure architecture compliance, and serve as lead for MAJCOM architecture governance bodies. 2.7.3. Facilitate the use of architecture products within the MAJCOM. 2.7.4. Develop and maintain architectures for designated portions of the AF EA (see Attachment 2), and use the architectures as an authoritative source to support MAJCOM execution of Air Force processes. MAJCOMs will ensure that the architectures are consistent with the AF EA (including Air Force activities, IT standards, and profiles). 2.7.5. Publish certified and under-development MAJCOM architecture metadata and contact information to AFARS. This ensures full lifecycle visibility of architectures from initial development, through certification, and subsequent evolution. 2.7.6. Represent their interests on all pertinent architectural matters before the applicable architecture governance bodies. 2.7.7. Plan for and provide financial, manpower, and other resources as needed to carry out their AF EA responsibilities. 2.7.8. Assist mission area and domain architects with their architectures to ensure that they accurately reflect existing MAJCOM and CONOPS capabilities and capture requirements for subsequent inclusion in their MAJCOM architecture. 2.8. Air Force Command and Control and Intelligence, Surveillance, and Reconnaissance Center (AFC2ISRC) will:
AFI33-401 14 MARCH 2007 11 2.8.1. Support SAF/XC in the development and maintenance of the command and control (C2) portion of the Warfighting sub-enterprise architecture (formally named the C2 Constellation Architecture). 2.8.2. Participate in architecture governance bodies as appropriate. 2.8.3. Assist mission area, domain, and MAJCOM architects with their architectures to ensure that they accurately reflect existing and planned C2 capabilities and capture C2 requirements for subsequent inclusion in the Warfighting sub-enterprise architecture. 2.8.4. Recommend C2-related technical standards, profiles, technical solutions, and products. Evaluate applicable commercial products, and develop commercial-off-the-shelf (COTS) technical forecasts. 2.8.5. Track and follow-up on C2 shortfalls identified in ISPs. Determine if doctrine, organization, training, materiel, leadership and education, personnel, and facilities (DOTMLPF) solutions are applicable in meeting shortfalls and work with program managers in implementing solutions to improve interoperability and integration of their systems. 2.9. Headquarters Air Force Communications Agency (HQ AFCA) will: 2.9.1. Support SAF/XC in the development and maintenance of the Air Force IT Infrastructure sub-enterprise architecture (formally named the ConstellationNet Architecture) and its underlying domain architectures. 2.9.2. Participate in architecture governance activities as determined by SAF/XC. 2.9.3. Assist mission area, domain, and MAJCOM architects with their architectures to ensure that they accurately reflect existing IT infrastructure capabilities and capture IT infrastructure requirements for subsequent inclusion in the IT Infrastructure sub-enterprise architecture. 2.9.4. Recommend IT infrastructure-related technical standards and products, evaluate applicable commercial products, and develop IT infrastructure-related profiles, technical solutions, and COTS technical forecasts. 2.9.5. Develop and maintain the Infostructure Technology Reference Model (i-trm). 2.9.6. Provide support to the DISR technical working groups and the DoD IT Standards Committee. 2.9.7. Review and coordinate Air Force submission of candidate technical standards to the DISR and submission of IT standards waiver requests. 2.10. Headquarters Air Education and Training Command (HQ AETC) will: 2.10.1. Develop and conduct non-resident architecture training with inputs from SAF/XC. 2.10.2. Maintain an appropriate training plan, course outline, and materials. 3. Governance. 3.1. The content of Air Force architectures are governed through a comprehensive set of processes that is structured to oversee the development, alignment, certification, maintenance, and application of the AF EA and subordinate architectures, as well as compliance with established standards and profiles. At the Air Force-level, a set of cross-functional, cross-majcom General Officer Steering
12 AFI33-401 14 MARCH 2007 Groups (GOSG) govern the enterprise, including the corresponding enterprise and sub-enterprise architectures (see Attachment 3 for specific information on the structure and functions of the GOSG). The GOSGs, in coordination with the Air Force Chief Architect, collectively govern the AF EA. 3.2. An Architecture Integrated Product Team (IPT) under the GOSG structure manages the development, maintenance, governance, and use of the enterprise and sub-enterprise architectures in support of corresponding initiatives. This IPT also has oversight of architectures within its scope and coordinates on and recommends certification of those architectures within its scope. This IPT performs the following functions, at a minimum: 3.2.1. Directs development of the sub-enterprise as-is and to-be architectures as required for analytical purposes. Architectures should include sufficient information and be the authoritative source for analysis activities performed by the other IPTs under the GOSG. 3.2.2. Supports domain owners in developing domain-level architectures to support their portfolio strategy. 3.2.3. Ensures alignment of assigned sub-enterprise architectures with the remaining sub-enterprise architectures and the AF EA and recommends certification and approval of the AF EA and its sub-enterprise architectures to the Air Force Chief Architect. 3.2.4. Ensures alignment of architectures within their scope with their assigned sub-enterprise architectures and recommends certification of those architectures to the Air Force Chief Architect. 3.2.5. Coordinates with any other enterprise-level Architecture IPTs, as directed by the Air Force Chief Architect, on alignment of architectures that map across multiple sub-enterprises. 3.2.6. Ensures consistency and alignment between the AF EA and architectures within the sub-enterprise s scope, and consistency with applicable standards and guidance internal and external to the Air Force. 3.2.7. Directs development of and assess/approve service/platform profiles supporting the sub-enterprise architecture. 3.3. Certification and approval of architectures. 3.3.1. The architecture certification and approval process is an integral part of the overall requirements development process. Architecture certification determines that an architecture is properly constructed in terms of traceability, completeness, and consistency within itself and with other applicable architectures. It determines the technical correctness of the architecture (i.e., the architecture itself is correct). Architecture approval determines the degree to which an architecture is an accurate representation of the real world or a planned future state and is accurate, feasible, and suitable (i.e., the missions, organizations, activities, systems, etc. represented in the architecture are correct). It s important to complete both certification and approval to ensure that the architecture provides accurate information in fulfillment of the Clinger-Cohen Act of 1996 intent and requirements levied in DoDD 4630.5 and CJCSI 6212.01D. Certification and approval can be pursued concurrently, but certification by the Air Force Chief Architect will not occur until the approval process is complete. 3.3.2. The Air Force architecture certification and approval process provides for the quality control and configuration management of the architecture, alignment with appropriate higher-level and peer architectures, and the accuracy and applicability of user activities. Certification and
AFI33-401 14 MARCH 2007 13 approval assesses and ensures that systems and activities meet capabilities and comply with applicable standards. Therefore, a certification and approval assessment must be accomplished for each architecture. 3.3.2.1. Architecture approval is performed by the users or subject matter experts (SME) for whom the architecture was developed. Wherever possible, approval should be done independent of the organization that developed the architecture. In many cases, however, especially with higher-level architectures, independent approval may be impractical. In such cases, this activity may be performed by the same organization that developed the architecture. For example, a MAJCOM architecture is developed within the MAJCOM and then coordinated among its functional areas to validate that the activities captured are true representations of its actual activities, or, in the case of to-be architectures, that the future activities captured are those previously agreed-upon. Figure 3. and Figure 4. outline this process in relation to the certification process. Coordinate the AF EA across all enterprise-level Architecture IPTs and submit it to the Air Force Chief Architect for approval following successful completion of this process. At a minimum, architecture approval will: 3.3.2.1.1. Be required for all architectures developed for requirement submission via the JCIDS or ISP processes, as well as higher-level architectures, such as domain, MAJCOM, mission area, and sub-enterprise architectures. 3.3.2.1.2. Provide a review of the architecture to determine accuracy of documented current ( as-is ) or future ( to-be ) activities and enablers (e.g., systems, organizations, etc.) and compliance with DoD and Air Force business rules, where established. 3.3.2.1.3. Ensure the architecture supports the mission and goals of the higher-level architectures to which it maps. 3.3.2.1.4. Ensure the architecture provides or supports a required Air Force capability as described in the Master Capability Library or identified via the Capabilities Review and Risk Assessment (CRRA). 3.3.2.2. Domains, MAJCOMs, and mission areas shall submit their architectures for certification, after being signed out by the MAJCOM/Agency 2-letter or HQ USAF 3-letter responsible for the architecture, to the Architecture and Standards Division within SAF/XC (SAF/ XCXA), who ensures that the architecture is reviewed by representatives from the appropriate Architecture IPTs (based on mapping of activities and systems to the sub-enterprise architectures). Recommendations from that review are sent to the Air Force Chief Architect for certification. If all reviewing Architecture IPTs agree that the architecture aligns with their sub-enterprise architectures, the Air Force Chief Architect certifies the architecture. Conflicts between Architecture IPTs regarding certification of domain, MAJCOM, and mission area architectures are resolved by SAF/XCXA and the affected Architecture IPTs as directed by the Air Force Chief Architect. See Figure 3. for a graphical representation of this process. The three sub-enterprise architectures are assessed for alignment and consistency across all enterprise-level Architecture IPTs and are certified by the Air Force Chief Architect. The AF EA is assessed for alignment and consistency across all enterprise-level Architecture IPTs, and then submitted to the Air Force Chief Information Officer for certification.
14 AFI33-401 14 MARCH 2007 Figure 3. Certification and Approval Process for Domain, Major Command (MAJCOM), and Mission Area Architectures. 3.3.2.3. Program offices shall also submit their architectures for certification to SAF/XCXA, who ensures that the architecture is reviewed by representatives from the appropriate Architecture IPTs, MAJCOMs, domain owners, and mission area owners (based on mapping of activities and systems). Program offices should submit their architectures concurrent with the ISP review conducted prior to Milestone C (Key Decision Point C for space programs). Programs outside of the formal acquisition process shall submit their architectures for certification as part of the ISP review. If all reviewing organizations agree that the program architecture aligns with their higher-level architecture, the Air Force Chief Architect certifies the program architecture. Conflicts between reviewing organizations regarding certification of program architectures are resolved by SAF/XCXA and the affected Architecture IPTs. See Figure 4. for a graphical representation of this process.
AFI33-401 14 MARCH 2007 15 Figure 4. Certification and Approval Process for Program Architectures. 3.3.2.4. At a minimum, architecture certification will: 3.3.2.4.1. Be required for all architectures developed for requirement submission via the JCIDS or ISP processes, as well as higher-level architectures, such as domain, MAJCOM, mission area, and sub-enterprise architectures. 3.3.2.4.2. Provide an assessment of the architecture to determine consistency among architecture views. Architecture assessments are completed by architects who have completed an AETC architecture course (e.g., SYS283 offered through AFIT) or equivalent. 3.3.2.4.3. Ensure the architecture complies with Air Force, DoD, federal, non-government, and allied international military standards, as applicable. 3.3.2.4.4. Ensure the architecture aligns with other architectures it is being assessed against, including reuse of activities, nodes, systems, and other objects where there are overlaps, as well as DoD and Air Force business rules, where established. 3.3.2.4.5. Ensure the organization responsible for the architecture follows a documented change management process.
16 AFI33-401 14 MARCH 2007 3.4. Once an architecture is certified, its associated metadata is published in AFARS. AFARS acts as the authoritative source for obtaining Air Force architecture information. Architects shall also provide contact information with the metadata. Architects are responsible for keeping metadata and contact information current in AFARS. Architectures labeled as certified in AFARS are considered authoritative sources. 3.5. Additions, Changes, and Waivers to Information Technology (IT) Standards. 3.5.1. When an Air Force organization identifies a need for a new or emerging standard to be added to the DISR, or to update a version of or retire an existing DISR standard, the DISR change request (CR) process must be followed, whether the CR is for a joint mandated standard or for an AF-unique standard. For ACAT programs, this must be done prior to Milestone B (Key Decision Point B for space programs); otherwise, an IT standards waiver must be obtained. 3.5.2. The CR process follows a 4-6 month cycle (driven by the DoD IT Standards Committee [ITSC]) culminating in a recommendational meeting of the DoD ITSC and a decisional meeting of the DoD IT Standards Oversight Panel. At the beginning of that cycle, Air Force organizations have at least 4 weeks to submit change requests via the DISRonline. Find CR templates in the DISR Standard Operating Procedures (https://disronline.disa.mil). Air Force organizations shall contact SAF/XCXA to get the CR approved. If SAF/XCXA determines that there is contention or issues requiring a corporate Air Force review, they request that the CR submitter prepare a package for the appropriate GOSG Architecture IPTs for consideration. The Architecture IPTs then make a recommendation to SAF/XCXA on whether or not to proceed with the CR. Once SAF/ XCXA releases the CR to the DoD ITSC, representatives of all DoD services and agencies review the CR to determine interoperability against the DISR baseline. If determined the proposed standard is of a joint nature, the CR is integrated into the next DISR baseline update; otherwise, if the CR is determined that it will not cause any interoperability issues, the CR is included in the Air Force organizational-unique area of DISRonline for use by any Air Force program. The basic process is shown in Figure 5.
AFI33-401 14 MARCH 2007 17 Figure 5. Information Technology (IT) Standards Addition/Change Process. 3.5.3. Requests for waivers from DoD-mandated IT standards stored in DISR may be made in accordance with Department of Defense Instruction (DoDI) 4630.8, Procedures for Interoperability and Supportability of Information Technology and National Security Systems. A waiver is required to use an IT standard not approved for use in the DISR or when a decision is made not to use a DoD-mandated IT standard. Waivers must also be requested for use of a standard listed in DISR as emerging or retired. Requests for waivers are submitted to the AFCA Technical Architecture Division (HQ AFCA/EAL) for review and coordination to ensure there are no interoperability issues. The process flow is shown in Figure 6. Find additional information on the DISR web site at https://disronline.disa.mil.
18 AFI33-401 14 MARCH 2007 Figure 6. Information Technology (IT) Standards Waiver Process. 3.5.4. As specified in AFI 63-101, Operations of Capabilities Based Acquisition System, and National Security Space 03-01, Acquisition Policy, the IT standard waiver request will include a comprehensive assessment of the impact on cost, schedule, performance and information security issues. If requested, HQ AFCA/EAL can provide a waiver request template to be used when submitting the request. Once AFCA has positively coordinated on the request, it is submitted to the appropriate Waiver Coordination Authority (WCA), based on ACAT (refer to Table 1. for WCA determination). 3.5.5. Once the WCA coordinates on the waiver request, the Air Force Program Executive Officer (AFPEO) submits the waiver package to SAF/XC, who serves as the Air Force IT Waiver Approval Authority, for review and submission to the appropriate Office of the Secretary of Defense Directorate for concurrence. Additional information is available on the DISRonline web site at https://disronline.disa.mil.
AFI33-401 14 MARCH 2007 19 Table 1. Acquisition Coordination Authority by Acquisition Catetory (ACAT). Acquisition Category (ACAT) ACAT I ACAT ID Coordination Authority AFPEO; Component Acquisition Executive (CAE); In Turn AFPEO; CAE; In Turn ACAT IC ACAT IA ACAT IAM AFPEO; CAE; In Turn ACAT IAC AFPEO; CAE; In Turn ACAT II AFPEO; Milestone Decision Authority (MDA); In Turn ACAT III AFPEO; MDA; In Turn Below ACAT III First General Officer or Civilian Equivalent in Chain of Command of Organization Responsible for Program (In some cases, the AFPEO and the MDA are the same office.) 4. Architecture Development, Standards, and Profiles. 4.1. Architecture Development. 4.1.1. Identifying and prioritizing the intended uses of the architecture is the first step in the architecture development process. An architecture should only be developed to meet specific objectives, based on user needs, such as: determining which systems need to interoperate and how best to achieve that interoperability; determining which investment mix will help achieve the desired capabilities based on previous programmatic decisions; and determining DOTMLPF changes necessary based on re-engineered processes. A specific and commonly understood purpose increases the efficiency of the effort and the utility of the resulting description. Defining that purpose is the responsibility of the user or sponsor of the architecture. 4.1.2. Architectures inform and capture DOTMLPF decisions. Beginning with the CRRA and capabilities-based planning processes, a portfolio of existing and desired capabilities are identified and goals are established that lead to specified outcomes with specified measurable performance parameters. 4.1.3. The identified outcomes drive the necessary activities to achieve them. Those activities, along with the mechanisms, controls, and inputs associated with them, define the requirements that support the established goals and capabilities. The defined set of activities is the very heart of the architecture. 4.1.4. From there, the activity requirements define the functions, skills, abilities, and standards that ultimately lead to solutions. It s important to note that the functions, skills, abilities, and standards are generic not specific to a particular system, organization, career field, etc. In that way, they lead to a more comprehensive DOTMLPF analysis of potential solutions to fulfill the activity.
20 AFI33-401 14 MARCH 2007 4.1.5. The determined solutions may be either materiel-focused (e.g., a new system/program), non-materiel-focused (e.g., a new training program for all airmen), or a combination (e.g., a new organizational construct that leverages new/existing technological solutions). Identified solutions should directly support the intended goals and capabilities and support portfolio investment mix and acquisition decisions, as well as non-materiel DOTMLPF decisions. Thus, the architecture provides the foundation for this process with the information for a range of decisional issues. 4.1.6. While the above process applies primarily to higher-level architectures, architecture development for specific programs should apply the same principles to the maximum extent possible. This ensures a comprehensive evaluation of the proposed materiel solution to ensure integration of the system into the appropriate business processes, organizations, operational network, etc. 4.1.7. Architecture products (e.g., architecture views) should be documented in the current DoDAF format to the maximum extent possible, as required by CJCSI 6212.01D. Other products may be required to support specific types of analysis. In all cases, architecture products (including DoDAF operational, systems, and technical standards views, as well as other products developed) should form an integrated architecture in accordance with DoDAF. Where one architecture maps to another architecture, reuse architecture content to ensure consistency and federation of related architectures. For example, an activity in a higher-level architecture that is more detailed in a lower-level architecture should be named identically. Similarly, an information exchange or service provided between a system in one architecture and a system in an interfacing architecture should be labeled identically. All architectures should map to a higher-level architecture and ultimately to the AF EA. 4.1.8. Inclusion of the NR-KPP is mandatory for all acquisition IT and National Security System (NSS) programs for systems used to enter, process, store, display, or transmit DoD information, regardless of classification or sensitivity and regardless of acquisition category. The only exception is for those IT or NSS systems that do not communicate with external systems. Non-acquisition programs must also comply in accordance with DoDD 4630.5, DoDI 4630.8, and AFPD 33-4. Documentation of the four NR-KPP components (as defined in CJCSI 6212.01D) is required for Interoperability and Supportability Certification. Architecture requirements for JCIDS, NR-KPP, and ISP documentation can also be found in CJCSI 6212.01D. 4.2. Technical Standards. 4.2.1. In accordance with DoDI 4630.8 and CJCSI 3170.01E, Joint Capabilities Integration and Development System, all Air Force program and buying offices shall use the DoD-mandated IT standards found in the DISR that are applicable to their acquisition for all new or upgraded IT and NSS, with the exception of standalone systems. The DISRonline is a repository containing DoD and service-unique IT standards that have been mandated for use, as well as those IT standards DoD has labeled as emerging or retired. Technical standards are documented in an architecture s Technical Standards Profile (TV-1) and Technical Standards Forecast (TV-2) as appropriate. Both the TV-1 and TV-2 architecture views can be built using the DISRonline Profiling Tool on the SIPRNET (https://disronline.dia.smil.mil). Standards listed in these two architecture products must be DoD-mandated standards contained in the DISR, Air Force-unique standards, or standards for which the program has obtained a waiver. Note that implementing a DoD-mandated standard does not guarantee interoperability, however, since the same standard could be implemented in different ways. Therefore, take special care to ensure interoperability between systems.
AFI33-401 14 MARCH 2007 21 Refer to paragraph 3.5. for information on the processes to add, change, or request a waiver for an IT standard. 4.2.2. Technical standards used in the AF EA are defense standardization documents that are either developed and maintained, or adopted by the DoD community. These are made available, in part by the Defense Standardization Program as implemented by AFPD 60-1, Air Force Standardization Program, and AFI 60-101. 4.3. Service and Platform Profiles. 4.3.1. Service profiles describe the behavior and proposed use of an Air Force service. A service is defined as the performance of a function by one entity for the benefit of another entity which can be invoked via a defined interface. Service profiles are necessary to guide and direct services development across the entire Air Force as the Air Force moves to a services based Net-centric environment. Detailed descriptions of a service s input requirements and outputs are contained in a service profile with limited information on the internal processes of the service. Developers of service profiles include those specifying, architecting, designing and deploying services in support of mission/capability requirements. Affiliated architectures (e.g., domain, mission, sub-enterprise) are also identified in the service profile. Service profiles are stored in the i-trm and employed as applicable. 4.3.2. Platform profiles describe a standardized direction for the design, development, and selection of IT or NSS system components to satisfy the mission needs of the Air Force while ensuring alignment with the GIG. They describe the principles, guidelines, component strategies, and product/technical standards that support the platform used and enable designers, developers and users to agree on definitions and share a common understanding of the model and its constituent components. Platform profiles are typically structured like a mini architecture and are comprised of a TV-1 supplemented with operational and system architecture products as needed. Platform profiles are stored in the i-trm and employed as applicable. 4.4. Infostructure Technology Reference Model (i-trm). The i-trm identifies mandatory IT hardware and software products, including standardized computer configurations. The i-trm also includes authoritative service and platform profiles for use in the development of architectures and/or standardized system configurations. Use of alternate products or deviations from established profiles must be approved by the appropriate GOSG Architecture IPT. 5. Using Architectures. As stated in paragraph 4.1., architectures are developed to meet specific objectives. Once developed, approved, and certified, the architectures are then used as the authoritative source to aid decision-makers in attaining those objectives. 5.1. Capabilities-Based Planning and Requirements Development. Architectures support operational planners by identifying the critical operational activities, systems/services, information needs, and the associated interrelationships necessary to support a specific capability. They provide an authoritative source to support DOTMLPF analysis of capability gaps to aid decision-makers in describing the operational needs in the capability-based planning and requirements development processes. Refer to AFI 10-601, Capabilities Based Requirements Development, and AFI 10-604, Capabilities Based Planning, for more information on how architectures are used in this process. 5.2. Planning, Programming, Budgeting, and Execution (PPBE). The ultimate objective of the PPBE process is to provide the best mix of forces, equipment, and support attainable within fiscal con-