… acquisition productivity is at an all time low for command and control and information systems…
Warfare has always been a tactical activity designed to coordinate large groups of people and weaponry to better the opposing forces. Those who win do so using superior warfare operations built upon advanced knowledge of enemy location, tactics, weapons, and plans. Such knowledge is obtained through forward sensors or scouts able to accommodate the commanders needs and communicate obtained information back to the commander in sufficient time to make a difference; i.e. Command and Control (C2) the battlefield.
Modern command and control remains dependent upon best knowledge of the opponents location, tactics, weapons, and plans, now supported by an elaborate array of remote and local sensors tied together with communications used to quickly move and evaluate sensed information. Through computer automation we are able to store, analyze, and display information designed to augment the commanders knowledge, and hence advantage, before and in time of battle.
…The problem is that our enemies have access to the same commercial information technology used within the DoD. If they become agile with this technology, our operating forces could be at a disadvantage despite our Country’s confidence that our high technology weapon our high technology weapon systems will always prevail.
Today’s information technology is dominated by the convergence of:
- Very dense integrated circuit chips;
- Packet switched communication networks; and,
- High speed computation in small physical packages.
The application of this technology has shifted the source for the bulk of command and control system technology from DoD “created” to “adoption” of commercial systems and software packages. Our current and future command and control system capabilities fall short of commanders needs because the complex DoD acquisition system has not adequately adapted to pace commercial technology advances and best practices, despite bureaucratic proclamations to the contrary.
DoD Directive 5000 is the policy “bible” for acquiring material systems and infrastructure for the Department which is designed to provide timely systems by definition.
“3.1. The Defense Acquisition System is the management process by which the Department of Defense provides effective, affordable, and timely systems to the users.”
According to DoDD 5000, five key areas describe the primary policies that govern the Defense acquisition system:
“4.3. The following policies shall govern the Defense Acquisition System:
4.3.1. Flexibility. There is no one best way to structure an acquisition program to accomplish the objective of the Defense Acquisition System. MDAs [milestone decision authority] and PMs [program managers] shall tailor program strategies and oversight, including documentation of program information, acquisition phases, the timing and scope of decision reviews, and decision levels, to fit the particular conditions of that program, consistent with applicable laws and regulations and the time-sensitivity of the capability need.
4.3.2. Responsiveness. Advanced technology shall be integrated into producible systems and deployed in the shortest time practicable. Approved, time-phased capability needs matched with available technology and resources enable evolutionary acquisition strategies. Evolutionary acquisition strategies are the preferred approach to satisfying operational needs. Spiral development is the preferred process for executing such strategies.
4.3.3. Innovation. Throughout the Department of Defense, acquisition professionals shall continuously develop and implement initiatives to streamline and improve the Defense Acquisition System. MDAs and PMs shall examine and, as appropriate, adopt innovative practices (including best commercial practices and electronic business solutions) that reduce cycle time and cost, and encourage teamwork.
4.3.4. Discipline. PMs shall manage programs consistent with statute and the regulatory requirements specified in this Directive and in reference (b). Every PM shall establish program goals for the minimum number of cost, schedule, and performance parameters that describe the program over its life cycle. Approved program baseline parameters shall serve as control objectives. PMs shall identify deviations from approved acquisition program baseline parameters and exit criteria.
4.3.5. Streamlined and Effective Management. Responsibility for the acquisition of systems shall be decentralized to the maximum extent practicable. The MDA shall provide a single individual with sufficient authority to accomplish MDA-approved program objectives for development, production, and sustainment. The MDA shall ensure accountability and maximize credibility in cost, schedule, and performance reporting.”
Given the millions of professionals from both within the DoD and from across the contractor community struggling to provide effective command & control and information systems for the DoD, one has to wonder what has become of the policy to provide “effective, affordable, and timely systems to the users.” Even more intriguing is what has become of the five strategic policies of flexibility, responsiveness, innovation, discipline, and streamlined and effective management. For information based systems characterized as “software intensive,” it is even more curious where the notion of evolution and best commercial practices has gotten lost.
The answer lies in the bureaucratic creep of the thousands of well intentioned military, civil service, and political appointed personnel engaged in the acquisition practice of “program oversight” which is designed to prevent program failures and the misuse of taxpayer revenue. If one could easily count up the number of people engaged in program oversight in software intensive C2 or information system programs relative to the number of people actually creating software and supporting system infrastructure, it would be easy to see that we are operating from the upside down triangle approach to resource allocation. That is, we have far more people engaged in program oversight than we have actually writing computer programs and assembling system capability.
If this were only about effectively spending tax payer dollars and delaying command & control capability to the war fighters it would not be as serious. The problem is that our enemies have access to the same commercial information technology used within the DoD. If they become agile with this technology, our operating forces could be at a disadvantage despite our Country’s confidence that our high technology weapon systems will always prevail.
- Today’s military warfare commanders and business leaders share a common need
- Both must dynamically access the environment and create an effective response
- Rapidly evolving information technology provides the basis for assessment of the environment and coordinating the organizations response
- Success for both is tightly coupled to the effectiveness of their information systems and the related obtained knowledge
- Those that adapt to the changing environment succeeded over those that fail to adapt
- Our Nations’ risk adverse military acquisition system is strangling military information systems and jeopardizing our over tasked military commanders
In an attempt to mitigate the maximum amount of risk as possible, we have created an acquiisition system rife with oversight layers and required stakeholder inputs. With respect to C2, never before in the history of warfare have our adversaries had access to simimlar technologies. We must maintain a technological edge but to do this we also need speed in acquisition, or we will face fog of war consequences.
Chris, great point about the use of COTS which adds the advantage of using rapidly evolving technology but playing on a level field with our adversaries. We do not know how to accommodate this condition and have not spent adequate time trying to sort it out.
As noted we have increased oversight and input from numerous stakeholders that limits the ability of any Agency to effectively meet the tenants of “better, faster, and cheaper.” Unfortunately many of our adversaries do not have the U.S. political structure in place that focuses more on how many jobs and how much money does a project deliver to a particular constituency then how much required and immediate capability does it deliver to the warfighter.
One only has to read the recent articles about the ability or lack thereof by Defense Secretary Robert Gates to effectively review, limit, and in some cases cancel large defense programs with significant cost, schedule, and performance issues.
Marv – Until JFCOM embraces title 10 authority (much like SOCOM has) and starts building joint C2 systrems (with their own funding stream) from the ground up, we will continue to be sub optimized in joint C2.
It might be well to consider two factors: 1) vulnerability of using software and firmware products that have been developed in environments the U.S. DoD doesn’t have insight into and can’t control (Supply Chain Vulerability), and 2) the importance of thinking about how to use COTS (what warfighting processes will use Service Oriented Architecture (SOA) components, for example, and to what extent will SOA components need to have deteriminstic-deadline performance for some warfighting functions, for another example).
Thanks for starting this blog, Marv, I think it will be very useful!
“Even more intriguing is what has become of the five strategic policies of flexibility, responsiveness, innovation, discipline, and streamlined and effective management.”
We have been hear before, and have developed and implemented approaches in the past to respond to deliver. After Desert Storm the Navy was required to make drammatic changes to it IT infrastructure, Navy required more SATCOM bandwidth, we needed modern networks (e.g. IT21). We met this challenge through challenging our leadership to allow us by-pass the bureaucrats, and found folks that were willing to manage the risk of implementing change across the Navy. Not just new systems & technology, but new tactics, training and procedures.
What you write is correct, but IMHO, not complete:
– the acquisition system is geared to producing platforms (tanks, planes, ships, etc) but not information systems that hang them together. cross-platform interoperability.
– most programs don’t produce any interchangeable parts, at least not in the C2 area. We’ve been building firearms with interchangeable parts since Eli Whitney, but we’re not doing same in the IT business.
– we seem to not learn very effectively from our failures. The IT landscape in DoD is littered with multi $M failures …. yet we never seem to hold autopsies or burials.
– no two programs are modularized the same way. Each program is required to do it’s own modularization … and then we wonder why we don’t have any interoperability.
– the language we use is very sloppy. As an example, pick a handful of DoN CIO and DoD CIO instructions. And a handful of programs (that are also required to produce glossaries) … and compare them. A particularly entertaining one is the n+1 different definitions of ‘waveform’.
– the sloppy language, egregious in itself, is only a symptom of the larger non-modularity problem.
… how many pages do you have here;-)
All good points. I think it is because software is deemed to be too complex for policy and management to impact it with modularity requirements. Like guns, the primary enabler of the information age is the integrated circuit chip. Had they not modularized we would be back to 1959. Services Oriented Architecture is trying to move in the right direction but is just the newest technology in a long line of attempts to change this paradigm. But I do actually hold out more promise for SOA. I believe it is closer to the 3rd wave of computing paradigms following main frames, then client-server systems.
Roger on the integrated chip. But if you buy the Eli Whitney analogy, that would be looking at the firearms interchangeable parts problem from the aspect of screws with common threads.
Our problem is not to employ chips; it’s to build information systems. And ones with interchangeable parts.
The analogy I use is to look at your own information system — your nervous system. You have sense, decide and act functions which are readily identifiable (and studied in biology class as separate organs … aka modules). And you have the neurons that hang all together.
The smaller version of the problem is to build complete information systems. I see a whole lot of programs and wannabes that only have one part of the information system (e.g. the decision support node). The larger version is two complete information systems that need to be interoperable with each other.
One warning that I take from our ‘acquisition reform’ history is that we’ve sallied forth to change the bureaucracy … without much idea of what the objective is. And we all know the result we get from that. It’s critically important that we have a clear objective: interchangeable parts and cross-program interoperability and information system modularity. And some good idea how to get that. THEN we can tinker with the bureaucracy productively.
Great discussions, I remember through acquisition reform era….the government agencies especially DoD tried to become more like the private sectors…actually I remember we changed everything including terminologies, to match industries practices, I think that is all that we have accomplished, the true acquisition reform has not happened yet.
I also believe that in order for either the private or public organizations to succeed in any acquisition is to modularize, development and implementations. Our private companies don’t have all necessary expertise in one place and neither our Government organizations.
Another element missing from today’s acquisition processes is simplicity (I think it should be added as the sixth element). Our enemies are using their imagination and simplicity to meet their objectives. We need to develop processes to make life simpler, and to be measurable against some specific objective.
The basic problem is the culture of the entire acquisition system. If we ever hope to acheive true Network Centricity with Network aware Applications we are going to have to learn to trust our “peers” and be willing to share some operational “control”. Both of these needs are the antithesis of Military Communications. Secondly, we are going to have to learn to truly “Crawl, Walk, Run” instead of our normal acquisition mindset to make EVERYONE happy and met EVERY requirement. We need reliaable, assured 80% solutions in 12 months not 99% solutions in 6 years plus 24-36 months of slips with 75% cost growth. We need to solve one or two requirements at a time so that we can actually solve the need not just put window dressing on the problem.
Bruce, I think we will need to distinguish between different types of IT. Building services applications upon a GIG network riding SOA services will be different than adding capability to the GIG network infrastructure. We will need a identifiable process that meets your short time lines for each. We also need to spread common architectures that facilitate speedy improvement cycles pushed out across the DoD rather than left up to individual Service or agency components.
You are right on target. I
All information systems are made up of the same four Greek elements:
I. end systems that attach to the network. These include
B. decision nodes
II. the network that connects all the I. parts up.
That’s it. Complexity can be explained by nesting and chaining of the same four elements. Look at your own nervous system as an illustration.
Your point about ‘different types of IT’. The applications live in the end systems — what kind of sensors? What decision support tools we build? But the internetwork is invariant — it hauls bits between the end systems … and is (should be) agnostic about what the bits represent. Therefore, we can modularize the ‘GIG infrastructure’ away from the end systems — it requires some constancy of purpose but doesn’t have a great deal of requirements volatility. By contrast, end systems change all the time, for both supply-side and demand-side reasons.
Herein you have the reason why GIG-BE was a successful program and NMCI was not. GIG-BE carefully separated out all the applications noise (over in NCES, for which the jury has not yet returned) and marched ahead with the upgrade of the terrestrial backbone. 3 years and the program is done. NMCI, on the other hand, is an artisan-based, vertical slice — a good case study in how to contract stovepipes.
Gotta quarrel with ‘common architectures’. First, knock off the ‘s’ — we need AN ARCHITECTURE. The proper definition for this grossly overloaded and poisoned term is ‘modularization model’. You need one model for the end systems that attach to the network and another for the internetwork itself … and that modularization model needs to be applied to all programs.
Right now, DoD 5000.2 requires each PM to cook a half dozen DODAF views. The only one that comes close to being a modularization model is SV1 (and you have to do some major definition disentangling to get there). As long as each PM cooks his own SV1 instead of dealing with a DoD-common one, then we continue to have multiple ‘architectures’ — no interoperability, no large information systems, no modularity.
Every four years we ‘reform the acquisition system’. This is the fourth year.
(and the administration is making all the right preparatory noises).
So, what date will the term ‘acquistion reform’ show up on the front page of a nationally respected paper (or news web page)?
I don’t think any acquisition reform will be successful unless we get the implementation/execution lined up with objectives and goals. Urgency does not exist in our processes today, therefore like a rubber band we keep going back to where we have started. I am always amazed on how history repeats itself but as human how little we learn or pay attention to it. I can’t get over the fact that during WWII, how we were able to build such a complex weapon systems in such a short period of time ….I call that acquisition reform, why can’t we duplicate that line of thinking again, by that I don’t mean to build more but build smarter.
I also do believe that our thinking and behavior is more geared toward Industrial era than Information era. Information is more accessible, collaboration is much easier, however using information still is challenging. The real reform needs to get us over this phase.
Thanks very much for writing and for moving thoughts forward here. This is a huge challenge for all of us. I really appreciate the way you capture the problem and look forward to more dialog here on possible solutions.
Cheers and v/r,
Great approach Marv! You need to get industry to buy in – we buy ships with networks that are at best 10 years old and when the ship is commissioned they can’t operate because either they are “different” or technology has moved on. The thought process of “buying” networks that are 10 years old when they’re delivered HAS TO CHANGE! Part of that change has to support buying “things” that are current and operable!
We are at the point in time when ships can be built as the carrying platform that they are. NAVSEA avoids this and the shipbuilders argue against it but the lack of flexibility delivered by the current methods will not sustain our needs going forward.
I’m not sure what I read, but I felt it had food for thought. Remember I’m 10 years older than you and the “little grey cells” don’t work like they once did.
Love ya anyway,
Thanks for stimulating the discussion.
A well founded and articulated strategy, aligned with the executing elements of the organization ( to include resources) are the key to success. Flat organizations requiring that there be a reason for each stop on the trail. Know the mission and how to support it. Have a chain of command that is short, and responsible.
Information age solutions, provided with industrial age methods… doing things the same exact way and expecting the outcome to be different can be defined as…. an acquisition career.
John, great point and many of us have made nice careers this way. Issue is that our Country and possibly the globe can no longer afford for careers to pass before we fix the problem:-)
Thanks all for the good comments. I plan to take this forward by arguing for a two step process that we can pilot as proof of concept prior to making big policy changes. The first important step is to get general agreement that IT acquisition is different than general weapon system acquisition. This should be easy because everyone knows this in their gut but they don’t know what to do about it. The second part will be about piloting a way forward incrementally so that we can prove value prior to creating the policy changes. More on this in the next post which is about ready.
Here is a comment from Chuck Deleot that didn’t get to the site for some reason. Thanks for adding your expertise Chuck…
“I agree that the system acquisition process is not geared to maintaining the C4I edge essential to our military. It is administered by a legion of well meaning senior political appointees and professional bureaucrats who try to build pieces of the system, encumbered by lack of a unifying system architecture/ approach, and development requirements that constipate the process and nearly guarantee delay in providing what the commander wants and needs. In my opinion, the best way to really effect meaningful revamp of the C4I acquisition process is to get the top political leadership (e.g. Obama’s senior staff) to take this on as a better way to support the troops, ensure our out-year C4I advantage, and save tax payer dollars. Recommendations for change must be clear, specific and implementable in the near term. The impetus for the major changes needed in how we do business must come from the top, and should be pursued early in the tenure of the new administration. The criticality of this issue could be emphasized by a few “gray beards” (composition TBD) with contacts to the new president or key members of his staff. CFD”
Marv, As you know, I’m in synch with your thinking. Let me climb up on your soap box for a turn…
Top down policy, in and of itself, rarely (ever?) creates sea change. The most effective policies generally recognize existing best practice somewhere on the ground and aim to scale it up.
Efforts by the government to reproduce Internet capabilities inside its firewalls are inevitably disappointing. That is because the government efforts fail to consider the Internet scale arguments. Internet success generally follows leveraging massive benefit of scale. That scale does not exist inside government firewalls.
When it comes to “information warfare” the battleground is really the Internet and other global communications infrastructure. That’s where the enemy and the endangered civilian population “live” and operate. To fight kinetic wars, the military gives its soldiers armor and modern weapons and trains them to exploit the native battlefield infrastructure and terrain. In contrast, to fight information wars, the military attempts to encase its soldiers in impenetrable bubbles that insulate them from the “information battlefield.” The analogy in kinetic space would be to encase our soldiers their vehicles and equipment in giant “hamster balls” and have them roll as best they can across the native infrastructure and terrain.
The DoD top down approach with concepts like “GIG 2.0” etc… is to cobble together an interoperable networked enterprise by forcefully federating several brittle, archaic, networks. This approach is the metaphorical equivalent of trying to link dozens of giant “hamster balls” and trying to get the resulting kluge to roll around chasing an agile enemy that is exploiting the native infrastructure and terrain. Perhaps a wiser approach would be to start with the existing interoperable network, i.e. the World Wide Web etc. Our military strategy would be to exploit that “information battlefield” by developing armor and weapons that give our soldiers a tactical advantage. After all, the overwhelming volume of cross domain traffic need not be classified, and the overwhelming volume of useful information sources and services exist on the open web.
Exploiting the open web and unapproved COTS to “get-the-job-done” is a “best practice” that occurs all over the DoD and IC community. However, it exists in shadows because it is contrary to policy. A policy that actually mandates the formerly forbidden innovative use of the open web and COTS would very likely create a sea change. By also deploying security services, hardened-DNS, CND tools, and other “armor” and “weapons” to protect and arm our soldiers we have a fighting chance to deliver the promise of GIG 2.0+.
Nice line of logic Chris. Achieving the agility that we train for on the battlefield is what we must do in the acquisition of IT.
It’ll be an interesting forum with the current drives within the Administration to say the least.
Well done Marv! Certainly you struck upon an IT-based DoD issue that has been allowed to grow without bound for far too long.
I do believe there exist significant discriminators, not withstanding DoD’s use of significant COTS (HW & SW) into their IT architectures, based upon what is realized within the “guts” of the underlying systems engineering. That is, it is the particular integration that distances ourselves from those systems that can be patched together by our opponents with access to most/all of the same COTS.
A decade ago we watched with dismay how DMEA had to resort to buying the “dregs” of the semiconductor chip world to keep our avionics and similar subsystems “flying”. The commercial world, once extolling their involvement with the DoD saw their fortunes lying elsewhere and the swung from DoD-specific project. The financial and military innovative worlds collided. Worse, within IT during this same period, a standard approach of a Johnny-come-lately piecing together of parts left by the commercial entities to best solve what DoD-users required. (Exceptions exist, such as CEC.)
Of late, DoD continues to maintain the trend to keep COTS alive & well – but perhaps in a smarter way: the emergence of smart sensor standards as those proposed/recommended by IEEE 1451, situational systems based on the OGC (open geospatial consortium), and other “open” committees with heavily-laden DoD contractor boards & committee membership are responsible for providing these guidelines.
That said, it is in the details where these disparate and “separate” (COTS-like) systems become unified and effective warfighting tools that have outpace our adversaries. Such integration being the “key ingredient” brought in by novel combinatorial design, service R&D efforts, DARPA participation, as well as federally funded R&D. The present evolution of UAV, UGS, and the C2 systems that work with these IT assets, deployable in minutes versus hours (days), have witnessed this shift.
Interesting sets of thoughts. A couple of sets seem to ring my ideas of how to get something
done that is quick and usefull for the troups, vs the process keepers. Chris and Mahnaz hit on
what you and I tried to push, with Rex, some time ago. First, get small and fast well managed
testing quickly at the “user level” and then get feedback from them for the next trial.
Didn’t see this pushed as much as it should have been. Second, the overwhelming volumn
of cross domain traffic need not be classified is a very real trueism. At the fighting level, fast
can be better than very secure and slow. Much info is time dated and time is more critical.
Consider that all C2/C4 systems and info do not have to be on the grand scale, and thus
totally integrated in real time. Battles exist at the local, reginal and grand scales, and one
size fits all C2/C4 today may not be the best solution (this idea may not be popular at some
levels but makes sense to me). Put more effort into 4.3.5 streamlining etc. Take more
risks with smaller amouts of $ and get good/bad answers quicker, then don’t kill the manager!
Don’t know if any of this makes sense, but why should it if we are trying to make changes.
To keep doing the same thing and hoping for different results makes less sense.
Hi Rex, we may be in your area late March, want to get together again for lunch/dinner
on the pier and hash out some of this in real time and catch up on life in general?
Marv, good synopsis and challenge, thank you. There are several people in the innovation world of info and media systems that should/could be brought into this discussion. John Kao and John Seely Brown (JSB) have both done serious thinking about collaboration and C2 issues. Also, I think a dynamic approach can be drawn from our friends throughout the VC and private investment worlds. I don’t think we can modify what is already in place…but then you may have said that in your first mailing……a new set of business rules or guidelines that stream from the world where speed matters and innovation is truly rewarded may be helpful.
Remembering Admiral Nimitz with a quote referring to the USMC activities on Iwo Jima, “Ucommon valor was a common virtue.” Well, not to make light of that glory, we find ourselves in the opposite realm. In the world of Navy acquisition and operations synergy, some consider uncommon goals to be a common virtue.
I agree with all the above, and note the fact that our dated systems engineering and beaurocratic oversight does not support the agile enterprise IT environment necessary to place us on the cutting edge. However, I don’t see change on the horizon that places Navy acquisition and Operations on a common footing to effect proper readiness and change. They are still two different worlds to me…having different standards, promotion paths, measures of success, etc…etc.. If operations recommends a new testing or fleet integration process to support continuous service improvement, who is really ready to embrace that process on the acqusition side?…especially if it is not an accordance withn the rigid path of acquisistion success as defined by legacy standards? It is easy to find a reference to support why something CAN’T be done in an innovative way, and fall back on a safe path, which offers a better (but false) sense of security…
Thanks for this site — it’s a good forum, and well attended by my estimation!
My own personal experience with communications systems includes the issues above, but goes a bit further — while I agree with the policy and acquisition issues that have been highlighted. The other problem is that communications (and by extension, IT) programs do not rank with weapon systems ordinarily in the eyes of the services. Satellites, bombers, ships, and ground vehicles have a higher priority. Cuts or priority shifts were spread across programs without any view towards priority or any enablement that a C2 system could provide.
I also wonder if programs like MUOS, WIN-T, and JTRS (for example) will ever be able to deliver “cutting-edge” technology when they are finally fielded. We have gotten trapped in a morass of beauracracy including inconsistent funding that cause delays in fielding, increase in costs, and removal of technologies whose maturity is not “proven” to a sufficient TRL.
Just my quick thoughts — keep it going!
Having reviewed every GAO report on failed IT Acquisitions, every DSB report and many wonderful reports from the public service community (IAC/ACT, BENS.org, CSIS.org, Markle Foundation, IT-AAC), it appears to me that the problems are obvious and that most efforts to address these gaps are stymied by a bureaucracy that is more interested in protecting rice bowls that improving outcomes. I notice Chris Gunderson blog on Measures of Effectiveness. This is key to changing a culture that is more focused on process compliance than outcomes. My friends at SAF/AQ tell me that the acquisition community is not vested in success, and hides behind their processes as this is what they are measured by. Those who take short cuts are hammered by the OSD policy wonks who care little about delivering solutions in a timely manner.
We also must change our supplier incentives, especially the major defense contractors who are motivated to maximize butts in seats vs COTS based solutions. The award fees must include drive timely COTS solution deliver and reduced customization. When looking at our “capability based acquisitions”, they end up being time and material because we don’t know how to specify the “outcomes” with rigorous SLAs.
Though I am proud to part of the grass roots effort that put a bright light on our failed IT Acquisitions, I am fast becoming very Machiavellian because of all the rice bowls. Just look at the 2008 NDAA Sec 803 that called out for a technology clearinghouse. Did our DOD leadership bother to look around to see if something already existed. The answer is no, and as a result, nothing was accomplished yet every was given an “award”.
Dr. Ash Carter and Bill Lynn are two people I have great faith in. They are making important leadership changes and open to new ideas outside the five sided wind tunnel. We can only hope and pray that the civil servants will recognize the dire situation we are facing, and step outside their comfort zone.
Has there been a detailed analysis on the procurement and deployment of the MRAP and boomerang, or closer to home IT home an analysis of Google’s successes? We all have perspectives and horror stories of what doesn’t work in procurement. What I have heard of the deployment of these two tactical systems may show a way to leap the administrative hurdles, if in a stovepipe. Google may not have some of our IA requirements, and other hurdles, but i am sure there are a few best practices that can be integrated there.
Aaron, there is a plethora of information on best practices for wave 3 IT systems. Most of it is associated with service oriented architectures. SOA for Dummies is one good reference. All of the SCRUM software development best practices relates as well. It is true that IA is a large challenge for our DoD systems but organizations like Google will not even consider a development project that has not designed in IA best practices from the beginning. Thanks for the comment.