As the first installment in this multi-part blog, permit me to first provide some credentials that give me more than enough right to speak on this topic.
In 1990, I became a consultant at the US Army Missile Command (now Aviation and Missile Command).
Mye task was to be the technical “expert-in-residence” on the Army’s first attempt to dig itself out of COBOL/ISAM/-based wholesale logistics using a database called Model 204 (still around and still kicking *** in Australia, Canada, and many US agencies of the (in)famous 3-letter variety.
Around 1993, the US government, in its always-infinite wisdom, decided to standardize on relational-databases and SQL – not because they were “better” than non-relational databases using non-SQL based languages, but because they allowed the government to purchase in the usual way. As Gio Wiederhold explained to me when he was chief of DARPA’s Database section, the US DoD wanted to be able to purchase databases like it purchases any other commodity (bread, toilet paper, bullets), and in order for this to be possible, the government had to restrict its choices to different vendors offering essentially the same thing but with different discounts.
As a result of this decision (which also, BTW, was more or less contemporaneous with the government’s decision to try and standardize on UNIX/TCP-IP instead of IBM/SNA), I left my Model 204 activities behind to particpate in the Missile Command’s involvement in DoD’s scandalous “JLSC” effort in the mid-nineties – an attempt to develop a new logistics system for all US armed services based on Oracle (this was Oracle BEFORE Oracle started pretending that it had workable COTS solutions for logistics.)
Next, after JSLC failed completely in its primary mission, I was a member of the original team which wrote the original winning (1999) proposal for US Army LMP project (which turned out to be the largest SAP installation in the continental US as of 2001).
In this capacity, I was the guy who pointed out that it was suicide to try and convery US Army CCSS and SDS incrementally instead of via a big-bang, and as a result, the project was immediately switched from incremental to big-bang AFTER award.
And finally, after leaving Army LMP I did 18 months of design and development on NAVY ERP 1.1, another SAP-based attempt by a US Armed Service to standardize on SAP.
So … here it is 20 years and four major projects later, and lo and behold …
neither SAP nor the Army nor the Navy nor DoD nor any weapon-system vendor have yet to successfully demonstrate that it has any idea at all of how to handle the problem posed by the “SMR-codes” that are regulatorily-mandated in all US military maintenance logisitics support systems.
This ends Part I of this blog.
In Part II, I will explain the problem posed by “SMR-codes” in A&D logistics systems, and why this poblem is related to the question of whether a 20th centry company can do 21st century A&D logistics right.
But for the moment, let me indicate the imporatnce of the “SMR-coding” problem by mentioning that back in 1993-1994, I co-wrote a proposal to DARPA on the topic of “SMR-codes” with an ex-loggie colonel named Doug Barclay.
Doug’s a great guy who was truly excited about the prospects of getting a solution to the SMR-coding problem, because he had “been there and done that” for twenty years, and he knew that “readiness” would be something of a joke in the services until this problem was solved.