In software program acquisition as in software program structure, one measurement doesn’t match all. Complicated mixed-criticality programs require a versatile government-acquisition system for approval, oversight, and funding. Our earlier weblog submit described how technical reference frameworks (TRFs) present versatile computing and infrastructure environments via modular elements that align a sample of temporal must scale with the processing wants for reusable area architectures. TRFs handle the total vary of navy capabilities, juxtaposing the boundaries of criticality and scale. On this submit we present tips on how to map TRFs to the completely different pathways that compose the DoD’s Adaptive Acquisition Framework (AAF).
Complicated architectures of architectures comprising features of blended criticality require a mixing of various TRFs. As proven in Determine 1, a single, unified acquisition technique that may additionally apply a unified technical structure for such a system of programs (referred to henceforth extra compactly as “programs”) would set up synthetic processes and limits for creating, securing, working, and enhancing these programs.
Determine 1: Coexisting Programs at Totally different Time Scales in a System of Programs
Simply as TRFs are tuned and optimized for the completely different scales during which these programs function, the methods and practices for buying these programs should be equally tuned and optimized. In response to this want, the DoD launched the Adaptive Acquisition Framework (AAF) to instantiate flexibility and agility as foundational parts for product improvement and lifecycle administration throughout all acquisition packages. The AAF may be pursued successfully by enveloping the DoD Digital Engineering Technique, thereby placing the best instruments into the best locations for the product being pursued. This method additional helps the acquisition group handle distinctive functionality wants and threat profiles whereas encouraging customization.
To restrict complexity and reduce threat, program govt officers and program managers historically apply an acquisition technique that self-limits the out there choices. These acquisition practices ignore the cadence, necessities, and threat profile that uniquely characterize the kinds of elements or subsystems being created, and as a substitute apply a typical schedule-driven cadence and main-event-like necessary programmatic critiques in packages that want a distinct method. Techniques for coping with technical complexity and future supply wants of innovation may be launched over time, however at an acceptable tempo for the goal know-how, program necessities, schedule, and funds.
The TRFs utilized in mixed-criticality programs ought to subsequently be structured to deal with layering-on these downstream options and deploying them in risk-prudent strategies which are conscious of the warfighter wants whereas addressing acceptable security/safety considerations. Luckily, the AAF permits packages to compose the method in ways in which finest match the know-how and use case of the completely different elements of the acquisition in probably the most environment friendly method. It affords appreciable flexibility to determination authorities and packages concerning acquisition technique, governance devices, and total execution of this system.
Particularly, DoDI 5000.02, Part 3.1 costs determination authorities with
- tailoring of program methods and oversight
- timing and scope of determination critiques
- phasing of functionality content material over time
- pathway choice and adaptation (see Determine 4 under)
By way of this acquisition reform, DoD empowers the professionals doing the work with engineering the constructs, governance, and processes that allow profitable achievement of program targets. Recognizing that necessities and threat profiles are distinctive to every program and subsequently require completely different acquisition methods for one main functionality acquisition (MCA), the DoD created six pathways, proven in Determine 2 under, aimed toward streamlining and lowering the chance related to the acquisition of IT programs, merchandise, and providers.
The pliability and steerage offered by DoD 5000.02 presents choices to discover a number of pathways to match the acquisition technique to program wants. It permits acquirers to supply tailor-made help for this system’s distinctive traits and threat profile.
Of the six pathways, each the Software program Acquisition and Protection Enterprise Programs pathways current alternatives to discover the applying of TRFs. Software program programs, together with both weapon or enterprise programs, want to make use of TRFs acceptable to the technical area being addressed. These decisions make it doable for this system to realize its targets by leveraging environments that may be utilized to their wants, as a substitute of making their very own surroundings(s) every time.
Software program Acquisition Pathway
Of explicit curiosity, the Software program Acquisition pathway, enlarged in Determine 3 under, permits a program workplace to outline an acquisition technique that leverages present software-delivery frameworks and introduces flexibility into planning and execution. This pathway encourages software-development practices, similar to Agile, DevOps, DevSecOps, and Lean, and provides a program the agility to discover cutting-edge improvement methods and applied sciences. By way of the iterative nature of the pathway, disclosure on the traits of the design will get to stakeholders early and infrequently. Stakeholders and distributors talk all through design and improvement with the federal government, offering enter and gaining clarification as acceptable.
Briefly, the Software program Acquisition pathway
- permits steady integration and supply of software program functionality on timelines acceptable to the battlefighter and finish consumer, or mission requirement
- is the popular path for acquisition and improvement of software-intensive programs
- establishes business-decision artifacts to handle threat and allow profitable software program acquisition and improvement
The Software program Acquisition pathway is acceptable for military-unique capabilities, similar to real-time command-and-control performance, the place the design is targeted on custom-built or extremely custom-made software program. The usage of TRFs 1 and a pair of could also be effectively suited to these programs.
Nevertheless, the Software program Acquisition pathway is probably going not acceptable for getting enterprise programs which are made up largely of business off-the-shelf (COTS) merchandise with some minor alterations or code-only enhancements (extra on this later).
Further Pathways for Consideration
Pressing Functionality Acquisition
The Pressing Functionality Acquisition pathway, enlarged in Determine 4 under, is reserved for capabilities required to avoid wasting lives or verify mission accomplishment. This pathway employs a Lean acquisition course of that fields capabilities fulfilling pressing current or rising operational wants or fast reactions in lower than two years.
Numerous kinds of merchandise may be fielded as an pressing functionality. It’s subsequently exhausting to say using a particular TRF for such a acquisition, although TRFs 1 and a pair of could also be appropriate. One benefit of utilizing these frameworks in fast functionality acquisition is that the hassle to determine and handle the event and deployment surroundings may be leveraged throughout many packages, releasing sources to give attention to the uniquely wanted navy functionality. It might seemingly additionally assist scale the productionization of an pressing functionality if its utility is confirmed particularly precious within the warfighting area.
Center Tier of Acquisition
The Center Tier of Acquisition (MTA) pathway, enlarged in Determine 5 under, is used to quickly develop fieldable prototypes inside an acquisition program to display new capabilities or quickly area manufacturing portions of programs with confirmed applied sciences that require minimal improvement. The MTA pathway is meant to fill a niche within the protection acquisition system for these capabilities with a degree of maturity that allows fast prototyping inside an acquisition program or fielded inside 5 years of the MTA program begin. The MTA pathway can be utilized to speed up functionality maturation earlier than transitioning to a different acquisition pathway or to minimally develop a functionality earlier than quickly fielding.
The rapid-prototyping path offers for using modern applied sciences and new capabilities to quickly develop fieldable prototypes to display new capabilities and meet rising navy wants. The targets of an acquisition program below this path contain fielding a prototype that was efficiently demonstrated in an operational surroundings and to supply a residual operational functionality inside 5 years of this system begin date. Digital-prototyping fashions are acceptable in the event that they yield a fieldable residual operational functionality. MTA packages is probably not deliberate to exceed 5 years to completion and, in execution, is not going to exceed 5 years after MTA program begin with out a protection acquisition govt (DAE) waiver.
The rapid-fielding path offers for using current merchandise and confirmed applied sciences to area manufacturing portions of recent or upgraded programs with minimal improvement required. The target of an acquisition program below this path is to start manufacturing inside six months and full fielding inside 5 years of the MTA program begin date. The manufacturing begin date of the MTA program is not going to exceed six months after the MTA program begin date with out a DAE waiver.
Comparable advantages to using TRFs 1 and a pair of within the improvement of pressing capabilities apply to the acquisition of middle-tier capabilities. This acquisition is especially precious provided that middle-tier merchandise are sometimes productized in a number of portions, fielded for longer intervals, and topic to evolving calls for for functionality that may very well be delivered with software program upgrades. TRFs 1 and a pair of are notably appropriate for this surroundings.
Protection Enterprise Programs Pathway
Determine 6 reveals the pathway and the cyclical Enterprise Functionality Acquisition Cycle. The authority to proceed (ATP) gates compartmentalize the phases, and the method reduces a lot of the paperwork required in DoDI 5000.02. Particulars concerning the execution of the pathway may be discovered at https://aaf.dau.edu/aaf/dbs/. The pathway is dependent upon steady course of enchancment and may very well be leveraged as a streamlined path for buying elements which are commercially out there.
Acquisition of Providers
This pathway, enlarged in Determine 7 under, is meant to establish the required providers, analysis the potential contractors, contract for the providers, and handle efficiency. The pathway actions are damaged into three phases: plan, develop, and execute. This pathway is described within the DoD Handbook for the Coaching and Growth of the Providers Acquisition Workforce.
Main Functionality Acquisition
A Main Functionality Acquisition (MCA) pathway acquires and modernizes military-unique packages that present enduring functionality. It’s exhausting to conceive of any MCA that may not be software-reliant. Ought to that be the case, a blended method to the authorities of the varied acquisition pathways would match the very best framework to the enterprise wants of this system similar to proven in Determine 8. Matching trade incentives and enterprise fashions may be tuned to the kind of exercise, sources, and cadence of motion. General execution threat can be diminished by combining these insurance policies in a coordinated vogue.
Determine 8: Main Functionality Acquisition as a Composition of Acquisition Frameworks
As beforehand described, there’s a correlation between acquisition pathways and TRFs. Determine 9 presents a mapping of how these may very well be utilized. Main capabilities would, in lots of instances, be tied to a particular navy platform (sea-going, land-based, flight car, spacecraft, and so on.). These autos would require real-time management programs for which TFR 1 is finest suited. As well as, the platform-level integration of programs and subsystems may be derived from cross-platform product strains. The applying of these merchandise into new main capabilities would supply the propelling have to transition into TRFs to cut back execution and integration threat for the general enterprise. These military-unique capabilities developed below the Center Tier or Software program Acquisition pathways may very well be constructed on TRFs 1, 2, and three.
Establishing improvement and deployment environments for functionality, in addition to the modeling and services used to help improvement testing, operational testing, and lifecycle help providers may very well be acquired below a mixture of the Acquisition of Providers and Protection Enterprise Programs pathways. These features would seemingly be finest suited to using TRF 3.
Determine 9: Correlation of TRFs and an MCA
On this submit, we’ve got proven that DoD acquisition packages now not should go it alone and settle for the burden of unbounded technical threat in relation to constructing their mission programs, or the help providers that they might depend on. What we prescribe right here is effectively throughout the realm of technical achievement in the present day. The most important problem is to wrangle the construction of the acquisition surroundings, the funding fashions, and the cultural incentives.
Future Evolution of TRFs for Blended-Criticality Programs
Because the idea of TRFs beneficial properties traction and extra programs are compelled to comply with swimsuit, the strategies of integration, improvement testing, and operational testing should evolve as effectively. As well as, the strategies of managing interoperability should evolve to deal with repeatedly evolving functionality within the area, delivered on completely different time horizons, and to handle shifting interoperability/evolving performance over a lifecycle of many years.