A Huge Price Tag for a De-Centralized Implementation. Twenty Four Billion dollars.
I don’t want to bore you. But, I insist.
What if you could take a minute to look into a particular spectrum of Department of Defense (DoD) spending on a specific element of Information Technology (IT) just because it interested you?
Okay, maybe it doesn’t interest you, but since I’ve had my eyeballs, sometimes firmly affixed, on the conduits of information ebbs and flows I often like to check in, if you will, and see how things are going. (That was a lot of commas; wasn’t it?) The takeaway you can have is, how much money does it take to get the armed forces on one sheet of music with regards to logistic enterprise resource planning? This is how much (in March 2012) that the Government Accountability Office (GAO) reports (all public information):
- Army systems = around $10 Billion
- NAVY systems = around $4 Billion
- Air Force systems = around $8.5 Billion
- USMC systems = around $1.1 Billion
- Defense Logistics Agency (DLA) = $209 Million
Twenty. Four. Billion. Dollars.
Could they (SAP) not have also accomplished this for the USMC? In 2020 allow the ability to perform data mining on the same systems too. Together. One team. One mission and purpose. There is my problem – being logical. Let’s not get carried away–that’s too big of a task and purpose! (like healthcare.gov) If we build one system structure, then it will be undermined by security nuances. Wait, why is it that there is so much information out there about how GCSS is being built (read: if you know how I created it; you can undermine it)? I heard someone once say that SAP, Oracle, whatever, they would all be interfaced to one another. Let’s consider: Does a contracting company who has invested over 10+ years in building this solution – will they make in easy integration? I’m looking at you sideways; only you can’t see me.
A thesis, public information, was written in September 2010 by Mark Jones. This paper identified the struggles that GCSS was plagued with, the Government Accountability Office (GAO)’s identification of some issues (in 2010) and clear recommendations to continue. Thesis paper here I’ve extracted the meat (grain fed organic!):
This two release strategy reinforced the philosophy that designing and implementing smaller increments of capability over short periods of time allows capacity, even if it is reduced from the original plan, to be fielded earlier to the user (it’s like the waterfall to software developers). Know that the “user” is the warfighter. The men and women we laud on days committed to them and invest our reverence to their very existence. (Without them; we can’t write informational blogs.) This is a critical concept in building systems to support DoD – at the end of the day if your requirements don’t fulfill that purpose means; then fail. Bean counters sweat bullets. If you catch my drift. But, is the end product supporting real users.
The Strategic Plan intends to share information across DoD and with mission partners. In summary this includes: the data itself; the Department’s management over the information life cycle; the processes associated with managing information to accomplish the DoD mission and functions; activities related to designing, building, populating, acquiring, maintaining, operating, protecting and defending the information enterprise; and sharing of related information resources such as personnel, funds, and equipment.
To develop such a system, a Lead Service or external entity could act as the Program Office and manage the entire lifecycle support of the system. —-that right there? Is just insane.
But I don’t think it is. I have experienced the lack of subject matter expertise in software and system development, and I’m almost certain that years of drowning in legacy systems only inebriated value-added growth. One vision, multiple missions, and end product that is usable, repeatable, and has outputs that drive decisions. Magic. I heard somewhere that magic was expensive. It indeed is when division comes into play.