Page 41 - FCW, September/October 2020

use. The saying “perfect is the enemy of good” applies when trying to satisfy the urge to complete every desired feature in a waterfall release schedule. It com- plicates the integration and testing of all the features, and it delays the delivery of valuable capabilities.
DevSecOps is positioned to signifi- cantly influence the traditional mono- lithic acquisition and development processes the federal government has canonized through the nearly 2,000-page Federal Acquisition Regulation. The FAR defines the processes that must be followed for the acquisition of prod- ucts and services by executive agen- cies. Because of these regulations, the rhythm of the FAR processes strongly influenced the adoption of waterfall development practices in government.
However, industry has demonstrat- ed that the waterfall model has signifi- cant shortcomings when it comes to
the development of innovative, novel solutions.
Problem-solving with DevSecOps
When solving a new problem, there are two types of unknowns. Known unknowns are challenges we know we will need to tackle. Unknown unknowns are those unforeseen challenges we will face as we break new ground in the production of a novel solution to an unsolved problem.
When producing innovative solu- tions, the unknown unknowns are the stumbling blocks that cannot be discovered or predicted when fol- lowing a waterfall model until after the schedule is set. This is another area where moving risk to the left is accomplished by maintaining small, strategic, incremental chang- es through the DevSecOps feedback loop. If a particular feature is intrac-
table or sufficiently complex, it can be reprioritized, abandoned, dis- sected or reimagined much earlier in the development process — before it can impact and possibly prevent the delivery of other valuable capa- bilities.
When they think of DevSecOps, many people imagine cloud-native web appli- cations that use microservice or server- less architectures or container-based workloads. But DevSecOps is not a process only for the development of those modern architectures. It can be used to create traditional monolithic applications, n-tier architectures, ser- vice-oriented architectures and even embedded systems. DevSecOps, howev- er, significantly improves the viability of producing those sophisticated systems.
One of the key concepts DOD is developing is known as the software factory. Such factories are a realiza- tion of the concepts of DevSecOps, and they focus on the remediation of the bespoke, artisanal nature of IT sys- tems fielded by DOD today. Software factories correlate with another devel- opment of the Industrial Revolution: the assembly line.
Just as the success of the assembly line is dependent on interchangeable parts, a software factory is dependent on the adoption of DevSecOps principles, though the implementation of DevSec- Ops does not imply the creation of a software factory.
Through the adoption of DevSecOps principles, DOD is moving quickly toward leaner, more responsive, more efficient armed forces. n
Chris Yates is senior solutions architect at Red Hat. This is the first in a series of articles, co-published by FCW and the IBM Center for the Business of Government, that examine the impacts DevSecOps adoption is having on the federal government. Future articles will continue to explore these issues in greater detail.
September/October 2020 FCW.COM 41