Quick Start Guide

1.1.3. Tap into subject matter expert partners (DELTA team, support contractors, FFRDCs/UARCs).

1. Think big, start small, and scale fast.
2. Pivot from cubes to physical and virtual collaboration and innovation spaces where the team can collaborate with tools at the appropriate classification level.
3. Bring all functional team members (PM, FM, PSM, LG, T&E, SE) into the fight.
4. Don’t leave data behind … get creative on how data can inform the design and acquisition decisions.
5. Build the Digital Acquisition so that the team has access to know whatever it needs to know when it needs to know it.

Considerations

1. What new skills does the government workforce need to develop/acquire?
2. How to grow these skills (e.g. utilize a framework like the Model Based Competency Framework)?
3. What academic sources can be leveraged (i.e. AFIT programs and content-sharing ability like Avolve or External Academic offerings).
4. Initial Best Practices / Lessons Learned exist for Government Workforce Skillsets.

Resources on the AF Digital Guide

• Digital Maturity Metrics
• Digital Training Curriculum Tracks

2. Define the effort and acquisition strategy that the program will use for the Digital Environment and modeling approaches

Activities

1. The program’s strategy for digital acquisition over the life cycle should be captured in the Acquisition Strategy. This strategy should define the overarching digital acquisition products and their injection points in the acquisition schedule. The strategy should address the acquisition’s modeling objectives, a digital maturity metrics assessment of the government and industry base and the identification of what model-based products are necessary to support acquisition decisions. The digital strategy and its corresponding digital implementation plan need to be referenced and supported by the major acquisition documents including the RFP, SOW, SEP, TEMP, LCMP, and any technology transition plan. A program’s digital strategy should address all of the steps within this quick start guide that are relevant to the capability the program is acquiring and included in the program’s modeling objectives.

Considerations

1. What are the Program Characteristics that either constrain or enable digital adoption such as program Development Type, Acquisition Phase, New start or Modification, and Adaptive Acquisition Framework Pathway? Consider a Digital Maturity Assessment as necessary.
2. Other constraints/enablers to consider are the legacy program data rights, the value proposition of adopting digital acquisition strategies, the program’s modeling objectives, the security levels at which data will reside, which program phases exist in the strategy, and the Government sustainment strategy.

Resources on the AF Digital Guide

• Digital Transformation Vision and Foundational Documents
• Digital Maturity Metrics
• Model-Based Strategic Contracts Guidance
• Digital Considerations for the Acquisition Documents (ASP/TEMP/LSCP/SEP)

3. Define the Digital Acquisition resources and IT needs

Activities

1. Identify through market research what tools & infrastructure the relevant industry base possesses that the program is contemplating utilizing and iterate findings as necessary. Determine which model acquisition approach to use (Model-Supported, Model-Collaborative, Model-Centric, and Model-Service Acquisition) and whether the digital ecosystem will be government furnished, contractor furnished, or a hybrid. See Competitive Contracting Methodology Guidance on the Model-Based Strategic Guidance Page for clarification on the acquisition approach terms.
2. Identify the tools that will need to reside in the Integrated Digital Environment (IDE). This will be the basis for the digital enterprise. Tool categories to be concerned about include software development, Model-Based Engineering (MBE), Model-Based Systems Engineering (MBSE), Physics Based Models, Input-Output Model (e.g. Artificial Intelligence, Neural Network), Model Based Definition (MBD), Product Lifecycle Management (PLM), and other models including non-engineering functional tools. Identify any required middleware, third-party plug-ins or other tools that facilitate data exchange or integration between Commercial off the Shelf (COTS) tools. Identify custom-developed tools, such as dashboards, that are required to support DE technical and programmatic objectives. Identify large model training data sets and how they will be acquired. Use COTs tools as much as possible to reduce unique tool development time.
3. Identify the infrastructure to network the IDE. Clearly understand Multi-Level Security (MLS) if the program has data at multiple security levels. Understand that the IDE may encompass a federated set of tools/data in order to meet all program digital needs. Identify the ability to integrate with contractor systems. The key is understanding configuration and security management for the data that will be stored in the infrastructure, and being able to get the right program stakeholders access to the data they need to perform their functions efficiently and effectively. Also consider data aggregation challenges for a Multi-Level Security IDE infrastructure. Contact AF Enterprise Digital Transformation Services for information on government hosted Integrated Data Environments (IDE).
4. Particularly, pay attention to the interoperability between the tools and the ability to transfer data between them without the loss of data as this will be important in maintaining the IDE as an authoritative source of truth. The program will need to collect, visualize, manipulate, and store the defined data for all functional team performance.
5. Plan for MBE/MBSE Model Development and Maintenance, Model Configuration Management and Model Portfolio Management to include both Government and Contractor Models, governance, model construction, model repositories, model re-use, and model developments. This plan should include an ontology or meta model of the different types of models required to support the acquisition strategy and individual model characteristics/capabilities requirements, how different model types are related, what their purpose is, use cases for how different stakeholders will use the models, and the necessary tools and environment for developing, managing, and viewing the models.
6. Estimate and budget for the costs needed for the defined tools and infrastructure and data. While there will be cost up front for the program, there should be an expectation that there will be benefits as the program progresses through development, production and fielding, operations, and sustainment. Also keep in mind that technology is rapidly changing and that budgeting in out-years need to consider hardware and software licensing arrangements, authorities to operate, and software and tech refreshes.
7. Identify the competencies of the government workforce needed to use the digital tools and the infrastructure. Ensure education and training is included throughout the program.

Considerations

1. What does market research show that the program’s industry base is already using for tools & infrastructure?
2. Is there appropriate bandwidth for government and industry to access the IDE
3. What new skills does the government workforce need to develop/acquire?
4. What IT tools and systems does the team need to learn and gain experience in using?
5. How can those skills and experience be grown prior to executing the program?
6. Initial Best Practices / Lessons Learned exist for Infrastructure & Tools.

4. Develop SysML-compliant models for the program

Activities

1. Identify 2-5 system architects with expertise in SysML modeling environment.
2. Establish cross-functional team that includes MAJCOM requirements owner, MAJCOM weapon system operators and maintainers, and sustainment experts to provide input to the system architecture.
3. Draw from available Government Reference Architectures (GRAs) to guide and constrain the system architecture. A list of GRAs is available here.
4. Utilize Acquisition and Sustainment Data Package (ASDP) Contracts Guidance to define support information that includes the model governance (data dictionary, data architecture, style guide, interoperability standards like SysML, XMI, and SISO) and contract requirements that the program will need to support the effort. These items will help standardize the development of the digital system model over the system lifecycle. Detailed information on the ASDP tiles can be found here.
5. Develop Government System Architecture model that includes the requirements (such as from ICD, Draft CDD), Operational Architecture, High-level Functional Architecture, and external interfaces. A MBSE Guidebook and MBSE Style Guides are available to support this step.
6. Architecture developers should start with an understanding of which AF domains the system will be a part of. (For the Air Force it should be part of the Air, Space, and Cyberspace Domains but the program might have access to higher level architectures such as campaign, mission, or other related GRAs that can be used to inform the program’s architecture development). Analysis will range from Campaign, Mission, Weapons, System, and Subsystem design trades.
7. Government System Architecture should identify critical interfaces.
8. Government System Architecture should include risks (Technical, Cost, and Schedule).
9. Hold a series of Requirements and Architecture Summits with MAJCOM user to refine the Government System Architecture.

Considerations

1. How does the business strategy align with the Government Reference Architecture development?
2. How does the business strategy align with the modeling objectives?
3. What architecture components should be open for future system modernization & sustainment competitions?
4. Does an existing contractor need to deliver or provide access to previously developed digital models, software, artifacts, data, etc. to complete this step?
5. Initial Best Practices / Lessons Learned exist for Standards, Contractor Integration, and Contracting.

Resources on the AF Digital Guide

• Government Reference Architecture
• MBSE Style Guides
• Acquisition and Sustainment Data Package

5. Develop Modular Open System Approach (MOSA) strategy to identify relevant modular systems and key interfaces within the System Architecture

Activities

1. Hold Intelligence Summits with key stakeholders from the operational, intelligence, acquisition, and Science & Technology communities to identify adversary capabilities and investments that impact the weapon system, identify key technologies/technology trends that impact the weapon system, and expose all external interfaces.
2. Map these threats and stressors against the System Architecture to identify relevant modular systems, key interfaces and design features to support a modular open system design.
3. Hold Sustainment Summits with operational, acquisition, and sustainment communities to identify relevant modular systems, key technologies/technology trends and key interfaces and design features that will improve long-term sustainment of weapon system.
4. Perform Model Data Intellectual Property Identification and use the AF Data Rights Guidebook for additional information on how to require, acquire, and manage technical data in a digital acquisition program. Align the business strategy for data access and data delivery and the intellectual property strategy with the open system approach and identified relevant Modular Systems to align with the government’s rights to the technical data.
5. Update the System Architecture to account for relevant modular systems, key interfaces, design features, and data rights that improve sustainment of the weapon system.
6. Designate, empower, resource, and train System Architects in Program Offices for managing open architecture implementation
7. Leverage commercial technology and leverage commercial open (non-proprietary) standards to the maximum extent practicable. A listing of commercial open standards can be found on ASSIST.

Considerations

1. In general, programs can use the following litmus test to know whether they are taking the right approach to Open Systems Architecture to yield its transformative benefits: “Can one or more qualified third parties add, modify, replace, remove, or support a component or subsystem of this system; and can a separate system or platform integrate and share data with my system, based on open standards and published interfaces?” If the answer to this question is yes, the program is on the right path.
2. It is better to use something that works and is commercially available and regularly matured, than attempt to create the “perfect standard” that too often never materializes or is unable to stay current with agile updates. Where no reasonable commercial standard exists, programs should leverage Government Reference Architecture Open Standards to ensure interoperability and ease of system integration and modernization.
3. Do the requirements documents reflect an Open Systems Architecture to communicate and share across domains?
4. How have operational users, maintainers, and sustainment community had their inputs into the development a government reference architecture (GRA)?
5. How can modeling help make better decisions faster on the program?
6. Initial Best Practices / Lessons Learned exist for Models. Note: The initial Lessons Learned Page is not separated into specific lesson areas and will evolve over time.

Resources on the AF Digital Guide

• Government Reference Architecture

6. Develop a verification strategy that matches the program’s development, production, test, and sustainment approach

Activities

1. Hold Requirements Verification Summits with the contractor, engineering, test, and (if required) operational communities to define requirements verification activities at component, subsystem, and system level. Determine what types of models are utilized for what purposes.
2. Develop plans to support requirements verification (determine what is required from industry and what must be done independently by government).
3. Define requirements for each phase of the product lifecycle.
4. Plan for system verification, validation, certification, and accreditation requirements to be managed within the Program-specific MBSE system model or requirements management system. System verification, validation, certification, and accreditation data/artifacts should have model integration & traceability (digital thread) in the IDE and routed through a PLM workflow. Develop Data Analysis Plans to show traceability for what data is needed to identify model parameters and to verify models.
5. Develop instrumentation plans that include instrumentation parameter type, quantity of data needed, and quality of data needed.
6. Develop plans for model attribute/capability requirements such as the ability for dynamic models to be able to both use model generated data (integrated feedback data) for model component inputs and also to be able to use test data for model component inputs.
7. Make plans for obtaining required data to train models.

Considerations

1. How will the program maximize use of digital and/or automated tools and architectures for verification of requirements in the Test Strategy?
2. Integrated Digital Environment – Don’t forget testers are a user/consumer.
3. How will digital artifacts replace or complement traditional “paper” deliverables?
4. Verification planning & traceability, test plans, test reports, certifications, etc.
5. Link test organizations to digital system model development & usage – along with GRA & any acquisition models.
6. Initial Best Practices / Lessons Learned exist for program office use. Note: The initial Lessons Learned Page is not separated into specific lesson areas and will evolve over time.

7. Develop digital sustainment strategy through Product Lifecycle Management (PLM)

Activities

1. Hold Digital Sustainment Summits to develop the Life Cycle Sustainment Plan (LCSP) ensuring LG & ALC participation. Keep in mind the PLM tool mandate.
2. Develop a Product Support Strategy (PSS) that addresses the approach for managing the data & data rights for each phase of the product lifecycle (access, delivery, format, and storage) and include sustainment of ASDP data.
3. Develop PLM system requirements for each phase of the product lifecycle.
4. Develop the program strategy for Model Integration and Traceability (Digital Thread) to connect Functional Architecture Models and tools with the PLM system to maintain an authoritative source of truth.

Considerations

1. What sustainment organization process and infrastructure changes are required to implement the program’s Model Acquisition Approach?
2. What legacy data from non-model based systems or programs needs to be integrated with the program data models and PLM in order to operate and sustain the weapon system?
3. What digital acquisition practices utilized in development can provide the greatest Value Proposition during operations & sustainment?
4. Initial Best Practices / Lessons Learned exist for Tools (PLM). Note: The initial Lessons Learned Page is not separated into specific lesson areas and will evolve over time.

8. Develop DevSecOps strategy

Activities

1. Hold DevSecOps Summits with the government team and software development experts to define the software strategy for all phases of the program lifecycle.
2. Develop a plan for the DevSecOps maturity growth over the program lifecycle in alignment with the available resources and IT needs over time.
3. Develop a plan for the program implementation of the DevSecOps design pillars (Organization, Process, Technology and Governance) from the DoD Enterprise DevSecOps Reference Design.
4. Utilize a DevSecOps pipeline that meets the key elements of modern software development practices (human centered design, active & committed user engagement, enterprise services/platforms, rapid & iterative releases, gov/industry software teams, and automated tools); Consider using an existing Air Force Software Factory.

Considerations

1. There are many pieces of software on a program (COTS, mission computing system, subsystem, avionics, etc), which ones are planning to use DevSecOps practices for development?
2. Have Agile requirements and code verification been included in contracts language?
3. What is the plan for demo and delivery of software?
4. Initial Best Practices / Lessons Learned exist for Software Development (Metrics, Continuous ATO, Contracting Considerations, Acquisition Strategy, etc). Note: The initial Lessons Learned Page is not separated into specific lesson areas and will evolve over time.

Resources on the AF Digital Guide

• Air Force Chief Software Officer site

9. Share the digital engineering strategy (Government System Architecture, OSA, Test, Sustainment, Software) with industry

Activities

1. Utalize RFPs, RFIs or hold several industry days … cast a wide net. Work with industry to shape deliverable and data rights requirements.
2. Share the government Digital Reference Library (pre-award) with industry early and often to receive feedback on the adequacy for proposal submissions.
3. Practice digital engineering data transfer with industry partners prior to contract award if integrating government with contractor systems or furnishing government systems for contractor usage during execution.
4. Deliver multiple Draft RFPs to garner industry feedback on the digital acquisition strategy and model acquisition approach.

Considerations

1. What evaluation criteria will help you select a contractor that will execute to the programs modeling objectives?
2. What technical data do you need to share with industry in a Digital Reference Library? What data do you have if you are a legacy program?
3. Initial Best Practices / Lessons Learned exist for Contractor Integration, Contracting. Note: The initial Lessons Learned Page is not separated into specific lesson areas and will evolve over time.

Resources on the AF Digital Guide

• Model Based Strategic Contract Guidance

10. Develop a Digital Acquisition centric Request for Proposal

Activities

1. Require industry to deliver a Weapon System Architecture Model based on Government System Architecture as part of their proposal.
2. Require industry to deliver a Requirements Verification Architecture Model
3. Develop Product Sustainment Architecture Model to connect product support elements to the Government System Architecture and PLM strategy.
4. Review the Model-Based Strategic Contract Guidance which includes key features, competitive contracting methodology & guidance, and key feature & CDRL alignment
5. Review the Acquisition Sustainment Data Package (ASDP) Contract Guidance which includes specific actionable language for Statement of Objectives/Statement of Work development.
6. Review the ASDP Data Tiles which include Data Item Description updates for model based acquisition.
7. Consider Model Based Reviews and Audits. Consider tailoring reviews and audits to continuous design review rather than milestone based design reviews, to meet the intent and still comply with DoDI and Air Force Instruction (AFI) acquisition review requirements.

Considerations

1. What is the contractor already doing and what do they, or the government, need to change to meet the program requirements and objectives? The industry base is likely already implementing digital approaches that may require changes to government program office processes.
2. Initial Best Practices / Lessons Learned exist for Contracting. Note: The initial Lessons Learned Page is not separated into specific lesson areas and will evolve over time.

Resources on the AF Digital Guide

1. Model Based Strategy Contract Guidance
2. Acquisition Sustainment Data Package (ASDP) Contract Guidance

For questions, or feedback on this quick start guide please contact the Digital Transformation Office ([email protected])