Its About the Enterprise, Not the Systems…

 

…The issue with our current acquisition practice is that we are attempting to use processes designed for an earlier technology…

 
data-center-t011

The reason traditional DoD acquisition practices are failing us today is because we no longer build traditional information based systems. Rather than building new IT systems the way we build new aircraft or ships, we evolve enterprise and application capabilities. Said another way, today’s IT based systems are all moving toward virtual storage, virtual computing, and web services or services oriented architecture layers riding atop the network communications infrastructure.  This means that unlike IT acquisition just ten years ago, today’s acquisition is either about building out or improving the enterprise infrastructure or adding new and/or improved functionality (applications) that ride the infrastructure.  In this case, infrastructure means the network communications connectivity, plus the computing and storage capacity to support the foundation software services and application functions enabled by these “integrated” layers of infrastructure.  To fit these enterprise and application improvements into the current acquisition and budget system we mask the improvements as new programs that fit the Congressional and DoD view of system acquisition.

It is time that we fix this situation!!

An easy way to envision an infrastructure is to think of a river that is ever flowing.  Most of our cities were built around rivers because they provide life supporting services to the people living in the cities along the river infrastructure.  sacto-river3Although people in river cities can shore up the river banks to protect against flooding or bank erosion, they cannot stop the river while damns or other improvements are implemented.  Like a river, we cannot take our DoD infrastructure offline while we add new capabilities.  We can and do incrementally add improvements to increase capacity of the networks, improve security,  add computing and storage capacity, extend the reach, and add or improve applications that are enabled by that infrastructure.

The issue with our current acquisition practice is that we are attempting to use processes designed for an earlier technology when information was processed and passed among semi-independent systems across radio frequency and later wired networks.  Albert Einstein’s famous quote: “We can’t solve problems by using the same kind of thinking we used when we created them,” provides guidance for what is needed to address the challenges we face today.  Rather than building and evolving our future enterprise infrastructure using the current broken acquisition processes, we need to exercise the flexibility built into DODD 5000 to enable incremental upgrades to existing enterprise layers and applications.   The very real challenge is that everyone in the current bureaucracy, from Congress, to senior DoD leaders, to the civil and military acquisition workforce, are trapped by the kind of thinking used to create the current problems.

…In my opinion, both organizations are approaching the challenge from an implicit assumption that the current system is fundamentally sound…

Fortunately there are ongoing National and senior DoD level discussions on acquisition reform.  The Congressional initiative to create yet another law on DoD acquisition under a proposed Weapon System Acquisition Reform Act was touched upon in the previous blog post.  President Obama’s early priorities are well summarized in a brief prepared by The Avascent Group’s work on DoD Transition: Status and Outlook for the Department of Defense. From this, we can see that acquisition reform is one of four top level DoD priorities among Afghanistan surge, program and budget realignment, and Iraq drawdown.

Within acquisition reform the Administration’s priorities are:

– Close growing mismatch between investment budget and program costs

– Contain growth in cost and schedule of acquisition programs, and

– Introduce greater transparency and competition into acquisition process

One can characterize both the Congressional and the Administration’s acquisition reform priorities as centered around better oversight conducted by additional highly skilled acquisition professionals.  In my opinion, both organizations are approaching the challenge from an implicit assumption that the current system is fundamentally sound but implemented less effectively than it could be after a few minor changes.  In other words we are still trying to fix acquisition processes using the same thinking that we used in a previous technology era.

 

Two recent Defense Science Board Task Forces start to provide ideas for shifting our current acquisition paradigm.  The February 2009  Defense Science Board Task Force on Integrating Commercial Systems into the DoD Effectively and Efficiently, does a good job of describing the opportunities and challenges of buying modern military capability using a greater emphasis on the use of commercial off the shelf, COTS, and government off the shelf, GOTS technology.  This report allows that some new capabilities should be acquired within the existing DODD 5000 process but that much of our military capability can be obtained through rapid COTS/GOTS acquisition using new streamlined processes.  The March 2009 Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology, focuses on why the current DODD 5000 is too long and cumbersome to support the rapid change needed in our modern military forces, and argues, as do I, for a unique acquisition process for information technology.  Neither report, however, provide a practical roadmap for moving us beyond our current thinking.

 

So what could we do within the flexibility that DODD 5000 provides?  With some needed alignment between Congress and senior DoD leaders, we could:

1. Recognize that we are building upgrades to existing infrastructure best developed as small incremental changes implemented in six to twelve month commercial best practices cycles;

2. Allocate IT budgets to layers of the enterprise and authorize program managers to expend resources on incremental improvements to programs of record;

3. Recognize that IT requirements are broad guidelines that are specifically implemented through technology pilots endorsed by operational users;

4. Evolve current and new applications as light weight services based upon technology pilots that can be implemented within shared enterprise programs of record;

5. Replace the current cumbersome operational test process with a new process geared toward infrastructure certification, reserving operational testing for the applications that ride the infrastructure;

6. Replace the current cumbersome information assurance practices with a built in “security enabler” process applied to enterprise upgrades with a uniformly governed risk management certification process.

Interestingly, the above roadmap supports President Obama’s acquisition reform priorities. Future posts will explore each of these options in more detail.

This entry was posted in DoD IT Acquisition, Technology Evolution. Bookmark the permalink.

5 Responses to Its About the Enterprise, Not the Systems…

  1. Joe Mazzafro says:

    Completely agree with the premise here. Nobody argues that we have moved from the industrail age to the information age, but there seems to be slow recognition in DoD and the IC (probably the rest of government as well) that acquisition practices have not yet made this transition. At DIA’s Acquisition Conference last week this misalignment was only discussed perhiperally by the leadership of the IC’s acquisition community. Its certainly not clear to me why the Congress believes better oversight of outdated practices will result in better acquisition outcomes for the government. Of course, shifting from industrail age to information age acquisition pratices will mean new “losers and “winner” which is why progress here will be glacerially slow joemaz

  2. Ted Parker says:

    Thanks for pointing me to your papers, Marv. I think that the biggest problem with DOD acquisition generally, IT included, is that we keep putting people in decisionmaking positions who do not have sufficient experience/knowledge to assess risk when a developmental decision is put before them, and have no ability to define (when necessary) mitigating technical steps that are needed. And then the bystanders in Congress and elsewhere imagine that if we just put more reviews and decision points in the process, it will get better.
    IT acquisition seems to me to be very muddled, and your conception seems about right; i.e., that a different decision process is needed in order to address this “different reality”.
    I think that design and construction of ships need a different process as well, for similar reasons.

    Ted

  3. Rex Buddenberg says:

    Marv,

    If you go to one part of the MBA school — the touchy-feely department — you get exposed to what we tend to call a management fad. We’ve all been through enough of them — TQL/TQM, six-sigma, MBO. Peters & Waterman were the rage when I got my lobotomy. And these fads rotate with enough frequency that we tend to get exposed to >1 within a memory span … leading us to indeed call them fads and get duly cynical.

    The salient problem with all of these management fads is that they give you lots of stick and rudder on _how_. (Over in the journalism school, things are better balanced: at least they bash ‘who/what/when/where/why’ into your skull along with the ‘how’.). Or i8n military terms, all tactics, no strategy.

    If you go to a different part of the MBA school — the financial management part — you get exposed to one or more management ‘ techniques’. These get transformed, in practice, into ‘acquisition doctrine’. Routinely this essentially accounting (think CPA) stuff gets cross-pollinated (cross-polluted?) with legal. DDOD 5000 is full of this stuff and you can see it repeated in OMB reports on DoD programs — they all point to ‘bad management’ for a screwed up program. Now ask yourself: are we dealing with ‘what’ or ‘how’?

    Nowhere is the ‘what’ of a program ever addressed here…. reread the ‘salient problem’ paragraph above … does it not fit? Is not the quadrennial exercise in reforming acquisition just another revolving door of management fads?

    What is _not_ taught in the MBA school is … biology. [!!]. The one inexorable force in this business is Darwin’s natural selection process. And the only real reason that ‘COTS’ is better than ‘grey box’ is that Darwin works faster in the COTS world — the technology that can’t be integrated into larger information systems tends to die off because nobody buys it (e.g. you can’t build the internet out of ARCNET components but you can with ethernet components). DoD’s economy badly distorts the free market (some of which is unavoidable) and it similarly (always negatively) distorts Darwin too. What we have in DoD’s IT is archepelagos of Galapagos Islands scattered around the ocean — isolated from each other … and from the outside world.

    Noted above, the ‘what’ is missing. In IT systems of whatever flavor — admin to combat — the ‘what’ needs the vocabulary of:
    – interchangeable parts
    – modularity
    – interoperability
    None of these terms appear in DoD 5000 material. None of them appear in any of the touch-feely management fads either. Wonder why Dilbert’s boss has such a bad rep?

  4. Hank Beebe says:

    Marv,

    I agree with the premise laid out here and with wide-ranging discussion around your March 18th post. I would caution, however, that there are pitfalls in trying to scale technology pilots to enterprise-level apps.
    We all know IT programs that have failed or “failed” under the weight of acquisition rules and oversight. Lots of formal process controlling virtually every program function but after years of work and tens or hundreds of millions spent, deliver nothing that is militarily useful.
    The technology pilot or prototype approach is often viewed as an appealing alternative. An operational prototype can be built quickly (and by comparison, cheaply). Domain (warfighter) expertise is usually available to guide the developers who are, in turn, responsive to immediate user needs. The pilot/prototype gains a user audience and warfighter (CoCOM) support because it provides direct military utility; the user comes to depend on the prototype and “advertises” its usefulness to domain peers.
    As usage expands, however, the pilot/prototype does not/cannot scale to accommodate demand. It frequently suffers from all the ills of a prototype: no (or poor) overall architecture, constraining design, little discipline or structure in code development, proprietary key components, growth like topsy in response to near real time user requests, insufficient documentation, etc. It’s not net-centric, doesn’t and can’t comply with DOD data or services strategies, doesn’t/can’t follow CJCSI 6212.01E, and so on.
    What is needed is a middle ground that takes advantage of the speed and operational user involvement of prototyping and piloting, but with some measure of engineering rigor and discipline of a formal program (PoR). Appropriate oversight needs to be provided but not be so burdensome that little actual work can get accomplished. This would be different from the current JCTD process in that (planning for) migration to a PoR would not be a mandatory requirement.
    IT acquisition reform needs to be accompanied by engineering reform.

  5. Hello there, I discovered your web site by means of Google even as looking for a similar topic,
    your site came up, it seems great. I’ve bookmarked it in my google bookmarks.

    Hi there, just become aware of your blog thru
    Google, and found that it is truly informative. I’m gonna watch out
    for brussels. I’ll be grateful should you proceed this in future.
    Numerous other folks will probably be benefited from your
    writing. Cheers!

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.