Q&A: Brigadier General Peter F. Hoene
NET-ENABLED COMMANDER:
Executive Lifecycle Management of the C2 Portfolio
Interview with
Brigadier General Peter F. Hoene
PEO C2 Capabilities DISA
Air Force Brigadier General Peter F. Hoene is the program executive officer for command and control capabilities, Defense Information Systems Agency (DISA). His portfolio includes Net- Enabled Command Capability; Global Command and Control System-Joint; Global Combat Support System (Combatant Command/ Joint Task Force); and Multinational Information Sharing initiatives.
Hoene is at the forefront of the department’s efforts to collaboratively develop and deliver net-centric capabilities for our joint and coalition forces in a rapid, distributed and cost-effective manner.
Hoene entered the Air Force in 1980 as a graduate of the Air Force Academy. He is a distinguished graduate of the Air Command and Staff College and the National War College. The general has served in a wide variety of research, development, acquisition, test and staff assignments, including a 27-month assignment to the Joint Staff. Prior to his current assignment, he was Commander, 350th Electronic Systems Wing, Electronic Systems Center, Hanscom Air Force Base, Mass.
Hoene was interviewed by MIT Editor Harrison Donnelly.
Q: How would you define your mission as program executive officer for command and control capabilities?
A: Program executive officer [PEO] is an acquisition term for the person who oversees the execution of a portfolio of programs. The oversight includes all elements of the cost, schedule and performance of these programs. It also includes the integration activities across all the programs within a portfolio, and supports the component acquisition executive or the defense acquisition executive’s role as the milestone decision authority. I wear two hats—one as the joint PEO for Net-Enabled Command Capability [NECC], and in that sense oversee the NECC program on behalf of the joint community and acquisition stakeholders and its execution for the defense acquisition executive, John Young.
I also oversee three other programs in my portfolio [GCCS-J, GCSS (CC/JTF), and MNIS], and in that capacity act as DISA’s PEO for Command and Control [C2] Capabilities. In this role, I report to DISA’s component acquisition executive, Tony Montemarano. The mission statement for the PEO is two-fold. First is to provide the executive lifecycle management of the C2 portfolio, which includes the programs, projects and initiatives that support the joint warfighter for planning and executing joint military and coalition operations. The second is to provide oversight of the evolution of C2 programs to deliver an integrated joint net-centric C2 capability to the warfighter.
Q: What programs are included under the PEO C2 Capabilities?
A: The C2 portfolio has four major efforts, as well as smaller initiatives. The first major effort is the Global Command and Control System-Joint [GCCS-J], which is the fielded system of record that our joint warfighters use for joint command and control. Then we have the Global Combat Support System (Combatant Command/ Joint Task Force) [GCSS (CC/JTF)], which provides joint logistic support capabilities; the Net-Enabled Command Capability [NECC], which is the next generation of joint C2 capabilities; and our Multi-National Information Sharing [MNIS] products, which facilitate coordination among DoD components and eligible foreign nations in support of planning and execution of military operations efforts. Notable among the smaller, yet vital, initiatives in the portfolio is Collaborative Force Analysis Sustainment and Transportation, an adaptive planning tool that we’re fielding on behalf of the joint community.
Q: Why was the command created, and how does it fit into the rest of the DISA structure?
A: In 2005, DISA established the PEO C2 Capabilities and three other PEOs, in recognition of the increasing need for DISA to take on a broader acquisition role for the joint community and meet the emerging needs of our customers. The new PEOs were established to provide direction, authority and accountability for all aspects of the acquisition efforts. Additionally, the PEOs were established to streamline the acquisition process for the mission areas, and assume the roles the military services traditionally performed.
More specifically, the PEO C2 Capabilities was created as a result of DISA being named the lead for the NECC program, known at the time as Joint Command and Control. The program construct was developed by the Office of the Assistant Secretary of Defense for Networks and Information Integration to have both a joint program executive officer and a joint program management organization and a set of component management organizations to have a truly joint acquisition effort for the design, development, procurement and fielding of software modules to support the joint warfighter. I mentioned earlier that I had two related titles—JPEO for NECC and PEO for C2 Capabilities. The latter covers GCCS-J, GCSS (CC/JTF) and MNIS. The agency made the decision to add those programs to capitalize on the synergy in the portfolio and the relationships between these programs and the future NECC, as well as to promote cross-program integration within the PEO portfolio.
Q: What would a “truly integrated, joint, net-centric C2 capability for the warfighter” look like?
A: Let me start by answering your question from a user perspective. If I am a warfighting user at an operational console in an ops center, such as an Air Operations Center, a joint net-centric C2 capability would be a work environment that ensures I have immediate access to the information I need to do my job within a few key strokes. I don’t need to know how I get this information or where it comes from. I just need to know it’s authentic and timely to support situational awareness and strike planning. Further, I need this information to help make informed command and control decisions, such as to direct aircraft to a target. In my view, joint warfighters in an ops center should not have to worry about the technology, and should know that they can get the information they need very quickly.
Many of the systems in the field today provide our warfighters access to the key information, but on a system-by-system stovepipe basis. Often the process to gather all the information needed to do their job is time consuming, requires the users to have intimate knowledge of the systems they’re using and know precisely where to go to find the data, and requires “gray-matter” integration. In fact, most of our legacy systems are a set of stovepipes with tightly coupled technical interfaces and “imprisoned” data. Many of these legacy systems include a user interface that drills all the way down into their individual databases. It’s difficult for the operator to get the broader information he or she needs for situational awareness and to make timely and informed strike decisions. In many cases, the warfighter has to be the integrator, taking multiple inputs from different systems and correlating them all in his or her mind, and then make decisions based on that information. Our entire portfolio is founded on the concept of taking those stovepiped systems and migrating them to a much more net-centric solution—instead of point-to-point interaction, moving to many-to-many interaction—providing the warfighter the services and data at the touch of a few keystrokes, to get exactly the right information at the right time to make informed decisions.
Q: How would you rate the field performance of DISA-developed C2 programs in Southwest Asia?
A: Right now, we have several fielded systems within our portfolio, and they are doing a great job supporting our warfighters in Southwest Asia. I’ll address each individually. First, there is the GCCS-J, which is our joint C2 system that provides secure, interoperable command and control capabilities responsive to warfighter needs. It allows the commander to direct forces and assets to identify and destroy enemy targets. It comprises several different features, including an operational picture used by joint warfighters. It has an intelligence capability that allows information to be brought in from multiple sources and displayed in a user-defined operational picture to help warfighters visualize the battlespace. It also includes force readiness information about units that we’re looking at for deploying to the region, as well as planning information for those units and the warfighting tools they have. GCCS-J is deployed to the AOR today, and it’s doing a great job. We are maintaining it for the warfighter community, and improving it over the next six months with updated versions that will take it from where we are today to a much more userfriendly, Web-based capability.
Second, we have GCSS (CC/JTF), which is providing joint users with end-to-end asset visibility from a logistics perspective, so they know where all their assets are in the AOR, as well as those logistics elements that they need to have brought into the theater. It allows the warfighter to query databases and provides visibility in materiel and personnel during mobilization, deployment, employment, sustainment and redeployment activities. The GCSS (CC/JTF) program management office continues to enhance flexibility and agility by de-coupling the system components by separating the data from the applications, services and user interfaces, to provide easy user access to information that was previously not available.
Finally, we’ve deployed a number of coalition information sharing capabilities under the umbrella of our MNIS portfolio. This portfolio includes both networks and guards that allow us to share information with our coalition partners. We have a number of different systems within the portfolio, the most notable of which is CENTRIXS, which is the combatant commander’s network of choice for coalition warfighting. We have more than 25,000 users and 77 nations today sharing information between allied nations, principally based on CENTRIXS. It is widely used across the world today, but it’s mostly information sharing through network separation, and each individual network is expensive to maintain. We’re migrating to a more net-centric based approach, based on properly tagged data and attribute-based information sharing. This effort is known as the CENTRIXS cross-enclave requirement, and it is an attempt to bridge current CENTRIXS networks into a more net-centric environment. To that end, the JFCOM-led MNIS analysis of alternatives, when completed, will guide us for longer term solutions beginning in 2010.
Q: How would you define the concept of service-oriented architecture, and how are you working to implement it?
A: Service-oriented architecture [SOA] is a commonly used term to describe software services that communicate with each other. These services could facilitate passing data to one another or working together to coordinate activity. For NECC we view SOA as a framework to loosely couple services with operating systems, programming languages and other technologies to support a wide user and application base. By loosely coupling these elements and separating the data from the applications, services, and user interface, we can both design systems that are much more net centric and also leverage our legacy systems. In fact our SOA approach allows us to tag data with metadata [data about the data], wrap, and adapt these legacy systems in order to expose their data to a much broader user base than before.
More specifically, our current C2 systems, such as GCCS-J, have quite a bit of computer to computer interaction behind the scenes. These interfaces are often custom developed and adding a new interface, or changing a warfighting business process takes extensive coding or re-coding. As a result, the evolution of our capabilities is often too slow and expensive. In contrast, a SOA allows us to move from these tightly integrated interfaces to a much looser coupling between systems. Each of the information sources become “services” on the wide area network that provide information or other services on demand/request by the user. Each service will evolve at its own pace but will have stable interfaces. Further, we will leverage these network-based services to “compose” command and control mission threads.
Q: What will this structure enable you to do?
A: Based on industry experience with SOA, we believe this structure will allow us to evolve command and control much more quickly in response to changing warfighter needs. It will also allow us to evolve many of the systems that are currently unique to a particular military service into enterprise services that everyone can use, potentially in unanticipated and innovative ways. This allows us to reuse many systems in our new SOA without extensive rework.
Further, by implementing a SOA framework, not just in NECC but in its companion programs like Net-Centric Enterprise Services [NCES], the Navy’s Consolidated Afloat Networks and Enterprise Services and the Air Force’s AOC Weapon System, we will be able to do better in several dimensions. First, we will be able to reuse older and external applications in new, user-facing ways, by web-enabling the legacy functions. This is what we are doing in the migration of the GCCS family of systems to the NECC architecture. In this way we take advantage of the large investment the Department of Defense has made in legacy systems by integrating good legacy capabilities into a new user interface. We will be able to add new capability or functionality more easily, at less cost and less time, and we’ll retire the legacy systems only when new SOA functions can perform the needed tasks. We will be able to access information from other domains not previously integrated with the GCCS family of systems [FoS], by exposing cross-domain data and building business rules that enable operational agility. Finally, we will be able to concentrate our scarce resources on capability rather than on infrastructure.
Q: What is the current status of the NECC program?
A: The NECC program is currently in the technology development phase. We had a Milestone A decision in March 2006, which allowed NECC to enter into this phase. Since then, we have gone through extensive architecture development, systems engineering, systems definition, and prototyping efforts. In late 2007, the program was redefined to have it accommodate, as part of its first increment, the GCCS FoS, which includes GCCS-J, GCCSMaritime, GCCS-Army and GCCS-Air Force FoS, to replace that family of systems capability, as well some enhancements, such as adaptive planning, that are critical to the program. These capabilities were identified for development during the first increment of NECC, with completion expected by the end of fiscal year 2011. When the program was redefined last fall, it went through a review cycle culminating with a DAE review with Under Secretary Young in the January timeframe. He gave direction to go ahead and pursue specific objectives as part of our technology development phase, and to get back with him in June/July to update the status of the program.
We provided a program review to Mr. Young and other DoD stakeholders on July 31, 2008. He expressed a vote of confidence for the program based on strong stakeholder commitment to this capability, and he approved continued NECC investment. However, he directed further refinement of our cost estimates, confirmation of technical maturity, and clarification of management provisions prior to entry into system development and demonstration, which is the next phase, post-Milestone B. We are now engaged with our community to develop by the end of September a plan for how we will focus our efforts in FY 09 to meet Mr. Young’s direction and inform OSD stakeholders for a Milestone B decision. In essence, he gave us an endorsement for the development work that we hoped to do in FY 09, with a follow up review in October to map out the details of the plan.
One challenge that we face is that the Senate Armed Services Committee has marked against the program in FY 09. Their mark cut $122.9 million, of which about $90 million is research and development, test and evaluation. We’re hopeful that the funding will be restored so we can maintain the schedule and development program we have and can complete the effort for Increment 1 by the end of 2011. Completing Increment 1 by 2011 provides the services the ability to start shutting down their legacy GCCS systems shortly thereafter. This in turn will avoid the long-term cost of sustaining these systems. Our OSD stakeholders are actively engaged with the congressional staff to restore the program funding.
Q: What are the key information assurance challenges you face?
A: As we’re moving into a credential-based capability, where user credentials are authenticated by a CAC or some other type of identity management capability, it’s essential that our systems can discern who you are, what your security access is and what information you should have access to. In an ideal scenario, you would have a CAC card that had all your credentials, or some other type of identity management tool. When you plug your card into a machine, it knows exactly who you are and what you should be able to see. The GCSS (CC/JTF] requires end users access the applications with a SIPRNet PKI certificate and provides access to externally owned applications via single sign-on.
In addition to the work we’ve been doing on identity assurance for U.S. military personnel, there is also the coalition information exchange part of this. It is essential that we have the attributes and level of knowledge about what we can share with our allies. We don’t go into any operations any more without having our coalition partners with us, so it is absolutely essential that we develop capabilities and technologies to authenticate very rapidly for any of our partners, and then to provide the information that they need and we need to do our jobs. One of the challenges that we face is technology, but we’re making great progress in that area. Another challenge is the policies for sharing information across those domains. As we solve the technical problems, we’re also working with some of our senior stakeholders to evolve the policies to support information exchange with our coalition partners.
Q: Your most recent assignment was as commander of the Air Force 350th Electronic Systems Wing (ELSW). How has your experience there shaped your approach to your work at DISA?
A: I appreciate the opportunity to talk about that. The 350th ELSW was a rather large portfolio of Air Force systems, closely related to the DISA portfolio. While many of these 350th ELSW systems supported both Air Force and joint users, the Air Force was the executive agent and we were more Air Force focused. At DISA, the portfolio I lead is really an extension of the work I was doing at Hanscom AFB, but at the joint level.
Additionally, one of the things I learned from my experience at Hanscom AFB is the vital importance the C2 and ISR systems play for the warfighter. For example, many of the systems we developed, like TBMCS and DCGS, were used directly by the Combined Forces Air Component Commanders [CFACC] and their staffs at the Combined Air Operations Center [CAOC] in Southwest Asia and other CAOCs worldwide. These systems provide the CFACC with the situational awareness needed across the entire theater and provided the tools for him to identify and destroy terrorist targets. That’s a huge responsibility and helped reinforce to my team the need to ensure we provided the systems needed to provide the CFACC with the tools needed to do his job. Further, during my time as the 350th ELSW I’m very proud of the sense of urgency my team had to support these deployed warriors in the heat of the battle.
Further, I learned the importance of building relationships with key stakeholders and working across organizational boundaries to achieve enterprise-level solutions. An example of this work was the extensive wing-wing integration efforts achieved between the 350th ELSW and the 653rd ELSW, our net-centric wing organization at Hanscom AFB, and the significant center-center efforts with Aeronautical Systems Center and Space and Missile Systems Center. We also worked extensively with DISA’s NCES program to take advantage of their early capability baseline efforts and help them refine them in support of a C2 data pilot we led as part of the ISPAN program for the commander of USSTRATCOM. This interaction was not only critical to the C2 data pilot, but also underscored the importance of focusing on enterprise level solutions and helping pave the way for NCES improvements.
With this as the backdrop, I feel the assignment to Hanscom AFB prepared me well for my position at DISA. We work across organizational boundaries every day to take advantage of, and adopt the good work done by the Air Force, Navy, Army, Marine Corps, COCOMs and agency partners. This work has also helped us chart a new course for coalition information sharing for DoD.
Q: Is there anything else you would like to add?
A: Finally, I would like to share one overarching observation. The acquisition community is often criticized for delivering systems that are late to need and over budget. I’ve seen this from several different positions over the course of my career, and in many cases the criticism relates to elements outside of their control. My view from both the trenches and from my PEO role is that the men and women of our acquisition workforce are dedicated warriors who often toil under very difficult conditions and receive little or no recognition for their efforts. Their motivation is not formal recognition, but rather the satisfaction that they have done everything they could to rapidly deliver the tools our warfighters need, period! ♦
