DoD can’t get to wave 3 using wave 2 processes!!!

Our military Wave 3 information capability is hostage to current Wave 2 bureaucratic processes…   …we can’t get there without radical change!

Our DoD Culture does not Understand Technology Adoption

DoD’s attempt to modernize Joint command & control (C2) is once again being rethought following the shut down of the Net-Enabled Command Capability (NECC) program. After four years, hundreds of meetings, and almost $300M, DoD has thought hard about how C2 can be improved using a services-based architecture, but in the end is leaving behind little more than a stack of documents, some experimental C2 capability, and confusion about what to do next.  NECC was about building a Wave 3 services based C2 capability. This acquisition failure is one among many similar situations within the Department.  These failures have little or nothing to do with associated senior leaders and well-intentioned acquisition professionals.  Rather, it is the result of using an institutionalized Wave 2 “technology adoption” budgeting & acquisition processes while attempting to build Wave 3 capabilities.

What is the Technology Adoption “S” Curve?

Chart 1. Technology Adoption Stages

Chart 1. Technology Adoption Stages

Chart 1 shows an “S” curve representing the adoption life-cycle of a synergistic group of technologies working together to create a product or service we purchase to improve our lives and society. Joe M. Bohlen and George M. Beal originally developed the technology adoption lifecycle in 1957.  Its purpose was to track the purchase patterns of hybrid seed corn by farmers.  It has evolved to represent the adoption of any new technology.  The curve tracks the slow initial adoption of new technology, sometimes referred to as the “fermentation period,” followed by a rapid growth “take-off” period as awareness and supporting infrastructure encourage more people to purchase the product.  The level of adoption then slows down as the market becomes saturated or the product becomes “stagnant.”  “S” curves are often shown in a linked series because new products of similar type follow a new “S” curve as they enter the market.  Chart 2 traces the adoption of primary technologies over the history of America.  Notice that information based technologies have been adopted more quickly than earlier inventions like the automobile, airplane, and telephone.

Chart 2 - US Technology Adoption History

Chart 2 - US Technology Adoption History

Moving into Wave 3 Information Technology

Chart 3 puts the information technology “S” curves in context so that we can understand the dilemma that moving from Wave 2 into Wave 3 presents to the DoD.  The first wave represents the invention and adoption of electronic processing equipment.  When large business began to purchase main-frame computers to automate business functions such as payroll, accounts payable, inventory, and eventually product design, the era of large data centers took-off, ushering in the age of computers.  The first useful computers began to emerge in the early 1950’s and this “S” curve had reached its upper plateau by the 1980’s.  We continue to use main-frame computers but they have become a high performance computer format for legacy and computer intensive Wave 2 functions.

Chart 3 - Information Technology Adoption Curves

Chart 3 - Information Technology Adoption Curves

By the early 1970’s computer manufacturers were able to take advantage of the technology evolution from transistors to semiconductor chips and began building smaller computers that were more easily purchased and distributed across dispersed Corporate locations.  These “mini” computers, the size of home refrigerators, were the beginning of Wave 2.  On the heals of the mini computer was the emergence of the first “personal computers” in the late 1970’s.  With the combination of mini and personal computers, the client-server architecture was born.  These small affordable PCs also facilitated computers into our personal lives for the first time.

Wave 2 was also enabled by the adoption of Ethernet as the data-bus standard of choice.  With Ethernet it became possible to eliminate point-to-point system connections in favor of the plug-and-play data-bus. This allowed businesses to place computers in every office using local networks to link information based employees onto client-server business applications. During this period, DARPA (Defense Advanced Research Project Agency) was busy inventing a communication method to tie together large distributed scientific computer centers.  This became the first MILNET, supporting early email across selected DoD laboratories.  The commercial adoption of MILNET technology led to the birth of the Internet.  The Internet explosion was facilitated by the birth of the Mosaic browser written by Mark Andreaessen, which he made freely available to anyone.  The cellular telephone invention was also a Wave 2 complementary technology.  This device moving through its own “S” curve, allowed the average private and business person to move communications from the home and office to virtually anyplace within large population centers.  With Internet connectivity, local networks, browsers, and cell phones, Wave 2 became the transformational driver of the modern information age.

Because most of us have lived a majority of our lives within the Wave 2 information age, it is less obvious that a Wave 3 “S” curve has been underway for almost a decade.  Wave 3, which is associated with the Web 2.0 buzz, is enabled by globalization of the Internet, augmented with high-bandwidth Internet service to home users using infrastructure built-out by television cable providers, Internet enabled telephone providers, and satellite television providers.

The real essence of Wave 3 IT is the simplification of IT usage by non-IT savvy business professionals and home computer users.  Unlike Wave 2 where every user is a self directed IT administrator (directing our software upgrades, printer driver installations, and communications parameters), Wave 3 is moving toward a ubiquitous IT cloud infrastructure that provides the majority of our applications as software services.  As a consultant, my life has already moved into Wave 3 where Google provides my email and office applications on and off line, WordPress facilitates this blog, DropBox stores and synchronizes all of my data across all of my computers, and Apple’s me.com backs up all of my email and files.  In this Wave 3 world, my browser of choice is the gateway into all of the applications I might need.   In addition, all of my data/information can be viewed, modified, and shared from my iPhone or any computer that has an Internet access.

Wave 3 is also about more than a high-performance IT support infrastructure.  It is about new functionality at our fingertips when we are willing to pay a usage service fee.  As an example, if I felt that a mapping function or a calendar function would add value to this blog site, they can be added as a drag and drop function from Google or many other Wave 3 service providers.  In a Wave 2 world, adding such functionality to my blog site would have meant several months and several man-years of computer software development to modify the client-server system supporting this blog.  This level of user abstraction is equivalent to the historical technology transformation from small electric generators supporting home or business, into our National electric grid, and from telegraph offices into our National telecommunications grid.

Wave 3 Requires Different Priorities and Different Processes

Like all things convenient, but yet complex below what the user sees, the ease of use comes with a price.  That price is the care and feeding required for each element of this complex infrastructure.  Each infrastructure has grown from a series of “S” curve evolutions, standards adoption, and rigorous testing and certifications processes to ensure users will disrupt the shared-infrastructure for other users.  Such standardization and commonality of operations is only possible through a process of governance or dictatorial controls.  Because most technology is born through open collaboration, democratic based governance will continue to be the success model for large global infrastructure interoperability.

I hope this discussion provides good background to support my argument that we cannot develop the desired application and information agility needed to support modern warfare if we continue to apply Wave 2 processes.  I mean by Wave 2 process our current JCIDS (Joint Capability Integration and Development System) requirements process, combined with our DODD (Department of Defense Directive) 5000 acquisition process, and funded through our PPBE (Planning Programming Budgeting Execution) process.   Each of these have evolved over decades of bureaucratic reforms designed to guard against misapplication of public funds for military capability. Taken as a whole, these interdependent processes have value for the overall purchase of DoD materiel.  But when viewed within the specific framework of Wave 3 IT, these processes are detrimental to both warfare IT intensive capability, and to the resources allocated to acquire IT capabilities.  To fully appreciate how these processes need to be modified it is instructive to compare Wave 2 DoD process with Wave 3 commercial process.

Wave 2 DoD “as-is” acquisition process:

  • Full detailed requirement defined prior to program approval
  • Up-front life cycle cost estimates for the program/system
  • Every project considered a system not a component of enterprise
  • Each system development budgeted within a “hump” curve of budget categories to support system development, implementation, and sustainment
  • Rigorous bureaucratic oversight of the system development to “ensure” program success
  • Rigorous testing of the system and the interdependencies that it will operate within
  • Complete information assurance certification of the system within its operational environment
  • Repeat each of these steps for system upgrade cycles as warfare requirements or supporting technologies change
  • Apply these same processes for DoD Wave 3 programs such as NECC, CANES, BTI, etc.
  • Standards and interoperability governance assumed covered within the rigorous acquisition process

Wave 3 commercial “as-is” best practices:

  • Requirements broadly defined to initiate a project and enable initial funding
  • Yearly (or periodic) funding cycles based upon previous progress and additional capability need
  • Application functions developed as iterative software development activity (generally built with “agile” 30 day development cycles)
  • Application functions abstracted from supporting infrastructure projects and funded as separate iterative projects
  • Infrastructure projects developed as hardware and software iterations designed to enhance and/or replace existing infrastructure (networks, cloud computing, SOA service middleware software)
  • Governance of infrastructure through processes external to infrastructure and application project development
  • Governance driven by bottom-up engineering teams and implemented through policy approval and budget control methods
  • Testing dominated by interoperability certification with evolving infrastructure
  • Information assurance (IA) validated for supporting infrastructure semi-independently from applications functionality
  • Governance and certification processes replace Wave 2 oversight processes

Responding to the Dilemma

Until DoD achieves adequate collective understanding of this Wave 3 dilemma, program failures like NECC will remain the norm.  Some senior leaders have argued that the DoD mission is not compatible with Wave 3 technologies.  If that were to prevail then the Wave 2 processes could remain as they are, but we should then also abandon any attempt to achieve Wave 3 capability.  Because DoD has been evolving as a Wave 2 military for decades, we already know the challenges of Joint operations and information agility that are aligned with the Wave 2 client server systems.  Alternatively, if DoD remains on the path toward Wave 3 technology we can look forward to significant improvements in:

  1. Much more effective Joint information and communication interoperability;
  2. Data & information flexibility, and;
  3. Rapid application deployment that will better pace warfare need.

In order to achieve these desired end-state goals we must rapidly move from the Wave 2 processes that are diverting valuable IT time and dollar resources and move rapidly adopt Wave 3 processes and budget practices that will:

  1. Understand the critical nature of infrastructure that must be evolved, protected, and layered for continuity of operations;
  2. Govern using bottom-up driven standards & design patterns, complimented with top-down policy and budget and budget controls;
  3. Certify Joint interoperability and information assurance across the infrastructure layers;
  4. Focus OT&E practices on semi-independent application and infrastructure functionality;
  5. Align IT budgets to support the semi-independent iterative development of applications riding shared infrastructure.

Although DoD mythology will assume that these significant changes will require Congressional approval, the majority, if not all of these changes are within the existing authority of the Department’s requirements, budgeting, and acquisition senior leaders.  In today’s complex defense environment it is time to adopt Wave 3 processes that can rapidly deliver future capability while reducing sustainment costs.

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

35 Responses to DoD can’t get to wave 3 using wave 2 processes!!!

  1. Dan says:

    Some fear it will take a Tsunami-like wave to bring about the proper level of “participation” in acquisition change, even within the framework of current DoD 5000. Since there is no Tsunami wave, we have an OPPORTUNITY here to be proactive, rather than wait and react. Nice article. D

    • Marv Langston says:

      Good thought Dan but we really are in a “National security Tsunami.” When our enemies and economic competitors can use the vast amount of commercial and military information against us, and without the wave 2 processes that keep one hand behind our backs, we don’t have the needed ability to pace the threat…

  2. John Weiler says:

    Marv,

    Again, you have hit the nail on the head. The question is now what steps DoD must take to overcome this persistent inability to leverage innovative solutions of the market or be able to establish a more open and adaptive IT Acquisition process. Having spent the last 10 years examining the root causes of failure, including a review of just about every GAO, DSB and think tank report on this issue, here is what the evidence suggests;
    1) DoD over relies on its FFRDCs (DSB 97) for IT programs, an area they are not structured to be effective. DSB concluded (Gordon England) the lack of competitive pressures has eliminated their ability to be efficient or effective, becoming an impediment vs an enabler.
    2) DoD’s MilSpec acquisition, architecture and analytical processes (DODAF, DOD5000, JCIDS, AoA) were designed for weapon systems stove pipes with 20 year life cycles. BTA’s Business Enterprise Architecture and limited adaptation of the 5000 called BCL, has proven that these WS approaches do not work for business systems or IT. Why else would it take four years and nearly a Billion dollars to develop just an architecture, which by the way has still yet to be used to help deliver an IT program on time or on budget. The good news is that the DBSAE has abandoned the status quo in creating its new Capability Assessment Method (CAM), without the traditional NIH mentality. Mr. Seaman took a “best practices” approach by leveraging existing innovations and non-traditional suppliers to deliver and validate his new process as less than 1% of the cost of updating the DoDAF. I am sure his peers will not be happy by the stark comparison.
    3) Like Marv said, Top Down approaches do not work without a bottom view of the realm of the possible. However, this requires a conflict free research coop that is not compromised by self interest like the FFRDCs. DoD needs an organization with an inclusive structure that accommodates the small businesses, innovators and non-traditional suppliers. However, lacking real measures of effectiveness (MOEs) for PMs and Service Level Agreements (SLAs) for our suppliers, DoD will not be able to take advantage of the Wave 3 opportunities and remain in Wave 1.
    4) Congress has seen the un-ending patterns of failure and sound recommendations of the recent Defense Science Board and BENS.org reports on the need for a new IT Acquisition Process. However, if we do not learn from our past failures or overcome the many Pentagon Rice Bowls, the resulting process with end up being a minor revision to the existing DoD5000, just like the BCL. Dr. Carter and Sec Lynn know the futility of trying to “fix todays problems with the same kind of thinking that got us their in the first place”. Hopefully, they will turn to the new IT Acquisition Advisory Council for some out of the box thinking. http://www.IT-ACC.org.
    5) OCI rules must be enforced to prevent contractors from gaming the process. The revolving door must also be close, along with the political process by which contracts are awarded. This will require a clean up of the past performance data base so that it reflects real contractor performance and the creation of enforceable Service Level Agreements that are based on real world best practices. As suggested by the 97 DSB report on FFRDCs, we need to use them as they were designed, and stop them from competing with the innovators of the market.
    6) Finally, the standards that DoD uses today for acquiring Weapon Systems DO NOT WORK in the fast paced IT market. A recent jointly sponsored Navy/OSD HA sponsored SOA Benchmarked Best Practices study documented patterns of failure and success within the world largest commercial enterprises. We documented multiple failures in the earlier adoptions of SOA (a Wave 3 enabler) of Citi, FedEx, GE, BofA, which appear to resemble the current SOA approaches being endorsed in DoD. However, the latter successes resulted in major savings and enterprise agility. These patterns of successes were visibly absent DOD’s preferred standards; CMMi, EVM, IDEF, or anything resembling DODAF, NESI, POPS, LISI, and other MilSpec processes.

    If DoD is to get serious about achieving a rapid IT Acquisition process that delivers IT solutions as the speed of need (critical to NetCentric, Cyber and Health IT missions), then it must do more than given lip service to the Clinger Cohen Act and the new NDAA directive. It must embrace the non-traditional suppliers and innovators who have proven to deliver. As Einstein would say if he were around today “insanity is continuing the same process over and over again and expecting different results”

    My two cents.

  3. Bob Gourley says:

    Marv,

    Thanks very much for the context. That puts things into a perspective that is compelling and I know at my core to be true.

    This piece also underscores the importance of legacy, and that injects another dilemma. I dont’ think the model can be to move from wave 2 to wave 3. Seems like Wave 1 and 2 will be with us a long long time and we need to make both better while disrupting things with wave 3. I think the challenge becomes: How do we bring in more of the new third wave while continuing to enhance the first and second wave systems?

    Like the chart on US Technology Adoption History shows, the things that are widely adopted are here with us for a long long time. Electricity, Radio, Television and even Phones will be with us long into the future. In DoD, mainframes, datacenters, command centers and a need for command support IT systems that deliver security (and non-repudiation) will also be with us long into the future.

    So maybe the answer is in optimizing all three waves?

    For Waves one and two the answer may be more CMMI, ITIL, Training, Education, and adherence to process like those taught by the Carnegie Mellon SEI.

    For Waves three and beyond I can’t pretend to know the answer, but of course I strongly support what you wrote above and I feel it is the way to go. But it may also have more to do with NSA’s Suite B encryption and the use of off the shelf commodity hardware/software bought for every member of DoD (or maybe they get an expense account to buy their own?).

    Anyway, I really appreciate your thoughts and vision and continued leadership.

    • Marv Langston says:

      Bob, you are making a good point that I was assuming away… The nice thing about the current SOA services technology, unlike all previous technology changes, is that we can adopt legacy functions along side new services and either keep the legacy running or phase it out over time. In fact this is a better solution than the ERP debacles that have been ongoing now since before the SOA middleware technologies appeared. The reason this works better than ERP is that phasing in new services along side legacy doesn’t require the demanding changes to the external systems required by most ERP conversions. Because DoD has distributed funding, causing the external systems to change in response to ERP needs is a failure path that is winning. So I am really saying that we can adopt new processes for wave 3 that account for legacy sustainment along side wave 3 innovation.

  4. Scott Heller says:

    Marv,

    Recommend asking a slightly different question. How can we enable rapid capability enhancements within the existing DoD system (JCIDS, PPBE, etc…)? A proven assumption is that we will not change the DoD acquisition process to any significant degree in the near term.

    Two basic steps could start us down the right path with out changing DoD acquisition processes.

    1) Leave room to grow when authoring JCIDS. In the vectors we wish to improve in over time, leave a gap between threshold and objective values. An objective should be a dramatic leap forward. The threshold should be what we can live with today given the current state of a rapidly maturing technology base. Many JCIDS documents un-necessarily tie the hands of future program managers 5+ years down the road in delivering desired enhancements to the war fighters.

    2) Set aside dollars for growth. An executability review should require R&D funding throughout the life of a program in order to support the use of our systems in ways that were not even thought of prior to fielding. Our engineers and war fighters are wildly creative individuals, but can only deliver new capability with dollars set aside to enable them. Creativity doesn’t requires vast sums, in fact it often flows from a constrained environment, but new capability does require funding engineering labor and war fighter dialog.

    There are many other obstacles, but lets not let a lack of imagination and funding prohibit highly motivated engineers and sailors from solving tomorrows challenges.

    Thank you for the dialog!

    • Marv Langston says:

      Scott, I like your points and agree that we could and should do some of that. A point made in earlier blog posts is that DODD 5000 allows for as much tailoring as we care to allow for ourselves. A good case in point is the ASW ARCI (advanced Rapid COTS Insertion) program where they do develop to an over arching requirement through iterative development and fielding. And the the ARCI program has been held up as a success story for a decade now…

  5. Dan Green says:

    Marv,
    Thanks for binning the trends in a way that allows us to communicate more strategically about current technological opportunities and challenges. As engineers, we tend to drill rapidly into details that leave many senior decision makers gasping for air before decision points, or even options, are articulated properly. Wave 3 is a good perspective to frame our technical discussions for all our decision makers whether they be policy, resource, requirements, acquisition, or operations focused.
    DanG

    • Marv Langston says:

      Dan, you are correct. We all have a tendency to focus on the details that need to get implemented while our decision makers remain lost in the bigger political and budget challenges that are much more easily discussed if the subject is an aircraft or ship.

  6. Rex Buddenberg says:

    Marv,

    It’s important to disentangle symptoms and underlying problems. I’d regard DoD5000 defects as symptoms (and quite easily remedied ones).

    We’ve been having a local debate on ‘systems’ thinking and the root is ‘just what is a system’. If you think ‘platform’ (like cruiser, fighter, tank) you’re not wrong. But vis current IT issues, wide of the target — almost all our core problems have to do with the integration of multiple platforms. An information system may have sensors on one platform, the decision support on another, and the actors on yet more — so cross-platform, cross-program, cross-service and cross-ally is the name of the game. The symptom is obvious: the acquisition process isn’t suitable for this.

    And cross-whatever integration cannot be done on a bottom-up, one-off basis. We have to go for the large information system generalized interoperability (and security) approach. This has a number of subtle and powerful implications. A couple:
    – all the Bad Guys are now insiders on the internet. Get over it. Infrastructure protection security measures don’t work…. like raising the drawbridge too late.
    – comms systems, especially, cannot be left in their own stovepipe. Indeed nothing can, but the $B comms programs are the schwerepunkt.
    – each PM cannot be an empire unto own which is what current 5000 mandates (and John describes nicely).
    – a symptom. DoDInst 5000.2 requires certain DODAF views of a PM. One of these is the TV2 — the glossary. So every PM cooks one. But no two are alike … read the various definitions of ‘waveform’ inthe various glossaries. After you’re done laughing, consider the implications. After you’re done crying, think what we ought to be doing … and simply fixing the glossaries won’t solve the problem — only cures a symptom.

    If you wish to start with DOD 5000 (I think that’s where you should end up, not start), then here’s what is needed:
    – at a level ABOVE the PMs, DoD needs to state a modularization model.
    – the modularization model can be stated astonishingly concisely:
    o all communications programs come in the form of routable networks.
    o all end systems attach to the resultant internet. The schwerepunkt in here is a security principle: no end system emits data onto the internet that is not protected and the corollary that no end system accepts data that is not protected.

    Notes. ‘all comms programs’ obviously includes the overt ones like JTRS and MUOS. But it also includes those embedded in platform programs — like the ‘data link’ components within aircraft programs and Navy cruisers. ‘Protected’ _always_ means with a digital signature for authenticity attached. And _sometimes_ with data encryption, depending.

    The JCIDS process was supposed to amalgamate and homogenize requirements, but I have not seen that happen. Some quick pen-and-ink surgery here, in parallel to the 5000 stuff above, would clear a lot up. Again, the comms programs should all be routable networks. If the requirements statements in JCIDS all were structured like:
    – ‘extend the internet’ is an invariant in all.
    – the following prepositional phrase is the variable, examples:
    o with satellite comms
    o to this or that set of points of presence
    o with this or that technology
    o for this program
    Expressing commander’s intent vis the end systems is a little harder (in my mind, at least), but it’s also a secondary problem — if you get the ‘extend internet’ out front and center, the PMs are supposed to get the idea that they should use it.

    I’d complement John’s observations with this:
    Most formal programs of record in the IT business in govt (not just DoD, btw) tend to be disasters. They’re worse in DoD because the $ figures are higher and it’s harder to kill off a turkey. And we do neither autopsies nor interments very well if at all.
    By contrast, most of the successful programs are stealth ones … at least at inception. For the rest of the readers, Marv has personal experience hatching one. … will cost you a beer to get the seastory.

    While the Wave2/Wave3 observation has merit (and I agree with much of the narrative), it lacks some of the power that I think is there. Scratching a little deeper, … what makes the curve S-shaped? Try this hypothesis on a few of them: somewhere on the flat part of the S we pass the gee-whiz stage and get to the real scale problems. And they all root back to interchangeable parts. Telephone and electrical are two examples on Marv’s chart where interchangeable parts (agreements on Hz, bandwidths, voltages …) are critical to the scale-up. None of our DoD programs are designed to produce interchangeable parts. Without that objective, we’re forever locked into the stovepipes (the routable network principle statement above is exactly pursuing this interchangeable parts goal).
    What should NOT get into the soup. Pursuit of interchangeable parts does not require the Heap Big Program. Indeed, an explicit pursuit of interchangeable parts would allow the IT programs in DoD to pursue divisions of labor that would control both cost and risk. And a good modularization model, while the root of interoperability, is also the root of life cycle maintainability.

    • Marv Langston says:

      Good points as always Rex. The issue for me has been that unlike platforms which can be built as systems, in the end they are individual platforms even if they operate as integrated forces. The point you make about the standards that help speed things up is correct and it follows technology maturity as you suggest. The important point is the commercial folks are innovating and standardizing much faster than DoD because we can’t get over the hump of fighting for and sustaining funding in an area with the result that our infrastructures are vastly inferior to the commercial practices that we are now following…

  7. HR 2647 was signed by the President and became Public Law 11-84 on October 28, 2009.
    The Law Authorizes the Secretary to designate up to ten information technology (IT) programs annually to be included in a demonstration of an alternative acquisition process for rapidly acquiring IT capabilities. Prohibits entering into any contract for acquiring an IT system using such authority unless funds for the full cost of such system are obligated or expended in the fiscal year of system delivery. Requires an annual report from the Secretary to the defense and appropriations committees on the use of such authority.

    QUESTIONS:

    1. Out of the $34.8 billion of FY11 projected spending which program would you pick to implement with an alternative acquisition process, rapidly ?
    2. How would you stop an existing program and divert money to an alternative acquisition process so that prior commitments are met?
    3. What savings will you be able to deliver to display the superiority of the alternative acquisition process?
    4. Since the greatest short term savings (60-70%) and less than a year break-even is now available from the mature virtualization technologies, how would you pick an alternative acquisition process to accomplish that on an existing project implementation?

    Cordially, Paul Strassmann, Distinguished Professor, George Mason University
    Center for Secure Information Systems

    • Marv Langston says:

      Paul, as I believe you and I would agree, the Navy NGEN would be a superb case for this new law (thanks for pointing that out). As we have discussed, with a better enterprise application structure such as you employed at NASA, I continue to believe that Navy could remove 50% of the annual cost of its current NMCI while improving performance, security, and user satisfaction. But that is a harder sell and the politics are enormous. An easier sell is to implement the high performance ashore ISR capability that I am suggesting as part of the MIEA {maritime ISR enterprise acquisitions) Review I am helping to lead.

  8. Chris Ward says:

    Marv,
    As always, you hit the nail on the head. The benefits to be gained from moving towards WAVE 3 are compelling, and in most (not all) circumstances, I think this transition is essential. The real crime about NECC is that good people had good vision and worked hard and didn’t succeed. If we could enable the success of these smart folks by adopting some of the changes that you outline above, I think we would all be better off.

    • Marv Langston says:

      Amen… at a time when the US is graduating less engineers than our competitors, we cannot afford to slow down progress and train engineers to be finesse oversight bureaucrats rather than solving high performance data sets..

  9. Marv Langston says:

    From Michael Davis

    All great points and we do need to update our acquisition processes to account for rapid technology insertion and COTS, etc… be that wave 3 or 2 .. as the other comments point out, legacy will be around for awhile, so that needs to be accommodated for years..

    **** Still, it’s ALL MUTE if the security is not built in, as we’ll loose the cyber war (see the recent 60 minutes interview… as we’re under attack NOW… CBS presentation on Cyber Terrorism. http://blogs.zdnet.com/security/?p=4865 )

    As I’ve done “IA” for some time (oops – now we call that “dynamic cyber defense”….;-(( I can tell you our “cyber” status is BAD… we’re way too vulnerable almost everywhere… physically and technically and socially..
    We need to get a maximally effective cyber security approach moving – we suggest five major thrusts:
    (1) Enterprise IA/cyber strategy, based on Joint staff IA/Cyber CONOPS/NETOPS, with measurable requirements and KPPs, determine what is “good enough” security
    (2) Enterprise risk assessment (ERA) that takes threat vectors AND vulnerability consequences into account and weights their impacts into a prioritized risk set.
    (3) Prioritize enterprise level mitigations to best effectively and affordably address the most damaging risks identified in the ERA, complementing the GCMP and CNCI 12 initiatives and leveraging NSA IA/CND/CDS.
    (4) Address the pervasive lack of basic IA/security hygiene and core foundations enterprise wide – as the lack of enforceable “CM” is our most virulent vulnerability by an order of magnitude. The key IA hygiene or core improvements include:
    (a) institutionalizing enforceable “CM”, leveraging the “SCAP”;
    (b) encapsulating the intractable supply chain security issues with configurable mitigations;
    (c) improving situational awareness (SA) at all decision levels;
    (d) developing an IA enterprise architecture (EA) with a definitive “trust model” and effective cross domain access control,
    (e) using a limited set of IA building blocks with C&A pedigrees
    (5) Add new IA “encapsulation and messaging” capabilities on top of existing IA/CND elements to support a secure net-centric automated environment.
    We have a OSD SBIR report, several papers, and other artifacts to back up our positions – I will send to whomever wants them

    • Marv Langston says:

      Michael, I fully agree but haven’t gotten around to working the security issues because we are so broken for building anything in a timely fashion. With the focus now on security our wave 2 security certification processes are taking 33% of our development time which is already too long. Because we can’t catch up to building useful enterprises that we could secure better, we treat each component of development as a free standing security challenge…

  10. Marv, I agree with you. In fact , as you know, I’m working on (….and am blogging about… at thecogblog… http://www.w2cog.org) tools that will help folks co-opt the existing 5000/8500/JCIDS process according to your argument.

    I find Clay Christensen’s treatment of the “s-curve” argument in Innovator’s Dilemma and Innovator’s Solution compelling. He makes the same observations you do about the progression of successive technology s-curves. However, he also proposes means to engineer “disruptive” changes through shrewd deployment of the new s-curves. He discusses “disruptive technology” in that context.

    In his argument, the “disruption” has nothing to do with the technology itself. It has everything to do with the sea changes in cultural behavior that the new technology wave catalyzes. He concludes that — in almost every case — the disruption occurs because a frustrated community is under-served by the status quo. The new technology makes it cheaper or more convenient for the under-served community to get some thing they value, but couldn’t get before. The under-served community is perfectly willing to accept a lesser variant of the thing. For example, poor people were happy to buy cheap, solid state, TV’s with lousy picture quality at discount stores. After all, they could not afford RCA floor models sold at high-end department stores, but they enjoyed watching TV programs…even if fuzzy. Pretty soon, transistors ruled and vacuum tubes were tubed… This change in behavior had nothing to do with the cool technology represented by solid-state electronic. It had everything to do with a business model that targeted the low end of the market.

    It seems to me that we have to figure out how to use the new cool Wave 3 technology s-curves to catalyze the new defense community behavior changes we need. First we have to find our under-served community at the low end of the defense market. That won’t be a giant program managed by a huge defense integrator. We’ve got to find a small program — or subset of a larger program — that is not vested in any particular status quo. Then we’ve got to make it less painful for them to do their jobs by engaging in the new behaviors we advocate. (This the part I’m working on… turning KPPs and certifications into pragmatic “consumer reports” COTS logos) We’ll make it clear that the “thing” they want at work is already readily available to them at home on the Internet, i.e. Wave 3 technology. The behavior “change” we advocate is that they don’t have to change their behavior when they go to work. It is not only appropriate, but also essential, that they take their Internet social behavior to work with them.

    • Marv Langston says:

      Chris, great points and I like the idea that we should do more to help move us up the adoption wave 3 curve in order to improve the needed IT agility across the DoD. Let’s figure out how to make that happen. I think “data as infrastructure” and the inherent layered earth visualization of that data could be one of the keys to that acceleration as was done with the Virtual Alabama transformation.

  11. Joe Mazzafro says:

    Marv,

    This is even more important than it is fascinating to read. You won’t be surprised I fully associated myself with Brother Gourley’s comments.

    Said less eloquently, I fear we have gotten as far as we have because IT Waves 1 and 2 are that far afield from the industrail age acquisition processes DoD has honed into near bureaucratic perfection. Its easy to say but hard to do to say DoD should just emulate the private sector’s best practives for developing and implementing innovative IT.

    What might work though is treating IT in DoD and IC as a protype proposition where DARPA and the FFRDC’s lead the innovation actions and the A&TL entities in DoD, the Combat Support Agencies and the services pick what they need contract with successful IT integrators/implementator to get them delivered.

    As Bob implies expecting DoD to heal itself is an unrealistic expectation

    Great blog post as usual! Thanks Marv joemaz

  12. Katherine L. Morse says:

    I’m a little surprised the discussion hasn’t drawn more associations with workforce issues, although Marv’s original observation “Application functions developed as iterative software development activity (generally built with ‘agile’ 30 day development cycles)” and Chris Ward’s comment about good people came close. For many years, I have had the pleasure of working with really intelligent, capable, energetic engineers right out of college. Go have a beer with them and they’ll tell you how frustrated they are that they could have deployed a working prototype in the time it took the DoDAF crowd to agree on an OV-1 (that looks like every other OV-1 we have all seen…think land/see/air, lightning bolts for communications, and several megabytes of PowerPoint)…and for less money. Even if it’s not quite right, we’d still be further ahead than we are with nothing but briefings. They get frustrated; they leave; the pipeline of people with the capability to solve this problem dries up. They are Wave 3 and we should be listening to them.

    • Marv Langston says:

      Katherine M, thanks for pointing out the disastrous impacts our bureaucratic activity has had on the key players in the workforce. Another reason for turning capability in useful time cycles. marv

  13. Kevin Jordan says:

    Marv,

    You make a compelling case for abandoning the lock-step procurement processes associated with waves 1 and 2. My concern is that these bureaucratic processes leave us increasingly vulnerable to cyber adversaries who demonstrate the agility and ingenuity to employ available cyber technology in new ways. Delay in implementing cyber defense-in-depth concepts leaves us vulnerable to an orthogonal attack that comes at us from “left field.” I use the term orthogonal instead of asymetrical because I want to emphasize that the concern is not with some sort of annoying viral pin prick that keeps us busy for a few days, but rather a cyber blitzkreig that goes straight at a vital center of gravity with blinding speed and devastating impact. After all, Guderian’s blitzkrieg concept was the result of combining armor and aircraft with integrating potential of netted radio in a new way that emphasized mass, unity of command, surpprise, and the shock value of offensive. The stunning thing about it is that the technology that comprized blitzkrieg was available for some time before Guderian figured out how to employ. I think the cyber technology is available today to deliver the orthogonal blow. Our challenge is to figure out how to defend against it. Perimeter defense, the digital equivalent of the Maginot Line, is certainly not the answer. Defense-in-depth based on agile interior boundaries just might be.

  14. Rex Buddenberg says:

    JoeMaz:
    “What might work though is treating IT in DoD and IC as a protype proposition where DARPA and the FFRDC’s lead the innovation actions”
    John Weilor:
    “research coop that is not compromised by self interest like the FFRDCs. ”

    Believe that you have fingers on a symptom (and accurate as far as that goes). But haven’t gotten to the root.

    The FFRDCs … and a whole lot of the R&D budget … is devoted to ‘S&T’ — science and technology. Our problems in getting things like ‘systems of systems’ to be something more than a figment do not require technology that we don’t already have. What they require is the organization of that technology (see the modularity comments in previous post).

  15. Rex Buddenberg says:

    Paul posted:

    ten information technology (IT) programs annually

    and

    1. Out of the $34.8 billion of FY11 projected spending which program would you pick to implement with an alternative acquisition process, rapidly ?
    2. How would you stop an existing program and divert money to an alternative acquisition process so that prior commitments are met?
    3. What savings will you be able to deliver to display the superiority of the alternative acquisition process?
    4. Since the greatest short term savings (60-70%) and less than a year break-even is now available from the mature virtualization technologies, how would you pick an alternative acquisition process to accomplish that on an existing project implementation?

    Now repeated with comments in line:

    1. Out of the $34.8 billion of FY11 projected spending which program would you pick to implement with an alternative acquisition process, rapidly ?

    Here we have a severe definitional problem. Does a satellite communications program (such as MUOS) qualify as an ‘IT system’? How about the sensors, communications networks and computers in the Aegis combat system? How about the ‘data links’ embedded in aircraft programs?
    I’m suspecting that I’m seeing in the question the artificial division between ‘combat’ and ‘business’ here.

    That said, think of the large information system that we need to construct a bit like Maslow’s hierarchy. We’d like to do ‘SOA things’ … publish/subscribe and so on. But that’s at the peak of the triangle.
    A layer down is the other 85% of the software (almost always in the decision node in information systems, the controversy never occurs in the sensors or actors). This is the area where we no longer have any business reinventing — we should have had this all on maintenance diet a quarter century ago and off of the reinvention diet (this is where the power of open source exists).

    2. How would you stop an existing program and divert money to an alternative acquisition process so that prior commitments are met?
    3. What savings will you be able to deliver to display the superiority of the alternative acquisition process?
    4. Since the greatest short term savings (60-70%) and less than a year break-even is now available from the mature virtualization technologies, how would you pick an alternative acquisition process to accomplish that on an existing project implementation?

  16. Rex Buddenberg says:

    Continuing (this thing went and self-mashed the post button too soon. the break is after ‘open source exists). The primary security principle belongs here: no end system emits data onto the internet that isn’t protected; corollary — no end system accepts data that isn’t protected.
    The bottom layer in the triangle is to get the network plumbing right. The short principle is that all comms needs to be in the form of routable networks.

    Observe that the network has to be there for the rest of the pyramid to be anything but moot. So Paul, the direct answer to your question is to grab a few (probably less than a half dozen) comms programs and impose ‘routable network’ on them. This does not require any technology that doesn’t exist. (reprise of the definitional problem — was the GIG-BE program one of the select ‘IT programs’ or outside of that count?)

    ‘2. How would you stop an existing program and divert money to an alternative acquisition process so that prior commitments are met?

    There seem to be two methods to do this. Neither of which consist of outright killing a program. DoD never holds interments and never holds autopsies, it seems.
    1) The Husk. Some programs continue to exist out there, but the budget has been drained away. You can usually find the evidence in GAO reports where ‘mismanagement’ has resulted in the program ‘not ready for production’ so the Milestone 2/3 money gets redirected. JTRS seems headed down this road, following Ada and GOSIP … and totally impervious to solution #2. The bad side effect of this approach is that the formal program usually holds some sort of monopoly position.
    2) The Fig Leaf. Some programs get an internal revolution while preserving the storefront. Army’s WIN-T seems to be doing this — it preserves the nameplate on the door but is substituting COTS-based comms inside the program for the defunct grey-box inventions that didn’t work out.

    But you really state a hard problem. Take one more step back for perspective. An awfully high percentage of formal IT programs (using my broader connotation) seem to be duds. By contrast, we seem to do pretty well with stealth programs — stuff that slips in by conspiracy, usually among mid-grade officers, and just might get some legitimacy in the form of Program of Record … later. USMC’s WPPL program clearly falls in this category. Getting proper program support, particularly when it’s time to mature from straight-up COTS to adapt-from-COTS, is not easy.

    3. What savings will you be able to deliver to display the superiority of the alternative acquisition process?

    This is a difficult question to address directly. Because NO information system these days is cut from the whole cloth. Or at least shouldn’t be. But the question needs to be turned around — not just penny pinching, but what benefits are we bringing. We build warships to win wars, not save money. And we need to be building our information systems for the same reasons.

    4. Since the greatest short term savings (60-70%) and less than a year break-even is now available from the mature virtualization technologies, how would you pick an alternative acquisition process to accomplish that on an existing project implementation?

    Shift from an artisan or an industrial production model.

    Today all the comms programs (I see it incessantly in satcom programs) have to deliver some nifty application in order to justify existence. This means that the satcom program — which needs to be really good at getting operational comms satellites into orbit — has to divert resources to building applications. Something that is clearly out of specialty. None of the things we learned in 10th grade history lesson on Industrial Revolution seem to be applied to DoD information systems. This includes both procurement and operations.

  17. John Richardson says:

    Dr. Langston;
    Thank you for the very concise and well articulated issues associated with the current technology adoption trends plaguing the DoD. To paraphrase others here, “You have completely nailed it”!

    Our acquisition process is broken, or at the very least inept in its ability to correctly track and adapt to what can accurately be described as nothing less than a paradigm shift, not only in technology, but in policy, operations, application, and workflow. This situation produces a stifling affect on ingenuity which can be seen through a downward trend in technology transfer from the government starting in the mid 1970’s and still exists today. This trend has pushed the need for industry, mostly commercial industry, to take over this role outside the scope of the DoD which has produced astonishing effects upon us all, most notable, the information technology push of the 1990s. This push has affected us all at every level of our daily lives in how we think (process information), how we communicate (information transfer and speed), and how we operate (application of technology, business process engineering, and innovation).
    During the 1990s I worked in the commercial sector developing B2B technology. The initial adoption response by industry was very slow, while technology development remained very high. It was only through education that we were able to turn the adoption curve upward. It was not only a lack of understanding the technology and its application, but also the flat ROI curve associated with this type of technology adoption, at least initially, that reduced adoption speed.

    Over the last 4 years I have been working to push Wave 3 technology adoption at the grass-roots level and many of the same artifacts represented during industry adoption are present here. The leading artifact, and one that may be directly associated with the acquisition process, is the ROI curve. The lack of a true support infrastructure plan and any ramp up strategy drives a sense of negative expectation onto the program managers who must decide how best to spend their limited funding to produce the “best bang for the buck”. Also confusing and often conflicting application strategies and goals produce a “wait and see” effect at the acquisition level, this can be seen with CANES and any potential adoption of CANES within NAVAIR, and this is mostly due to a complete lack of understanding of what CANES represents and its application to address a specific problem space, I refer to this has the SOA in a box syndrome or living in a Black Box world.

    I could go on and on, but I would like to thank you for taking the lead here in expressing these issues and all the frustration that goes with it.

    • Marv Langston says:

      John R, good points on the ROI issue. The problem I have seen over and over in our DoD world is that ROI is never really measured so all ROI discussions become esoteric. When someone does provide ROI estimates the comptroller system takes the savings from the budget up front and then we fail to build the support infrastructure associated with the ROI estimates. Case in point is that CANES has been under budget attack again this year. We just have no way to tie in the potential IT agility and what that would mean with the cost of ashore or afloat infrastructure. If you can help come up with a better way to work this through our system I would love to know the answer. marv

  18. Pingback: If We Can Put a Man on the Moon: Getting Big Things Done In Government | CTOvision.com

  19. Kurt Rothenhaus says:

    Marv,
    Interesting post. I think one of our fundamental challenges is the layers of “process” between the software problem we are trying to solve and the developer to solve them. I think ubiquitous computing or cloud computing in the DoD will be enabled by a renaissance in the SPAWAR or government labs. Small focused developers with strong domain area expertise in a campus like environment delivering small targeted software services is perhaps a better model than farming challenges out to industry. We could create “trusted developers” with proven track records to “fast track” services to the fleet.
    V/R
    Kurt

    • Marv Langston says:

      Kurt, one of the biggest obstacles I hear people cite against the idea of iterative IT development is the contract process. I find that bogus because using multi-award task order contracts and bundling work activity onto those tasks can allow this development work to be effective and efficient. What we lack is the certification processes to validate that applications will play well with the infrastructure and oh by the way, we do need to build the infrastructure:-) marv

  20. Kurt Rothenhaus says:

    Marv,
    Terrific topic! I think this next stage of system development will see a renaissance of the government labs for software application development (if permitted). Some of the best products in industry come from small empowered developers with significant domain experience as the technical barrier of entrance lowers with improved development environments. I’m not advocating that all development be limited to a lab, however it seems that small focused applications for rapid insertion are ideal for small two/three person developer groups operating in a campus like environment. An interesting note, when engineers visit TRUMAN today from industry or government never one of them had the ability/authority/inclination to make any changes in the system code. Due to all the process, gates and institutional inertia even the most simple and obvious solutions are piled in the ever eternal “next build.”
    Thanks.
    V.R
    Kurt

  21. Andy Bentley says:

    One other aspect of the acquisition process that is broken IMO, is that contractors have historically build a system for one program, then gotten paid again and again to build the same/similar system for other programs. There is little incentive for contractors to build re-usable components or services that could be used by many programs. This is especially true for SOA, and hence the slow adoption. Contractors will build services and claim inter-operability but usually inject proprietary or non-interoperable technologies to ensure vendor lock in. IMO any system that is build to have a SOA like service interface should either have a pay-per-use payment model or have the interfaces and standards strictly defined. The hard part about strictly defining the interfaces in complex system is in leaving no wiggle room anywhere; which take a long time to spec out. The pay-for-use payment model would greatly incentivize contractors to build re-usable services. Getting the granularity of the services right is hard and getting the paymet dollar number per capability is hard. The right balance needs to be wrought to ensure that contractors dont build thousands on micro services that get called hundereds of times to increase the payments.

  22. fastforward says:

    Hello,

    I really like the Technology Adoption Curve chart. Realizing that this was a forward thinking analysis from 5 to 6 years ago, I’m curious about the next wave. By the time intervals on the chart, it would seem the 4th wave would be germinating right about now. What is it? Thanks

Leave a Reply

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