Tag Archives: Software Acquisition

Pentagon Intellectual Property And Enterprise Tool Challenges

Image: DAU


The Pentagon is in the midst of releasing a flurry of guidance related to its new adaptive acquisition framework. The public got its first look at the software pathway early in January when a Navy official informally released the interim guidance.

Besides the usual bureaucratic challenges of documentation and approval, two highlights could make or break the Pentagon’s ability to move fast on software.


“Like the middle-tier acquisition pathway, the budding software pathway is exempted from the regular requirements and milestone review processes. But software programs must still submit abridged requirements documents through a parallel, but “expedited,” approval process. Similarly, an acquisition strategy and set of metrics must be submitted in lieu of formal milestone reviews.

Intellectual property

A crucial component of the acquisition strategy is a plan for intellectual property (IP). As the recently released intellectual property policy specified, IP plans emphasize “the criticality of long-term analysis and planning during the earliest phases of the program.” Long-term planning is required for IP so that specified terms and pricing can be set up front, for such things as who owns the data, whether third-parties can modify the code, and which interfaces will be used. But if used improperly, it could lock in technical plans at the expense of course correction.

The IP process may run against the stated intentions of the software pathway policy — that programs use agile development methods. Some of the values from the Agile Manifesto include: responding to change over following a plan; collaboration over contract negotiation; and working software over comprehensive documentation. The requirement of defining all IP needs upfront runs counter to the values of agile.

If software is supposed to be incrementally released, then the definition of IP needs and pricing should also be an iterative exercise. Otherwise, the Pentagon’s IP policy would in practice necessitate a waterfall planning process. Developers would have to execute within the constraints of the IP plan.

Enterprise tools

The challenges of defining — and the unresolved problem of pricing — IP rights may be alleviated by a second highlight of the interim software policy: enterprise tools. Using government-owned infrastructure and platforms, many parts of the software program do not need to be recreated and separately priced. Firms can compete primarily on the application layer.

Building on enterprise tools like a government cloud, for example, would have saved the Pentagon from its IP struggle with Lockheed Martin over F-35 sustainment data. The company claimed ownership of data collected by the Automated Information Logistics System and stored on its premises. Data reports delivered to the government had Lockheed’s proprietary markings.

The U.S. Air Force has taken the lead in standing up enterprise tools for the services. Chief Software Officer Nicholas Chaillan is in the process of releasing the Unified Platform layer upon which applications can be built and deployed. The Air Force has increased funding for its Unified Platform and related elements from just over $55 million in fiscal 2019 to a request of nearly $100 million in 2020.

The Unified Platform will in turn run on government cloud solutions, which will incorporate the forthcoming Joint Enterprise Defense Infrastructure, or JEDI, contract expected to run $10 billion over the next 10 years.

Chaillan explained. “You go to big companies, they have infrastructure cloud team, they have a platform team, you don’t have each software team building the entire stack from scratch. They can reuse all these existing enterprise capabilities in terms of testing and security.”

Enterprise tools help minimize the amount of effort, and thus IP planning, required of individual software efforts. By reducing the cost of building and operating new applications, more modularized software can be written by competing suppliers. It increases participation from companies of all sizes.

With viable alternatives not only in development, but in operations, tugs and pulls of the market may reveal efficient pricing for IP without lock-in effects from sole-source providers. In other words, the government will be less reliant on lifecycle planning and cost data.

By building on government-owned infrastructure and platform layers, applications can be modularized and priced incrementally. That will help bring the business team into a culture that supports agile developers. Enterprise tools may then help move the software acquisition pathway away from “water-agile-fall” and toward a real agile development process.

Investments in enabling tools and technologies can accelerate program developments. They should be given higher funding priority as programs in themselves. If enterprise tools are built, the question remains whether the services and contractors will adopt them.”


Government Seeks Technology To Improve DOD’s Complex Supply Chain And Logistics

Air Force Senior Airman Jeremy Kosick guides a K-loader loading cargo onto a C-17 Globemaster III before an airdrop mission at Bagram Air Field, Afghanistan, May 10, 2018. (U.S. Air Force / Staff Sgt. Keith James)


DARPA [has] posted a solicitation for proposals  for a program it’s calling LogX.

Specifically, the program wants software that can provide real-time logistics and supply chain situational awareness “at unprecedented scale and speed.” ______________________________________________________________________________

“Imagine trying to coordinate hundreds of airplanes charting the globe on a daily basis, as United Airlines or FedEx do. Multiply that several times, and you have the logistical workload for the U.S. military.

It takes special tools to track all those aircraft and the related supply chains, and the Defense Advanced Research Projects Agency is now reaching out to industry for ideas on upgrading the military’s existing technology, which is managed through the Joint Logistics Enterprise.

“The DoD Joint Logistics Enterprise is immense,” John Paschkewitz, DARPA program manager in the Strategic Technology Office, said in a news release announcing LogX in May. “The supply chain inventory to sustain the Air Force fleet has been estimated to be as large as multiple Fortune 500 companies combined. Add the Army, Navy, and Marine Corps’ needs, and you see how enormous the department’s global logistics and supply systems are, dwarfing any commercial logistics system.”

The logistics enterprise still uses legacy technology, according to the request. LogX is looking for research approaches “that enable revolutionary advances in science, devices, or systems,” the request states.

The request goes on to describe the logistics enterprise as a triple-decker layer of networks. There is the physical supply chain, information networks that inform the physical mobilization of supplies and finical networks. LogX will focus on improving the information network, according to the request.

Part of the information network changes the DOD hopes to implement is a migration to cloud-based data storage. LogX is expected to be implemented during the next 10 years, over which new technologies will further change the logistical landscape.”

Army To Kick Off IT-As-A-Service Procurement



“The Army has issued a request for information to help guide its development of an Enterprise IT-as-a-Service (EITaaS) procurement pilot

EITaaS will leverage industry best practices and capabilities from the private sector to assess whether commercial solutions can provide standardized, innovative, and agile IT services to the Army.”


“The service issued the solicitation earlier this month in search of commercial, vendor-owned IT services, rather than building out and maintaining the tech on its own. The pilot will apply to network, end user and compute and storage needs.

“With the assumption that a wholly service-owned and service-operated model could sub-optimize Army operational readiness, the Army is exploring a new approach for delivering enterprise network and core IT services: Enterprise IT as a Service (EITaaS). The EITaaS pilot will assess feasibility and deploy commercial solutions for data transport, end-user device provision, and cloud services for selected Army installations,” the RFI states. “An initial EITaaS pilot will allow the Army to evaluate commercial solutions and their ability to strengthen enterprise IT service delivery, improve user experience and integrate with existing government-only systems, architecture, processes and facilities, while maintaining an aggressive cybersecurity posture.”

The Army plans to host an industry day at Fort Belvoir, Virginia, May 7, to provide an overview of the procurement and the planned use of other transaction agreements (OTAs) for pilots to test the concept. Those who wish to attend have until April 29 to register.

Other Transaction Authority (OTA), which has existed for decades but was expanded in the 2016 National Defense Authorization Act, allows the military to grant relatively small contracts for the development of prototypes and then follow on with an additional contract for production if and when the pilot is successful.

During the pilot, the Army looks to conduct “site assessment surveys at three Army installations and the implementation of assessable services at Army Futures Command (AFC) Headquarters in Austin, Texas” in fiscal 2019. If the first pilots go accordingly, the Army hopes to also expand to another two bases in 2019, and five more in fiscal 2020. In total, over the first three years, the Army says it could launch up to 15 pilots at bases of varying sizes.

Army CIO Bruce Crawford broadly detailed the plan in a recent appearance. The Army, he said, will “move from an incremental approach at 288 different posts, camps and stations to more of a prioritized approach at about 50 of our most important and significant readiness-related, power-projection platforms.”

Crawford said it would “take beyond the year 2030 if we stayed on the current path to modernize the enterprise,” building out Army-owned systems and IT infrastructure, which comes at a massive cost and investment in time.

[The RFI] says. “Upon successful implementation, EITaaS enables the transfer of government resources to focus on core cyberspace operations, increase readiness and cyberspace effectiveness while enhancing security to ensure successful completion of Army missions.”

The Army’s EITaaS model of launching pilots sounds a lot like the Air Force’s, which also used OTAs to test the concept. It awarded OTA contracts to AT&T, Microsoft and Unisys in 2018 and 2019.”

Army to kick off IT-as-a-Service procurement with industry day

Defense Innovation Board Software Acquisition and Practices (SWAP) Findings



The study, which was congressionally mandated by the fiscal 2018 National Defense Authorization Act, comes down to 10 recommendations structured around three themes and four areas of effort. 

(There are also 16 additional recommendations, structured in the same way, which represent the “next set of things to do,” said board member Richard Murray.)”


“Murray and Michael McQuade, the study’s leads, briefly introduced the draft Thursday, along with each of the top-level recommendations. The document, which was created by an internal Department of Defense team, was also published to the board’s website last week.

The three main themes in the report are:

  • Speed and cycle time are the most important metrics for software;
  • Software is made by people and for people, so digital talent matters; and
  • Software is different than hardware.

The four “lines of effort” the board recommends to realize these three themes are:

  • Refactor statutes, regulations, and processes for software;
  • Create and maintain cross-program/cross-service digital infrastructure;
  • Create new paths for digital talent (especially internal talent); and
  • Change the practice of how software is procured and developed.

These areas target different stakeholders in the software acquisition process. The first of these lines of effort is targeted at Congress and the secretary of Defense; the second for the secretary and the various services; the third squarely at the services; and the fourth at acquisition officials and contractors.

Each area has component recommendations attached. For example, to “refactor statutes, regulations and processes for software,” Congress and the secretary should endeavor to create “a new acquisition pathway for software that prioritizes continuous integration and delivery of working software in a secure manner, with continuous oversight from automated analytics.”

The study also recommends that the secretary “establish and maintain digital infrastructure within each Service or Agency that enables rapid deployment of secure software to the field and incentivize its use by contractors; Create software development groups in each Service consisting of military and/or civilian personnel who write code that is used in the field and track individuals who serve in these groups for future DoD leadership roles; Make security a first-order consideration for all software-intensive systems, under the assumption that security-at-the-border will not be enough” and more.

Like the science and tech enthusiasts they are, the study’s authors included this diagram of how the themes, lines of effort and recommendations are structured:

SWAP study structure. (Screenshot)

The draft study also includes an implementation plan for each recommendation. McQuade announced that the internal team that worked to produce the study has been funded to stay on and help with implementation.

While some of the recommendations are pretty independent of each other, the board warned against thinking of it as a pick-what-you-like kind of situation. “It’s not a complete Chinese menu… they do depend on each other,” Murray said.

Various members of the board spoke up to praise the creation of the study, its readability and its contents. “You cannot imagine a rational objection to [the content of the report],” Neil deGrasse Tyson said. “This changes my view on the value for reports,” DIB Chairman Eric Schmidt added.

The board then voted unanimously to approve the document. The study will now be delivered to the DOD within the next two weeks, Executive Director Josh Marcuse said, before the department officially sends it to Congress in “early May.”


Today’s Challenges In Federal Government Software Acquisition

Image: “E-Commerce Times”


Previously, when purchasing equipment, the Defense Department spent most of its money on the physical material to build a system instead of the guts of the platform.

That has now flipped to a point where the department spends only about 30 percent on the physical side and 70 percent on software “


“Effectively acquiring and sustaining the massive number of software systems the Pentagon employs is a perennial problem, experts say. It often takes too long for the Defense Department to purchase and deploy new, cutting-edge software or upgrades.

Despite efforts by Congress to root out the problem through various well-intentioned reports, issues persist, said Jeff Boleng, a special assistant for software acquisition at the Defense Department. He is a key member of Undersecretary of Defense for Acquisition and Sustainment Ellen Lord’s executive leadership team.

“We’ve got a whole bunch of numbers staring us down — we’ve got 804, 805, 809, 813, 872, 873, 874, 868,” he said, referring to sections of recent National Defense Authorization Acts.

“Essentially, Congress is inside DoD’s decision loop here telling us how to fix software more quickly than we can actually address some of the problems and implement them,” he noted.

Boleng is working closely with the Section 872 panel which — alongside the Defense Innovation Board — is focusing on software acquisition regulations, he said during a recent event hosted by the Center for Strategic and International Studies, a Washington, D.C.-based think tank.

The report will soon wrap up and is slated to be delivered to the Pentagon in April and then to Congress in May, he added.

“There’s a lot in there. Surprisingly, there’s not a ton that’s new,” he said. “I hope that the timing is right for some of these recommendations. We’ve been looking back in history at various other studies that have been done on acquisition reform, software technology, information technologies. [And] we’ve been lamenting about this problem since the ‘70s — literally when software first started to even be created for defense systems — and a lot of times we say the same things.”

Andrew Hunter, director of the defense-industrial initiatives group at CSIS, said in his former life as a Capitol Hill staffer he saw many reports come and go that were meant to get after improving software acquisition at the Defense Department.

Congress “asked the department to make radical change in its approach to software acquisition some years ago — the original [Section] 804 — which was essentially do everything for software different without any definition of what that meant, what that would look like [or] how to do that,” he said.

Staffers would ask if the department was executing what Congress had requested and it was sometimes tough to make the case that it was, Hunter said.
Now, however, there is more granularity and solidity to the efforts underway, he noted.

Beth McGrath is a managing director at Deloitte who formerly worked for the Pentagon as a chief management officer for information technology and worked closely with Capitol Hill on ways to acquire IT systems faster. Software acquisition is often complicated, she said.

“Business IT seems super easy when you compare it to F-35 [joint strike fighter] or all of the other systems or major defense acquisition programs,” she said. “But I found it to be probably one of the most challenging, and some of it has to do with the … literacy of the department in terms of … how to buy and what to buy.”

Brett Lambert, vice president for corporate strategy at Northrop Grumman, said software is just one example of a transforming defense industrial base. “At the same time, the acquisition system by which we acquire these products and services didn’t change that much and that’s where all the frustration grew,” he added. Pentagon officials must be mindful of avoiding a one-size-fits-all mentality when it comes to software acquisition, he said.

“Not all software is created equal,” he said. Lambert noted that there is software inside of his dishwasher at home. It is important but represents only a small part of the cost of the overall system.

“But I also have software in my car that updates every day and it kept me from hitting a scooter coming down here this morning,” he said.

The software in the car is inherently more valuable because it is providing a service all day, every day and must be constantly refreshed, Lambert said. As the Pentagon acquires new software, it needs to think hard about what those systems are meant to do.

Lambert also cautioned against vendor lock.

“What you want to avoid if you’re an acquisition executive is being in a position where you’ve acquired a piece of kit or a piece of software and now you’re beholden to that single entity,” he said. “You can’t make changes to it. You can’t update it. You can’t refresh it and you’re kind of held captive to the individual who created” it.

Additionally, McGrath said the Pentagon should be wary of lowest price, technically-acceptable contracts for software.

“Being in the commercial space, I can tell you it’s a price point competition,” she said. “It’s essentially LPTA for most of the sustainment for business software.”

Despite being a common contracting method, LPTA does not leave room for innovation, she added. “It’s a race to the bottom,” she said. That dynamic has to change in order to give the Pentagon the best capability available.”