Interview

Justice touts open source for the Army

Open-source technologies drive change

Army Maj. Gen. Nickolas Justice has commanded the Program Executive Office for Command, Control and Communications-Tactical at Fort Monmouth, N.J., since July 2003, when he was promoted from deputy. Justice presides over a diverse group of programs — his standard joke is that “if it’s got electricity running in it, they probably blame me for it.”

Justice oversees several projects, including the Warfighter Information Network-Tactical (See Page 34 for an interview with the WIN-T project manager), the Army Battle Command Systems, Force XXI Battlefield Command Brigade and Below, and a mobile electric power program (See Page 31), which supplies ruggedized power generators across the Defense Department.

Justice spoke with Defense Systems contributing editor David Perera about his portfolio and about open-source technology, for which he has been a noted proponent.

DS: Can you explain how the various directorates you oversee as commander of PEO-C3T fit together? They seem like a diverse group.

Justice: It’s a broad portfolio, but the function of everything is having the infrastructure to power an electronic force, or digital force.

DS: Is it fair to say that many of the programs you oversee are charged with making interoperable systems that weren’t designed to be so?

Justice: A lot of the programs we’ve had have been have been around for many years in various forms. So, yes, they started out as very specific solutions to problems.

DS: If many of the projects started out as stand-alone systems and you now have to make them interoperable, how do you do that?

Justice: One of the first things you want to do is separate data from the actual application. One of the things we’ve started to do is architect the Army Battle Command System into very specific services that you can call across applications. We’ve put in place the ability to share information with a publish-and-subscribe service that allows you to reduce the number of interfaces between programs. You write interfaces for a publish-and-subscribe service. That allows people to write their interface to [the service] so you have a common denominator to get information across systems.

DS: Is service-oriented architecture the magic solution that can erase stovepipes?

Justice: It’s certainly treated that way in the press a lot of times.… It’s very fashionable to use that term. What it is, and what you need, is a defined architecture to build to and come up with common standards and solutions and allow people to develop solutions that have applicability beyond the specific intent they were defined for. You put an architecture in place that allows you to share data with guys that you didn’t intend to share data with, because you didn't have a need, but when the need arises, you have the ability to get the data published out to places where other people can access it and use it.

I don’t think I would call SOA the ultimate solution. I think good planning and good engineering is how you solve problems. If you look at this world, one of the challenges you have is always new and emerging technologies. I don’t see a silver bullet out there. What I see is that as technology is fielded and becomes available, you have a number of challenges that you will always be faced with to overcome, to be able to bring a broader applicability to what the technology has to offer.

DS: You are a noted proponent of open-source applications. What’s your assessment of the degree to which the Army has embraced them?

Justice: I have [seen] some positives and some shortfalls that I will share with you. We’ve actually embraced a lot of the open-source operating systems material and some very specific tools out there that give us collaboration tools, chat and things like that. We have a large base of open-source operating systems that we’re doing. What we have not really embraced very well yet is open-source application development. Getting our feet wet in the open-source world in the operating systems world is pretty easy because it matches up with some of the appliance kinds of devices that we have that go into the platforms and are embedded. But changing the culture where you’re developing applications in an open-source environment is a bit challenging for us right now.

In the applications world, you have to have a process in place that’s very collaborative and have the ability to place that software up there, have it peer reviewed, have people who are willing to invest their time and energy in making it better. That process infrastructure is just going into place right now within [the Office of the Secretary of Defense]. We’re just beginning to look at an ability to be able to share those codes around.

We’ve also got to learn to write contracts with our software developers and folks that allow us to take advantage of that. That whole world of intellectual property is a challenge throughout the whole open-source world, and it’s certainly a challenge for us in DOD, where we’re sort of new to that realm.

What I also find is the opportunity is starting to avail itself for open source as we work with our coalition partners — because I think a lot of the NATO nations are more embracing of open-source technology than we have been. You’ll find a lot of cost solutions that we can work on with other nations are often open source.

DS: The objections to open source include concerns about its security, its stability, a possible lack of life cycle support and a shallow industrial base. What objection concerns you most?

Justice: I hear a lot about security — but open source is not limited to concerns about security. Our security guys are concerned about software, period. I don’t see that as just limited to open source. I think of a lot of the challenge, when you really push down those first responses that you hear, tend to go back to ‘I don’t know how to contract for it. I don’t know what my deliverables are. I don’t know what my intellectual property rights are.’ How do you sustain it — that’s another question. But if you really look, there’s a large sustainment pool out there for open-source solutions.

DS: What needs to happen, either at an Army or Defense Department level, to make adoption more widespread?

Justice: I think what we need to do is actively promote it more. The current process and system is: You go out and you look for your own sustainment, so it typically comes in a more proprietary format. We also need to take an active role and participate in that. I think a lot of our computer guys would be excellent at actually operating in that environment. And we look to do that.

Some of the criticisms are often outweighed by some of the advantages. And one of the advantages, particularly with our coalition partners, is the low cost of entrance into some very robust technologies. We find that open source allows for a very low entry fee to start playing in it. Oftentimes, that’s where we see it: new technologies that are very robust, and they give us an opportunity to leverage that kind of stuff. I found it most easy to embrace in the NATO world.

DS: What were some of the changes PEO-C3T had to make as it began supporting battle operations in Iraq and Afghanistan?

Justice: It was really about three things that we had to adjust to. No. 1, we had to get a system-of-systems focus and really understand that, unlike in peacetime where we were just delivering a solution, people’s lives depended on what we were doing. It was imperative for us to get down into those formations and actually understand how we could assist in solving its challenges and sharing information and being able to make it more effective. And that meant taking a lot of my civilian engineer talent and sending them out to get side-by-side with young soldiers and spend nights in training sessions with them, learning what those soldiers actually expected out of those solutions.

Now, that sounds pretty basic, but sometimes when you look at the Army, large as it is, we often get compartmentalized in what we do. Just being out there, watching the units and being able to learn what they do and the urgency of it and the conditions in which that stuff had to operate was one of the biggest challenges. Also, we literally had to start new forums, where you take a lot of your genius people and have them get together and collaborate on common solutions, having them understand that everything in a combat formation has to be balanced against the very limited amount of resources — that you have to nurture and care for those solutions. If you can share things and reduce the footprint and the weight that unit has to carry, that in of itself is of tremendous value.

We had to partner with the science and technology community to learn how to get ahead of their cycles and engage with them far earlier so that we were able to help outline the best way to implement some of the science and technology solution they were bringing to the table. I’ve got some of my folks that are working very closely with project managers in DARPA and the research and development and engineering community, that whole science and technology world. How you change some of those stovepiped solutions is to invent in new technologies and do engineering changes to those solutions and integrate those into the current battle command systems.

About the Author

David Perera is a special contributor to Defense Systems.

Reader Comments

Wed, May 13, 2009 Mario A. Cervantes Texas

General Justice, you may move to open source technology and find that this may work for Europeans. Europeans are not directly responsible and critically involved in real-world defensive operations as the US. We need to learn to quickly develo software and properly documented, control its configuration in an automatic fashion and also archive it. We must improve algorithms so we don't reinvent them every time we decide to build new systems. US military services continue to get larger, more and more system-of-systems approach are built to accomodate advancement in our technological capabilities. We are in an never-ending cost increase and one that some day we may not be able to afford. Let's go back to basics and do it correctly, shorten our developmental cycles. Taking ten years to develop systems does not deliver tailored capabilities to the field on-time. Everyone of your systems under your control are examples of systems, when they fielded, were years behind in technological capabilities, took too long to field and had cost overruns, never really achieved all resolutions, thus did not resolve all user requirements. A long line of your predecesors have not resolved this issues, we have not learned the lessons, continue to pay more and more and always delay our delivery of these albatroses. Don't get caught on this cylce.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above