A Turkey on Thanksgiving

Nicolas Chaillan has done it again.  From his new perch outside the Air Force looking in, he has been extremely critical of our military/industrial complex and prescribed an Rx for the cure against China that can win in six months.  And his echo chamber has responded with accolades.  No critical thought has emerged as to the efficacy of his ideas.  He just says them outright.  Everyone is frustrated with the status quo so agile change, under DevOps is the solution.  Of the current comments (137) I read two which may have contained some critical push back.   One, that six months is unrealistic despite the merit of the intent, and two we probably should be more worried about hypersonic systems being developed in China than AI.  I, of course, agree with both of those comments, but there are many more that exist in this article that have been left unsaid in Chaillan’s vision/version of winning with Silicon Valley principles.  I have written my comments here.  

Here is his Od-ed piece if you want to read it.  

The Pentagon needs a new AI strategy to catch up with China | Financial Times (ft.com)

and his Op-ed he posted on LinkedIN

Let's catch-up with China within 6 months (linkedin.com)

I don't want to spend my entire Thanksgiving holiday responding to his Op-ed in the Financial times and his link to this post.  But I do have to make several comments.   Let's start with his academics. Chaillan, of course, cites the problem with China as captured by Christian Brose in the book "The Kill Chain" and implores everyone to read it.  This book ignores centuries of warfighting history and aside from the honor of Brose having worked for, and with, Senator John McCain, falls well short of understanding how we fight wars.  At the end of the book, Brose does capture the political struggles inside the beltway accurately.  It’s worth reading for that reason, but not the warfighting parts. For the record, academically, the other book Chaillan has read, "A Seat at the Table" falls well short of a solution for the DoD. Software agility alone does not win wars even if you couple it with the magic of AI.  Acquisition agility, alone, also does not close the OODA Loop.  If you study John Boyd, in depth, in particular he’s thoughts on both “Maneuver Warfare” and “Destruction and Creation”, rather than his OODA Loop alone, you get a sense of what innovation is really about, particularly when systems must evolve.  And when I say systems, I mean warfighting hardware.  This the hardware in the physical realm that will kill people and break things.  Not the software.

 Also, his recipe for winning can only be applied to the acquisition of things.  And I’ll agree, acquisition is a fun place to be, because what's not cool about building something shiny and new, winding it up, and testing it?  Unfortunately, within our DoD, one could spend their entire career inside a single acquisition channel and never see the system that one has labored on for decades ever be adopted for use.  This is frustrating for those individuals on that evolutionary path, but evolutionarily speaking, entire species spend their entire natural life on a path that ends.  Dinosaurs, for which I am surely one, found that out...until one realizes that every bird around us, came from a dinosaur.  We need many things in development to be agile.  We don’t survive evolutionarily because everyone moves to the mountain in the face of a flood.  We move to the top of the mountain, we move over the mountain, we move to a different shoreline.  Natural selection doesn’t actually choose.  Those who survive are chosen by default.

Organizing, training, and equipping the Department of Defense, alone, does not win wars.  In fact, the entire DoD alone, does not win wars.  National Security is a whole government enterprise.  All instruments of national power must be aligned, along with the will of the people, and brought to bear against our adversaries.  That's not easy to do in any government.  It's very easy to do in North Korea, where you can execute (murder) for example, the students and teachers, who might bring in subversive material (Squid Game as an example), or easier, within a government that can control much of the public dialogue in the press, and mandate more exacting use of standards and protocols so systems can integrate. Even then, if you don't think there is infighting within China (and Russia) about the use of standards for military hardware and the optimization of warfighting effectiveness, you haven't been reading about China (or Russia).

So…if I had the time, I would write an academic paper on each of the things that Chaillan should be checked on…and asked to show us his homework.  John Boyd would ask to see his homework.  My fear is that when we ask, he will tell us his dog ate it.  But here we go…

1) Software is never done- how does this notion not cost more over the lifetime of a system?

2) If you remove IP you remove profit incentives from a capitalist enterprise.  How do hardware companies build hardware for profit that can be taken from them and given to their competitors?  Pretty sure Silicon Valley runs on proprietary IP, the only thing many companies have.

3) DevOps is an unsecure thing.  SecDevOps is putting lipstick on an unsecure thing, what makes SecDevOps secure?  And why can’t we allow our Prime’s do it within their own secure ecosystems?

4) Decision making at the point of work?  That works with widgets, not on the F-35.  How does a software guy working on a fusion algorithm for the F-35 make a decision about the entire aircraft, or more importantly, how a pilot in combat will use that algorithm?

5) Not creating silos fundamentally misses how we fight wars.  Reading books like the "Kill Chain" which doesn't define a single kill chain, will give you this impression.  Explain how netted warfare increases combat power?  This is a fallacy for which many in the NCW business have fallen prey, not just Chaillan and Brose.

6) How can we possibly accept increased risk of insider threat?  First, the insider threat eliminates any chance of #3 above being real.  Second, one insider threat, like Snowden, is all it takes.

7) Just so I’m labeled as a total troll, although I’ll accept the label, one view of the world I agree with Chaillan on is the necessity for increased data sharing...not so much to share widely in both public and private partnership unless under classified agreements/contracts.  But we should find ways to return to the DoD Post 9//11 sharing of data with the IC prior to the Snowden situation (one single insider) and lockdown.  Again, see #3 and #6 above.

I am not denying that China is a threat...  I'm saying that we don't win by catching up to China with AI in the next six months.  It is dangerous if we try.   We win, by continuing to push technology through capitalist principles and solving problems like energy ubiquity.  We need more energy.    Find more energy while continuing to defend and secure our infrastructure while building warfighting hardware optimized for fighting in an effective kill chain.  Then we organize around these kill chains, we already are.  And train relentlessly to fight.  We already do.  To be clear, a kill chain is not a kill web.  Brose is talking about a nonexistent kill web.  To fight everywhere, is akin to defending everywhere.  Must I quote, Alexander the Great?  I will, “To defend everywhere is to defend nowhere.”  The same is true for the offensive projection of force.  That’s an impossible pipe dream…we don’t achieve it with hardware or software.  It’s unachievable.  

In closing, I just have to point out that Chaillan also takes a swipe at DARPA.  That’s truly odd.  Of course, DARPA is not above criticism...however as an organization that defines most of the agility he craves, an organization that has broken the stove pipes, an organization that moves quickly, with the ability to fail often, and with decisions being made at the edge, he totally doesn't understand that organization.  That is a very strange snipe when there are so many other things wrong with DoD Acquisition for him to focus his ire on.

Defining a Real Kill Chain

 

A new book making the rounds inside the Beltway is entitled, “The Kill Chain, Defending America in the Future of High-Tech Warfare”. Written by Christian Brose, a former speech writer for Condoleezza Rice, a defense policy advisor to Senator McCain. Brose creates a rally cry to reform the military industrial complex into something that resembles Silicon Valley. Specifically, Brose believes that our military has atrophied over the past two decades and if we fight a war with China, for example, we would lose. The only way to reestablish our global dominance and prevail over China is to fix our Department of Defense (DoD) through the adaptation of the high-tech innovation and the speed of product delivery demonstrated by many successful commercial companies in Northern California. Brose spent a good deal of time with Senator McCain and shared conversations with him in this book. Those discussions reflect McCain’s love of country and desire for the US not to fall behind our near peer adversaries. Beyond that, as a beltway insider myself, I’ve spent many of the same years inside the halls of the Pentagon and see things a bit differently. I’ll describe some of that in this review.

While perhaps unknown to many Americans, the colorful phrase used by David Ockmanek to describe to Brose what happens if we engage in a war with China was a common phrase used inside the Pentagon. That phrase, “We get our ‘a**’ handed to us”, never gets old. The outcome of a direct engagement with the Chinese has been dubious for some time despite what Brose has reported. The scenarios Ockmanek refers to, those in which we lose, are purposefully designed to do analysis of force structure. Not develop a plan to actually fight a war with China. The question is one of how big a military force should we procure? Balancing dollars vs quasi-realistic scenarios is at the heart of the force structure analysis business. If we are considering a direct assault on China, something beyond deterring their aggression in the South China Sea, or deflecting an attack by them on Taiwan, I have not read any of that in any current, or past, National Defense Strategy. Thus, Brose believes independently that either 1) our force must be large enough to provide a winning hit on the Chinese to deter their aggression or 2) our force must change with advanced technology to provide the same deterrence value.

Brose reports that if we are not doing either of those two things we are in a losing proposition against China. Brose completely misses that fact that deterrence against a near peer will never emerge though a conventional engagement alone. Rather, deterrence comes from all levers of National power including military, diplomatic, and economic. Specifically related to defense, Brose misses, for example, the role of a nuclear deterrent strategy--similar to the one we engaged in for 50 years to defeat the USSR during the Cold War—as a deterrent of near peer aggression. You can’t have a defensive strategy for the US without consideration of all levels of power. Since his book is absent any mention of nuclear policy, I’ll suspend reality and pretend that that option doesn’t exist in our world and address what he is really after. And that is technological change in our defense department to win with high tech weapons connected to a network, or Military Internet of Things (MIOT) since what he is really after is modeling the DoD after the tech companies in Silicon Valley that has brought us the real, Internet of Things (IOT). He envisions a construct that enables us to fight our next war from our iPhones.

This is a similar argument that networks can deliver combat power which is an incorrect notion first put forth at the advent of the internet. Brose talks about Andy Marshal and the Office of Net Assessment. Marshall bought us the term Revolution in Military Affairs (RMA). A true RMA comes along every few generations and it’s important to see them when they are upon us. However, the true architect of fighting wars in the information age were the visionaries behind the term Network Centric Warfare (NCW) and specifically the Navy’s foray into their Cooperative Engagement Capability (CEC). Those architects, although noble in pursuit of their goals, fell short well short of their vision…Adm Cembroski network warfare’s chief proponent specifically failed in delivering his vision, 20 years and many billions of dollars later. specifically, the Navy’s pursuit of a kill chain, known as Joint Integrated Fire Control, (JIFC). This kill chain lies at heart of the Navy CEC capability. Brose only talks about this kill chain in a general sense. He never actually defines a single kill chain in this book. Yet there are so many kill chains in the DoD. To not describe a single kill chain is a major flaw in his work. You learn kill chains as a part of your warfighter 101 when you enter the military. And you train to whatever part of the kill chain to which you happen to be a member.

Here’s a kill chain. An anti-ship cruise missile is launched from a Chinese vessel at a US Navy ship. The E-2D Hawkeye flying in the skies above the fleet is the first to detect the missile skimming across the ocean. The Spy-1 radar on the Aegis Cruiser cannot see the missile yet because it is too far off and too low over the horizon. If defensive F-18 are in the air and close to the area in question they can be vectored by the Hawkeye to take a look and perhaps engage. As the missile breaks the horizon, the Aegis could fire a fast missile to shoot it down. As the missile closes on the ship for its final impact, the Navy vessel targeted can try to shoot it down with its Phalanx CWIS system. (CWIS stand for Close in Weapons System). Three chances to shoot the missile down in a layered defense. Moving beyond the Navy both the Air Force and the Army have their own kill chain to deal with incoming missile threats. Everyone involved in these kill chains train for these engagements over and over again. The idea to integrate (network) them at a weapons control level might seem like a good idea on the surface, but it is a distraction and a pure red herring. At the detail level, it’s not the way to conduct these engagements. Three things make this an impossible endeavor. 1) Physically the systems are constrained by physics from cooperating during these engagements. 2) Tactically the defense is layered for increased kill effectiveness and 3) the engagement zones are constrained to prevent fratricide. Sharing situational awareness between systems is a good goal but sharing fire control quality data is unnecessary and is the unobtainium of which Brose speaks broadly but never truly defines in this way.

There are many kill chains depending on the mission. Integrating kill chains is thought to be the nirvana of warfighting, but it’s not that easy. Why, because of a thing called physics. Physics in the kinetic realm and physics in the non-kinetic realm. Newton’s laws (along with Bernoulli and Naiver-Stokes) govern the conservation of energy for kinetic kill chains on the surface and in the air of our planet. Kepler’s laws govern what we can do from orbit. And Shannon’s Information Theory, along with the math of Nyquist, rule the realm of information. Why? Because at the heart of our digital world, believed to be comprised of ones and zeros, is a physical world made up entirely of energy and conductors of energy (metals and silicon metalloids). The ones and zeroes are an imaginary construct for humans to understand in order to communicate with the physics of our hardware-based overlords. Everyone knows about Newton and Kepler, most have not heard of Shannon and/or Nyquist. But to understand how networks can be used to fight within a kill chain, one must also be a student of them all first…and then write the software. The science and technology must be bent into form by engineers and tested by the way we will fight wars. The services organize, train, and equip to fight and present these forces to the combatant commanders who exercise the operational art of war with the best people (trained), kill chains (organized), and weapons systems (equipped) we can afford. It takes time and it cost’s money. There is no free lunch.

There are so many more kill chains, I’ll describe one more, a very simple one. Dropping a bomb on a target. First the bunker has to be targeted. It has to be on a map, there has to be an image of it with measured coordinately inside some type of reference system. In the old days a bombardier would look through a Norton bomb scope with the instrument correcting for speed and heading of the aircraft. Today, with Global Position System (GPS) guided munitions, the bomb does all the work. With a set of guidance fins on the back, flying the falling bomb down to it’s target by receiving it’s position, of all things, from the GPS, while closing on it’s targeted coordinates. That app you are using to drive your car is part of the military targeting kill chain. A military system built to kill people and break things with uncanny effectiveness. GPS ushered in smart weapons and was indeed a Revolution in Military Affairs. Imagery, coordinates, and a constellation of GPS satellites seemingly is all you need. Oh, it’s important that the bomb be within it’s kinematic limits, which means it actually has to be released on it’s target, somewhere in the kinematic vicinity of it’s target. Something has to bring it there. We call all of the material necessary to get that bomb into the vicinity of the target, force structure. It’s not a network. It’s not software. It’s hardware. And a lot of it. The earth is a big place.

Brose’s vision of an MIOT is simply not based in reality. It has nothing to do with big prime defense contractors not being able to evolve, innovate, or code software in an agile fashion. Fighting wars on this planet must be a function of distance and mass first and then information and the speed of that information (and it’s ability to be changed). They are both important but we haven’t solved the mass and distance problem yet. During the Cold War we would have lost a conventional fight in Russia not because we didn’t have information or speed, but because 50,000 Russian main battle tanks would have been streaming through the Fulda Gap. They would have outnumbered our forces combined with the forces of our NATO allies in Europe, 5 to 1. We are not going to attack 50,000 main battle tanks with swarms of battery charged quadcopters all equipped with megapixel cameras anytime soon. Nor will those quadcopters make it across the South China Sea. In the end we beat Russia economically while we held them at bay with an ever-evolving strategic nuclear policy. We will lose against China, not because we can’t close a kill chain. We are a long way from our adversary, those kill chains are extremely hard to close without huge investment in weapons and infrastructure we simply can’t afford and don’t need to buy regardless. We will lose to China and Russia period if we can’t keep up with them politically and economically…as it turns out these are definitely better places the information age, and Silicon Valley can help. Can somebody get me a chip for a GPU for heaven’s sake?

Another pet peeve of mine, comes early in his book. That is this tired and inane notion that because the F-22 and the F-35 can’t communicate with each other, that’s a failure of technology, and a failure of our country's ability to field systems through the huge bureaucracy of an acquisition process known as JCIDS or the Joint Capabilities Integration and Development System. Brose has written a book called “The Kill Chain”. Clearly, he knows that the F-22 is our premier Air-to-Air Fighter designed to fight in the Air-to-Air kill chain. Big radar, big missiles, and the best flying machine ever conceived and flown. The F-35 was designed for a different mission entirely. The F-35 was designed to fight principally as an Air-to-Ground fighter first. It drops bombs to take out IADS and kill tanks. And, oh by the way, the two aircraft can indeed communicate when necessary. Through a thing called radio, or more specifically, JTIDS or Link-16. The two aircraft are being maligned for not being able to communicate through their shared data link. Something designed very specifically for a coordinated multi-ship attack of F-35’s to work together during a specific mission, without revealing themselves, but still be able to coordinate lethal effects, locally. Not globally. Why would a kinetic attack, happening 1000’s of miles away, need to report (or share) engagement level data back home? They were not designed to fight together in this way. Also, they were designed 20 years apart...the data link on the F-35 is far superior to the data link on the F-22 in most ways.

By far, the best Chapter is Brose’s book, is his chapter on the politics within Congress and the decisions being made within the DoD. He’s experience at this level of government shines through. Brose is right, we do have a problem in figuring out what to do…the service MAJCOMs along with the COCOMS figure out what we need. Sure they fight among themselves and OSD straightens them out. But then the politics get involved and decisions are made based on everything but the military strategy. It’s the politics. It’s not the cost, the lack of vision or the ability to invent new warfighting technology…that happens on a daily basis…much of it cannot be shared. As we know our adversaries are looking through every window they can to see into and steal what they can carry out…that way they don’t have to invent it themselves. That bleeding of information has to stop. It’s not adopting the concepts of Silicon Valley that will save us. It’s getting our politicians too corporate on a strategy for what’s best for our nation. Granted, we took two decades off to fight a different war, the Global War on Terrorism, and we did take our eye off the great threats from Russia and China. But we are not losing. We just are not winning. But conventional force structure alone, with better networks, and faster software, does not help us win either. It only distracts us.

The DoD has not lost its pace on innovation and technology...we still excel in materials science, energy, propulsion, aircraft & spacecraft design, stealth, electronic warfare, and a few other things. We are also pretty good in cyber. Our issue isn’t smarts or lack of technology or the greedy primes, it’s simply the number of people we have. We are exceeded by China in pure numbers alone. To combat their numbers, we need more engineers. Yes software programmers should be among them…but we need good, solid, motivated engineers, scientists, mathematics, analysts, and researchers. We need American’s committed to the defense of our country to turn away from the glitter and high pay of Silicon Valley in favor of the hard stuff. You didn’t learn calculus in college to write a computer application that delivers pizza. You learned calculus to become a physicist, a mathematician, or a mechanical, electrical, or aerospace engineer. These are the fine American’s in our Military Industrial Complex. And yes we are losing them to high paying software jobs in Silicon Valley. But that’s not why we should change our military strategy.

Since Brose is a good writer and tells compelling stories, and he was on the front line in the State Department and the Senate, I’ll start with the idea that he should get 4 stars for this effort. Add one star because I love John McCain. But I'll deduct one star for the F-35/F-22 flaw. I’ll deduct another star because Brose does not define a single Kill Chain in a book called “The Kill Chain”. Three stars only--and that is generous--for this book from deep inside the beltway despite its glowing reviews from some people who should know better (Stavridis and Petraeus).

They Mostly Come at Night...Mostly

The Fallacy of DevOps

by Mooch

 https://drive.google.com/file/d/1ZUUlQuSfgoB0-mxABc30zZAtHkVt7RYv/view

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.

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

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…

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.