Leading the Army's technology charge

When describing the collection of technology projects under his command, Army Maj. Gen. Nickolas Justice likes to joke that “if it’s got electricity running in it, they probably blame me for it.”

The quip understates the complexity and importance of the systems Justice runs at the Program Executive Office for Command, Control and Communications Tactical (PEO-C3T) at Fort Monmouth, N.J. They include the Warfighter Information Network-Tactical, the Army Battle Command System, Force XXI Battle Command Brigade and Below, and a mobile electricity program that supplies ruggedized power generators for the Defense Department.

In his six years as commander and several more as deputy of PEO-C3T, Justice has learned a few tricks that other government information technology executives would do well to follow, including how to get the most from the resources one has, knowing what risks are worth taking and shaping new technology to serve a mission’s needs, not the other way around. He has also become a vocal proponent of open-source software because of its flexibility and cost-effectiveness.

Justice spoke with Federal Computer Week contributor David Perera about putting those lessons into practice and the opportunities he’s pursuing for using open-source technology.

FCW: 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.

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

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

FCW: If many of the projects started out as stand-alone systems, how do you now make them interoperable?

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.

FCW: 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 [are] 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.

FCW: 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 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 [to use] 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 [that] a lot of cost solutions that we can work on with other nations are often open source.

FCW: The objections to open source include concerns about its security and 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 a lot of the challenge, when you really push down those first responses that you hear, tends 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.

FCW: What needs to happen, either at the Army or DOD level, to make adoption more widespread?

Justice: I think what we need to do is actively promote it more. The current process and system [are]: 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.

FCW: 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 [their] challenges and sharing information and being able to make [them] 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 itself is of tremendous value.

We also 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 solutions they were bringing to the table. I’ve got some of my folks who are working very closely with project managers in [the Defense Advanced Research Projects Agency] 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 new technologies and do engineering changes to those solutions and integrate those into the current battle command systems.