January 20, 2021, by SSgt Maxwell Lehmann, Chainsaw (Dynamic Targeting) Designer
The Department of Defense (DoD) has seldom built anything of its own, purchasing numerous materials, platforms, weapons, infrastructure, and technologies from the commercial sector for centuries. This type of acquisition is sufficient for things that have quantifiable requirements and long production times, but it has proven ineffective at acquiring software applications. The two main reasons traditional software acquisition falls short is primarily due to the nature of software application development.
1.) Software’s user experience (UX) is both extraordinarily subjective and impactful to the value of a software product. However, due to the way requirements are written, contracts seldom elicit the efficient, usable, and intuitive interfaces that we desperately need to effectively perform our jobs.
2.) It takes far too long! The average time to field software traditionally is approximately seven years. Delay to this magnitude debilitates the new software’s ability to provide value.
Let’s consider a hypothetical example using traditional acquisition; Say new software is required to solve a new problem. The department gets the smartest people in this domain to define the requirements. Let’s say they write them perfectly, precisely 100% of what they need. Even in this fallacy, the product is destined for reduced value and probable failure. By the time the product is delivered, warfare, processes, and technology would have changed so much the app will need to be replaced the first day it makes it to the field, destining thousands of users to forever use tools that are archaic and designed for wars with adversaries of seven years past.
I experienced this first hand going through Contracting Specialist school in 2017. I spent the first half of the course learning business acumen, federal and supplemental acquisition regulations, and how to wrangle defense contractors. Then the subsequent half of my training focused on learning how to use forms, processes, and software applications to execute contracting actions. My role in the Mission Support Group was to act as a business advisor to the various units/organizations on base. However, unexpectedly the time I spent talking to my customers, negotiating with suppliers, and evaluating offers was dwarfed by the amount of time I spent following arbitrary processes and manually data into a multitude of apps with labyrinth user interfaces built in the 80s and 90s.
This means that during the next war, on the day that decides the war’s outcome, it will largely be determined by the capabilities built seven years before. Technology moves pretty far in seven years. That is if you believe that software impacts our combat capability. After evaluating, warfighters use different software for the last two and a half years, I can tell you definitively, it does.
When technology and the way we use it are advancing exponentially, that opens the potential for combat capabilities to follow suit, both for us and our adversaries. Make no mistake; if we do not take full advantage of this opportunity in the DOD, we will be left behind. The critical point is that the speed software can be changed/replaced in response to operational needs, and the quality of that software – really matters.
When you see all the changes and unknowns that come with developing our software internally, it seems foolish. But when you recognize the risks of not evolving our capabilities, how can we not take it. Doing nothing is the riskiest path of all.
All of this drives the question, “How can we deliver the best software in the shortest amount of time?”. Our best answer right now is to build and deliver software internally as a DevSecOps unit.
“DevSecOps” differs from the more commonly known “DevOps” is a different name, branded to ensure and communicate that software security is an equal part of the process and has a seat at the table. This is important to make sure security corners aren’t cut in favor of the speed of delivery. Not only do they verify that our applications are secure, they build automatic code scanners that run every time a new version of the code is released, instantly checking if there are clear vulnerabilities in the application. Where before, you could only have security at the cost of so much time or release a feature that had an unknown risk (I don’t think this ever happened). But now that we can verify the security automatically, and verify that the code passes all tests. We can have our cake and eat it too!
In short, a DevSecOps team = Software Development plus Platform Operations, wrapped end to end with security measures.
The way DevOps teams are structured enables us to sense and respond to our users’ needs, but getting users to tell us what they need is often more difficult than you might think.
“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford
As designers, we see this every day where the features they are requesting are limited to the processes enforced by the system that we are trying to replace even though we have the discretion to vary in however needed to optimize the mission as long as it works for users and meets their missions objectives. The keystone question that we designers ask to cut through all of the self-imposed restrictions is “why”. We ask “why” time and time again until we find the root of the need, and that is the need that we work to solve. When we discover that solution, test it with users, build it, and deploy the updated application to users, where we monitor that feature’s success. Allowing us to field needed features in days or weeks, not months or years.
The ability to rapidly deploy software updates is DevOps’s special sauce that separates us from the rest of our competitors. It allows us to more safely take risks and build software for future unknowns because we can quickly learn and adjust, or rollback deployments as soon as we learn from our users and stakeholders. Taking a single light, cheap and reversible step then measuring how it affected combat capabilities allows us to move through unknown territory with reduced cost and risk. It also helps us mitigate the risk of evolving adversaries and threats; we have the agility to quickly respond if we had incorrectly predicted strategic needs.
Users, stakeholders, and subject matter experts all play a crucial role in DevOps. They are our connection to reality and our primary information source. As a designer, I read Air Force doctrine, papers and look at information from past conflicts in my domain, but as much as I might try, I would not design the best system for today’s and tomorrow’s war based on my research. The key is learning what users need to do their mission and how that works today, what are the external factors that impact their abilities. Pulling from all that feedback, doctrine, and research, we build multiple different versions of a prototype that almost feels like a real application in a fraction of the time that it would take to build that functionality in the application. Then we engage with users, having them test the prototype, giving them tasks to complete using the new features, and if they have troubles understanding what they need to do, take too long, or breaks their system in unintended ways, then we know we have to go back to the drawing board until testing over and over again until the problem is solved in the best way. A key part of this step of testing is getting a realistic and diverse set of feedback that will realistically validate that the planned feature will work. For example, a SMSgt or Colonel might be able to understand all of the information on a page and have a keen perception of what needs to be done without knowing how to do it in the application, where an Airman First Class or First Lieutenant might be more familiar operating software, but not understand doctrinal terms and the desired end goal of the task. Another variation that we need to consider is users in different theaters might have different processes, names, requirements, and priorities for things. If any of these conflicts arise, it would be cause for the designer to modify the design to ensure it is balanced and tuned to the desired experience before passing it to the developers to build.
|Stakeholder relations||Primary Duty||Maintain awareness and advocate user needs||Maintain awareness and advocate user needs|
|User Interviews/Engagement||Attends, take notes, and chime in||Primary Duty||@Attends and takes notes|
|Product Domain/Context||Primary Duty|
|User Interface/experience||Primary Duty|
|Prioritization and roadmap||Primary Duty|