“DISA Inside” – NCES should be a SaaS Appliance


The title of this post is not part of my secret plan to obscure meaning through the liberal use of acronyms. It really just came out that way.

Here’s what the acronyms mean:

DISA = Defense Information Systems Agency. The once and future DoD phone company, now also responsible for stuff like enterprise application hosting, service oriented architecture (SOA) infrastructure and the command and control systems that will use it. Today DISA’s center of gravity remains firmly in the data center.

NCES = Net Centric Enterprise Services. The SOA infrastructure that I mentioned above plus stuff like enterprise chat and search. Current state has a high ppt to compute ratio.

SaaS = Software as a Service. I know you already knew that one but I felt compelled to include it for completeness.

So, now on to the meat of the post.

If DISA is going to have relevance outside of the data center, and therefore relevance to the warfighter, it needs to have an impact on the experience at the warfighting network edge. Today’s data center focus combined with the realities of network availability at the edge makes that unlikely. The NCES’ core services of messaging, security, search, and things like that are simply going to be useless to the warfighter at the end of an intermittent or low bandwidth network. This is really nothing new as everyone already recognizes the difficulty in supporting shipboard command and control systems with remotely provisioned NCES services. What’s missing today though is a focused strategy to obtain relevancy at the edge.

This article’s mention of SaaS appliances reminded me of a conversation I had with DISA engineers about two years ago. The gist of the conversation was “what if you guys were to think like a company and stretch NCES out to the edge by building (or commissioning) a line of NCES appliances as a combined product and services offering? You could build them into the two or three common form factors so that they could fit into server racks (like in a Tactical Operations Center) or into a vehicle (in an Integrated Computer System form factor). Then design them so that you could add value by remotely providing systems management, domain spanning messaging, and things like that. Finally, paint them white and put big blue ‘DISA Inside’ logos on them so everyone knows they came from you.”

The appliances would allow for modular software deployment (including messaging and message routing, mediation, information assurance functions, search and etc.) either as different appliances or as independent functions within a single appliance depending on the deployment environment. Relying on local caching it would serve as a complete (if narrowly aware) NCES environment on the battlefield when intermittent network realities left it disconnected from the borg, but it would intelligently re-synch when connected.

Done right, I can imagine all kinds of programs spec’ing such an appliance as both a core piece of local infrastructure and also as the bridge back to the enterprise. Army Battle Command System, the USAF Objective Gateway, Future Combat System, Shipboard command and control systems, USAF Air Operations Center, just to name a few, could all use common services packaged this way and whose enterprise awareness seamlessly expanded and collapsed as network availability allowed.

So what do I think “done right’ means? I think it means an adoption-friendly appliance line based on an open stack that all of those consuming programs can inspect and contribute to. I imagine a DISA-managed collaborative ecosystem of related open communities delivering the stack and service components into a related ecosystem of appliance hardware vendors. In a perfect world the collaborative eco-system would be market driven and would span the DoD’s garden walls. By avoiding excessive gating it would serve as an effective two way technology transfer mechanism into and out of the defense establishment; stack components coming in technologies like context-aware message routers flowing out.

I know this probably sounds kind as crazy to the DoD establishment as it does mundane to the open source world outside it. It’s all a matter of perspective I guess. You have to dream it to do it.

• • •

DoD Software Development – the Wrong Center of Effort

I spent some time last week going through the details of a well known DoD three letter acronym IT program. There’s no point in disclosing the particulars because the observation I’m about to make applies to most of them. But, as I was looking at the capabilities of the software and seeing it demonstrated I asked “Hmmm… I always thought there was more to this thing. Is this really all it is?” A: “Well, yeah, it’s mostly just an integration of a COTS database with middleware. The code itself is a few hundred lines of database data definition language and probably less than ten thousand lines of Java, probably a lot less.”

During the rest of the conversation we talked about the fact that, since this is “joint” program it has a staff of program managers and systems engineers at each service plus at OSD and JFCOM to develop the requirements, “design the architecture” and so on. Each group also has its own testing and certification staff to prove out the code before it can be integrated into their versions of the C2 node this thing is designed to integrate… What you get looks like this (where conceptually, the cost per line of code can be estimated by integrating the area under the curve and dividing by the lines of code):


10,000 lines of code. I’ve seen commercial software development programs with 500 developers and millions of lines of code with less management and oversight. Besides a willingness to accept extraordinarily slow delivery of software, this approach so burdens each line of code with overhead, that the world of defense IT has developed bloated expectations for what things cost. The kind of overhead burden that makes quotes like “you don’t understand the pressures we’re under, we only have a budget of $250M” seem to make sense.

When it comes to IT, we in defense systems development need to move past this industrial age systems engineering choked approach and get to something that is agile, fast, and more cost effective. Just make it look like this:


• • •

General Lord Responds on /.

General Lord responded today to questions posted on Slashdot. Like I said before hats off to Gen Lord for even attempting this. On a relative scale this is an amazing amount of openness. The General’s responses had just enough authenticity that I believe he probably authored the original content. But, I suspect it went through a process something like this before it was released:

1st Draft:

YGTBKM! But seriously, I’d love to have a strategy like the one the Chinese have and harness you guys into some kind of ass-kicking lead-turning civil cyber patrol but you know I can’t, turns out that would be illegal. Oh well. But hey, if you kick a little ass and I didn’t ask you to, what can I do about it? By the way, you didn’t hear it from me, but there is a list of interesting IP addresses stego-hidden in my bio picture at af.mil, in the big jpeg one.

2nd Draft after once over by his deputy:

YGTBKM! But seriously, I’d love to have a strategy like “some other places” and harness you guys into some kind of really good civil cyber patrol but you know I can’t, turns out that would be illegal. Oh well. But hey, if you kick a little ass and I didn’t ask you to, what can I do about it? Please email me for a list of interesting IP addresses (margin note: what’s stego?).

3rd Draft after legal review:

YGTBKM! LOL! I CAN haz cheezburger!

4th Draft after second deputy review:

YGTBKM! LOL! But seriously, I’d love to have a strategy like some other places and harness you guys into some kind of really good civil cyber patrol but you know I can’t, that would be illegal. Oh well. But hey, if you kick a little ass and I didn’t ask you to, what can I do about it? Really, email me.

5th Draft, PAO Approval:

Mmmmm… Cheezburger.

Final Draft after all corrections:

YGTBKM! LOL! I like your enthusiasm, but you know the Air Force neither encourages nor condones criminal activity.

• • •

CHIPSAFE for Critical Components?


There has been a surge of articles like this one lately that raise the issue of supply chain integrity for critical computing components especially in the context of security. The emerging trend toward open hardware as exemplified by Sun OpenSPARC will only make the sourcing provenance issue more important as the openness of the design will make it that much easier to knock off a slightly modified chip.

I was the Quality Assurance officer on a U.S. Navy Submarine for a while (too long, it was an awful if important job) and this problem made me think of the SUBSAFE program. Started after the loss of the Thresher it put in stringent controls on material for all seawater systems that cover how the materials are sourced, inspected, tracked to point of installation, installed, tested in place and etc. The reactor systems are covered by similar controls all of which are designed to make sure that the specified thing was manufactured, bought, shipped, and installed, and that it lived up to its specification as implemented. To me, the QA officer at the end of a long chain, it meant material control tags, work package reviews, periodic work-in-progress inspections, a stack of pre-underway paperwork next to my desk that reached from the floor to the desktop, and many many many signatures.

The NSA’s Trusted Foundry Access program sounds like the sourcing piece of SUBSAFE for silicon. I hope it never needs to be extended into a CHIPSAFE program that covers the entire supply chain as the expense and difficulty imposed by such a system would be staggering (there are a lot more things using computers than there are submarines). However, I suspect eventually it will for at least some uses. However, computing is so pervasive that I’m not sure a system like SUBSAFE with carefully controlled and focused scope can be effective.

• • •