Middle Tier of Acquisition (MTA)
Scenario 1: THE SUPERCOMPUTER
(based loosely on the Condor Cluster supercomputer built by AFRL in 2010)
Rapid Prototyping: How might we leverage COTS hardware to rapidly prototype a high-tech device with potential to transition to rapid fielding for operational users?
Planning
Requirements
Contracting
Costs & Funding
Schedule
Prototype Development
Test and Demonstration
Prototype Operation & Sustainment
Transition
Reference Source: Guidance from OUSD(A&S)
PLANNING
When faced with increased demand for supercomputing capabilities, a military research laboratory initiates a Rapid Prototyping MTA to develop a new, low-cost supercomputer prototype out of commercially available gaming consoles running Linux. The intent is to explore possible solutions through an iterative series of hardware prototypes for in-house use by the research lab itself. However, the program office recognizes that if the prototyping effort is successful the capability could be transitioned for use by operational analysts and planners in support of real-world missions.
REQUIREMENTS
Because this is an MTA effort being developed under DODI 5000.80, the requirements are not subject to the full JCIDS process. Instead, the project uses a requirement document for the initial hardware system that is short, simple, and narrowly focused on developing supercomputing hardware with performance capabilities comparable to existing commercial products.
Rather than seeking to advance the state of the art, the program is aiming to quickly develop a low-cost supercomputer to support and augment the lab’s computing power with potential transition to the operational community. The focus is on hardware, as the researchers plan to use an existing operating system and related software, with minimal modification. The requirements document is produced, reviewed and approved in coordination with operational and user community representatives before the development effort moves forward. After each prototype is developed, the requirements are revisited and updated to provide direction for the next prototype within this MTA program.
Key Documentation Considerations
Given the scope of the MTA program was small, they request use of a tailored version of the Component MTA requirements process with lower-level approvals commensurate with program risk.
CONTRACTING
The program office uses 10 USC 2373 authority aka Procurement for Experimental Purposes to purchase 2,000 PlayStation gaming consoles for in-house testing under the telecommunications technology area of the statute. This authorizes the government to acquire quantities necessary for experimentation, technical evaluation, assessment of operational utility, or to maintain a residual operational capability. A resulting contract may be written as a FAR-based contract or may be written as a non-FAR-based agreement that is not required to include standard provisions and clauses required by procurement laws. For this effort, the Contracting Officer uses a non-FAR-based agreement written using commercial terms.
This authority allows the government to procure significant quantities of supplies (in this case nearly 2,000 PlayStations) for experimentation. One downside to this approach is that the government often finds itself with little leverage on pricing, but since the gaming consoles in question are last year’s models, the lab is able to purchase them at a significant discount despite the usual contracting leverage provided by typical contracting approaches.
Key Documentation Considerations
To minimize delays, they develop an initial Program Office Estimate for up-front planning. They build on these initial cost estimates and get an approved Service Cost Position for longer-term planning and budgeting, recognizing that a project may be intended to meet a short-term need but failing to budget for long-term use may delay its broader deployment and impact maintenance.
SCHEDULE
The schedule for this prototype is deliberately short, with delivery of the initial hardware prototype within a year, to be followed by a series of iterations and upgrades over the next three years. The specific dates for this program to deliver prototypes 2.0 and beyond are not specified, aside from establishing an expectation that each prototype should build on the previous and there should not be a gap of more than one year between prototypes.
Final residual operational capability is scheduled to be provided four years after program start date. This is one year less than the statutory limitation of 5 years for MTA efforts, and it provides the option of continuing for a fifth year if necessary.
PROTOTYPE DEVELOPMENT
Using the MTA pathway, the team quickly purchases the PlayStation hardware, which vastly accelerates the design and development phase. Lab personnel re able to experiment with a variety of designs, configurations and system architectures before demonstrating a way to network them into a computing cluster that operates at 500 TFLOPS (incidentally making it the fastest supercomputer in the DoD’s inventory). The initial prototype immediately demonstrates the viability of the overall approach and confirms the design was on the right track. However, the processing speed of the first prototype is a little low. Fortunately, the modular design and integrated test strategy makes this performance shortfall visible quickly and allows the team to easily pivot to the second prototype design.
TEST AND DEMONSTRATION
The testing strategy defines the operational environment and a limited set of parameters which constitute successful performance. In this case, the environment is a standard computing environment and the test parameters include the ability to run a meteorological algorithm that simulates various weather patterns and effects on various weapons systems to determine the optimal time to conduct a mission. Research laboratory personnel perform the tests and demonstrations, in coordination with military weather experts who are brought in as subject matter experts and test partners.
Key Documentation Considerations
They use a draft test strategy to initiate the project and minimize delays while also garnering crucial buy-in from key stakeholders that might drive potential fielding delays. Given the program was small, they combine the final test strategy with other key documents that were signed off concurrently.
Key Documentation Considerations
Recognizing the importance of planning for long-term sustainment of a fielded prototype or production unit on MTA programs that are fielded independent of a program of record, they develop a tailored LCSP that captures the areas that need to be addressed and the budget that will be required to provide long-term support.
TRANSITION
While the capability to perform operational mission planning is not an official urgent need, the hardware prototype may perform well enough to justify transition to a follow-on development activity using a different acquisition pathway. This follow-on development effort may involve additional coding, development, and modification so the sooner the computing cluster hardware has been demonstrated as successful, the sooner the rest of the system can be customized for specific operational applications.
Key Documentation Considerations
Since acquisition programs using the MTA pathway are not MDAPs (per 10 USC 2430), they are not required to produce statutorily-required MDAP documentation, so they plan ahead for the documentation required to transition to other pathways to minimize any fielding delays. They verify with the appropriate functionals that documentation created in the MTA pathway would be honored after transitioning to a different pathway as the initial prototype matures. This preempts any coordination issues or future program delays.