Middle Tier of Acquisition (MTA)

AAF  >  MTA  >  MTA Scenarios  >  Scenario 4: OPERATIONAL C2 SYSTEM

(based loosely on Kessel Run)

Rapid Prototyping: How might we use a series of modular prototypes to rapidly create and deliver a useful system?

Planning
Requirements
Contracting
Costs & Funding
Schedule
Prototype Development
Test and Demonstration
Prototype Operation & Sustainment
Transition

Reference Source: Guidance from OUSD(A&S)

PLANNING 

A major effort to deliver a technical update to a C2 system has been terminated due to extensive delays and cost overruns. However, the existing requirement set remains valid, so an MTA Rapid Prototyping effort is planned as a way to quickly begin developing and delivering the necessary capabilities in a modular, incremental fashion. It uses the initial MTA authority to get started, then is grandfathered in as the final DODI 5000.80 policy is established. 

REQUIREMENTS

The program office deconstructs the large collection of previously validated requirements for the original C2 system and creates a modular, prioritized collection of smaller, more focused requirements.  These requirements are continually updated with a regularly prioritized backlog from the user community. 

CONTRACTING

The program office then issues a dozen discrete contracting actions, using a modular contracting strategy as described in FAR Part 39.103. This contract portfolio includes Services contracts for software development teams using FAR Part 8.4 (Federal Supply Schedules), FAR Part 12 (Commercial Items), and FAR Part 13.5 (Simplified Procedures, commercial items up to $7M) as well as IDIQ awards for platform and infrastructure subscriptions. Similarly, the system is designed using a modular architecture to rapidly develop prototype capabilities which can be provided to operators within a larger open architecture. 

COSTS & FUNDING

The program uses a funding line previously established under the original effort. This is consistent with the general guiding principle that organizations using MTA must make use of their existing funding consistent with the purpose for which the funds were appropriated.

The NDAA Section 804 statute that led to the creation of the MTA pathway also directed the creation of a Rapid Prototyping Fund (RPF). However, there are no assurances that those funds will only be used for MTA programs nor is there a requirement that the RPF must be used for all MTA programs. Instead, MTA programs can compete with other technology efforts as part of the OSD data call that distributes the RPF funds. 

SCHEDULE

The schedule consists of frequent deliveries of software prototypes on a continuous cycle, measured in days and weeks, not months and years. The first operational prototype is online within a few weeks, and additional modular capabilities are added weekly.  Over time, more complex features may take longer while more maintenance updates and security patches may be provided even more frequently. The overall schedule is primarily driven by program increment and sprint planning. While “software is never done,” the MTA-based portion of this effort will deliver residual operational capability within a year, and will continue to augment that capability with further rapid prototypes.

During an initial period of software prototyping under the MTA pathway, the program office should focus on maturing the system’s technologies and processes. The program office should transition from MTA to the Software Acquisition Pathway, once the technologies and processes have matured sufficiently. 

PROTOTYPE DEVELOPMENT

This effort used modern software development methods and pair programming to design and develop prototypes that provide new features and functions for the C2 system within a series of sprint cycles. This is done in collaboration with contractors, users, and program office personnel. Executing a structured, repeatable series of sprint cycles allowed the program to quickly deliver prototypes of the top-priority capabilities first, while also creating the necessary infrastructure to accommodate future capability additions.

The program office should transition from MTA to the Software Acquisition Pathway, once the technologies and processes have matured sufficiently. 

TEST AND DEMONSTRATION

Given the agile software-centric approach, the team uses the opportunity to incorporate automated test features that verify code stability, security and deployability. It also tracks a number of indicative metrics that provide the development team insight into where they need to improve their processes or where they may need to assign more specialized skillsets.  Over time, the program establishes such a robust testing process that it achieves a continuous authority to operate which accelerates software delivery.

PROTOTYPE OPERATION & SUSTAINMENT

Given the iterative and continuous nature of agile software development, sustainment planning on this program consists of ensuring that the infrastructure and personnel will be in-place over the life of the program.

TRANSITION

The program office begins planning early to transition this MTA Rapid Prototyping program into the Software Acquisition pathway.