Building a model of the software supply chain

As enterprises struggle to deliver software efficiently at scale, you can look to supply chain thinking to help control complexity

supply chain

The standard depiction of a software development value stream begins with coding and ends with code in production. You often see devops diagrams that start with “the business” and end with “the customer.” However, this depiction is doesn’t accurately reflect the complexity of software delivery at enterprise scale.

Taking a step back, you see many more activities involved in supplying software to customers, but current approaches to managing these activities are rooted in service delivery frameworks and not in production models. As such, they do not connect all activities involved as a single end-to-end system.

The model used in other product industries is the supply chain model, and by applying that model to software delivery, you can expand your understanding of the software delivery “system” beyond devops, giving you new insight in to how to optimize it.

What is the supply chain?

The supply chain starts with the idea that you can coordinate all production and nonproduction activities as a single system. Supply chain management is often misunderstood as being simply “supplier management,” when really that is only one aspect of supply chain management (though a critical one).

All product and services businesses have a supply chain, and the activities involved and their relative importance to the supply chain system will vary. The core idea, however, is that by coordinating these activities as a single system, you get value greater than the sum of the parts and flow efficient delivery of that value to stakeholders.

The following activities are just a few of the important aspects of all supply chains, but for software they are executed uniquely:


In the traditional supply chain, planning activities involve coordinating assets and optimizing the flow of processes to balance supply of materials with demand for products. In the software supply chain, that coordination involves making sure the right code is being developed for the product features that are needed the most. At large scale, with hundreds of applications and thousands of software developers, this is a monumental endeavor.

The extent of planning activities is often minimized by existing devops models. It is somewhat ironic, then, that the large enterprises that need devops the most must contend with legal, regulatory, contractual, and customer obligations that make planning lengthy and complex. A supply chain approach to planning involves optimizing the interfaces between the many different planning roles and disciplines involved, and a key success factor is being able to integrate them effectively.

On one hand, the agile methodologies that guide development in the enterprise are often couched inside waterfall processes. Few businesses can escape fiscal planning cycles, and agile processes can contain abstractions that conflict with those cycles; for example, sprints may not align to the boundaries of the fiscal quarters. Lack of communication and connections between development processes using agile and nonproduction activities using waterfall can lead to waste and inefficiency across the business.

On the other hand, enterprise product planning has always involved extensive requirements management and traceability systems, and this is no different for software products. Requirements management is especially critical in highly regulated industries such as health care, where software may be developed for medical devices that can mean life or death for the users. Requirements management involves specialized tools and methodologies, and the ability to trace the fidelity and quality of their implementation across the development life cycle can be critical to enterprise software products.   


In the traditional supply chain, sourcing components involves managing relationships with suppliers and developing procurement strategies for parts and materials. Software also relies heavily on sourced components—according to recent research by Sonatype, open source now forms the majority of software products: as much as 80 to 90 percent of the code in modern applications is from open source components. And these components create unique management challenges.

First, it can be difficult to decide how to determine the quality of the components, with many factors influencing decisions like consumability, testing, documentation, community, support, and trends in technology. Having a clear strategy and approach to selecting components is imperative.

Secondly, as the number of open source components balloons, even knowing what they all are let along managing all of them effectively is a challenge. Product managers and engineers need to pay close attention to licensing concerns and security issues. The state of your open source components can change daily as new vulnerabilities are discovered and maintainers change their intellectual property strategies. And customers want to know exactly what they are receiving—many large enterprises will not purchase software without a bill of goods describing what’s in the box. Managing all these open source issues is a core aspect of software product development.


Getting software into the hands of customers can involve a complex web of partners of all kind: deployment, distribution, integration, reseller; agreements of all kind: OEMs, licenses, NDAs, RFPs; meetings of all kind: demos, PoCs, presentations; and so much more.

These relationships serve as inputs, outputs and even steps in the software delivery process. The state of any of these relationships can directly impact development activities. Without closely managing them and connecting them to the work being performed, very tangible waste occurs.

Imagine delivering an epic for a prospect that quietly became a lost opportunity, or deploying a feature for a partner that cancelled their agreement a month ago. This happens regularly when software is delivered independently from the value stream of the business—when the software delivery function is not linked to the supply chain.

The devops pipeline needs to be closely connected to the partnerships, agreements and goals for which the work is being performed. Code can be traceable and linked from the story to the requirement through to the customer record in your CRM, all by treating your software delivery like a supply chain and following through with a strategy of integration.

Imagine, instead, being able to surface all in-progress activities being performed for a specific contract, or all features planned for a new customer—this is the outcome of software supply chain management—visibility and traceability across the entire lifecycle.


While your classic manufacturing tooling might consist of die cutting machines and heat treatment ovens, the software supply chain involves a class of tools (variously called ALM tools, life cycle tools, or devops tools) that are used to manage the various stages of software delivery.

The strategy for managing these tools is very different from the classic approach because the technical and intellectual investment in software development tools is huge and highly impactful. This type of tool is also quickly evolving and highly fragmented—the Jenkins of today will be the Hudson of yesteryear. An organization needs to be positioned to have a resilient yet modular tool stack, one that provides teams with what they need, while retaining the flexibility to adapt.

Furthermore, the tool chain cannot be disconnected—it needs to be flowing information back upstream and downstream across the value chain to get knowledge where it is needed. It is critical to examine this area from an integration standpoint as well—how can you connect the activities at a given layer to the surrounding and supporting supply chain management activities?


Business has historically separated technology management from the revenue-generating lines of business, treating it as a set of support activities driven by values and objectives aligned with the delivery of services. In a software-defined world, however, that business model no longer fits.

Software delivery capability has moved out of the classically-defined support space and has come to define all primary revenue-generating activities.

You therefore need to rethink your model as a production system and move towards one that captures the complexity relationships across value stream activities. The supply chain embodies that thinking, and as the production of software products evolved we will surely see this model mature.

This article is published as part of the IDG Contributor Network. Want to Join?