The Standards Gap in System Engineering George W. Anderson, CSEP Chesapeake INCOSE, January 15, 2012 ‘System engineering (SE) is foundering in a plethora of processes, models, policy guidance and ‘methodologies. It would also appear that very little of the literature dealing with these subjects is well focused, easy to understand or user friendly. So then, why do many intelligent and capable systems engineers not speak out against this seeming millstone being won collectively by the profession? Is there something in the SE culture that demands that every detail need be explained to mind numbing extremes? I would suggest that reasonable answers to these two questions rest in examining the role of the market place-not the profession, There is a demand for system engineering guidance and recent experience has shown that about anything that relates to this can be published, presented or sold somewhere. The situation may be comparable to the early days of aviation when amateur builders created cutting edge technology by pure trial and error. No sound theories or professional understanding to support either aerodynamic or structural design appeared to be available. Instead, popular articles abounded with all kinds of authoritative advice much of which appears today to be dangerous and totally without factual basis. ‘The early pioneers paid a dear price for working without sound technical knowledge. Orville ‘Wright suffered from severe back problems for the remainder of his life after injuring his back in the first fatal aircraft crash in 1908). The cause of that crash was the disintegration of one of the aircraft's propellers. A structural failure that today would spark a nasty product liability lawsuit. Do we really have a complete understanding our current situation given the breadth and intensity of technical progress since 1903? Hardly! Instead, it can be suggested that we are still genuinely struggling to master the complexity that our new technology creates. History shows that innovations normally precede sound understanding of their substance and impact on society. If we are to successfully exploit new technology and create innovative technical solutions in new systems, we must recognize this lag and carefully focus our attention on identifying and mitigating the gaps in our knowledge. am of the opinion that failure to utilize standards properly in building systems has been such a gap. The gap is so large as to be instantly recognizable even by persons not attuned to the systems engineering practices of enumeration, decomposition, and definition. There is no shortage of papers containing guidance on standards in the SE literature. We can find a great deal of help in defining, identifying, classifying, and describing them. We can create, adopt, tailor, and replace them. And, finally, we can tout their potential for cost savings, technical superiority, and ease of use. " an Army Demonstration flight at Ft. Myer, VA, on December 10, 1908, resulted ina crash that Killed Lt. Thomas Selftiige and injured Orville Wright. ? The first controlled, powered and sustained heavier-than-air human flight, on December 17, 1903,What we cannot do is properly employ standards as building blocks of our systems design. Standards actually define the majority of most modem information system technical designs and system engineering process guidance that explains this fact is hard to find. To be sure, the DoD has a "selection process” for standards and has top down control for the (stated) purpose of ensuring interoperability. A cursory examination of this undertaking, however, raises doubts about its potential for success because of the apparent superficiality of the technical process being used and the lack of resources employed. ‘The Intemet is the centerpiece example of why we need to have formal SE processes dedicated to employing standards in our system designs. If we attempt to describe the internet from a technical perspective, we quickly discover that virtually every process, protocol, and interconnect is defined by a standard. In spite of this, many otherwise competent systems ‘engineers sometimes engage in a sad and unproductive form of Sophistry arguing about what constitutes a standard, This frequently happens when Internet standards interfere with accepting a vendor's product. The goal of the argument is to eliminate the pesky conflict between a standard and non-compliant and often proprietary technology. Scott Adam's biting satire in his Dilbert Comic strip is often very apt in describing what ‘happens next. In most standards adoption processes, boards of experts that "have no actual knowledge of the problem" are used to select standards for a project or system. This makes the decision process straightforward and contlict free. As has often been noticed, the Dilbert Comics stories mirror our current SE work environment to an alarming degree. Ione produced a graphic of the internet's technical design components, we would discover that all physical and logical artifacts and their interconnections are described by specific standards called Request for Comments (RFC). These standards are maintained by the Intemet Engineering Task Force (IETF) and as such represent tested and consensus approved solutions to requirements. The requirements can be related to: performance, test, process, assembly, or survivability as well as many other categories. Asa minimum, consider some of the potentially favorable results of a standards employment process in the project SE plan. I would expect the following common sources of failure, delay and cost overruns to be identified and mitigated by such a process: 1, New untested or prototype technology 2. Kluges? and work-arounds 3. Non-compliant reinventions of already available solutions 4, Politically imposed hardware or software that is unsuited for its intended purpose(s). 5. Design defects 6. Integration failures 3 Kluge 1. Something that should not work, but does. 2. A device assembled from components intended for disparate purposes.‘The proper employment of standards in the SE process cannot occur if there is no explicit explanation in the literature, It's time to consider standards activities as a subject deserving of equal treatment and atthe same level of taxonomy as configuration management or requirements development. In conclusion, think of a defined Standards process as the vitamins ofthe overarching SE process, All other processes thrive when the system health is enhanced, simplified and