January 10, 2007
I attended the AFCEA DISA Luncheon Symposium in Washington, DC yesterday.
After the parading of the colors, a symbolic lunch that included black eyed peas for good luck and collard greens for prosperity, an invocation that ended with a rather old-Testament call for our enemies’ destruction, and a series of odd one-clap introductions, the panel discussion began.
For the most part the discussion stayed close to existing public statements so there were no real surprises. Recognition that fast is better, reiteration of the adopt-before-build doctrine, an emphasis on lighter up front requirements to speed delivery, and the impact of globalization of the software business on security were all reemphasized.
There were a couple of moments that stimulated an audience reaction.
First Dave Mihelcic got some guffaws from the crowd with his statement that “Ideally NECC will have a release per week” when he was describing the purpose of the Federated Development and Certification Environment (FDCE).
He didn’t use the term continuous beta but he was clearly emphasizing the need to get feedback early from “sandbox” testing with the idea that a sandbox on operational networks could readily evolve to an operational capability, and would get real feedback from operators in the meantime.
Clearly at least some of the audience didn’t see weekly releases as even within the realm of possiblity. I applaud him for putting that goal out there.
The second reaction came from Brig Gen Warner’s statement that “The day of the big system integrator is over” to a room full of, well, big system integrators.
It was a provocative statement, but in concert with Mihelcic’s statement about release cycles, Brig Gen Warner’s later comments about the time spent on requirements are probably more interesting. He made the point that when the typical two years is consumed defining requirements, commanders in the field will go off-reservation and “hobby shop” a solution. Innovation always shorts to ground when a big enough need builds up.
I think that they should have gone on to make the point that less time on requirements only works in concert with very rapid releases, and the discipline and competencies to do them.
The problem today is that very infrequent system-wide integration combined with the long tail of accreditation, certification, and testing completely decouples the development of a capability from it’s real world use. In this environment reduced time spent on requirements will only result in poorly defined software reaching the sandbox; but without the necessary relief from a rapid follow-on of releases to correct misunderstandings of those broadly defined requirements.
What is required in my view is an environment more like Amazon.com’s where rapid evolution of requirements is combined with as-frequently-as-daily releases to in-situ A/B user-instrumented tests and production. Measurement based product management combined with super-disciplined build, test, and release management is the combination that would permit NECC capabilities to be fielded every single day.
But I want to back up a bit … What was missing for me from the entire conversation was an exposition of DISA’s value proposition in market-defined language. Moving beyond “existence as mandate,” I was hoping for a discussion of “what business we plan to be in” and “what will make us great at it.” The discussion often revolved around what DISA is going to do and provide (e.g. NCES product areas), but not why their customers need it or want it.
If DISA was a commercial concern and the DoD was its market, how would it talk about its mission?
In November I attended Jeff Bezo’s talk “Web Scale Computing” at the Web 2.0 Summit in San Francisco. In it he talked about Amazon’s entree into the infrastructure business. His discussion was completely focused on the customer need being solved and barely mentioned technology; other than to say that they were using the same technology that they use internally for their web services customers.
We know, for example, that EC2 is based on XEN virtualization but he didn’t mention it once.
What he did say was very simple and powerful: historically 70% of a startup company’s effort and money is spent on the “undifferentiated muck” of computing, networking, licensing, disaster recovery, and etc.; and that Amazon’s strategy will be “We make muck so you don’t have to.” He went on to say that he thought that they would be good at running muck for customers because they run a lot of muck for themselves.
Walking out of Bezo’s presentation I knew I understood the customer pain that needed salve, what Amazon’s value was to heal it, and why Bezo thought that Amazon would be good at it.
What is DISA’s equivalent pain / value / competency triplet? It probably shouldn’t be all that different; after all, every DoD program deals with similar muck, plus the muck that goes with government processes for testing and accreditation.
Let’s take a stab at it for the NECC/NCES domain space…
Programs that provide capability to NECC spend too much time and money defining and provisioning hardware, infrastructure software, and networks; re-creating base command and control capabilities such as mapping, imagery handling, and collaboration; and dealing with the complexity of testing and certification. DoD programs, unlike most of their commercial counterparts, remain “vertically integrated” and often end up building the same base capabilities in incompatible ways. The result is a multi-year gap between a recognized need and the belated delivery of obsolescent capability.
DISA will help the services rapidly field new capabilities by providing remote hosting and management of these capabilities while also providing the “base platforms” of mapping, imagery, collaboration etc. Essentially we intend to be the “Google maps-like mashup engine for C2 plus the data center for hosting the higher order capabilities built on top of that platform.” In addition to developing that base platform we will leverage foundational enterprise integration capabilities to tie in commonly reusable data from Blue Force Tracker, ADSI / Link 16, NIMA, MIDB, and etc. for ready re-use by all joint service capabilities.
Additionally DISA will take on the role of community process owner and testing and certification facilitator to streamline the ability to build and deploy both these core capabilities AND the service-specific capabilities built on top of them on a daily release schedule when required. Furthermore, we will develop those base capabilities as a DoD open source / open technology project to improve quality and to enhance the liklihood of adoption.
Finally, we will structure the processes and capabilities that we provide such that capabilities can be delivered, early, often, and incrementally to avoid the problem of huge upfront requirements specification effort.
• • •