Configuration Identification
MIL-STD-973 lists configuration identification as the first step in the configuration management (CM) process. We do not think this is some bureaucratic whim, but rather, one of the most important components of CM. Are speaking about systems, subsystems, components, parts, software revisions, and more? The simple answer is, yes! To avoid confusion when using bills of materials, our parts should have unique designations. We can use code names such as “QWTY-104-3” which may become intelligible over time or we can also add a nomenclature that is unique in our working language of choice (English, Spanish, Japanese, etc). Nomenclature is important enough that the U.S. Department of Defense (and other countries’ ministries of defense) have standards for nomenclature. One of the best ways to set up an identification/nomenclature system is to create taxonomy, a tree or root diagram, the leaves of which are unique designations. If we take this idea a step further, we can see that we should be able to specify a designation just by defining the part adequately. We are so far so good for lowest-level components. What about higher level items? Again, the nomenclature system should be well defined, perhaps using a taxonomy. The recent concerns over “assault rifles” points to part of the problem—we don’t have a universally accepted definition for what an assault rifle is, although long weapon (rifle) originally designed for automatic fire that uses rifle cartridges and not pistol rounds seems like a good start. Look at how many words had to go into this definition! And we haven’t even defined “pistol round” yet. In the software world, one method for defining components of a computer language is the Backus-Naur Form or Extended Backus-Naur Form (BNF or EBNF). We would like to see some exploration into the more extensive use of this tool. Ultimately, we are discussing disambiguation. If we don’t know what it is, we can’t control it, report on it, or audit it.