fbpx

Department of Defense UC 2.0

In response to the large number of requests received to publish a follow-up on my last post, I am posting this in response.

With my last post I hit on the multiple issues that represent real world roadblocks to seeing Unified Communications (voice, video and collaboration) being successfully rolled out within the Department of Defense (DOD) enterprise. The major issues surrounded the lack of acceptable base/local network infrastructure needed to successfully deliver real time services, as well as the lack of a single information assurance solution that is actively supported across the department. Adding to that is the lack of a service delivery model that is based on a single technology platform that can meet the many integrated UC requirements for the millions of DOD users located around the world.

So the question that has been proposed is “Where do we go from here”?

Step 1: Policy Requirement(s).

The DOD Chief Information Officer (CIO) has a responsibility to publish designed to provide guidance and instruction to the department. The last piece of policy published by the DOD CIO office was the DODI 8100.04 (Unified Capabilities) signed out on December 9, 2010. The objective of this instruction was to “require” the department’s commands, components and agencies to transition from legacy voice technology to new voice and video over Internet Protocol (IP) in adherence to the Defense Information Systems Agency (DISA) Unified Capabilities Requirements (UCR) technical specification and the DOD CIO published UC Master Plan. One of the underpinnings was the continued requirement for technology to be tested and certified by the Joint Test & Interoperability Command (JITC) and placed on an Approved Products List (APL) where acquisition commands within the DOD could go to ensure products being proposed by bidders had been approved for integration into the DOD IP networks. There was a provision within the DOD UC Master Plan for all components and agencies to submit to DISA a comprehensive Implementation Plan demonstrating how each was going to accomplish this transition, and a timeline for when it would begin and when it would be completed. This is where the wheels fell of the cart… DISA did not receive the required plans in the time frame required. In fact, over 24 months passed before they had responses from all the services, and at that time much of the technologies captured in the plans were no longer on the APL, rendering many of the plans worthless to DISA.

Due to the pace of advances in UC technology, for the DOD to be successful, there must be a single voice that is projected to both industry as well as internally that captures the specifics of a UC technical architecture, design and defined roles and responsibilities. The Joint Information Environment (JIE) work has an opportunity to host such an initiative, but for it to be successful all combatant commands, components and agencies would have to participate with both operators and acquisition authorities in a single working group with the mission of creating a single Solution Architecture and Implementation Plan. Such a plan would be required to be signed out by the DOD CIO as the replacement for the current UC Reference Architecture and Master Plan. Parts of the new plan would be needed to update the existing Instruction to sustain its relevancy.

Step 2: Acquisition Planning

One of the key phrases repeated often by the DOD CIO is that there is “no new money”. In fact, because of the past eight fiscal years being funded mostly with continuing resolutions, he is absolutely correct. By law, no new projects can be funded with continuing resolution funds. In short, the money allowed to be spent is designed to only “kick the can” on the existing solutions, limiting spending to sustainment and technology refresh efforts. This becomes an interesting dance for acquisition commands, as many of the technologies in operation are no longer on the APL and in many cases are no longer supported by the vendors. The end result is many parts of the DOD do not have active maintenance agreements with industry putting the overall health of the DOD Information Technology at risk, as well as our national security.

Another acquisition challenge is dealing with the many “rice bowl” issues within the DOD. Many Program of Records (PORs) have successfully fenced their funding, and their scopes are so narrowly defined that allowing for any new technology to be sponsored through the POR is all but impossible. Separating operations dollars from procurement dollars is also challenging, as any money that can be used to purchase and install technology cannot be used to fund maintenance or operational support. To often there has been technology purchased without any maintenance or training tail, leaving operators with a new responsibility and no means to support it. The end result is the technology is never used, and taxpayer dollars are wasted.

In order for the DOD to successfully accomplish an acquisition needed to deliver a successful UC enterprise, it is imperative that acquisition rolls and responsibilities be established within each component and agency. There truly needs to be a single voice within each component and agency that has single acquisition authority for that individual component or agency. Without such authority, what ultimately gets purchased and fielded will become disjointed and accomplishing a single integrated enterprise will be all but impossible.

Step 3: Network & Cyber Operation

Too often it is easy to focus on the acquisition part of the equation without regard to the how the delivered solution will be managed, operated and protected. Today there are many “pockets” of voice and video operational management and in some cases… none at all. As the department transitions to a single integrated platform, how the end-to-end management of the services will be accomplished has to be vetted and agreed to by all responsible stack-holders within the department. While the promise of JIE is supposed to be addressing this topic, most all focus has been only on data networking and applications, and the unique requirements for real time service protocols have gone wanting.
Lastly from a cyber perspective, there will need to be new tools and procedures for protecting real time service protocols within the enterprise, as their uniqueness left unattended will result in voice and video communications being compromised… and no, just adding a Session Border Controller (SBC) is not going to solve the problem.

Leave Comment

Your email address will not be published. Required fields are marked *