The Fallacy of DevOps
by Mooch
https://drive.google.com/file/d/1ZUUlQuSfgoB0-mxABc30zZAtHkVt7RYv/view
Monday, February 8, 2021
Thursday, March 26, 2020
Keep Bringing the Juice Boxes
Sadly the book, “A Seat at the Table”, by Mark Swartz, is the worst book I’ve read in a long time. Heralded by the Chief Software Officer of the United States Air Force, Nicolas M. Chaillan, as a must read, I believe we are being led down the primrose path by the likes of personalities such as Swartz and Chalillan. The buzz word in software is DevOps and whether or not we believe software is key to every business, and the business of most businesses, the tenants of DevOps are not new to the real business of innovation. Recast as some sort of new knowledge, when it comes to rapid development of anything, look through history at the companies who have found rapid ways to develop new things and get them to the marketplace, and the exact same rules will apply. Nothing new here. Even when applied to software. What is new is the idea that the Chief Information Officer at a company should be in charge of it. The danger, as I see it, is not with how the next Uber or Airbnb will get their app to market. The danger is that some companies are not strictly software development houses, They also do other things, like build cars, planes, and rockets. Coming from a military background I’ll rephrase that as tanks, planes, rockets, and satellites. Yes, the software development involved with these systems is extensive, 35 million lines of code and counting on programs such as the F-35 (including ground support systems), but so too must these companies also build the hardware that works, physically, and the hardware that supports and runs the software at the interface between the physical world and the digital logic inside.. The world does not consist strictly inside your desktop, laptop, and iPhone. At least not yet. The world is still a physical place. And thus we must still interact with it in physical ways. Engineers build these physical systems. Deeper still, is the need for these software driven physical systems to be secure. This does not happen on the software side alone. Thus even if the CIO understands not only IT but software as well, they will not understand the other product development in other engineering disciplines. They still are in a heavily supporting role.
In the old days a company consisted of the CEO, COO, and CFO. Typically, before the days where everybody wanted an MBA, engineering companies would advance, not necessarily the best engineers, but the good engineers who could communicate with the outside world. Those smart folk would rise to the top and it was hard to compete with them because of their deep knowledge of what the company was actually in the business of producing. As the information age blossomed, companies began creating positions like the Chief Information Officer or CIO to run their Information Technology enterprise. So let me just ask a question, who do the software developers work for? Do they work for the CIO or do they work for the CEO? In an information company, where software applications, games, webpages, shrink wrapped software are the products, do the software developers work for the CIO? In a hardware company where the product is the next business jet, do the software developers work for the CIO? The answer is no. The fallacy here is that the CIO needs a seat at the table. The misunderstanding here is that the CIO drives the DevOps cycle. What’s happening here is because of the surge in software development in every company, the CEOs and COOs understand less about the technology. That is why if you put a software engineer in charge, like Elon Musk at Tesla, he is smart enough to speak all of the languages he needs to speak in order to run the company. The CIO can play his supporting role to keep the networks up so that everyone can do their job. The software engineers do not work for the CIO at Tesla, or SpaceX for that matter.
Hopefully you understand where I am going with this. I like CIOs, don’t get me wrong, but giving them a seat at the table to drive DevOps when the software developers don’t work for the CIO is a dumb idea. And it would be an even dumber idea to put them in charge of software development thus splinting the development of an integrated engineering solution. Software might be the cool magic in any given hardware, who doesn’t love the artificial intelligence of a self driving car? But the car can only drive because it has cameras that can see, radars that can feel, tires that can turn, and brakes that can stop the car. This is a fully integrated engineering hodgepodge of technology that must remain on the engineering side of the house under the CEO. The CIO has other things to worry about, like making sure the engineers can communicate with one another and save data. Driving DevOps is for engineering management and whereas it may have arrived for commercial companies it is still not ready for primetime in the military...nor should it ever be.
The United States Air Force, as the foremost technology service, has been enamoured with this book and with other fantasies about Silicon Valley. Thus the Air Force appointed a Chief Software Officer to drive software development into a DevOps future. Yes Chalian has started a few software companies. He has not, however, built a F-16, a B-2, or a MilStar Satellite. Yes all companies can do better with their software development cycles, but they still must build hardware. They must build an integrated solution. They still must test hardware and they still must secure everything from attack. DevOps is antithetical to building defense systems that must work in a life and death situation while also under attack from both within (cyber) and from without (physical). In this still highly relevant paradigm the CIO is still in a supporting role and should still just keep bringing the juice boxes.
Saturday, October 19, 2019
The Socialization of Air Power
It all starts on a dreamy Christmas morning. You open a present from your mother-in-law. You find a "multi-tool" with or without a "sturdy belt holster". You thank her for the thoughtfulness. You might even give her a mother-in-law hug. Later you can't find your pocket knife so you grab your new multi-tool and go hiking in Moab, Utah. 127 hours later, trapped and near death in a canyon, you hack through your arm with the dull blade of the multi-tool and cut through your nerve fibers with its crappy fold-out pliers. Multi-tools don't work. You might say, "Hey, that famous climber Aron Ralston saved his own life because he had a multi-tool and was able to successfully cut his arm off". He was lucky. And his luck was the kind that casts James Franco as his character in the Hollywood reenactment. The rest of us don't have that kind of luck. The rest of us die.
When we send troops into combat, we don't issue multi-tools. We give them weapons with singular lethal purpose. If more killing power is required we keep it simple. Last time I checked a fire team consisted of two riflemen, a grenadier, and a machine gunner. They may all be able to operate each weapon but when the fire-fight starts they stick to their specialty. Then they might add a mortar team, or heavy artillery, or close air support. This is the building block approach to effective warfare...and it works. The same goes for air power. We don't issue multi-tools to our Air Force pilots. Instead, along with their high performance jet aircraft, a fighter pilot is issued a hook blade knife. The hook pops out like a switch-blade. The hook is used to cut the parachute risers in case their aircraft ceases to fly properly and they must bale out. The smart ones open the hook blade in advance and tuck it into their flight suit. This way they have the right tool for the job and don't have to struggle to open it as they plummet beneath a tangled parachute.
Use the right tool for the job. Any mechanic, carpenter, infantry soldier, or fighter pilot will tell you having the right tool is a life saver. Why then is there a belief that tools can be bundled into more effective packages. The answer is, of course, cost. There is always a cost savings when you buy five tools in one, just watch late night television. There is a fallacy in believing this combination of tools does cost less, or is just as effective as the tools in their individual form, or even worse, believing they are better.
John Boyd successfully argued against the multi-tool in the 70's and made his point. The result was the F-16 fighter. This aircraft is the greatest pure dog fighting aircraft ever conceived. Here's another question that Boyd answered. How do you put a 30 mm cannon in the air? Ladies and gentleman we give you the A-10 Warthog...not very pretty but pretty damn effective. The A-10 was also a direct product of this proper tool for the job mentality. Fighter's fight, bomber's bomb, attack aircraft attack, and ISR aircraft...well, what exactly do ISR aircraft do? More on ISR aircraft later. First some preparatory thoughts.
The philosophy of the multi-tool goes deeper than cost. There is a belief that grouping things or aggregating them into communal living improves effectiveness too. What could be more effective then always having the right tool for the job at your finger tips? Well, for starters, having the right tool for the job. The multi-tool is rarely the right tool for any job. So why does everybody buy them? Well that's the magic of creative marketing and hopeful gift giving. Giving someone a plain screwdriver is somewhat unimaginative. But giving someone a tool that does everything is believed to carry more value. Here's a better idea. How about giving someone a non-conductive screwdriver? That's both thoughtful and could be a life saver. Last thing I want to do is poke around in a high voltage fuse panel with a screwdriver that unfolds from the handle of my multi-tool. That's candidate material for next year's Darwin award. Yet we still have leaders in our Department of Defense who think giving the troops a multi-tool will reduce the budget and enhance effectiveness. These leaders should also be on the short list for next year's Darwin award, except it's not those leaders who have to use the crappy pliers. It's the men and women in the trenches who get stuck with the bad Christmas gift. Ultimately our national security is eroded by the same faulty logic.
Some of this can be traced to an early belief in the power of network centric warfare. Twenty years ago, Andrew Marshall, in the OSD Office of Net Assessment, threw down a vision for a Revolution in Military Affairs in which the DoD could transform the way we fight wars, predicated by the coming advances in information technology. Much has been written and many things have been attempted. The promise of increased combat power, based on the power of the network alone, has not materialized. We do not have a single integrated air picture (SIAP). We do not have joint integrated fire control (JIFC). We do not have a cooperative engagement capability (CEC). At least not to the level envisioned by their proponents. We do have a few more unmanned systems in operation; remotely piloted aircraft have increased for instance. But we have always had unmanned satellites, rockets, big missiles, cruise missiles, and target drones. The unmanned technology is not new; just the attempt to apply the technology in a ubiquitous fashion is new. Technology has driven a belief in something ethereal, something strung together in network form, with an added social benefit. It is this communal effect applied to technology that fuels the promise of the multi-tool. It is the socialization of air power that we should work hard to avoid less we suffer a reduction in our effectiveness.
Recently a high ranking DoD official stood up at a conference and said, "The DoD will never again buy a single aircraft with a single mission purpose". This DoD official has a lock on a job with television infomercials upon their retirement. The myth of the multi-mission aircraft remains strong within the Department of Defense. Although the Navy is still building the MP-8 multi-mission aircraft, the Air Force abandoned hopes for their version of a large multi-mission aircraft several years ago. Thank God. Back then it was called the E-10A and was destined to cost the country close to $500M dollars per copy. Oddly the multi-tool concept of lower cost broke down with the E-10A. Seems like bundling the capability should reduce its cost right? Not if you are placing two unique $200M dollar systems on a $100M dollar aircraft. But the real confusion existed in the operational concept for this multi-mission aircraft. Where would it fight? And which mission would have priority? Combining the mission of the JSTARS with the mission of the AWACS on a single platform seems, on the surface, to be a worthy goal. Until you realize the missions are vastly different. The JSTARS looks at what’s moving on the ground while the AWACS keeps an eye on what's flying in the air. Both missions must happen continuously. They fly two completely different radars both in frequency, power, and utilization. But of even greater importance is the fact that the two missions operate in separate areas of the battlefield. This operational information was lost from the very beginning. Sure, the technology could be made more comparable, after all both systems are radars. But to fly one to cover the JSTARS mission means a second one would have to be flying to cover the AWACS mission. Instead of two multi-tool jets costing the country $1B dollars, we could buy two dedicated jets (1 radar system a piece) that would cost a total of $600M thereby saving the country $400M, for which we could purchase a third jet and still return $100M to the national treasury. What were they thinking? The word we are searching for is multi-tool.
And it is this multi-tool mindset that continues to inspire our dreams and cloud our judgment. Here is another example. Dedicated mission aircraft, such as the JSTARS and AWACS have served proudly for decades. The promise of lower cost remotely piloted aircraft, serving a general purpose, non-dedicated aircraft has crept into our imagination. The highly publicized KC-X tanker has also raised the spectra of possibility to do more general purpose service in more mission areas. Using general purpose aircraft to fly non-dedicate missions has been a goal of transformation advocates for many years. If more of our mission systems could be placed into pods then any aircraft could be used to fly any mission. The flexibility of air power seemingly rises to the infinite in possibility. There is of course no free lunch as many would wish to believe. One senior Air Force official has said with regard to the application of a non-dedicated concept to the ISR mission, that, “…they [non-dedicated ISR concepts] have been the bane of my existence".
Non-dedicated operations break down because there are too many variables to control. We dedicate things when the mission is too important to delay, screw up, or fail…like fighting a war. Will there be an aircraft available? Have the generic systems on the aircraft been maintained? Will a higher priority mission bump our mission at the last minute? Many of these issues could be solved with proper technology. But we are talking about more than technology. People are involved. The technology could be ubiquitous. To a computer a one or a zero is still the same tomorrow as it was today. But it's the people who fight the wars. You wouldn't tell Mario Andretti to go out into the parking lot and pick a random car to drive in the Indianapolis 500. When we ask Air Force personnel to fly and operate sophisticated machinery, it's not just at a race on Sunday; it's in a war zone. It would be nice for them to have taken a few laps around the track first. Yes there is the right stuff mentality prevalent in all pilots, and Mario Andretti could probably smoke us all driving a Ford Focus, but that's not the right way to organize, train, and equip people for mortal combat.
We have to stop thinking with a one-size-fits-all mentality. We might think the benefit of technology is to enable one-size-fits-all. It does not. Technology may provide the infantry soldier an M-16 that is lighter, more powerful, and less likely to misfire. But it will not reduce the requirement to have an M-16 with a dedicated soldier behind the trigger. It will not reduce the reality that certain missions cannot be made stronger by combining them with those that are less strong. And those that are weak can be strengthened by combining them with those that are less weak. To think that technology enables every system to contribute according to its capability and every need can be filled with whatever capability is available sounds suspiciously like a failed system of government. It is not in any way like any war that has ever been fought and won. Warfare is not a social experiment nor is it a system of government. You win with weapons that work effectively applied with overwhelming force, and a whole lot of intelligence. Then one bullet must be fired from one rifle. Just ask Osama bin Laden. Giving Seal Team 6 a multi-tool doesn’t work.
The Socialization of Air Power
by Jim Muccio
When we send troops into combat, we don't issue multi-tools. We give them weapons with singular lethal purpose. If more killing power is required we keep it simple. Last time I checked a fire team consisted of two riflemen, a grenadier, and a machine gunner. They may all be able to operate each weapon but when the fire-fight starts they stick to their specialty. Then they might add a mortar team, or heavy artillery, or close air support. This is the building block approach to effective warfare...and it works. The same goes for air power. We don't issue multi-tools to our Air Force pilots. Instead, along with their high performance jet aircraft, a fighter pilot is issued a hook blade knife. The hook pops out like a switch-blade. The hook is used to cut the parachute risers in case their aircraft ceases to fly properly and they must bale out. The smart ones open the hook blade in advance and tuck it into their flight suit. This way they have the right tool for the job and don't have to struggle to open it as they plummet beneath a tangled parachute.
Use the right tool for the job. Any mechanic, carpenter, infantry soldier, or fighter pilot will tell you having the right tool is a life saver. Why then is there a belief that tools can be bundled into more effective packages. The answer is, of course, cost. There is always a cost savings when you buy five tools in one, just watch late night television. There is a fallacy in believing this combination of tools does cost less, or is just as effective as the tools in their individual form, or even worse, believing they are better.
John Boyd successfully argued against the multi-tool in the 70's and made his point. The result was the F-16 fighter. This aircraft is the greatest pure dog fighting aircraft ever conceived. Here's another question that Boyd answered. How do you put a 30 mm cannon in the air? Ladies and gentleman we give you the A-10 Warthog...not very pretty but pretty damn effective. The A-10 was also a direct product of this proper tool for the job mentality. Fighter's fight, bomber's bomb, attack aircraft attack, and ISR aircraft...well, what exactly do ISR aircraft do? More on ISR aircraft later. First some preparatory thoughts.
The philosophy of the multi-tool goes deeper than cost. There is a belief that grouping things or aggregating them into communal living improves effectiveness too. What could be more effective then always having the right tool for the job at your finger tips? Well, for starters, having the right tool for the job. The multi-tool is rarely the right tool for any job. So why does everybody buy them? Well that's the magic of creative marketing and hopeful gift giving. Giving someone a plain screwdriver is somewhat unimaginative. But giving someone a tool that does everything is believed to carry more value. Here's a better idea. How about giving someone a non-conductive screwdriver? That's both thoughtful and could be a life saver. Last thing I want to do is poke around in a high voltage fuse panel with a screwdriver that unfolds from the handle of my multi-tool. That's candidate material for next year's Darwin award. Yet we still have leaders in our Department of Defense who think giving the troops a multi-tool will reduce the budget and enhance effectiveness. These leaders should also be on the short list for next year's Darwin award, except it's not those leaders who have to use the crappy pliers. It's the men and women in the trenches who get stuck with the bad Christmas gift. Ultimately our national security is eroded by the same faulty logic.
Some of this can be traced to an early belief in the power of network centric warfare. Twenty years ago, Andrew Marshall, in the OSD Office of Net Assessment, threw down a vision for a Revolution in Military Affairs in which the DoD could transform the way we fight wars, predicated by the coming advances in information technology. Much has been written and many things have been attempted. The promise of increased combat power, based on the power of the network alone, has not materialized. We do not have a single integrated air picture (SIAP). We do not have joint integrated fire control (JIFC). We do not have a cooperative engagement capability (CEC). At least not to the level envisioned by their proponents. We do have a few more unmanned systems in operation; remotely piloted aircraft have increased for instance. But we have always had unmanned satellites, rockets, big missiles, cruise missiles, and target drones. The unmanned technology is not new; just the attempt to apply the technology in a ubiquitous fashion is new. Technology has driven a belief in something ethereal, something strung together in network form, with an added social benefit. It is this communal effect applied to technology that fuels the promise of the multi-tool. It is the socialization of air power that we should work hard to avoid less we suffer a reduction in our effectiveness.
Recently a high ranking DoD official stood up at a conference and said, "The DoD will never again buy a single aircraft with a single mission purpose". This DoD official has a lock on a job with television infomercials upon their retirement. The myth of the multi-mission aircraft remains strong within the Department of Defense. Although the Navy is still building the MP-8 multi-mission aircraft, the Air Force abandoned hopes for their version of a large multi-mission aircraft several years ago. Thank God. Back then it was called the E-10A and was destined to cost the country close to $500M dollars per copy. Oddly the multi-tool concept of lower cost broke down with the E-10A. Seems like bundling the capability should reduce its cost right? Not if you are placing two unique $200M dollar systems on a $100M dollar aircraft. But the real confusion existed in the operational concept for this multi-mission aircraft. Where would it fight? And which mission would have priority? Combining the mission of the JSTARS with the mission of the AWACS on a single platform seems, on the surface, to be a worthy goal. Until you realize the missions are vastly different. The JSTARS looks at what’s moving on the ground while the AWACS keeps an eye on what's flying in the air. Both missions must happen continuously. They fly two completely different radars both in frequency, power, and utilization. But of even greater importance is the fact that the two missions operate in separate areas of the battlefield. This operational information was lost from the very beginning. Sure, the technology could be made more comparable, after all both systems are radars. But to fly one to cover the JSTARS mission means a second one would have to be flying to cover the AWACS mission. Instead of two multi-tool jets costing the country $1B dollars, we could buy two dedicated jets (1 radar system a piece) that would cost a total of $600M thereby saving the country $400M, for which we could purchase a third jet and still return $100M to the national treasury. What were they thinking? The word we are searching for is multi-tool.
And it is this multi-tool mindset that continues to inspire our dreams and cloud our judgment. Here is another example. Dedicated mission aircraft, such as the JSTARS and AWACS have served proudly for decades. The promise of lower cost remotely piloted aircraft, serving a general purpose, non-dedicated aircraft has crept into our imagination. The highly publicized KC-X tanker has also raised the spectra of possibility to do more general purpose service in more mission areas. Using general purpose aircraft to fly non-dedicate missions has been a goal of transformation advocates for many years. If more of our mission systems could be placed into pods then any aircraft could be used to fly any mission. The flexibility of air power seemingly rises to the infinite in possibility. There is of course no free lunch as many would wish to believe. One senior Air Force official has said with regard to the application of a non-dedicated concept to the ISR mission, that, “…they [non-dedicated ISR concepts] have been the bane of my existence".
Non-dedicated operations break down because there are too many variables to control. We dedicate things when the mission is too important to delay, screw up, or fail…like fighting a war. Will there be an aircraft available? Have the generic systems on the aircraft been maintained? Will a higher priority mission bump our mission at the last minute? Many of these issues could be solved with proper technology. But we are talking about more than technology. People are involved. The technology could be ubiquitous. To a computer a one or a zero is still the same tomorrow as it was today. But it's the people who fight the wars. You wouldn't tell Mario Andretti to go out into the parking lot and pick a random car to drive in the Indianapolis 500. When we ask Air Force personnel to fly and operate sophisticated machinery, it's not just at a race on Sunday; it's in a war zone. It would be nice for them to have taken a few laps around the track first. Yes there is the right stuff mentality prevalent in all pilots, and Mario Andretti could probably smoke us all driving a Ford Focus, but that's not the right way to organize, train, and equip people for mortal combat.
We have to stop thinking with a one-size-fits-all mentality. We might think the benefit of technology is to enable one-size-fits-all. It does not. Technology may provide the infantry soldier an M-16 that is lighter, more powerful, and less likely to misfire. But it will not reduce the requirement to have an M-16 with a dedicated soldier behind the trigger. It will not reduce the reality that certain missions cannot be made stronger by combining them with those that are less strong. And those that are weak can be strengthened by combining them with those that are less weak. To think that technology enables every system to contribute according to its capability and every need can be filled with whatever capability is available sounds suspiciously like a failed system of government. It is not in any way like any war that has ever been fought and won. Warfare is not a social experiment nor is it a system of government. You win with weapons that work effectively applied with overwhelming force, and a whole lot of intelligence. Then one bullet must be fired from one rifle. Just ask Osama bin Laden. Giving Seal Team 6 a multi-tool doesn’t work.
The Socialization of Air Power
by Jim Muccio
Monday, October 14, 2019
Open Mission System Blues
Before we get to the military utility of open mission systems the reason for this website is security. Open architectures and open systems are more vulnerable to security breaches simply because the blue-prints to hack them are published and proliferated. Once that is done, the possibility of a single key fitting all locks becomes a possibility. Maybe the military utility of moving to an open architecture out-weighs that kind of risk? Doubtful. But generally, at least for this essay, I take aim at the subject of open mission systems and the perceived belief in their superiority. The increased lack of security is just another reason not to jump wholly onto this bandwagon.
It is sad to say but the trend in the DoD today with regard to open mission systems is not new when it comes to the hopeful belief in a technology that can solve multiple problems. Most technologist skip the best way to fight in combat and jump straight to a technology that can make things faster, smaller, and more integrated. They believe that somehow this jump to technology will make things better and magically increase combat power. That, of course, is the great promise and the free lunch. One such jump to technology is a belief in standards that drive open mission systems and subsequently open architectures. Both concepts have been in the game of buzzword bingo around the Pentagon for many years. It’s important to note that I believe in standards. Without them, we would have technological chaos and no internet…plus a railroad system riding on a national network of rails where the width of the track was decided by the Roman Empire chariot wheel separation. When we ask for standards, we must understand what we are asking for in the context of their employment. The great promise of Network Centric Warfare (Admiral Cembroski), the Navy Cooperative Engagement Capability (CEC), decades of Joint Integrated Fire Control (JIFC), and the long pursuit of such capability through the Joint Integrated Air and Missile Defense Organization (JIAMDO) were all envisioned by open standards upon which everything can communicate with everything else. Others organizations have also been enamored by the promise. Everything we build should talk to everything we build. It is the warfighting equivalent to the Internet of Things (IoT). Or so it goes. Well just what do open mission systems and open architectures actually mean and what are the ramifications of such technology (and buzzwords) on the future of DoD force structure and our ability to fight wars?
In his recent article for Defense News, General Goldfein the current Chief of Staff of the United States Air Force (CSAF) put forth his vision. He has embraced the buzzwords and authored a short article entitled, “Future wars will be won with open mission systems”. The article draws you in for its upbeat promise. Because, on the surface, the concept of open mission systems has merit. Unfortunately, it is a red herring from the stand point of what we should be doing. And it is an inefficient use of resources in the wrong hands. I’m saddened that the article came out of the highest echelons in the Air Force and wish someone with some background in the technology would have helped him edit the piece for accuracy. For the record, it’s not easy to critique the CSAF. One day I may work for the USAF again. For now, I can only fall back on often-quoted phrase about speaking truth to power...”Hey power, please listen, national blood and treasure is at stake”. So let us dive in.
The idea of integrated mission systems stemming from open architectures has been around since the very first soldier on the battlefield tried to coordinate fires or pass intelligence data through whatever means possible. You brought smoke signals? Oh hell, I brought two tin cans and some string. Skipping a few thousand years of military history, the poetic “One if by land, two if by sea”, speaks volumes to the merit of broadcasting a signal (open) that could get a coordinating word out to an intended recipient (integrated). Interestingly, this type of communication is known as a cue. It’s a tip-off that something is coming. Not a whole lot more information is contained in the signal but nevertheless it’s a signal of huge strategic value, or could be. It’s not the tactical signal that enables a Minuteman to shoot a Red Coat. As it turns out, forever captured in Revolutionary lore by poet Longfellow, the midnight ride of Paul Revere and his lanterns in the Old North Church, were redundant to the operation that evening in Boston. The lanterns were a back-up plan. The primary conduit for the signal was a messenger traveling across the Charles River by boat. Consider for a moment the bandwidth available in the two approaches, One, “the messenger” and two, “the lanterns” in the Old North Church. The messenger, with eyes on the movement of troops out of the Boston Common would be more accurate in every detail. Let's call that analog. On the other hand, the lanterns possess only a binary signal...and it’s important to note that one light or two lights is a binary signal with better positive affirmation than one light or no lights. Call it an early form of error correction.
Obviously, by saying binary my foreshadowing about coming digital technology is showing. That said, almost everything one needs to know about military communication is contained in this simple example. Anyone who has ever sent a text message tends to know that an email is superior. And a phone call is superior to an email. And a video chat is superior to a phone call. And a face to face meeting is superior to a video chat. But is that really true? Of course not. As a society, we would not be texting as much if texting did not provide a very relevant service at a low data rate. And an analog, face to face meeting, is expensive. But the difference is huge. It is the difference between attending Cirque du Soleil in person and watching it from your iPhone on YouTube. Paul Revere, from his flip phone (he never upgraded), standing behind a tree, peering upon the Boston Common, would probably have sent a text. And then followed up with an email. But a simple text would have gotten the job done. The message was strategic. The bits required to convey that, “The British are coming”, by land or by sea, few.
And that is the common misconception with regard to military communications. That somehow, more is better. Yes, more is better in some cases, as in an engagement solution that requires fire control quality data. The only way to achieve this level of accuracy is to pass high bandwidth information, straight from the sensor to the shooter. Superior to that, is for the weapon itself, to collect the required data in real time, at endgame, through its seeker. The following graph loosely depicts how much and when.
Strategically, we need less data and less often. Tactically, we need more data and more frequently. Gen Goldfein is a fighter pilot. That means he is a disciple of the OODA Loop and seemingly John Boyd theory's on maneuver warfare. Some of the best tacticians in the world are fighter pilots…but we win wars with strategy not tactics…getting inside someone's strategic OODA Loop requires thinking, not technology. When we chase a tactical solution to strategic problem, we are looking in the wrong direction. And that’s not to say in other circles, more strategic in nature, those folks (intelligence) would love technology to give them more, more, and then some more. This is very expensive and drives very expensive architectures, think satellites, with mixed results.
The pace of technology has caused many within the DoD to lose track of first principles. How and why we are here? Just because it is possible to watch a video on an iPhone, while inside a self-driving Tesla, and at the same time order dinner from PF Chang’s, does not mean an F-35 pilot should be texting home that it would be great to Chicken Fried Rice for dinner. And if you couldn’t order from PF Chang’s tonight, because GrubHub, hasn’t added PF Chang’s to their restaurant options yet, doesn’t mean you should be upset if the company who wrote the app did not push a new update for the new restaurant option on the very next day. If left unchecked, the DoD, will most certainly move in this direction. If you do not recognize the development cycle, I am speaking specifically about DevOps and the way Silicon Valley has revolutionized building software applications, quickly, and cloud based. Great for commercial markets, great for start-ups wanting to disrupt status quo, great for selling iPhones, and ordering pizza. However, not so great for fighting wars.
What many consider to be a problem, stovepipes, by stark contrast, are strangely the solution when in combat. The vision was originally directed at DoD system of systems (SoS) because of the perception that stove pipes are in actual need of integration. That is easy to understand if you consider the seeming incompetence of Lockheed Martin Corporation (or the United States Air Force), that developed two 5th generation stealth fighter aircraft, the F-22 and the F-35, that are unable to communicate with one another through their data links. Many would consider this to be a humiliation however the reality is something quite different. Consider for a minute the way things that can be connected shown below. All are valid and useful constructs. Some are more expensive than others. None have a monopoly on combat power although individuals chasing connectivity as an empowering solution will drive to “Fully Connected”.
A vision of an integrated future, and the reality of how the DoD fights wars, are two different things. JIAMDO labored for years to bring the DoD such things as JIFC and the Navy CEC. There was this great promise of enhancing military effectiveness by increasing combat power through integration. That promise has never materialized. Two things conspired to reduce the promise. One, there actually is no combat power increase when integrating systems. Kinetic energy is kinetic energy. You can't create energy by networking systems that deliver kinetic energy. And two, military concepts for operations (CONOPS), concepts for employment (CONEMPS), doctrine, and tactics, techniques, procedures (TTPs) are all developed to simplify the delivery of violent effects to reduce the fog and friction of war and increase the chance of survival of combat forces. That is why stove pipes emerge, not because of the lack of ability to integrate. You integrate what is necessary. What is necessary in combat are such things as ubiquitous knowledge of commander's intent. And some shared situational awareness (SA) of the battle space. You do not integrate at the end game. At the engagement, all focus must be on the last seconds before impact. Texting a dinner order home reduces your SA and more importantly reduces the probability of a successful engagement.
Here is how we build a layered air defense. Notice the engagement zones and more importantly where the kinetic effects zones are located. We intentionally isolate engagement zones to divide command and control and reduce fratricide. Technologist need to understand the CONOPS behind how we fight wars and not just how we plug into the internet.
A good example of an open architecture that did change the world is GPS. However, GPS is not well understood in this regard. GPS is not a technology that provides integration of multiple systems to a JDAM. GPS is a broadcast service that provides sufficient precision information to a JDAM in order for it to divine its own location. Even though the timing signal that GPS provides becomes enticing, it a red herring if pursuing multiple communications systems that should be able to communicate with one another simply because there is a exquisite timing source upon which to synchronize. GPS provides a ubiquitous service for location and navigation accuracy that an engagement sensor uses to precisely position itself at endgame. Beyond that it is a dumb signal conveying nothing smarter to the weapon no better than the coordinates that were loaded into the weapon. If those coordinates are inaccurate, the JDAM will guide precisely to the wrong coordinates. Use of that signal for timing has become ubiquitous as well because most of the world is not dropping JDAM. But unlike an autonomous JDAM that calculates its own trajectory off the signal, systems that communicate integrate with each other using the timing to synchronize. It’s not the fault of GPS if you can’t make your own integration synchronization work because the signal fails, for whatever reason. To date many millions of dollars still pour into fixing vulnerabilities that arise from using the GPS timing signal for military communications having discovered that it is easy for an adversary to deny systems the use of that GPS timing signal. When we emerge on the other side of that understanding, which I hope is the defense department's ubiquitous use of GPS-III with M-Code, we will be better off for it, but we should have learned a valuable lesson from this history.
A better lesson, and one that Gen Goldfein incorrectly tries to use from history is the development of the SAGE program some 70 years ago, to illustrate his point about the success for open architectures. Given that SAGE was the most advanced integrated warfighting (and computing system) of it’s time, it was far from what anyone could possibly confuse with what we describe as an open architecture today. Nothing existed back then. It all had to be created from scratch. It was it’s own stove pipe on a national level. Anything that touched it had to comply with the protocol as it existed. Granted, in today’s terms, the protocol was not sophisticated. Bit’s that flowed across networks could pass with 1 and 2 bit error correction code. One of the first uses of bit error correction. It was an integrated air defense systems built throughout the United States with the mission beating back a nuclear attack by the Soviet Union. A first of it’s kind and it’s development ushered in the computer age. A worthy reference but far from an integrated and open system. Early on it was programmed in machine language, with coders leaning octal. In later stages, Systems Development Corporation (SDC), an off-shoot of RAND Corporation, invented Jovial for programmers to begin developing code in one of the very first higher level programming languages. This is hardly the right historical reference to define open systems. My dad, a developer on the SAGE system, has plenty of war stories to tell about, reprogramming the radar detection zones, in one case to search for missing aircraft outside the displayed coverage regions of a radar on a Texas Towers off the east coast. In another case, during a national exercise, the simulated tracks of inbound Soviet bombers were not being displayed in the command center. Patching the binary to set the proper flag to allow the simulated tracks through to the command center was perhaps the first real time hack in SAGE history. Communication protocols between radar sites and higher echelons had to be created. They were not copied and implemented from libraries. Forward error correction grew up out of necessity. And what about encryption...seriously?
Gen Goldfein, please don’t reference the SAGE system as some shiny beacon of integration and the perfect example of an open systems architecture out of history...it’s so inappropriate for your discussion. At best it was a National level stove-pipe kluge of many things. Uniquely built, uniquely run, and uniquely upgraded on a vast scale. Instead, reference the failure that was the E-10A and that program heavily birthed out of the JIFC communities. Let’s learn from a disaster of a program. I’m going to state for the record that nobody in the Pentagon knew the mission of that aircraft. When I briefed COMACC a few years ago, and stated that very fact. COMACC told me point-blank in his conference room, surrounded by his cohort of O-6's, who I had briefed previously (but failed to come to my rescue) the harsh words, “Don’t ever fucking say that again”, and yes he used the F-bomb. I will not say which COMACC or when that happened, but I will say, he was dead wrong. At that moment, it was not necessary for me to correct him (nor would I have) or for his council of colonels to come to my rescue. Everything he needed to know was contained in my briefing so I moved forward. If you have three hours, and a full three hours, I’ll walk you through the analysis. Our analysis decimated the E-10A. In the words of one engineer from Hanscom AFB who had labored on the program for 10 years, "I felt like I just found out my wife had been cheating on me". Nobody knew the mission of that aircraft. Nobody really wanted to know. Everybody had their eyes on the $51B in new funding. Or a combat career field for the C3ISR community. What was uncovered was a series of misunderstandings (to be generous) or out and out deceptions from the program office. The greatest perhaps was the MP-RTIP Radar. That stands for Multi-Platform Radar Technology Insertion Program. The promise was a scalable radar for use on many different platforms. The reality was that there was nothing common beyond the backend software. Where is the E-10A today? I still remember as vividly as yesterday when the light turned on for the first Senior Executive in the chain on the way to the fateful day with COMACC. The executive pushed himself clear of the table and announced to the room, “That will be the death of the E-10A’. After that, I spent a few years looking over my shoulder for those who were not happy with that particular outcome.
Simply stated, those involved in the research and development of new technology for our military are not the ones who have to pull the trigger. Thus, the warfighter wants a system that works, is robust, is reliable, and enables their CONOPS. The channel must be understood completely, and must be impervious to disruption, and above all, completely reliable. Anything else will get left on the sideline. There is enough fog of war without the uncertainty of the cloud of technology. Simple is always better. Kick it simple stupid. But there is more.
Warfighting systems fight in stove-pipes by design. Stovepipes fight in kinetically restricted baskets that optimize their effectiveness and outcomes. They only touch command and control (C2) at their periphery for shared SA and commands from higher echelons. This is why, even if all systems had open architectures to allow fire control quality information and passed engagement solutions to be past amongst themselves, the majority of that information wouldn't be used. The engagement solution is predetermined by very restricted physical limitations governed by kinematics. The engagement solution is also predetermined by the forces in contact alongside the pre-established operating and engagement zones, for multiple reasons but of specific note, to prevent fratricide.
I’m not saying communications standards are not necessary and shouldn’t be considered when building a system. Standards are a good thing in many cases when they actually exist. But when solutions are necessary in areas where technology is literally being invented as is the case in most military systems, imposing standards reduces the design space for the engineers and increases the overhead they have to carry. Computers and any system on the ground can tolerate those increases in size, weight, and power. Military systems that roll, fly, sail, or orbit are significantly different. Asking engineers to pack more and more into a design does not save money…it increases the complexity of the design, waters down any specific capability, reduces its ability to function correctly, and delays it’s development timeline. Think well Gen Goldfein before you take our Air Force into that particular future…that feels more like Silicon Valley then the Department of Defense…
It is sad to say but the trend in the DoD today with regard to open mission systems is not new when it comes to the hopeful belief in a technology that can solve multiple problems. Most technologist skip the best way to fight in combat and jump straight to a technology that can make things faster, smaller, and more integrated. They believe that somehow this jump to technology will make things better and magically increase combat power. That, of course, is the great promise and the free lunch. One such jump to technology is a belief in standards that drive open mission systems and subsequently open architectures. Both concepts have been in the game of buzzword bingo around the Pentagon for many years. It’s important to note that I believe in standards. Without them, we would have technological chaos and no internet…plus a railroad system riding on a national network of rails where the width of the track was decided by the Roman Empire chariot wheel separation. When we ask for standards, we must understand what we are asking for in the context of their employment. The great promise of Network Centric Warfare (Admiral Cembroski), the Navy Cooperative Engagement Capability (CEC), decades of Joint Integrated Fire Control (JIFC), and the long pursuit of such capability through the Joint Integrated Air and Missile Defense Organization (JIAMDO) were all envisioned by open standards upon which everything can communicate with everything else. Others organizations have also been enamored by the promise. Everything we build should talk to everything we build. It is the warfighting equivalent to the Internet of Things (IoT). Or so it goes. Well just what do open mission systems and open architectures actually mean and what are the ramifications of such technology (and buzzwords) on the future of DoD force structure and our ability to fight wars?
In his recent article for Defense News, General Goldfein the current Chief of Staff of the United States Air Force (CSAF) put forth his vision. He has embraced the buzzwords and authored a short article entitled, “Future wars will be won with open mission systems”. The article draws you in for its upbeat promise. Because, on the surface, the concept of open mission systems has merit. Unfortunately, it is a red herring from the stand point of what we should be doing. And it is an inefficient use of resources in the wrong hands. I’m saddened that the article came out of the highest echelons in the Air Force and wish someone with some background in the technology would have helped him edit the piece for accuracy. For the record, it’s not easy to critique the CSAF. One day I may work for the USAF again. For now, I can only fall back on often-quoted phrase about speaking truth to power...”Hey power, please listen, national blood and treasure is at stake”. So let us dive in.
The idea of integrated mission systems stemming from open architectures has been around since the very first soldier on the battlefield tried to coordinate fires or pass intelligence data through whatever means possible. You brought smoke signals? Oh hell, I brought two tin cans and some string. Skipping a few thousand years of military history, the poetic “One if by land, two if by sea”, speaks volumes to the merit of broadcasting a signal (open) that could get a coordinating word out to an intended recipient (integrated). Interestingly, this type of communication is known as a cue. It’s a tip-off that something is coming. Not a whole lot more information is contained in the signal but nevertheless it’s a signal of huge strategic value, or could be. It’s not the tactical signal that enables a Minuteman to shoot a Red Coat. As it turns out, forever captured in Revolutionary lore by poet Longfellow, the midnight ride of Paul Revere and his lanterns in the Old North Church, were redundant to the operation that evening in Boston. The lanterns were a back-up plan. The primary conduit for the signal was a messenger traveling across the Charles River by boat. Consider for a moment the bandwidth available in the two approaches, One, “the messenger” and two, “the lanterns” in the Old North Church. The messenger, with eyes on the movement of troops out of the Boston Common would be more accurate in every detail. Let's call that analog. On the other hand, the lanterns possess only a binary signal...and it’s important to note that one light or two lights is a binary signal with better positive affirmation than one light or no lights. Call it an early form of error correction.
Obviously, by saying binary my foreshadowing about coming digital technology is showing. That said, almost everything one needs to know about military communication is contained in this simple example. Anyone who has ever sent a text message tends to know that an email is superior. And a phone call is superior to an email. And a video chat is superior to a phone call. And a face to face meeting is superior to a video chat. But is that really true? Of course not. As a society, we would not be texting as much if texting did not provide a very relevant service at a low data rate. And an analog, face to face meeting, is expensive. But the difference is huge. It is the difference between attending Cirque du Soleil in person and watching it from your iPhone on YouTube. Paul Revere, from his flip phone (he never upgraded), standing behind a tree, peering upon the Boston Common, would probably have sent a text. And then followed up with an email. But a simple text would have gotten the job done. The message was strategic. The bits required to convey that, “The British are coming”, by land or by sea, few.
And that is the common misconception with regard to military communications. That somehow, more is better. Yes, more is better in some cases, as in an engagement solution that requires fire control quality data. The only way to achieve this level of accuracy is to pass high bandwidth information, straight from the sensor to the shooter. Superior to that, is for the weapon itself, to collect the required data in real time, at endgame, through its seeker. The following graph loosely depicts how much and when.
Strategically, we need less data and less often. Tactically, we need more data and more frequently. Gen Goldfein is a fighter pilot. That means he is a disciple of the OODA Loop and seemingly John Boyd theory's on maneuver warfare. Some of the best tacticians in the world are fighter pilots…but we win wars with strategy not tactics…getting inside someone's strategic OODA Loop requires thinking, not technology. When we chase a tactical solution to strategic problem, we are looking in the wrong direction. And that’s not to say in other circles, more strategic in nature, those folks (intelligence) would love technology to give them more, more, and then some more. This is very expensive and drives very expensive architectures, think satellites, with mixed results.
The pace of technology has caused many within the DoD to lose track of first principles. How and why we are here? Just because it is possible to watch a video on an iPhone, while inside a self-driving Tesla, and at the same time order dinner from PF Chang’s, does not mean an F-35 pilot should be texting home that it would be great to Chicken Fried Rice for dinner. And if you couldn’t order from PF Chang’s tonight, because GrubHub, hasn’t added PF Chang’s to their restaurant options yet, doesn’t mean you should be upset if the company who wrote the app did not push a new update for the new restaurant option on the very next day. If left unchecked, the DoD, will most certainly move in this direction. If you do not recognize the development cycle, I am speaking specifically about DevOps and the way Silicon Valley has revolutionized building software applications, quickly, and cloud based. Great for commercial markets, great for start-ups wanting to disrupt status quo, great for selling iPhones, and ordering pizza. However, not so great for fighting wars.
What many consider to be a problem, stovepipes, by stark contrast, are strangely the solution when in combat. The vision was originally directed at DoD system of systems (SoS) because of the perception that stove pipes are in actual need of integration. That is easy to understand if you consider the seeming incompetence of Lockheed Martin Corporation (or the United States Air Force), that developed two 5th generation stealth fighter aircraft, the F-22 and the F-35, that are unable to communicate with one another through their data links. Many would consider this to be a humiliation however the reality is something quite different. Consider for a minute the way things that can be connected shown below. All are valid and useful constructs. Some are more expensive than others. None have a monopoly on combat power although individuals chasing connectivity as an empowering solution will drive to “Fully Connected”.
A vision of an integrated future, and the reality of how the DoD fights wars, are two different things. JIAMDO labored for years to bring the DoD such things as JIFC and the Navy CEC. There was this great promise of enhancing military effectiveness by increasing combat power through integration. That promise has never materialized. Two things conspired to reduce the promise. One, there actually is no combat power increase when integrating systems. Kinetic energy is kinetic energy. You can't create energy by networking systems that deliver kinetic energy. And two, military concepts for operations (CONOPS), concepts for employment (CONEMPS), doctrine, and tactics, techniques, procedures (TTPs) are all developed to simplify the delivery of violent effects to reduce the fog and friction of war and increase the chance of survival of combat forces. That is why stove pipes emerge, not because of the lack of ability to integrate. You integrate what is necessary. What is necessary in combat are such things as ubiquitous knowledge of commander's intent. And some shared situational awareness (SA) of the battle space. You do not integrate at the end game. At the engagement, all focus must be on the last seconds before impact. Texting a dinner order home reduces your SA and more importantly reduces the probability of a successful engagement.
Here is how we build a layered air defense. Notice the engagement zones and more importantly where the kinetic effects zones are located. We intentionally isolate engagement zones to divide command and control and reduce fratricide. Technologist need to understand the CONOPS behind how we fight wars and not just how we plug into the internet.
A good example of an open architecture that did change the world is GPS. However, GPS is not well understood in this regard. GPS is not a technology that provides integration of multiple systems to a JDAM. GPS is a broadcast service that provides sufficient precision information to a JDAM in order for it to divine its own location. Even though the timing signal that GPS provides becomes enticing, it a red herring if pursuing multiple communications systems that should be able to communicate with one another simply because there is a exquisite timing source upon which to synchronize. GPS provides a ubiquitous service for location and navigation accuracy that an engagement sensor uses to precisely position itself at endgame. Beyond that it is a dumb signal conveying nothing smarter to the weapon no better than the coordinates that were loaded into the weapon. If those coordinates are inaccurate, the JDAM will guide precisely to the wrong coordinates. Use of that signal for timing has become ubiquitous as well because most of the world is not dropping JDAM. But unlike an autonomous JDAM that calculates its own trajectory off the signal, systems that communicate integrate with each other using the timing to synchronize. It’s not the fault of GPS if you can’t make your own integration synchronization work because the signal fails, for whatever reason. To date many millions of dollars still pour into fixing vulnerabilities that arise from using the GPS timing signal for military communications having discovered that it is easy for an adversary to deny systems the use of that GPS timing signal. When we emerge on the other side of that understanding, which I hope is the defense department's ubiquitous use of GPS-III with M-Code, we will be better off for it, but we should have learned a valuable lesson from this history.
A better lesson, and one that Gen Goldfein incorrectly tries to use from history is the development of the SAGE program some 70 years ago, to illustrate his point about the success for open architectures. Given that SAGE was the most advanced integrated warfighting (and computing system) of it’s time, it was far from what anyone could possibly confuse with what we describe as an open architecture today. Nothing existed back then. It all had to be created from scratch. It was it’s own stove pipe on a national level. Anything that touched it had to comply with the protocol as it existed. Granted, in today’s terms, the protocol was not sophisticated. Bit’s that flowed across networks could pass with 1 and 2 bit error correction code. One of the first uses of bit error correction. It was an integrated air defense systems built throughout the United States with the mission beating back a nuclear attack by the Soviet Union. A first of it’s kind and it’s development ushered in the computer age. A worthy reference but far from an integrated and open system. Early on it was programmed in machine language, with coders leaning octal. In later stages, Systems Development Corporation (SDC), an off-shoot of RAND Corporation, invented Jovial for programmers to begin developing code in one of the very first higher level programming languages. This is hardly the right historical reference to define open systems. My dad, a developer on the SAGE system, has plenty of war stories to tell about, reprogramming the radar detection zones, in one case to search for missing aircraft outside the displayed coverage regions of a radar on a Texas Towers off the east coast. In another case, during a national exercise, the simulated tracks of inbound Soviet bombers were not being displayed in the command center. Patching the binary to set the proper flag to allow the simulated tracks through to the command center was perhaps the first real time hack in SAGE history. Communication protocols between radar sites and higher echelons had to be created. They were not copied and implemented from libraries. Forward error correction grew up out of necessity. And what about encryption...seriously?
Gen Goldfein, please don’t reference the SAGE system as some shiny beacon of integration and the perfect example of an open systems architecture out of history...it’s so inappropriate for your discussion. At best it was a National level stove-pipe kluge of many things. Uniquely built, uniquely run, and uniquely upgraded on a vast scale. Instead, reference the failure that was the E-10A and that program heavily birthed out of the JIFC communities. Let’s learn from a disaster of a program. I’m going to state for the record that nobody in the Pentagon knew the mission of that aircraft. When I briefed COMACC a few years ago, and stated that very fact. COMACC told me point-blank in his conference room, surrounded by his cohort of O-6's, who I had briefed previously (but failed to come to my rescue) the harsh words, “Don’t ever fucking say that again”, and yes he used the F-bomb. I will not say which COMACC or when that happened, but I will say, he was dead wrong. At that moment, it was not necessary for me to correct him (nor would I have) or for his council of colonels to come to my rescue. Everything he needed to know was contained in my briefing so I moved forward. If you have three hours, and a full three hours, I’ll walk you through the analysis. Our analysis decimated the E-10A. In the words of one engineer from Hanscom AFB who had labored on the program for 10 years, "I felt like I just found out my wife had been cheating on me". Nobody knew the mission of that aircraft. Nobody really wanted to know. Everybody had their eyes on the $51B in new funding. Or a combat career field for the C3ISR community. What was uncovered was a series of misunderstandings (to be generous) or out and out deceptions from the program office. The greatest perhaps was the MP-RTIP Radar. That stands for Multi-Platform Radar Technology Insertion Program. The promise was a scalable radar for use on many different platforms. The reality was that there was nothing common beyond the backend software. Where is the E-10A today? I still remember as vividly as yesterday when the light turned on for the first Senior Executive in the chain on the way to the fateful day with COMACC. The executive pushed himself clear of the table and announced to the room, “That will be the death of the E-10A’. After that, I spent a few years looking over my shoulder for those who were not happy with that particular outcome.
Simply stated, those involved in the research and development of new technology for our military are not the ones who have to pull the trigger. Thus, the warfighter wants a system that works, is robust, is reliable, and enables their CONOPS. The channel must be understood completely, and must be impervious to disruption, and above all, completely reliable. Anything else will get left on the sideline. There is enough fog of war without the uncertainty of the cloud of technology. Simple is always better. Kick it simple stupid. But there is more.
Warfighting systems fight in stove-pipes by design. Stovepipes fight in kinetically restricted baskets that optimize their effectiveness and outcomes. They only touch command and control (C2) at their periphery for shared SA and commands from higher echelons. This is why, even if all systems had open architectures to allow fire control quality information and passed engagement solutions to be past amongst themselves, the majority of that information wouldn't be used. The engagement solution is predetermined by very restricted physical limitations governed by kinematics. The engagement solution is also predetermined by the forces in contact alongside the pre-established operating and engagement zones, for multiple reasons but of specific note, to prevent fratricide.
I’m not saying communications standards are not necessary and shouldn’t be considered when building a system. Standards are a good thing in many cases when they actually exist. But when solutions are necessary in areas where technology is literally being invented as is the case in most military systems, imposing standards reduces the design space for the engineers and increases the overhead they have to carry. Computers and any system on the ground can tolerate those increases in size, weight, and power. Military systems that roll, fly, sail, or orbit are significantly different. Asking engineers to pack more and more into a design does not save money…it increases the complexity of the design, waters down any specific capability, reduces its ability to function correctly, and delays it’s development timeline. Think well Gen Goldfein before you take our Air Force into that particular future…that feels more like Silicon Valley then the Department of Defense…
Saturday, September 21, 2019
First Blood - Letter to the Editor for AF Magazine Sept 2019
The Editors,
In her article "SOFT WARE" about the Star-Warsian revolution in code development occurring inside the Air Force, Rachel Cohen has taken us in the wrong direction by glorifying bad coding practice. Ironically, she points out the worry that a new DevOps mindset in the military, "…may be stymied by cultural resistance." Well count me as the start of the cultural resistance. Ms. Cohen's article will hopefully rally push-back from those who are trying to defend this Country from cyber-attack.
First principal of the resistance should be to block development of code for our military systems in the DevOps manner described in the article. In fairness it's not Ms. Cohen's fault, she was trying to report on something she was being told. Those who were interviewed didn't point out the hidden side of a cool App. The dark side--where vulnerabilities inherent in open source code and other rapid coding practices live.
We are vulnerable enough to the everyday run-of-the-mill adolescent in their mother's basement using social engineering and script-kitty skills aided by dark web services to make a hacker capable of conducting grade school DDOS or ransomware attacks. Beyond that nuisance, our second-rate adversaries, ISIS and 3rd world countries among them, have demonstrated increasing skills and are gunning for us with teams of better mercenary hackers. Finally, the best in the world from countries like China and Russia, pour resources into supply chain attacks (Huawei and ZTE), attacks against embedded systems and networks (SCADA, ICS, IOT) as well as our strategic military C2 networks. Not to mention the daily influence attacks happening within our social media. If we can't rely on some systems, preferably our military systems, we place at risk our national standard of living for our citizens and the lives of our soldiers, sailors, airmen and marines who have offered their service in hostile environments.
Given this onslaught, anyone who permits a block of code from an open source to be written into software attached to a military system should look for a new job. The metric for evaluating software should not be how rapidly an application is up and running but whether or not it can provide a secure and assured function. This battle will continue far into the future and is on the cusp of becoming automated by robots and other automatons running algorithms with vast scale.w We wage this battle with our adversaries. We should not be fighting within our own military development organizations on proper coding practices. We would never put weapons on an aircraft with inferior or untested parts. This is a culture that should not be changed whimsically.
It should be noted here that I am not sounding the Cyber Doomsday alarm. I'm simply saying let's not have ID.1.Zero-T deficiencies in our code. And I get it, one way to try to recruit coders away from the lure of Silicon Valley is to be like Silicon Valley. And we certainly are losing talent to commercial industry…continuously. They are high paid and the applications are cool. But we must find other ways to motivate high end software talent to join our ranks. We might have to adjust and let them keep their environment of t-shirts, the brainstorming, stickie notes, pizza boxes, and dogs at work. The real solution will come in the form of a shared government GitHub with assured code, assured tools, and an integration environment that will link all developers together in an enclave with advanced tools at their fingertips with everyone sharing found vulnerabilities and using automation to check and recheck. Those tools will help them not only write code, but will help them write assured and secure code. Those are the initiatives we should invest in, not the flash of Silicon Valley with the work ethic that brought us the "Fake it till you Make it" culture. The tools exist for such an enclave to be built today. Development environments such as those provided by Green Hills will lead this charge. Other companies such as Red Balloon, Trail of Bits, Vector 35, Cromulus, For All Secure, Galois and it's off -shoot TangramFlex, alongside Guardtime Federal all have the talent and the tools under development to take things further. But such an enclave would require breaking down proprietary walls and reducing other impediments not so easily solved with Red Bull and pizza. That initiative will cost money. But that's the vector we should be following. I recommend Air Force Magazine send Rachel Cohen to report on DEFCON next year to report on a counter perspective.
Jim "Mooch" Muccio
Fairfax, VA
Mooch has spent his career supporting the USAF in various capacities primarily as a civilian analyst conducting force structure analysis of air, space, and cyber forces. He is currently assisting DARPA usher in a new age of cyber tools for the Country.
In her article "SOFT WARE" about the Star-Warsian revolution in code development occurring inside the Air Force, Rachel Cohen has taken us in the wrong direction by glorifying bad coding practice. Ironically, she points out the worry that a new DevOps mindset in the military, "…may be stymied by cultural resistance." Well count me as the start of the cultural resistance. Ms. Cohen's article will hopefully rally push-back from those who are trying to defend this Country from cyber-attack.
First principal of the resistance should be to block development of code for our military systems in the DevOps manner described in the article. In fairness it's not Ms. Cohen's fault, she was trying to report on something she was being told. Those who were interviewed didn't point out the hidden side of a cool App. The dark side--where vulnerabilities inherent in open source code and other rapid coding practices live.
We are vulnerable enough to the everyday run-of-the-mill adolescent in their mother's basement using social engineering and script-kitty skills aided by dark web services to make a hacker capable of conducting grade school DDOS or ransomware attacks. Beyond that nuisance, our second-rate adversaries, ISIS and 3rd world countries among them, have demonstrated increasing skills and are gunning for us with teams of better mercenary hackers. Finally, the best in the world from countries like China and Russia, pour resources into supply chain attacks (Huawei and ZTE), attacks against embedded systems and networks (SCADA, ICS, IOT) as well as our strategic military C2 networks. Not to mention the daily influence attacks happening within our social media. If we can't rely on some systems, preferably our military systems, we place at risk our national standard of living for our citizens and the lives of our soldiers, sailors, airmen and marines who have offered their service in hostile environments.
Given this onslaught, anyone who permits a block of code from an open source to be written into software attached to a military system should look for a new job. The metric for evaluating software should not be how rapidly an application is up and running but whether or not it can provide a secure and assured function. This battle will continue far into the future and is on the cusp of becoming automated by robots and other automatons running algorithms with vast scale.w We wage this battle with our adversaries. We should not be fighting within our own military development organizations on proper coding practices. We would never put weapons on an aircraft with inferior or untested parts. This is a culture that should not be changed whimsically.
It should be noted here that I am not sounding the Cyber Doomsday alarm. I'm simply saying let's not have ID.1.Zero-T deficiencies in our code. And I get it, one way to try to recruit coders away from the lure of Silicon Valley is to be like Silicon Valley. And we certainly are losing talent to commercial industry…continuously. They are high paid and the applications are cool. But we must find other ways to motivate high end software talent to join our ranks. We might have to adjust and let them keep their environment of t-shirts, the brainstorming, stickie notes, pizza boxes, and dogs at work. The real solution will come in the form of a shared government GitHub with assured code, assured tools, and an integration environment that will link all developers together in an enclave with advanced tools at their fingertips with everyone sharing found vulnerabilities and using automation to check and recheck. Those tools will help them not only write code, but will help them write assured and secure code. Those are the initiatives we should invest in, not the flash of Silicon Valley with the work ethic that brought us the "Fake it till you Make it" culture. The tools exist for such an enclave to be built today. Development environments such as those provided by Green Hills will lead this charge. Other companies such as Red Balloon, Trail of Bits, Vector 35, Cromulus, For All Secure, Galois and it's off -shoot TangramFlex, alongside Guardtime Federal all have the talent and the tools under development to take things further. But such an enclave would require breaking down proprietary walls and reducing other impediments not so easily solved with Red Bull and pizza. That initiative will cost money. But that's the vector we should be following. I recommend Air Force Magazine send Rachel Cohen to report on DEFCON next year to report on a counter perspective.
Jim "Mooch" Muccio
Fairfax, VA
Mooch has spent his career supporting the USAF in various capacities primarily as a civilian analyst conducting force structure analysis of air, space, and cyber forces. He is currently assisting DARPA usher in a new age of cyber tools for the Country.
Subscribe to:
Posts (Atom)