IT_Lean_Reengineering_Process_Guidebook.pdf

IT Lean Reengineering Process Guidebook

IT Lean Reengineering Process Guidebook

Version 6.0

24 October 2008

Prepared by the IT Lean Reengineering Stakeholders

DOCUMENT VERSION HISTORY

DATE VERSION REASON FOR CHANGE

5 March 2007 5.0 DIACAP and policy change to

AFPD 33-2 and AFI 33-210

7 Jun 2007 5.0

Removed the “draft” header and changed Paragraph 2.1 as

“suggested” scope.

5 Aug 2008 6.0

AFI 33-210, DoDI 8510.01, EITDR v2.6, 2.7 and DIACAP information.

TABLE OF CONTENTS

1.0 INTRODUCTION

1.1 Background

2.0 APPLICABILITY

2.1 IT Lean Process

3.0 IT LEAN PROCESS

3.1 Background

3.2 Pre-IT Lean Process Activities

3.3 Information Sharing Strategy

3.4 Enterprise Information Technology Data Repository (EITDR)

3.5 IT Lean Define Need Phase

3.5.1 Define Sub-Phase

3.5.2 Refine Sub-Phase

3.5.3 Analyze Sub-Phase

3.5.4 Define Need Review

3.6 IT Lean Design Phase

3.6.1 Prepare Sub-Phase

3.6.2 Design Sub-Phase

3.6.3 Validate Sub-Phase

3.6.4 Design Review

3.7 IT Lean Build and Test Phase

3.7.1 Build and Test Activities

3.7.2 Formal System Test Activities

3.7.3 Conduct Test Readiness Review II (TRR II)

3.7.4 Operational Test Activities

3.7.5 Field Readiness Review (FRR)

3.8 IT Lean Release and Support Phase

3.8.1 Release Sub-Phase

3.8.2 Implement Sub-phase

3.8.3 Operational Support and Sustainment Sub-phase

4.0 “HOW-TO” IT LEAN PROCESS

4.1 Goal

4.2 Pre-IT Lean Process

4.2.1 Obtain EITDR Account and Determine Stakeholders

4.2.2 Getting Started in the IT Lean Process

4.2.3 Initial Version Review (Initial Review Summary)

4.2.4 Systems in Sustainment

4.2.5 No Impact to Current System Security Posture Change

4.2.6 Finalizing the IT Lean Version

4.2.7 Phases of a Version

4.2.8 Accessing the IT Lean Version for IT Lean Processing

4.2.9 Discipline Bypass Option

4.2.10 Disciplines Bypass

4.3 Roles

4.4 Process Description

4.4.1 IT Lean Production and Posting

4.4.2 SISSU Review and Resolution

4.4.3 SISSU Validation

4.4.4 IT Lean Automatic Notification

4.4.5 SISSU Discipline Validation

4.4.6 Approval of a Milestone Review

4.4.7 IT Lean Closing a Phase

4.4.8 IT Lean Completing a Version

4.4.9 SISSU Checklist

4.4.10 Interim DIACAP Version 2.6

4.4.11 DIACAP Version 2.7

5.0 APPLICABILITY TO DOD 5000-SERIES ACQUISITION PROGRAMS

5.1 Background

5.2 Early and Continuous Stakeholder Involvement

5.3 Use of EITDR

5.4 Validation of SISSU Checklist Elements

5.5 AF-DAA Approval

5.6 Linkage to the DoD 5000 Model and JCIDS

6.0 SYSTEM CERTIFICATION AND ACCREDITATION (C&A) ROLES AND

RESPONSIBILITIES

6.1 Office of the Secretary of the Air Force Chief Information Officer (SAF/XC)

6.2 Air Force-Designated Accrediting Authority (DAA)

6.3 Senior Information Assurance (IA) Official

6.4 Air Force DAA Representative

6.5 Lead Designated Accrediting Authorities (AF-DAA, SAP/SAR DAA, and Space DAA):

6.6 Designated Accrediting Authority (DAA) (Appointed DAA):

6.7 Information System Owner (formerly System DAA)

6.8 SISSU Security Validator

6.9 Program Manager (PM)

7.0 AF-DAA PROCEDURES

7.1 Application

7.2 References

7.3 Air Force-Owned or Air Force-Sponsored Systems

7.4 DoD Certification and Accreditation (C&A) Policy and Guidance

7.5 Air Force C&A Policy and Guidance

7.6 Connectivity Approval Process

7.6.1 IT Lean Define Need Phase (DIACAP Initiate and Plan IA C&A)

7.6.2 Design Phase

7.6.3 Build and Test Phase

7.6.4 Field Readiness Review (FRR) (DIACAP Accreditation Decision)

8.0 EMERGENCY AUTHORIZATION TO CONNECT (EATC)

8.1 EATC Requirements

8.2 Requesting EATC

8.3 EATC Process

9.0 GUEST SYSTEMS

9.1 DoD Certification and Accreditation (C&A) Policy and Guidance

9.2 Connectivity Approval Process

9.3 Submitting Information

9.4 SISSU Actions Taken

9.5 AF-DAA, AF-DAA Representative and AF CA Support

10.0 CIRCUIT AND/OR ENCLAVES

10.1 Policy and Definition

10.2 Unique Circuit-Enclave Accreditation Scenarios

10.3 Roles and Responsibilities

10.3.1 DISA

10.3.2 CITS Lead Command

10.3.3 AFCA

10.3.4 Air Force Network Operations (AFNETOPS)

10.3.5 Integrated Network Operations Security Center (I-NOSC)

10.3.6 Enclave Information System Owner (ISO)

10.3.7 Other System ISOs/PMs/SMs

10.4 Exercises

11.0 TYPE ACCREDITATION

12.0 AGENT OF THE CERTIFYING AUTHORITY (ACA) LICENSING

APPENDIX A – COTS/GOTS PROCESS SISSU CHECKLIST

1.0 COTS SOFTWARE ASSET MANAGEMENT OVERVIEW

2.0 COTS SOFTWARE ASSET MANAGEMENT GOALS

3.0 COTS SOFTWARE ASSET MANAGEMENT GOVERNANCE STRUCTURE

4.0 COTS SOFTWARE ASSET MANAGEMENT PROCESS

5.0 COTS SOFTWARE ASSET MANAGEMENT PROCESS SUPPORTING DETAIL

5.1 COTS SOFTWARE DEFINE NEED PLANNING PHASE

5.2 COTS SOFTWARE DESIGN CERTIFICATION PHASE

5.3 COTS SOFTWARE BUILD & TEST ACQUISITION PHASE

5.4 COTS SOFTWARE RELEASE & SUPPORT PHASE

6.0 COTS SOFTWARE APPROVED PRODUCTS LIST DETAIL

7.0 ENTERPRISE SOFTWARE AGREEMENT LIST DETAIL

8.0 SOFTWARE (COTS & GOTS) CURRENT PROCESS

9.0 ISO 19770-2 SOFTWARE ASSET TAG DETAIL

10.0 COTS SOFTWARE ASSET MANAGEMENT EXISTING POLICY AND GUIDANCE

11.0 COTS SOFTWARE ASSET MANAGEMENT TEAM

12.0 COTS SOFTWARE ASSET MANAGEMENT IT LEAN PRESENTATION

APPENDIX B – TEMPLATE FOR DECISION REVIEW MEMORANDUM

APPENDIX C – METRICS

APPENDIX D – ACRONYMS

APPENDIX E – DEFINITIONS

TABLE OF FIGURES

Figure 1. IT Lean Process Figure 2. IT Lean Information Sharing Strategy Figure 3. IT Lean Define Need Phase Figure 4. Stakeholder Team List Figure 5. Define Need Review Participants Figure 6. IT Lean Design Phase Figure 7. Design Review Participants Figure 8. IT Lean Build and Test Phase Figure 9. TRR I Participants Figure 10. TRR II Participants Figure 11. FRR Participants Figure 12. IT Lean Release and Support Phase Figure 13. Information Requirements Figure 14. IT Lean Version Deletion or Archival Figure 15. IT Lean Version Deletion or Archival - Justification and Save Figure 16. Phases Tab Screen Capture Figure 17. Phases Tab, Target Date Text Box Screen Capture Figure 18. Phases Tab, Calendar Pop-Up Screen Capture Figure 19. Phases Tab - Target Date Set Screen Capture Figure 20. IT Lean Tab – Version Figure 21. Differentiator Filter Figure 22. IT Lean Phases Tab - All Question Category Figure 23. Phases Tab - Expand Security Questions Figure 24. Discipline Action Icons Figure 25. Discipline Bypass – Question Workflow Figure 26. Disciplines Tab- Bypass a Discipline Figure 27. Disciplines Tab - Bypass Discipline Justification

Figure 28. DisciplinesTab - Bypass Discipline Completion Figure 29. SISSU Validation Authorities Figure 30. IT Lean Process Figure 31. IT Lean Define Need Phase - Security Question Screen Capture Figure 32. SISSU Initial Question Indicators Screen Capture Figure 33. SISSU Completed Question Indicators Screen Capture Figure 34. SISSU Question Review Screen Capture Figure 35. SISSU Question Validation (Valid/Invalid) Screen Capture Figure 36. IT Lean Process Automatic Notifications Figure 37. Toggling Email Notification Figure 38. Email Notification Toggled Figure 39. Messages Tab - Organization Sort - All Message Delete Figure 40. Master Survey, Messages Tab Figure 41. Disciplines Tab – Validated Questions, Lock and Approval Figure 42. Summary Tab - Status Check Figure 43. Differentiator - Status Checking Figure 44. Phase Summary Hyperlink Figure 45. Disciplines Tab – Lock Discipline Figure 46. Disciplines Tab - Locked Screen Capture Figure 47. Disciplines Tab - Discipline Approval Figure 48. Milestones Tab - Validating a Milestone Screen Capture Figure 49. Pop-up Window - Confirming the Approval of a Milestone Screen Capture Figure 50. Milestones Tab - Milestone Approved Figure 51. Milestones Tab - Toggle Milestone Reviews as Required/Not Required Figure 52. Phases Tab - Locking a Phase Screen Capture Figure 53. Phases Tab - Phase Locked, Approving a Phase Screen Capture Figure 54. Interim DIACAP Version 2.6 IA control - Parent Question Figure 55. Interim DIACAP V2.6 IA control - COAS-2A Child Question Figure 56. Interim DIACAP V2.6 IA control - COAS-2B Child Question Figure 57. Phases Tab - Excludes Reports & Scorecard Functionality Figure 58. Security Discipline, IA control - Upload File Figure 59. DIACAP V2.7 – Define Need Summary Figure 60. DIACAP v2.7 - IA control (Example: COAS-1) Figure 61. Security Discipline, SISSU Question - Enter the system POA&M information Figure 62. Security Discipline, SISSU Question - Enter the system POA&M information Figure 63. Security Discipline - System POA&M Question (Add New) Figure 64. Security Discipline - System POA&M Question (Add New) Continued Figure 65. Security Discipline - System POA&M Sample Entry Figure 66. Phases Tab Figure 67. Reports Tab - Add Report or Add Package Figure 68. Reports Tab – Add Report Figure 69. Reports Tab - Generating Report Figure 70. Reports Tab - Generation of Report Figure 71. Reports Tab - Generate Package Figure 72. DoDI 8510.01 DIACAP Package Contents Figure 73. DIACAP Scorecard Tab Figure 74. System Identification Plan (SIP) Report Template Figure 75. DIACAP Implementation Plan (DIP) Template Figure 76. Plan of Action & Milestones (POA&M) Template Figure 77. DIACAP Scorecard Template Figure 78. DoD 5000 Process Aligned with IT Lean Sub-Process (DIACAP) Figure 79. JCIDS, DoD 5000-Series and IT Lean Relationships Figure 80. DoD IT System Categories Figure 81. AF CA and AF-DAA Support

Appendix A - Figure 1. COTS Software Asset Management Process

Appendix A - Figure 2. ISO 19770-2 Mandatory Software Tags Appendix A - Figure 3. ISO 19770-2 Optional Software Tags

Appendix B - Figure 1. Template for Decision Memorandum

Appendix C - Figure 1. Portal Home Web Page Appendix C - Figure 2. EITDR Home Web Page Appendix C - Figure 3. AFKS Home Web Page Appendix C - Figure 4. IT Lean Corporate Report – Execute Report Appendix C - Figure 5. IT Lean Corporate Report – Execution Popup Window Appendix C - Figure 6. IT Lean Corporate Report – Prompts Window Appendix C - Figure 7. IT Lean Corporate Report – Prompts Window Appendix C - Figure 8. IT Lean Corporate Reports “Management Multiple System Report” Sample for

POC Information Appendix C - Figure 9. “Management Multiple System Report and Management Overall Report” Query

Screen Appendix C - Figure 10. “Management Single System Report” and “Single System Duration by Question”

Query Screen 1 Appendix C - Figure 11. “Management Single System Report” and “Single System Duration by Question”

Query Screen 2 Appendix C - Figure 12. “Single System Duration Summary” Query Screen Appendix C - Figure 13. Phase Bypass Status Query Screen Appendix C - Figure 14. Query Result “Save” Options Appendix C - Figure 15. Sample “Management Multiple System Report” Appendix C - Figure 16. Sample “Management Overall Report” Appendix C - Figure 17. Sample “Management Single System Report” Appendix C - Figure 18. Sample “Single System Duration Summary” Appendix C - Figure 19. Sample “Single System Duration by Question” Appendix C - Figure 20. Sample “Phase Bypass Status’ Appendix C - Figure 21. AFKS Universe Home Web Page Appendix C - Figure 22. AFKS Web Intelligence InfoView Query Screen

1.0 INTRODUCTION

1.1 Background

Prior to IT Lean, the Air Force used numerous processes to develop, test, field, and support information technology (IT) systems. The policies and processes of the various stakeholders were poorly integrated, and often security, interoperability, supportability, sustainability, and usability (SISSU) were not communicated or addressed early enough in IT systems acquisition. This resulted in costly delays and failures in satisfying warfighter needs.

To resolve these issues, the Air Force Chief Information Officer (SAF/XC), and the Director of Acquisition Integration (SAF/AQX) chartered a business process reengineering team to establish a new, integrated process that clearly defines requirements, design, and test activities to ensure that SISSU is incorporated from requirements generation forward. This effort, dubbed “IT Lean Reengineering”, was led by representatives from SAF/XC and SAF/AQX, and included representatives from other HQ United States Air Force (USAF) offices, major commands (MAJCOM), functional communities, and product centers.

The reengineering team developed the IT Lean Process based on the acquisition process described in Department of Defense Instruction (DoDI) 5000.2, Operation of the Defense Acquisition System, but streamlined it to accommodate the need to rapidly develop and field secure IT. This process establishes clearly defined phases, activities, and decision points and requires early and continuous stakeholder involvement. The IT Lean Process reinforces the application of robust systems engineering principles to the IT lifecycle.1

The SISSU process is the information sharing methodology for the IT Lean Process. The SISSU process facilitates the networthiness assessment of IT, formerly accomplished through the Certificate of Networthiness (CoN) and Certificate to Operate (CtO). The SISSU process eliminates the CoN and CtO for all IT systems. The activities and information requirements previously associated with the CoN and CtO, often as an “end of runway” check, now occur early and throughout a program’s development cycle.

The SISSU process focuses on sharing information in lieu of generating, reviewing, and staffing redundant documentation. The SISSU process, through use of the SISSU Checklist, can help the program team identify security certification and accreditation (C&A) requirements.

The IT Lean Reengineering Guidebook describes both the IT Lean and SISSU processes, including their applicability and relationship to other Department of Defense (DoD) and Joint requirements, acquisition, and security certification processes. References to the IT Lean Reengineering Guidebook will be added to the appropriate 10-, 33-, 63-, and 99-series and other Air Force instructions and/or policy directives.

Detailed information on the IT Lean Process is provided in this IT Lean Reengineering Guidebook, which is available electronically on the AF Portal at:

https://wwwd.my.af.mil/afknprod/ASPs/CoP/OpenCoP.asp?Filter=OO-SC-AF-47.

1 Air Force Software-Intensive Systems Strategic Improvement Program (AFSSIP) memo, 13 January 2004.

https://wwwd.my.af.mil/afknprod/ASPs/CoP/OpenCoP.asp?Filter=OO-SC-AF-47

2.0 APPLICABILITY

2.1 IT Lean Process

The IT Lean process applies to programs in acquisition or sustainment including upgrades or modernizations. IT Lean will also be used for commercial-off-the-shelf (COTS) and government-off-the-shelf (GOTS) products being integrated into the Air Force Enterprise Network. The requirements of the DoD 5000-series acquisition policy, CJCSI 3170.01F, Joint Capabilities Integration and Development System, 1 May 2007, and AFI 10-601, AFI 99-103, Capabilities-Based Test and Evaluation, 12 May 2008, still apply.2

All AF programs except SAP/SAR and Space must use the SISSU Checklist for Security Certification and Accreditation (C&A) regardless of Acquisition Category (ACAT). SAP/SAR and Space systems will provide the system C&A package through use of the Guest (previously called non-AF) IT Lean process for AF connection approval. Approval for a program to enter IT Lean is vested in the appropriate acquisition autjhority for the program (MDA or local acquisition authority.

IAW AFI 63-101, all programs that meet the following criteria can use the IT Lean process:

• An IT program as defined in DoDI 5000.2;

• Designated ACAT III or Non-ACAT with a total cost of less than $15M or below in development or enhancement costs; and

• Has a Joint Potential Designator (JPD) of “Independent” (programs with no JPD are assumed to be “independent” – see CJCSI 3170.01F for definition of JPD)

SISSU Checklist. Although it is not required for non-IT Lean programs (e.g., Information Systems), the SISSU checklist can benefit all IT programs, including ACAT and major automated information system (MAIS) designated programs, to assist in the early identification of derived SISSU requirements. The security portion of the IT Lean process will be used by all programs for security C&A activities. Starting with requirements generation and continuing throughout the program, the continuous use of this tool will assist Program Managers in creating an efficient and effective development environment. The SISSU Checklist can be found at: https://wwwd.my.af.mil/afknprod/ASPs/CoP/OpenCoP.asp?Filter=OO-SC-AF- 47.

For Guest (DoD, Joint, non-AF) systems, see paragraph 9.0 and reference the “Non-AF System Getting Started Guide”.

2 This IT Lean Guidebook serves as one of the integral guides used to map acquisition and sustainment strategies for successfully executing capabilities based acquisition. Coupled with AFI 10-601, the PM shall use the DoD 5000 series, AFI 10-601, AFI 99-103, AFI 63-101, CJCSI 3170.01, AFPD 33-2, assistance from the Acquisition Centers of Excellence (ACE), and the plethora of references and supporting information sited in this document, to ensure the depth and breadth of necessary information is acted upon to develop and implement a successful program strategy.

https://wwwd.my.af.mil/afknprod/ASPs/CoP/OpenCoP.asp?Filter=OO-SC-AF-47 https://wwwd.my.af.mil/afknprod/ASPs/CoP/OpenCoP.asp?Filter=OO-SC-AF-47 https://wwwd.my.af.mil/afknprod/ASPs/DocMan/DOCMain.asp?FolderID=OO-SC-IA-01-31-6&Filter=OO-SC-IA-01 https://wwwd.my.af.mil/afknprod/ASPs/DocMan/DOCMain.asp?FolderID=OO-SC-IA-01-31-6&Filter=OO-SC-IA-01

3.0 IT LEAN PROCESS

3.1 Background

The IT Lean Process provides a standardized and streamlined approach to develop and field SISSU compliant IT capabilities. The process has four distinct phases: Define Need, Design, Build and Test, and Release and Support, as well as five milestone reviews: Define Need Review (DNR), Design Review (DR), Test Readiness Reviews (TRR) I and II, and Field Readiness Review (FRR). The IT Lean Process is depicted in Figure 1.3 A side-by-side comparison of the IT Lean Process with the traditional DoD acquisition process is shown in paragraph 5.6.

Figure 1. IT Lean Process.

Initiate & Plan C&A Execute DIACAP I-Plan Certification & Accreditation Maintain ATO, Review, Decomm

Implementation Plan SIP

ATO/ATC - IATO/IATC - DATO/DATC ST&E

Scorecard - POA&M

Define Need Design Build & Test Release & Support

DNR DR FRRTRR 2TRR 1

Integrated Test Plan

Cert. Testing OT&E

SISSU Sub -Process Validation Validation ValidationStart EITDR

Integrated Test Plan

Integrated Test Plan

Integrated Test Plan

“ AoA ” Req. Development

Validated Test Results

DIACAP

IT Lean Process

IATT

Activity Decision

Required document

Document required by an external process

The IT Lean Process focuses on addressing SISSU requirements early and posting the information for continual review, issue resolution, and validation in the Enterprise Information Technology Data Repository (EITDR)4. As depicted above, SISSU validation occurs before each major decision review in the IT Lean Process. The SISSU process is described in paragraph 4.0.

The DoD Information Assurance Certification and Accreditation Process (DIACAP)5 is required for all DoD-owned or controlled information systems that receive, process, store, display, or transmit DoD information, and is aligned with the IT Lean Process above.6

3.2 Pre-IT Lean Process Activities

As described in the Clinger-Cohen Act of 1996 and CJCSI 3170.01F, organizations must continually identify and assess their business processes and enterprise architectures to expose capability gaps and needs. These needs are exposed through methods such as functional area analysis, functional needs analysis, business process reengineering, corporate-level processes (such as the Capabilities Review

3 Acronyms are defined in Appendix D.

4 SISSU information is posted in the Enterprise Information Technology Data Repository (EITDR), described in Figure 2.

5 Department of Defense Information Assurance Certification and Accreditation Program , 28 November 2007, URL https://diacap.iaportal.navy.mil/ 6 AFPD 33-2 documents the AF policy for the IT Lean process https://diacap.iaportal.navy.mil/ and Risk Assessment), and architectural analyses between the current and objective IT architecture.

After the capability gap or need has been identified, the sponsor must consider all doctrine, organization, training, materiel, leadership, personnel, and facility (DOTMLPF) approaches, and exhaustively document the need to acquire or procure an IT solution to fill the gap.

National Defense Authorization Act (NDAA). The Defense Business Systems Management Committee (DBSMC) replaces the Information Technology Advisory Board (ITAB); functions associated with the Officer of the Secretary of Defense (OSD) Overarching Integrated Product Team (IPT) process are replaced by a standing Investment Review Board for Defense Business Systems.

Management of Defense Business Systems.

The system program manager shall utilize DoD and Air Force policies and processes in support of the management of defense business system programs. DoDD 5000.1 provides management principles and mandatory policies and procedures for managing acquisition programs. DoDI 5000.2 establishes a simplified and flexible management framework for translating mission needs and technology opportunities, based on approved mission needs and requirements, into stable, affordable, and well-managed acquisition programs that include weapon systems and automated information systems (AIS).

It authorizes Milestone Decision Authorities (MDA) to tailor procedures to achieve cost, schedule, and performance goals (within statutory requirements). AFI 63-101, Operations of Capabilities Based Acquisition System, 29 Jul 2005, implements AFPD 63-1, Capability Based Acquisition System, 10 Jul 2003, DoDD 5000.01, The Defense Acquisition System, 12 May 2003, and DoDI 5000.2, Operation of the Defense Acquisition System, 12 May 2003.

Certification of Defense Business Systems.

Any IT system that is designated as a defense business system with total modernization or development funding exceeding $1 million must be certified by the designated Investment Review Board (IRB) and approved by the DBSMC prior to obligating funds. Per Section 332 of the Ronald W. Reagan National Defense Authorization Act for FY05 (FY05 NDAA, P.L.108-375), failure to obtain DBSMC approval may result in an Anti-Deficiency Act violation. Details of the AF’s certification process are found in the AF IT Investment Review Guide located at the AF IT Investment Compliance Review CoP. In addition, information on the DoD Certification and Annual Review Processes can be found on the Business Transformation Agency7 website.

3.3 Information Sharing Strategy

The IT Lean process promotes a net-centric approach to information use that is making program-specific SISSU information accessible and reusable - not just captured in multiple redundant documents. The new process is supported by an IT solution that allows assigned stakeholders common, secure, and reliable access to this information throughout the life cycle of an IT acquisition. In addition, this information sharing solution provides reporting, query, and search capabilities to minimize the need to create extensive documentation. Under this construct, producers of requirements and system information (i.e., sponsors and Program Management Offices (PMOs)) should make all SISSU information available to reviewers and validators so a continuous review of a program’s derived requirements can be conducted. Additionally, this information is needed by requirements, acquisition, and fielding authorities to make program decisions at proper milestone reviews. Figure 2 provides a high-level operational concept graphic of the IT Lean information sharing strategy.

7 Business Transformation Agency URL http://www.defenselink.mil/bta/ http://www.defenselink.mil/bta/

Figure 2. IT Lean Information Sharing Strategy.

Produce

SISSU

Information Produce

SISSU

Information Validate

SISSU

Information Validate

SISSU

Information

Consume

SISSU

Information Consume

SISSU

Information

Generate

SISSU

Documentation Generate

SISSU

Documentation

Requirements sponsor and PMO address and post SISSU information from requirements generation forward

Mandatory DoD and CJCS documentation is generated from the information repository Decision makers use SISSU information for requirements, acquisition, and fielding decisions

Stakeholders continually review and validate that SISSU information has been addressed

PMO

Sponsor

AFCA

Stakeholders

Functionals MAJCOMs

PM PM

MDA MDA

DAA DAA

DIACAP

Supportability

Usability Sustainability

Interoperability Security

ETIDR & AFKS

SISSU Checklist

3.4 Enterprise Information Technology Data Repository (EITDR) The EITDR8 is the system of record for storage, management, and collection of SISSU information for all Air Force IT programs and initiatives. Sponsors and PMOs must input all required information into the EITDR starting with the requirements definition. Reviewers and validators must use the EITDR to conduct virtual evaluations of a program’s SISSU information. By using the EITDR and the Air Force Knowledge Service (AFKS) for data storage, stakeholders with access will continually review and validate SISSU information. Requirements, acquisition, and fielding decision makers will use this information throughout the IT Lean and DoD 5000-series processes. Program offices can produce some DoD required documentation by leveraging report-generation functionality of the EITDR.

3.5 IT Lean Define Need Phase

The IT Lean Define Need phase allows the sponsor (customer or user) to describe their capability need, develop functional and non-functional requirements, and allows the program manager (PM) to analyze the best acquisition strategy and solution. The IT Lean process begins here. The IT Lean Define Need phase is made up of three sub-phases: Define, Refine, and Analyze, which culminate in the Define Need Review. Activities and information requirements for each phase of the process are described in this section. All necessary information, including architecture views (or location of architecture views), SISSU requirements, and location of functional requirements are stored in the EITDR, accessible by all stakeholders through the Air Force Portal. For the purposes of the IT Lean Reengineering Guidebook, the information required during each phase of the IT Lean Process and stored in the EITDR is referred to as the “Capabilities Package.”9 A high-level depiction of the Define Need phase is provided in Figure 3.

8 SAF/XCI Email Policy dated 5 Aug 06, Mandatory Use of the Enterprise Information Technology Data Registry (EITDR) 9 The Capabilities Package is synonymous with “survey” in EITDR.

Figure 3. IT Lean Define Need Phase

Define Refine

Define Need Review (DNR)

Validation SISSU Sub-Process

Analyze

3.5.1 Define Sub-Phase

The Define sub-phase allows the sponsor to document the high-level capability need and begin addressing SISSU requirements. Activities associated with the Define sub-phase are described below.

(1) Identify IT capability need. The IT Lean Process begins when a sponsor identifies an IT capability need. This occurs after all activities described in paragraph 3.2 have been executed.

(2) Set up survey10 in the EITDR (if one doesn’t exist). After receiving management approval, the sponsor should contact their organization’s Portfolio Manager (PfM) to create a new initiative in the EITDR. PMs must contact their PfM for specific system(s) and role assignments in EITDR. PfM Point of Contact (POC) information can be found on the EITDR CoP URL;

https://rso.my.af.mil/afknprod/ASPs/DocMan/DocMain.asp?Filter=OO-TR-MC-16&FolderID=OO-TR- MC-16-5&Tab=0. Sponsors can contact SAF/XCPR if necessary to identify an organization’s PfM.

The sponsor can request an EITDR account (if they don’t already have one) through 554 ELSG /SBI by completing a DD Form 2875, System Authorization Access Request (SAAR).11 The EITDR CoP contains the account access form (DD Form 2875) and access instructions.12 Reference “Air Force Information Systems – Getting Started Guide for Processing Systems for Certification and Accreditation” from registration to conducting IT Lean process.

(3) Identify and engage system stakeholders and assign SISSU roles. Having proper stakeholder involvement is crucial to the success of defining the requirement and addressing SISSU needs.

Identify the system personnel required to fulfill the SISSU roles for data entry, review, and validation of the SISSU discipline information within EITDR. Figure 4 should be used as a general guidance when the PM develops the System Stakeholder Review Team list.13 This stakeholder list may be used, maintained, and revised as necessary throughout the system life cycle. The PM must ensure availability of these members.

Figure 4. Stakeholder Team List.

System Stakeholder Review Team List

TEAM LIST UPDATED: DD MMM YYYY

The following information must be provided by the Program Manager/System Owner, except as noted.

10 Surveys are the “meat and potatoes” of the EITDR system, where portfolio owners answer questions to input information about their systems and initiatives in several categories of topics. The different functional groups supported by EITDR (i.e., IPv6, NDAA, PfM/CIR, FISMA etc) require different subsets of these questions to be answered. Collectively, the complete set of questions is called a survey. Surveys are typically completed for a particular budget cycle, because answers to particular questions can determine the continued budgetary support for the portfolio in subsequent budget cycles.

11 Requests can be sent to EITDR.Helpdesk@wpafb.af.mil.

12 EITDR account information is located on the EITDR CoP URL https://afkm.wpafb.af.mil/asps/DocMan/DOCMain.asp?Tab=0&FolderID=OO-TR-MC-16-36&Filter=OO-TR-MC-16 13 This stakeholder list is not exhaustive; it is intended to give the sponsor and/or Program Manger an idea of the type of expertise they will need for system development.

https://rso.my.af.mil/afknprod/ASPs/DocMan/DocMain.asp?Filter=OO-TR-MC-16&FolderID=OO-TR-MC-16-5&Tab=0 https://rso.my.af.mil/afknprod/ASPs/DocMan/DocMain.asp?Filter=OO-TR-MC-16&FolderID=OO-TR-MC-16-5&Tab=0 https://wwwd.my.af.mil/afknprod/ASPs/DocMan/DOCMain.asp?FolderID=OO-SC-IA-01-31-6&Filter=OO-SC-IA-01 https://wwwd.my.af.mil/afknprod/ASPs/DocMan/DOCMain.asp?FolderID=OO-SC-IA-01-31-6&Filter=OO-SC-IA-01 https://wwwd.my.af.mil/afknprod/ASPs/DocMan/DOCMain.asp?FolderID=OO-SC-IA-01-31-6&Filter=OO-SC-IA-01 https://wwwd.my.af.mil/afknprod/ASPs/docman/DOCMain.asp?Tab=0&FolderID=OO-SC-IA-01-31-20&Filter=OO-SC-IA-01 mailto:EITDR.Helpdesk@wpafb.af.mil https://afkm.wpafb.af.mil/asps/DocMan/DOCMain.asp?Tab=0&FolderID=OO-TR-MC-16-36&Filter=OO-TR-MC-16

Individuals may fill more than one role. For detailed stakeholder process information, consult the IT Lean Guidebook (paragraph 3.4.1(3), (5), and (6)) on the Information Assurance Community of Practice (CoP) Web Site on the Home page under the category “Community Bookshelf”.

System Name System Acronym

Version Number (Exactly as entered in EITDR)

System Stakeholder Review Minimum Team Member List

Title Team Members [Name, Rank, Phone (DSN preferred), Email Address, Organization/Office Symbol]

Program Manager

Functional User

IA Manager Lead Architect (if assigned)

Lead Engineer (if assigned)

Software Development Lead

DAA

Certifying Authority (CA)

CA Representative

Agent of CA (ACA) Information System Owner (ISO)

Test Director / Manager

Assigned and provided during Initial Review on initial email.

HQ Air Force Communications Agency (AFCA)/EVSC

DSN 229–6485 or afca.evsc@scott.af.mil

AFCA SISSU

Security Action Officer

Title Other Team Members

AFFMA

Representative (for wireless requirements)

CITS

Representative

Network Engineer

STEM

Financial Manager

Intelligence Representative

Security Forces (if assigned)

Civil Engineer (if assigned) https://wwwd.my.af.mil/afknprod/ASPs/docman/DOCMain.asp?Tab=0&FolderID=OO-SC-IA-01-31-20&Filter=OO-SC-IA-01 https://wwwd.my.af.mil/afknprod/ASPs/docman/DOCMain.asp?Tab=0&FolderID=OO-SC-IA-01-31-20&Filter=OO-SC-IA-01 mailto:afca.evsc@scott.af.mil

(4) Create System Version and Determine the Degree of System Modification.

a. Create System Version. If the system’s configuration changes the configuration change/modification must be processed through the IT Lean process and a system version must be created within EITDR.14 NOTE: The SISSU version must be the configuration management version number that the system will field. The accreditation decision/connection approval documents reflect the version number and therefore must match. Reference paragraph 3.7.1 (1). (Other terms used for the version number: Product Baseline number, Release number, configuration control version number etc.)

b. Initial Version Review Processing. SISSU Security Validator/AFCA Action Officer (AO) process only. AFCA AO will email a report to the PM to resolve the responses in EITDR. (The AO and PM will work through the Initial Version Review ((IVR) comments). If unable to come to resolution or if the PM fails to respond within 2 working days, the AO will email a report to the Certifying Authority (CA) (AFCA/EV) with all invalid questions and AO comments. The CA will forward the report to the PM’s chain of command (O-6) for action. The PM will make necessary changes in EITDR, notifying the AO when complete. The AFCA AO must ensure all IVR questions are brought to a valid state before IVR approval. NOTE: Systems with Invalid IVR question responses are not ready to move to Define Need Phase. If the IVR questions are determined to be valid: if not requesting a bypass, the AO sends an e-mail to the PM with instructions to finalize the version and proceed to the Define Need Phase. If requesting a bypass, the AO sends e-mail to the PM with instructions to finalize the version and proceed to the directed phase.

c. Determine the Degree of System Modification. If the system has undergone a previous version in the IT Lean process, a “predecessor version” can be brought forward to allow update to the system information. Also the Initial Review Meeting is initiated and conducted by the PM through contact of stakeholders to determine the level of assessment required for the current version of the system. If the IVR determines there is no change to the SISSU discipline(s) from the previous version, the discipline(s) can be “bypassed.” The remaining disciplines are addressed through the IT Lean process as deemed necessary. NOTE: The Security discipline will require approval from AFCA/EVSC based on the security review of the artifacts uploaded in the Initial Review Decision Outcome question.

(5) A key group of stakeholders is the integrated test team (ITT) as defined in AFI 99-103. The ITT will actively participate in all process phases and advise about the need for an Integrated Test Plan (ITP) beginning at the Refine sub-phase.

The sponsor will engage their supporting intelligence representative to determine whether or not intelligence support is required. If intelligence support is required, procedures in accordance with AFI 14-111, Intelligence in Force Modernization, must be followed in conjunction with the IT Lean process.

(6) Notify reviewers and validators. During this activity, the sponsor and/or program manager will negotiate a window of time with the SISSU reviewers and validators when production, posting, reviewing, and validating of SISSU information in EITDR will be accomplished. Negotiation of participation can be included and discussed during the Initial Review Meeting. NOTE: The AFCA AO and SISSU Security Validator are not involved in the Initial Review Meeting. However, 100% of the SISSU security questions must be answered before SISSU Security validation occurs. As a minimum, reviewing and validating agencies will have 2 weeks (10 working days) to provide comments on the applicable set of SISSU answers once EITDR provides notification that SISSU questions are all answered and locked, reviewed, and validated. EITDR will provide automatic

14 System version is referred to as a “snapshot in time” and correlates to a Configuration Management Product Baseline.

notification to all stakeholders when the current date is equal to 10 days of the discipline target completion date. The information producer must perform comment resolution as necessary to resolve any/all issues/concerns to keep with the system IT Lean Phase schedule. If time permits, reviewing and validating agencies may review questions once questions are locked and reviewed, to escalate the review and validation process.

(7) Produce and post SISSU requirements. After an IT capability need is identified, the sponsor and/or program manager must answer questions questions associated with this IT Lean sub-phase from the SISSU Checklist (reference paragraph 4.4.9.)

3.5.2 Refine Sub-Phase.

The Refine sub-phase is intended to further refine the capability need by defining functional requirements, drafting the ITP and project schedule, and posting required SISSU information in EITDR. Activities associated with the Refine sub-phase are described below.

(1) Document functional requirements. The sponsor, with the help of the program manager, can document their functional requirements however they see fit. The sponsor validates functional requirements during the Refine sub-phase.

(2) Develop draft Integrated Test Plan (ITP). The ITP integrates individual contractor and government test plans into an interlocking series of evaluations focused on the current increment with follow-on increments described in lesser detail.15 The program manager, sponsor, and Integrated Test Team will collaborate to write the ITP. The ITP includes all security test criteria (reference DIACAP Validation Procedures) including those formerly identified and collected through the security testing .

(3) Develop the project schedule. The program manager, with the help of the sponsor, will develop the project schedule. The project schedule must identify the tasks and assign resources to those tasks.

The project schedule must reflect activities associated with producing, posting, reviewing, and validating SISSU information in EITDR.

3.5.3 Analyze Sub-Phase

The Analyze sub-phase consists of an analysis of potential alternatives and an extensive SISSU analysis on the proposed solution. Activities associated with the Analyze sub-phase are described below. For intelligence-sensitive initiatives, an intelligence support working group (ISWG) begins the intelligence infrastructure analysis in accordance with AFI 14-111.

(1) Assess potential alternatives. The sponsor and program team assess the performance characteristics and estimated costs of alternative systems to satisfy the capability need and weigh SISSU requirements for each alternative. The sponsor and program management team must research existing and non-existing materiel solutions including COTS and GOTS products that could potentially satisfy the capability need and are compatible with the objective architecture used to define the need.

The sponsor and program team, if identified, should prioritize the following potential alternatives:

Utilize enterprise resource planning (ERP) when ERP capabilities offer advantages over other available alternatives.

Utilize COTS or GOTS; either procure a COTS or GOTS product or integrate/tailor COTS or GOTS through a contractor or organically.16 (See SD-2, Buying Commercial &

15 AFI 99-103, Capabilities Based Test and Evaluation.

16 The Enterprise Integration Toolkit (www.eitoolkit.com) and SD-2, Buying Commercial & Non-developmental Items: A Handbook, Apr 1996. http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA309030 can assist in COTS procurements.

http://www.eitoolkit.com/ http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA309030%20

Nondevelopmental Items: A Handbook, Apr 1996, for details about acquisition and testing of COTS and GOTS items). Reference Appendix A for the COTS/GOTS process.

Build a custom solution using a contractor or the government.

If the alternative involves organic development, the sponsor should provide sufficient analysis to show that no alternative or private sector source can support the need more effectively or at lower cost.17

(2) Choose alternative. The sponsor, with the help of the program manager, must choose the best value solution that will satisfy the capability’s need and be secure, interoperable, supportable, sustainable, and usable.

(3) Develop acquisition strategy. The program manager, with the help of the sponsor and other stakeholders, develops an acquisition strategy during this phase. The acquisition strategy explains the method for acquiring or procuring the solution such as a purchase agreement, contractor solicitation, etc. If the acquisition strategy involves contractor development, a request for proposal package and source selection criteria must be developed.

(4) Produce and post SISSU requirements. When the program manager decides on the appropriate acquisition strategy and solution, the SISSU information for that solution is addressed. The program manager, with the help of the stakeholder team, answers all required SISSU questions in the EITDR.

(a) DIACAP Comprehensive Package. System Identification Profile (SIP). The SIP is started during system registration in the EITDR and continually compiled throughout the certification and accreditation process. The SIP provides general information about the system. Assignment of DIACAP IA controls should be validated based on the Mission Assurance Category and Confidentially Level assigned to the system.

(b) Air Force Clinger-Cohen Act (CCA). Compliance with the Clinger-Cohen Act (CCA) of 1996. All acquisitions of IT services, regardless of services category shown in Table 3-2, are subject to Title 40, Subtitle III, USC 11101.

The PM shall initiate a Clinger-Cohen Act (CCA) compliance and certification package at program initiation or the earliest point possible for all IT (including National Security Systems (NSS)) acquisitions. The PM shall prepare a matrix identifying the eleven items (See table located in E4.T1 of DoD 5000.2). This package should be a coordinated effort with the appropriate functional operator or user. The completed CCA package will be forwarded to the AF Chief Information Officer (CIO) (SAF/XC) to confirm compliance back to the MDA. Major Automated Information System (MAIS) programs (ACAT IAM or IAC) require additional certification of compliance with the CCA by the DoD-CIO (OSD/NII).

(c) Federal Information Security Management Act (FISMA)18. FISMA (PL 107-347) mandates the agency CIO maintain an inventory of all information systems under their purview. OMB Circular A-130 mandates all federal computer systems be certified and accredited. Within DoD, DoDI 8500.1, paragraph 4.13, requires all DoD ISs be certified and accredited. Systems in pre-deployment are not required to be C&A’d for FISMA purposes but should be working towards accreditation utilizing the DIACAP implemented via IT Lean.

(d) Information Support Plan (ISP). All systems - ACAT and non-ACAT acquisitions, and fielded systems must be evaluated and certified prior to (initial or updated) fielding, and periodically during the entire lifecycle of the program. Program Managers shall prepare the ISP, which documents the information support needed to develop warfighter capabilities described in the

17 In accordance with the Clinger-Cohen Act of 1996.

18 Title 44 U.S.C. Sections 3541-3549 (Federal Information Security Management Act (FISMA).

Initial Capabilities Document (ICD), Capability Development Document (CDD), and Capability Production Document (CPD) or requirement document. The ISP describes and evaluates intelligence, infrastructure, interoperability and other IT and NSS interfaces the acquisition program needs during development, testing, training and operations. The ISP also documents current/projected deficiencies in intelligence support needed to develop the weapon system capability.

An approved ISP is required not later than Milestone B (or appropriate and related “milestone-like event” (for Non-ACAT) and should be initially developed concurrently and collaboratively with the associated CDD or CPD, unless exceptions are noted in an Acquisition Decision Memorandum. As the program matures, or proceeds through multiple evolutionary blocks or phases, the Program Manager shall update the ISP. Updates shall contain progressively more detailed and specific time-phased descriptions of the types of information needed; integrated architectures; spectrum supportability, security, connectivity, and interoperability issues; and infrastructure, intelligence, information assurance, net-readiness, and other information support needs. Changes in information support, infrastructure, and interface requirements resulting from proposed changes in approved JCIDS documents shall be highlighted to facilitate the ISP review.

(5) The MDA or cognizant fielding authority shall review, assess, and approve ISPs for ACAT and

Non-ACAT programs. At the end of MS B (or milestone-like event), the PM will ensure all support concept elements are fully identified with supporting documentation. For IT Lean the ISP should be completed by Design Review. At this point, the PM, together with the operator MAJCOM, will decide whether technologies will be organically supported, contractor supported, or a combination thereof. Examination and evaluation of existing support concepts and preparation for the development of the new support systems is key to posturing for the next phase. Additional guidance on ISPs can be found at http://www.dau.mil/pubs/gdbks/acqulogguide.asp; DoD Directive 4630.5, Interoperability and Supportability of Information Technology (IT) and (NSS), -http://www.dtic.mil/whs/directives/corres/html/46305.htm; DoD Instruction 4630.8, Procedures for Interoperability and Supportability of Information Technology (IT) and (NSS), http://www.dtic.mil/whs/directives/corres/html/46308.htm; and CJCSI 6212.01, Interoperability and Supportability of Information Technology and NSS, http://www.dtic.mil/cjcs_directives/cjcs/instructions.htm#6000. For procedures on submitting and coordinating the ISP, see the SAF/XCX ISP Policy Community of Practice on Air Force Knowledge Now: https://rso.my.af.mil/afknprod/ASPs/CoP/OpenCoP.asp?Filter=OO-AQ-

AF-18.

(5) Validate SISSU information in EITDR. This activity is performed by personnel and/or organizations identified in Figure 4.

(6) SISSU Security Validator/AFCA AO process only. The AFCA AO will validate/invalidate the responses to Define Need Phase security questions. Invalidated questions will be accompanied by an entry in the comment portion of each question. NOTE: All questions must be brought to a “Valid” state before applying for Define Need SISSU Security discipline approval. The AO will email a report to the PM to resolve the invalid responses in EITDR. (This is a one-time attempt at Define Need response resolution between the AO and the PM). The PM will make necessary changes in EITDR, notifying the AO when complete. If the PM does not resolve all the invalid questions or if the PM fails to respond within 2 working days after all Define Need questions have had a validation review, the AO will email a report to the CA with all invalid questions and comments for resolution. The CA will forward the report to the PM’s chain of command (O-6) for action. The PM will make necessary changes in EITDR, notifying the AO when complete. AO will re-validate the Define Need questions. If Define Need questions remain invalid, the AO will recommend “Non-Concur” to the CA. The AO will include a report with all Invalid questions and comments. The CA will notify the ISO and DAA with recommendation for “Non-Concur”. NOTE:

Systems with invalid Define Need question responses are not ready to move to the Design Phase. If a “Non-Concur” has been recommended, the PM cannot proceed to the Design Phase.

The CA, ISO, DAA, & PM must resolve before further AO actions. Once all Security Define Need http://www.dtic.mil/cjcs_directives/cjcs/instructions.htm#6000 https://rso.my.af.mil/afknprod/ASPs/CoP/OpenCoP.asp?Filter=OO-AQ-AF-18 https://rso.my.af.mil/afknprod/ASPs/CoP/OpenCoP.asp?Filter=OO-AQ-AF-18 questions have been validated, the AO will email the PM allowing them to proceed to the Design Phase and request the PM contact AFCA/EVSC for approval of the Security Discipline when all other SISSU disciplines have been approved. The PM sends email request for SISSU Security Approver (AFSC/EVSC) to lock and approve the security discipline when all other disciplines are complete.

(7) Send recommendation to the program manager. This activity is performed by the validation authorities identified in Figure 29. The recommendation includes any associated risks and/or any SISSU information that requires adjudication by the decision authority. This recommendation is used by the decision authority as part of the Define Need Review.

3.5.4 Define Need Review.

After the need has been documented, refined, and analyzed, the Define Need Review is held. A validation of all applicable SISSU requirements by the appropriate validators (described in paragraph 4.3) is an input to the Define Need Review. The chair of the Define Need Review determines the appropriate type of meeting (i.e., physical or virtual). The DNR cannot be done until all questions in the SISSU Define Needs Phase have been answered, reviewed and validated.

This review ensures the appropriate analysis has been done on the functional requirements, derived SISSU requirements, and potential solutions. The approval authority varies based on the scope and dollar amount of the requirement. For functional and MAJCOM requirements that do not meet Air Force Requirements for Operational Capabilities Councl (AFROCC) thresholds (ref AFI 10-601), the approving authorities are the chairs of the functional and MAJCOM requirements boards. In some cases, the functional and MAJCOM requirements boards will approve a requirement before sending it to the AFROCC. For infostructure requirements that do not fall within a specific functional domain (e.g., potential cross-cutting MAJCOM requirements), the O-6 level Infostructure Requirements Council will validate and approve.19

To initiate the Define Need Review, the sponsor/program…