Printer Friendly

"Adopting joint": interoperability through convergence.

"Born joint"--developing new systems to meet joint capabilities--is the preferred way of ensuring future systems, especially C4ISR (command, control, communications, computers, intelligence, surveillance, and reconnaissance) systems, are interoperable. However, if the systems are already developed and in the field, two options exist to break Service stovepipes. Systems can be made interoperable by providing additional functionality to enable the required information exchange. This option is especially viable when the systems provide distinct/unique capability to the warfighter. If the systems provide a similar capability, the better option may be to converge to one. When a system already exists, a Service can "adopt joint." The Army, Marine Corps, and to a limited extent. Special Operations Command (SOCOM), have recently made the decision to adopt each other's tactical command and control (C2) and situational awareness (SA) systems of record in order to improve interoperability for the ground force. In this article we will lay out the process. Our purpose is not to recommend a how-to approach or to discuss in detail the technical challenges faced, but to provide a case study of the process and to discuss key enablers to overcoming obstacles.


Defining the Problem with Authority

Operation Iraqi Freedom highlighted the limiting fact that Army and Marine Corps C2/SA systems at the tactical level were not interoperable. As the Army moved towards Baghdad on the west side of the Tigris/Euphrates Valley, it could not "see" or effectively exchange digital information with the Marine Corps units moving north on the east side. The Army's systems of record were Maneuver Control System at the tactical operations center (TOC) level and Force XXI battle command brigade and below (FBCB2) at the platform level. The Marine Corps systems of record were Tactical Combat Operations for its operations centers and Digital Automated Computer Terminal at the platform level. Both Tactical Combat Operations and Digital Automated Computer Terminal shared C2 Personal Computer as their base software (also known as the Joint Tactical Common Operational Picture Workstation (JTCW)). The Army and Marine Corps systems were interoperable with the global command and control system (GCCS), which allowed for information exchange at higher echelons; however, these tactical systems were not designed to be interoperable with each other.

This limitation was well-known before initiation of combat operations and was mitigated to some extent by the limited use of FBCB2 blue force tracking within the Marine Corps, as well as other efforts to improve integration of the common operational picture at the theater level. These fixes were based on operational necessity but did not solve the long-term problem from a system or programmatic level. In fact, the problem is still present in theater today. The task organization for the recent offensive operations in Fallujah required a force mix of seven Marine Corps battalions and two Army battalions. During execution, none of these battalions could exchange digital information with the others.

The Services recognized the need to improve, at a minimum, the extent to which each could see the others' blue force tracking information (the location and identification of friendly units) and so took steps to solve the problem. Real momentum began when the Joint Requirements Oversight Council issued JROC Memorandum 161-03 (June 13, 2003), which requested that the vice chief of staff of the Army and the assistant commandant of the Marine Corps provide an integrated briefing on converging efforts for achieving a single joint capability. Joint Forces Command OIF Lessons Learned Change Recommendation also captured the need to improve. Authoritative direction (such as from the Joint Staff) and JFCOM support are the first key enablers in adopting joint.

Vision and Direction

Armed with the direction from the Joint Staff and feedback from the warfighter, it was now incumbent upon both Services' headquarters staff to provide direction to their respective Service on how best to meet the intent of JROCM 161-03. As with any problem-solving process, a key first step is listing facts and assumptions. The key fact bearing on this problem was that preliminary reports from both Services in theater indicated that the Marine Corps' C2 personal computer and the Army's FBCB2 had performed well during combat operations. Initial direction from both headquarters staffs was based on the premise that the best method for converging the ground force toward a single capability was to use the same systems. This assertion became the vision for the joint effort: Adopting the same systems--specifically JTCW for command posts and FBCB2 for platforms--would provide the most efficient path towards interoperability from a performance, schedule, and life cycle cost standpoint. Both Services were invested in their current systems of record. A clear definition of the problem and direction from the Services' headquarters staff provided the next key enabler.

JROCM 161-03 provided broad direction. The Services worked with the Joint Staff to develop a more effective problem statement. First, although the JROCM was addressed specifically to the Army and Marine Corps, it became clear that a ground solution needed to include the Special Operations community. Air Force and Navy involvement was desirable, but this initial effort would focus solely on the ground, with the understanding that a converged ground solution would provide a far improved baseline for follow-on air-to-ground interoperability efforts. Next, the JROCM specified only blue force tracking as a capability; however, to operate effectively in close proximity, the ground force required not only knowledge of each other's blue locations, but also the ability to share additional SA, such as reported enemy locations and obstacles, and to exchange C2 messages. Finally, the JROCM did not provide a timeline for convergence, but given the ongoing operations in support of operations Enduring Freedom and Iraqi Freedom, it was understood that schedule would be a major driver for the effort. The resultant problem statement was to develop a single capability for the exchange of C2 and SA information within the ground force as soon as possible. This problem statement also effectively bounded the problem by limiting the effort to the ground force, focusing on C2 and SA exchange at the tactical echelon and establishing schedule as a driver.

Organize to Solve the Problem

Given the vision of convergence with schedule as a metric, the effort moved towards developing courses of action to solve the problem statement. First, we divided the problem in two: the battalion and above (BAA)/command post team had the mission to investigate converging the Marine Corps' JTCW and the Army's maneuver control system to the JTCW; the brigade and below (BAB)/platform team had the mission of investigating converging the Army's FBCB2 and the Marine Corps' Digital Automated Computer Terminal to FBCB2. We then further divided these two teams into three workgroups each: capabilities, technical/architecture, and programmatics. Converging was a complex, multi-Service problem. Developing several workgroups had the benefits of breaking the problem into interdependent segments that could fully develop courses of action involving Army, Marine Corps, and SOCOM subject matter experts from multiple disciplines. However, the separation of BAA and BAB would prove awkward as the convergence effort progressed, as we shall see later.

Importance of the Capabilities Workgroup

We initially made the mistake of underplaying the importance of the capabilities workgroup by assuming that since the systems in question were already fielded, the requirements would be well-known. In retrospect, however, this workgroup provided the absolutely critical first step of ensuring that any materiel solution meets the warfighter's capability needs. Combat developers from the Army, the Marine Corps, and SOCOM scrubbed the existing requirements documents and found a very large degree of overlap between the two Services' operational requirement documents for the command post systems and the two Service ORDs for the platform systems. This analysis from the combat developers provided further validation that convergence was a viable course of action. The combat developers then discussed must-have capabilities required for one Service to accept the other Service's system. Finally, the capabilities workgroup established early on that the converged solution was unlikely to meet special operations forces blue force tracking capability requirements for some elements of the special operations forces community. In order to keep the overall convergence on timeline and provide a capability to the majority of users, interoperability with those special operations forces elements was deemed outside the scope of this problem and approached by different means.

The efficiency of the capabilities workgroup depended on several factors. First, the combat developers remained capability-focused and systems-agnostic. Neither Service based its analysis on what its current system could do, but on what it needed to do. Equally important, the combat developers adopted the positions of no new capabilities beyond what was in the current Service ORDs and of joint interoperability as the ultimate goal. New requirements would have put the schedule at risk, added cost, and were not within the scope of what we were asked to investigate. The next key enabler for adopting joint is support of the user, both from the Services' combat developers and the combatant commands as represented by JFCOM.

Technical/Architecture Workgroups Uncover Key Issues

Provided with known capabilities and each Service's must-haves, the technical/architecture workgroups for BAA and BAB began developing technical solutions. The architectures developed for this effort were, in many cases, the first joint views of how C2 and SA are exchanged currently and how they could be exchanged after convergence at tactical echelons. This workgroup was the first to uncover one of the flaws in our process to date. Up to this point we were focused on applications only, converging one Service to JTCW hardware and software and the other Service to FBCB2 hardware and software. The architecture effort uncovered the second- and third-order effects of exchanging applications and the other layers that would need to be addressed to ensure interoperability. The most salient issues uncovered were:


* The Army and Marine Corps had very different communications architectures; even after converging applications, data would not be exchanged until a communications bridge between the architectures was developed and fielded.

* The Army, Marine Corps and SOCOM had different policies for the classification of SA information; data would not be exchanged until these policy differences were resolved.

* The Services had different methods of managing data; data management schema would need to be aligned to allow for exchange.

Communications architecture, security, and unit reference number management workgroups were formed to address these issues. In each case, JFCOM played an important role by leading the workgroups and providing a neutral viewpoint. For the purpose of analyzing courses of action, the technical/architecture workgroup analyzed what additional development was necessary for JTCW and FBCB2 to meet both Services' ORDs and must-haves. Ensuring that the full problem is understood--including materiel, standards, and policy implications--by a multi-discipline team of neutral subject matter experts involved is also a key enabler.

Programmatics Workgroup Develop Cost and Schedule

Armed with this initial estimate of the scope of effort required to develop the converged solution, the programmatics workgroup developed a proposed cost and schedule, ensuring that only "delta costs" associated with convergence were considered in the course of action development. In other words, both Services had an existing funding stream for their system of record. That funding included, in some cases, hardware refresh, software sustainment, testing, and training resources. For instance, both the Marine Corps' JTCW and the Army's maneuver control system software was Microsoft Windows[R]-based and hosted on a laptop in the command post. Refresh of laptops was not a cost included in the convergence cost because the Army would need to resource this requirement regardless of convergence. Conversely, providing additional functionality to JTCW to ensure it met the Army's capabilities was included. The programmatics workgroup also identified the schedule that would quantify the "soonest" in the problem statement. They identified contributing external schedule drivers and development, testing, and fielding timelines. The most important external drivers were OIF rotation dates, scheduled hardware refresh dates for the Marine Corps Digital Automated Computer Terminal, and the Army software blocking milestones. This workgroup provided the associated cost and schedule for the courses of action we would brief for decision.

Providing Governance: The Army Marine Corps Board

With courses of action developed that included cost, schedule, and performance implications, the next step was to select one course for execution. The key enabler here is to have a body with the authority to make that decision and enforce it. We were extremely fortunate in this case to have the recently established Army Marine Corps Board available. The AMCB was chartered in January 2004 to "identify, develop, review, and resolve issues with Army/Marine Corps concepts, capabilities, Service-approved requirements and programs." The Army deputy chief of staff G-8 and the Marine Corps deputy commandant, programs and resources, serve as co-chair with permanent membership from Army and Marine Corps operations, combat developers, and materiel developers. The AMCB meets monthly at the 06 level, the one- to two-star flag officer level, and the three-star flag officer level. This board, expanded as required with SOCOM representation, was extremely well-suited not only for approving the convergence plan but also for directing the budgeting of required resources to accomplish the development of the joint solutions.

Through 2004, we briefed the AMCB on three separate occasions to obtain decisions in support of the BAA convergence, the BAB convergence, and a strategy to resolve the security policy differences between the Services. We were now ready to return to the JROC, per JROCM 161-03, and respond on how the Services would resolve the blue force tracking issue. The JROCM provided the final endorsement in JROCM 163-04, which stated: "The JROCM approved the Army-Marine Corps convergence plan to achieve a single capability based on existing Service capabilities documents. The Army will adopt the JTCW application for tactical command posts and the Marine Corps will adopt FBCB2 for both platforms and dismounted applications."

JROCM 163-04 and the minutes from each of the three-star AMCBs provided a written record of the decision to converge. However, memoranda of agreement (MOAs) between the Services were necessary so both Services could understand and agree to the details of their proposed cooperation in the joint development and who had lead for each effort. The appropriate combat developer and materiel developer in the Army, Marine Corps, and SOCOM signed the MOAs at the two- to three-star flag officer level. The MOAs established a joint operational requirements workgroup and a joint configuration control board for BAA and BAB, and they identified the AMCB as the final authority for adjudicating any problems that could not be resolved by these two bodies. Again, the existence of the AMCB greatly facilitated overcoming challenges to convergence. The final key enabler is documentation through minutes and memoranda signed at an appropriately senior level to ensure the agreement holds over the life of the process, since there will invariably be changes in leadership.

Expectation Management

The decision to converge and how to converge are required initial steps. Now, perhaps, the most difficult steps can begin, further complicated by the large number of stakeholders. Not only are the typical players involved from both Services and SOCOM, but also, as a result of the high-profile nature of converging, the development has the interest of the Office of the Secretary of Defense, DoD, and the Joint Staff. Already some issues have arisen during the early development.

As stated earlier, the separation of BAA and BAB, while useful early on to develop decision-quality information, is now proving to be dysfunctional. To ensure the development of a truly seamless solution for the tactical echelons, the BAA and BAB joint configuration control boards are converging into one board to ensure interoperability between the command post and the platform. Additionally, there is concern that the joint materiel solutions, although based on legacy requirements documents, must be developed to satisfy emerging capabilities such as net centricity and compatibility with the joint C2 program.

Much work remains. To bring the "adoption" analogy full circle, difficult as the decision and process to adopt a child are, they are by no means an end state. Raising children after adoption tends to have second- and third-order consequences of its own. Similarly, the decision to converge to a single capability will have challenges of its own throughout development and fielding. However, the decision and process for converging materiel solutions among Services opens lines of communication and creates healthy dependencies--and the corresponding trust--to continue movement towards meeting the combatant commander's requirement for joint forces equipped with interoperable systems.

The authors welcome comments and questions and can be contacted at and

Lt. Col. Jim Smith, USA * Lt. Col. Mike Sweeney, USMC

Smith and Sweeney served in HQDA G8-FDT and HQMC C4 respectively during this convergence effort. Smith is currently PM Sensors and Lasers. PEO Soldier. Sweeney commands the 8th Communications Battalion, II MEF.


"Adopting Joint" Process and Key Enablers

* Define the Problem

-- Authoritative direction

-- Service support

* Identify Key Facts and Assumptions/Develop Courses of Action

-- User defined/approved capabilities

-- Participation from subject matter experts across full breadth of problem

* Choose Course of Action

-- Empowered decision body with ability to provide resources

* Execute Course of Action

-- Documented agreement approved at the senior level providing how convergence will be executed
COPYRIGHT 2005 Defense Acquisition University Press
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2005, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Author:Sweeney, Mike
Publication:Defense AT & L
Geographic Code:1USA
Date:Sep 1, 2005
Previous Article:Sensing beyond the visible: combat-enabling technologies increase warfighter safety in Iraq.
Next Article:Army news service (April 5, 2005): Army announces business restructuring of the FCS program.

Related Articles
EasyRun teams with Telrad Tenecs. (Strategic Alliances).
Division hosts systems engineering meeting. (NDIA News).
Converging on the language of financial reporting. (Global Views).
Navy to Upgrade UAV Tactical Control System: planned modifications focus on interoperability with Air Force, Army.
'Information fusion' key to winning wars.
F5'S BIG-IP product delivers mission-critical availability to Microsoft Office.
Teamwork needed for Net Centric Ops, AFEI head says.
Joint Interoperability Certification: what the program manager should know.

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters