CHIPS: What is your role at PEO-C4I & Space?
Mr. Cox: As the Technical Director for PEO-C4I & Space, I provide technical guidance for the development and engineering related activities to support the warfighters.
CHIPS: What is RAPIDS?
Mr. Cox: RAPIDS is a set of mandated software development guidance within the PEO. In short, it is technical guidance. From a contracting perspective, it is the way we will do business from now on. All new development will be compliant with RAPIDS guidance.
We are looking into a "limited open source environment," in which there will be several open source development projects where third party developers can contribute to the software or code baseline. Using this open source development model will extend the development community to anyone interested in a certain product line. This means that instead of one person writing the code for a program, the source code will be open to a larger set of interested developers so they can contribute to the baseline.
CHIPS: How was the concept of RAPIDS developed?
Mr. Cox: RAPIDS is about software development guidance for our development community to make sure that when we write software code it is portable, scalable, extensible and better supports the warfighters. This is a huge improvement in the way we do software development today. Value can be added to the application without having to do any real software development. This is the direction we are working toward with our product line.
The concept started a few years ago, during a trip to the Naval Strike and Air Warfare Center (NSAWC) at NAS Fallon, Nev. NSAWC is responsible for training aviators in strike warfare. While there, we noticed they built an application to manage strike targets. It was a well-built tool, however, they were not using the infrastructure that we provided, because the interface was cumbersome to operate. That sent a clear signal to all of us that we could enhance our products to better support the warfighters by making them more agile. We formulated a plan to support the warfighter better by putting tools in their hands. The advent of IT-21 enabled them to do their own development using commercial products. Our goal is to get the software development practice to support innovation, not only within the fleet, but at all levels and in a joint manner.
We are developing a Web site that lists the components for items such as targeting, weather, supply, logistics and situational awareness. Both internal and external developers and the fleet can take these components and customize their own applications.
CHIPS: What about the security issue in using an open source product?
Mr. Cox: The security issue has two sides — one side believes an open source product allows developers to see the internal mechanisms in the code and, therefore, this makes it more vulnerable. The other side believes that by offering source code to a wider community developers will be able to find and fix the holes faster. It is not our intention to make the source code for our software available on the Internet, but at the same time we will protect it and make it available to a wider community.
CHIPS: What are RAPIDS' objectives?
Mr. Cox: The main goal is to support the fleet and the warfighters by maximizing the reuse of software. We want to get to the point where we are not building capabilities two or three times over, but that we do it once in a single service that is improved, modified and reusable for other projects.
Another important goal is a concept we call "speed to capability." This capability means getting enhancements into the hands of the people who can use them while the technology is fresh. If we can go to a resource for a complete list of services and applications that can be utilized within a program, then we can get the capability to the warfighter faster. We believe by having all of these components in a particular area moving toward this distributed development model we can get software out the door significantly faster.
CHIPS: How soon will there be an improvement to IT-21 by using this method?
Mr. Cox: There are projects undergoing an improvement effort right now. The largest is something called Web COP (Common Operational Picture). Web COP is on our open source site now and we are currently migrating it to an open source model. Within six months this effort will be available for fleet use.
Currently, requirements that come in from the fleet take time to validate, fund and fold into a program baseline. In most cases, by the time that is done the requirement has either changed or evolved. We are going to get ahead of this cycle where the requirement may come in from the fleet, as a prototype, which they will write using our code. They may take the code and add a new interface, a new button, or make the interface more user-friendly — which may be the new requirement. In other words, they will be telling us how they want the software to look and operate. The unspoken question here is, "Could you please put this into production and make it a real tool?"
Now we can respond to that need and not necessarily have to go through that expensive process of interviewing the fleet to try to figure out what they need and translate that into technology. They can help us in the development process upfront in defining the requirements. Once the requirements are completed, the software, which is flexible, will provide the speed to capability, which is again, our main objective.
CHIPS: How are you working the contracting aspects associated with requiring "unrestricted government data and software rights" for all RAPIDS compliant software?
Mr. Cox: This is one of the more challenging parts of the RAPIDS development. In some instances, contracts do not explicitly give the government unrestricted data rights to the software which the government has paid to develop so the code cannot be made available to other agencies for reuse. We will ensure that our development practices have unrestricted rights to the software, so that if a better way comes along or a better application is available we will have the flexibility to include that initiative into the development.
CHIPS: How are you going to integrate RAPIDS into the existing portfolio of C4I applications?
Mr. Cox: This will occur within a short amount of time. The plan is to dictate the RAPIDS development environment to all the software development activities so that the new applications undergoing development will be modified from an architectural standpoint to meet certain objectives. As GCCS, NTCSS and METOC applications evolve into this new architecture and as new patches or upgrades are developed they will be immediately deployed.
CHIPS: How are you going to enable or encourage reuse of RAPIDS software components for new warfighter capabilities?
Mr. Cox: One aspect of our contracting strategy will be to figure out how to entice people to reuse components. This approach involves some developers opening up the development environment and breaking down the walls and barriers to collaborative development. When we open the environment and make it more difficult to own all the code and dominate development in a particular area, we will compensate contractors by offering incentives to reuse software components. For example, when a contract is awarded, the developer can be compensated for a "loss of monopoly" on that particular development for the percentage of code reused. We want to encourage development contractors to participate. We are actively looking for incentives to encourage them to reuse code.
CHIPS: Can you tell us about the Distributed Development Website Environment (DDWE)?
Mr. Cox: DDWE will be the location for developers to submit their code and product line. This site will be managed by PEO C4I & Space. DDWE will provide the environment where applications and source codes can easily be managed. For example, if METOC receives a submission from one of their contractors, the application and source code will be available to them on DDWE. They will be able to control who receives the application code and who is allowed to see the source code. The program manager may decide to restrict the availability of the source code or open the source code to a larger community. The site will also provide the configuration management tools required to manage open source projects. If another developer sees an area of code he believes he can improve he will be able to check out the code, make the modifications and compare the code with the changes so it can be folded into the main baseline project. The DDWE is going to provide all these tools and the environment for code delivery, enhancement and configuration management.
CHIPS: How are you going to give access to the RAPIDS development site to fleet personnel — can you discuss how this will operate?
Mr. Cox: I do expect fleet users will be able to download components comprised of our Programs of Record. We will deliver products to the fleet, and they will have access to all the tools that went into building that product. Think of it as a child's Erector set, where we will be able to build a robot, but also be able to have the nuts, bolts and everything that came in the box available to the fleet. They are going to be able to assemble and reassemble capabilities in many different ways without rewriting the code.
CHIPS: Can you talk about how RAPIDS will result in time savings?
Mr. Cox: There are no statistics yet to describe the amount of reduced time to market or increased speed to capability because the project has just started. But, intuitively we are anticipating significant efficiencies simply by knowing that if we write the code and applications smarter — and that’s an advantage of RAPIDS — capabilities will get to the market faster.
CHIPS: What about Navy Test and Evaluation requirements since Navy requires testing before implementing anything new on IT-21?
Mr. Cox: We are not expecting test requirements to change. Developers and programmers will take their programs through the standard development process. They will also take it through their proper certification authorities. However, we will require some small change in the way we do testing and fielding. Once a program has gone through that process, and they have had a product evaluated and certified, the components that went into building that product will be available for reuse in different ways. This means we will work with the test communities so they understand that we will not be rewriting the entire piece of software that we just certified or evaluated, but will be reusing those components in a different manner. The test community will need to figure out how to avoid complete recertification of essentially the same base code that just has already been certified and has only been reassembled in a different way than previously fielded.
CHIPS: Has the Navy used this method before?
Mr. Cox: There are many programs that have gone down this path. Currently, I think the difference is that we are mandating this as a development practice for an acquisition command. This differs from most efforts that we have seen to date. Basically we are formalizing a new development philosophy as a method of development for all our products. We concluded that our software must be more modular and flexible in order to effectively manage change. We are aggressively working with Naval Sea Systems Command and PEO IWS (Integrated Warfare System) to merge development documentation and philosophies among our organizations. This is significant because a majority of Navy products produced at the Systems Commands will be more flexible and we will all be able to send capabilities into the fleet faster.
CHIPS: How do you see this method working in a joint environment?
Mr. Cox: By making software code accessible to other development partners there will be more flexibility in interacting with the other Services. If a component performs an operation similar to what one of the other Services does, then we can collaborate on that development together and move forward with a single common product that is used jointly by all the Services. Interoperability will be greatly improved by this process and that is the name of the game in joint warfare.
CHIPS: Are you working with DARPA or industry partners?
Mr. Cox: Yes, portions of the first product that we put on RAPIDS, the Web COP, were developed by DARPA. Since this is such a relatively new project there is a very small list of developers that have come onboard as partners in this development process. We anticipate that will expand with time.