DRAFT 22 February 2006
Chris.Gunderson@w2cog.org
703 262 5332
The ABC’S of GIG C2, or… Hastily Improved Networks MacGyver Style!
Lieutenant General Charlie Croom, Director of DISA, has a new strategy for fielding netcentric capability on the Global Information Grid (GIG). It calls for A dapting existing tools, or if existing tools are inadequate, B uying generic commercial tools and a dapting them to solve specific problems, or as a last resort, C reating specialized solutions. It follows that we should also look to A dapt any bought or created solution as broadly as possible. So… It’s about Adapting! Since DoD transformational policy aims to encourage netcentric innovation in our war fighting communities, i.e. adapting to stressful situations with “MacGyver-like” ingenuity , this ABC policy resonates strongly as a means to inject that same innovation into our engineering communities. The NPS
Hastily Formed Network initiative (HFN) is an excellent exemplar of this spirit! Can we apply lessons learned by HFN more broadly across the GIG engineering community?
GIG vision for next generation Command and Control (C2) capability calls for an evolution from today’s multiple “closed” specialized C2 systems to an “open” distributed suite of networked services hosted on generic computer network equipment. The idea is that operators innovatively compose these services on line to provide capability as required by the problem at hand. With that in mind, we might think of the GIG C2 implementation strategy as The ABC’s of GIG C2, or . . . C2 like MacGyver would do it . MacGyver has a formula that always beats the bad guy:
(1) b ore sight on the most important problem(s);
(2) don’t constrain the solution set;
(3) decompose available resources into component parts and critically inventory their functionality;
(4) urgently and concurrently design, build, and USE the tool necessary to solve the most important problem.
Bore sight on the most critical issue .
GC2’s objective is to deliver User Defined Operating Pictures (UDOP) that help real warriors solve real problems faster and better than before. We’ve got to identify the most critical warriors, problems, time lines, and objectives before designing generic solutions.
The warrior in the hot spot has to be in the middle of the process. The new widget he helps design has to be delivered to him during his current tour of duty, and it’s got to come with guaranteed tech refresh. GIG life cycle maintenance must become an
“innovative service.”
1

DRAFT 22 February 2006
Don’t constrain the solution set .
GC2 design process should help the warrior explain his problems, opportunities, and desired outcomes directly to creative government, academic, and commercial developers.
The process should incentivize those developers to exceed that warrior’s desired outcomes, and not attempt to control the solution design. (While MacGyver never fails, our more real world innovative process must offer the opportunity to fail fast and cheap the better to learn what will work the best!)
Decompose into components; critically inventory functionality .
GC2 development resources should be spent to continuously compose critical UDOPs by adapting existing C2 components . The alphabet soup of DoD systems like GCSS
(CC/JTF), GCCS, FCS, C2C, FORCEnet, CPOF, DCGS, etc, all have components that can be decomposed into C2 building blocks. We should incentivize program managers to decompose and “open” their systems by applying GC2 developmental funds to critically test, evaluate, certify, catalog and distribute the resulting inventory of best of breed components .
For example, can we compose an enterprise security service from components from: JCDX, an NSA PL4 cross domain service that handles 64,000 tracks;
NETOPS, an NSA licensed multi-level access thin client “virtual machine” built entirely with COTS; PEO C4I’s scaleable role based access web service that employs DMDC’s
CAC-based identity management service, uses Navy Enterprise Single Sign On (NESSO) for logical identity authentication, and applies a Trusted Authorization Policy Engine
(TAPE) for authorization? Clearly we can use the National Geospatial-Intelligence
Agency’s (NGA) Commercial Joint Mapping Tool Kit (C/JMTK) for GC2 geospatial services. Further, the C/JMTK architecture employs a distributed SOA approach and is centrally licensed and funded by NGA for the DoD (and Coast Guard) NCES C2I community, which means free use for development and deployment for over 200 programs approved. Couldn’t C/JMTK also serve as a GC2 service oriented reference architecture? The Oracle 10G data base is so common as to be a de facto standard across
DoD; are we using it to its full potential? Army Knowledge On-Line (AKO) will become the DoD’s single knowledge portal (DKO); shouldn’t GC2 leverage DKO’s developmental resources? The collaborative visualization tools embedded in the recently fielded Command Post of the Future (CPOF) have been proclaimed as “better that being there” by senior commanders in the field; can we commoditize the CPOF collaborative tool suite across the GIG? The bottom line is that we need an independent
“Consumers’ Report” that offers cross program visibility and objective evaluation of existing network-enabling components available for re-use. The new NPS “Netcentric
Certification Office” (NCO) research initiative, sponsored by DISA’s Joint
Interoperability Test Command, aims to create and maintain such a resource.
2

DRAFT 22 February 2006
Urgently and concurrently design, build, and USE the tool.
Successful e-businesses apply MacGyver’s formula on the Internet every day. They partner with their customers to experiment with various bundles of technologies to create process improvements and product upgrades in 90 – 180 cycles. GIG C2 engineers should follow that model and team up with operational customers in interlinked helical developmental spirals where technology and doctrine co-evolve. NPS’s World Wide
Consortium for the Grid (W2COG) research initiative created a “Netcentric Incubator” process designed to facilitate this brand of Netcentric Engineering.
Join the Team!
Aren’t NPS students especially qualified to identify the most critical war fighting issues?
Isn’t graduate research fundamentally about exploring unconstrained solutions?
Shouldn’t NPS students perform independent assessment of existing DoD computer network capability to validate military relevance of computer network research topics?
Hasn’t HFN demonstrated NPS particular skill at e-business engineering? If you agree that the answer to these questions is yes, consider joining the Netcentric Engineering
Team.
3