DCGS-A : US Army spent $2.7 billion on a battlefield computer that doesn’t work

Cui bono?

Quote:

---

It has emerged that the multi-billion-dollar DCGS-A military computer system that was designed to help the US Army in Iraq and Afghanistan simply doesn’t work. DCGS-A is meant to accrue intelligence, surveillance, and reconnaissance, and provide real-time battlefield analysis and the current location of high-value targets. According to two former intelligence officers that have worked with the system, however, it has hindered the war effort rather than helped.

This story has developed over the last year, beginning with a memo sent by Major General Michael Flynn, the Army’s top intelligence officer stationed in Afghanistan. In the memo [PDF], Flynn damns the apparent ineffectiveness of DCGS-A: “Analysts cannot provide their commanders a full understanding of the operational environment. Without the full understanding of the enemy and human terrain, our operations are not as successful as they could be. This shortfall translates into operational opportunities missed and lives lost.”

---

http://www.extremetech.com/extreme/8...at-doesnt-work

Let me just pull out the important part for y'all - This shortfall translates into operational opportunities missed and lives lost.

Useful search capacities don't seem like a hell of a lot to ask for.

It is worth reading the comments below the article, and also the enclosed Memo that LTG Flynn sent out, it didn't attack DCGS-A. I didn't use DCGS-A, but talked to some who did, and a couple of folks really liked the capabilities of DCGS-A. Some people think the article was a cheap shot and an advertisement for Palantir (another tool), which may be true, but Palantir is only as good as the user. In other words, if you don't take the time to master the system and experiment with it you won't get much out of it. In reality the biggest challenge is finding the time to train our guys on these systems. They are NOT intuitive.

A number of government labs, DARPA and private industries in the U.S. and around the world are developing many systems/tools to help with this challenge, and I have had the opportunity to see a few systems demo'd, and they're all trending towards very impressive capabilities. However, we can't swap out systems every year in pursuit of the newest shiniest toy if we are going to employ the tools effectively. The users need time to master the tools they have.

I think there are two approaches (I'm sure there are more), first we focus on mastering what we have, and then refining those tools over time to make them more responsive to the users. Second, we can hire contractors to employ the new tools down range that are soley focused on that technology, which will lift the training burden from our shoulders. Three we could do a combination, which in fact we're doing now to some extent.

From my experiences with DCGS, there are several issues, but overall it has the right chops. The article's inadvertent advertising of Palantir aside, DCGS is not without flaws.

You cannot sustain a modern day data solution that resides on a non-standard method of sharing data. DCGS uses a framework that requires a significant learning curve, if you want to contribute or extract data into other solutions. However, because the model behind DCGS-A is more of a backbone through which data travels, and less of a repository, this unique method of data entry and exit seems to be a necessary evil derived from the timing of the solutions development.

It also suffers from evolutionary development - Because the requirements drove DCGS-A to spider in its requirements, everything became important, and therefore the overall strategy was constantly pushed in various directions. I would suspect now that the 2.7B (A lot of which was likely fielding), could be rebuilt better for significantly less. There is an old software development adage that says "Be prepared to throw out version 1.0", and this may be the case here - Because Agile development in the combat conditions in which our systems are forged drives us to make immediate decisions, without knowing what is around the corner, DCGS-A may suffer from those decisions today.

The other issue, which is not inherent in DCGS-A, but rather our approach to intelligence data proliferation, is that DCGS-A is an island in the archipelago of DCGS systems - There are several systems in DoD and throughout the IC that bear the DCGS moniker, but they fail to share data across this or even use the same development and production tools. In turn, you have a set of islands, and no real interisland travel. This is policy and not technology, but a serious flaw nonetheless.

On the other hand, DCGS-A has taken a complex requirement - storing and management of intel data - and made some sense out of it. They have provided tools (which take a Master's understanding to use IMHO), and given them to Intel analysts to make some sense with. Unfortunately, because they require advanced training, the operational world is reliant upon the Intel team to make the analysis happen.

My suggestion for them would be to make a simplified access medium so that in today's data and tool-rich environment, an Analyst could plug in Palantir straight into the DCGS-A backbone, and an Company Commander could dump a query into Excel or some other simple reporting tool. In addition, we should plug our other C2 systems straight into DCGS-A so tools like CPOF and others are contributing directly and benefitting immediately from others using the DCGS solution.

DCGS-A may be filed under the old axiom: "No plan survives first contact with the enemy..."

Seriously, each system has its strengths and limitations, and while LTG Flynn has a point, like his article "Fixing Intel", he may have applied a bit of drama to influence policymakers.

To me, the issue revolves around bandwidth and accessibility. There is a great deal of data in numerous locations in and out of the AOR, but when you have a dedicated T-line in the States (FBI/CIA), as well as a focused objective, it becomes easy to have a system perform beyond expectations.

However, when you start moving further and further into the hinterlands of Afghanistan and Iraq, bandwidth becomes a challenge. Compound that with trying to access numerous password-protected databases (thanks again, PVT Manning and fellow ilk)as well as poor utilization of in-theater common databases , it becomes an almost-insurmountable task.

Add in the issue of training, sometimes training hinders folks since the schoolhouse is usually the last to get the current version of a software/ system. It forces analysts and other users to only use the part of the training that carries over to the newer version, which becomes its own barricade to full utilization.

Just a thought or two.

Quote:

---

The idea was simple enough: Create a cloud-based software tool that can comb through the entire universe of military intelligence reports for a given region, group, or individual and come back with actionable intel that battlefield commanders can use on the ground, and do it in realtime.

But analysts that have used the system, as well as documentation obtained by Politico, show that the tool is hurting more than it is helping because it doesn't work properly. And that's when it works at all.

---

Read more: http://www.foxnews.com/scitech/2011/...#ixzz1RSvoUeKP

Quote:

---

Originally Posted by Bill Moore

It is worth reading the comments below the article

---

Yes, it is.

I thought this one was particularly good

Quote:

---

Artor 2 days ago
I'm amused that the CIA & FBI are using a Palantir for their intelligence operations. Remember the original Palantir? The crystal ball used by Denethor of Gondor? It was controlled by Sauron, who chose whatever it would show, and reduced Denethor to a paranoid, raving lunatic. Maybe that explains what's going on with CIA & FBI intel?

---

As they used to say on Pinky & The Brain : Narf!

I joined the forum here just to respond to this topic.

As an S2 recently returned from Afghanistan who worked with both platforms, what analysts and intelligence officers are normally referring to when they say that DCGS-A doesn't work is actually the Multi-Function Work Station (MFWS). ArcGIS, QueryTree, and a few of the other tools function as designed and are useful. MFWS is not.

As an S2 for the last 7 years, I have seen DCGS-A evolve from ASAS, and I have continually been let down by their front-end software interface. The back-end enterprise supporting the data feeds and the ability to query across multiple databases is great (though a bit clunky to be honest). The problem is the user interface with MFWS - it's a terrible design (and I feel fine saying that as a former programmer). It's not intuitive, it is not designed for physical separation of units, it takes entirely too much time for data entry and normalization, and it has proven unstable time and again (FSRs are required to back up the database daily to an separate drive because it crashes so often). Most units ended up just using Analyst's Notebook and e-mailing link diagrams to each other; it was not a collaborative environment that encouraged analytical development - it was link charts being emailed...sometimes they were just simply done in PowerPoint and e-mailed.

When you are tracking an insurgency across a Regional Command and trying to understand cross-boundry and cross-border issues, e-mailing PowerPoint link charts is not helpful. Trying to keep track of large patronage networks, drug networks, insurgent networks and criminal networks is impossible without some great tools. Our unit had over 80,000 entities to try and keep track of - it's a staggering amount of information. We have great collection capabilities - but we always struggle with information overload.

LTG Flynn sent up a JUONS specifying that units needed a collaborative network analysis capability along with the ability to support low-bandwidth users - the reason the conversation jumps to Palantir is that it's a proven platform that's simple to use and it works as a collaborative tool among different echelons of command. My companies were able to access all of our intelligence holdings at the BDE level daily over their small bandwidth pipelines at their COPs - they could see pictures, see the network link diagrams, see the most recent exploitation of IEDs that were in their area and help refine our analysis with their input at the ground level - it made intelligence accessible to my companies without requiring a 2-hour briefing from an S2 with a 10MB PowerPoint file; it also allowed the ground units to contribute to our analysis. One-stop shopping. They could drag in pictures of Shura members and Village Elders and update their information. It worked, and it was simple - it was intelligence and operations fusion that worked.

DCGS-A couldn't make that happen. That may sound like I'm in the Palantir camp - but I'm in the camp of things that work; especially when the Company level fight is where the rubber meets the road in COIN. Technology should enable us - not frustrate and irritate us; especially in a war zone. My analysts have used both platforms while deployed and they hated me when I told them we needed to test and validate the new DCGS-A release this year.

The bottom line for DCGS-A is that the analysts and S2s hate MFWS - which is made by Overwatch Systems; the database that underlies this software is pretty much the same Entity Database that was used for ASAS. It is not extensible, doesn't provide basic administrative management controls, is bloated and has not taken advantage of all the most recent developments in database design and user interfaces. It shouldn't surprise that Overwatch Systems used to be called AIS (Austin Information Systems), which was the company that was developing ASAS software - so the Army has dumped money into a company trying to use 10 year old software based on the Axis Pro platform (another clunky network analysis tool) with a backend database that hasn't changed much in a decade.

With this most recent patch released from DCGS-A, it is the first time they can actually say the software functions in Afghanistan (it worked better in Iraq). It was widely known and accepted that version 3.1.3 of DCGS-A would not function in the Afghan Theater - and that was tolerated by the Program Managers - this was unacceptable. It is a combat system that didn't work in combat. It was simply broken. 10 years into this conflict, and this is the first year that DCGS-A can say their software actually works in Afghanistan. A decade. We were able to get MRAPs fielded to troops faster than DCGS-A could make their primary software function.

As an S2 in a BCT for my entire career, I have been told for the last 7 years that tools I need to actually work will "be in the next patch release, next year." Analysts are seeing other platforms now that do what they need without 15 steps and 10 work-arounds due to bad design; in a word, analysts have asked why DCGS-A doesn't encourage open competition to find the best solution.

DCGS-A has been maddening as an S2 - there's potential, but it is horribly mis-managed with requirements and decisions being levied by officers who are simply not analysts - the managers I've seen have been Aviation, Acquisition Corps, Logistics and Infantry. For the cost of this platform (a lot of which has actually been hardware development) - S2s should want to use it.

I hope this helps other folks trying to understand why some Intelligence Officers are saying that DCGS-A is failing us as an All Source Analysis Platform. We know they are trying and that they care - but sometimes you have to admit when your efforts are not meeting the mark and allow innovation to come from different avenues.