The Army is signaling that its next big software directive will not be another checklist but a financial reset, one that treats code as a living capability rather than a one time purchase. The service is tying that shift to more flexible funding tools, promising to move money at the speed of software instead of the pace of traditional acquisition paperwork. I see that as a pivotal test of whether policy can finally catch up with the way modern code is built, secured, and sustained.
Cash flexibility as the centerpiece of the new directive
The clearest signal of change is the way senior leaders are talking about money, not just code. Jan has framed the coming software directive as a direct response to years of frustration with the “color of money” rules that split development, procurement, and sustainment into rigid silos that do not match how software actually evolves. In that framing, the priority is not a new buzzword for agile, it is a commitment to let program offices move funds across phases so they can update a battlefield app as quickly as a commercial team patches a ride sharing platform, instead of waiting for the next budget cycle to catch up.
That shift is already visible in how the Army describes the directive’s goals. Leaders have said the new policy will put a premium on flexible funding so teams can respond when a cyber threat changes or a unit in the field discovers that a new interface simply does not work under combat conditions. I read that as an acknowledgment that the old model, where software was treated like a tank or a truck that moved from development to sustainment and then sat in a static account, is no longer defensible in a world of continuous delivery and adversaries who probe for vulnerabilities every day.
From rigid policy to Obadal’s push for speed
The Army is not only promising new guidance, it is also tearing up some of the old rulebooks. Obadal has already cancelled a rigid policy that locked software programs into outdated processes and has described a deliberate move toward a more adaptive framework that lets teams act faster and smarter. In my view, that cancellation matters as much as any new directive, because it signals that the service is willing to admit that some of its own rules have become obstacles to the very modernization they were meant to enable.
Obadal’s comments about pursuing a more agile approach are backed by a broader institutional push to streamline how software is tested and cleared for use on operational networks. The Army has said it intends to simplify both capability testing and cybersecurity validation so that new tools can obtain authority to operate on the service’s networks without years of delay, a goal that aligns with the cancellation of the older policy and the promise of a new directive that prizes speed. I see the combination of that cancelled guidance and the planned reforms as a signal that the Army wants to replace slow, linear gatekeeping with a model that treats security and performance as continuous activities rather than one time hurdles, a shift that is reflected in Obadal’s description of the effort to act faster and in the Army’s plan to streamline testing.
SBOM mandates and the security spine of the new regime
Speed without security would be a hollow victory, and the Army’s emerging rules show that leaders know it. The service is moving to require a software bill of materials for the code it buys, a move that forces vendors to disclose the components and dependencies inside their products. I see that New SBOM Requirement as the backbone of a more transparent supply chain, one that gives the Army a clear view of which open source libraries, third party modules, and legacy components are running inside critical systems so it can respond quickly when a vulnerability surfaces.
The Army has been explicit that this New SBOM Requirement is not optional for industry partners. Vendors have been told that they need to Know what is inside their code and be ready to share that information or risk being excluded from future contracts, a stance that raises the bar for any company that wants to sell software into the Army’s ecosystem. In practice, that means a firm offering a logistics platform or a targeting tool will need to maintain a living inventory of its components and be able to prove that it can track and remediate issues across that stack, a standard reflected in the Army’s plan to mandate an SBOM and in the warning that vendors who do not meet the New SBOM Requirement and What Software Vendors Need to Know could face exclusion from Army contracts.
Changing the color of money and the structure behind it
Underneath the policy language sits a more radical financial change, one that reshapes how software is funded across its life cycle. Boatner has explained that under the new approach, software will no longer make a formal transition to sustainment, and Instead the program office will keep control of the effort and the associated funds. I interpret that as a direct challenge to the traditional model where a program shifted from development to a sustainment command, often losing momentum and flexibility as its budget moved into a different account with different rules.
That financial rethinking is tied to a broader acquisition overhaul that is reshaping the Army’s internal structure. A major reform effort set for implementation will consolidate program executive offices and reduce the number of general officers at the top rank, with the stated goal of sharpening the service’s technological edge in all domains. In my view, that structural consolidation is meant to complement the software directive by giving fewer, more empowered leaders the authority to move money and make decisions quickly, rather than spreading responsibility across a sprawling bureaucracy. The combination of Boatner’s description of how the Army is changing the color of money and the plan outlined in acquisition reform suggests that the service is trying to align its organizational chart with the realities of software centric warfare.
Agile pilots, BA-08 funding, and the case for lasting change
The Army is not waiting for the new directive to test its ideas in the field. Earlier policy moves have already pushed units toward agile software development practices, with guidance that encourages shorter delivery cycles, closer collaboration between coders and operators, and more frequent user feedback. I see those efforts as the practical expression of the CASE FOR CHANGE laid out in Army Directive 2024-02, which the Army has described as the first attempt across DOD to adjust institutional processes for software at scale, and as a foundation for the more ambitious funding reforms now on the horizon.
Concrete pilots are giving that theory real budget lines. The service has highlighted the strategic use of BA-08 funding to support software efforts within PM DCO’s programs, arguing that this approach optimizes programming and budgeting, avoids delays in procurement, and reduces risk for critical cyber capabilities. In my assessment, those BA-08 pilots are the clearest proof that cash flexibility can work in practice, because they show how a program can shift resources quickly to address emerging threats or user needs without waiting for a new appropriation. The Army has framed its agile policy as a way to drive adoption of modern development practices, and it has tied that to the broader policy and reform initiatives summarized under policy initiatives, the push to drive adoption of agile practices, and the argument that the strategic use of BA-08 funding is paramount to making those reforms stick.