A ‘supply chain’ is defined as such:

A supply chain is a system of organizations, people, technology, activities, information and resources involved in moving a product or service from supplier to customer.
– Wikipedia

This definition, while typically used in context of a manufacturing supply chain actually holds up fairly well for a Software Supply Chain; with some significant differences. This article will examine some the commonalities and differences.

Manufacturing Supply Chain:

A Manufacturing supply chain transforms natural resources, raw materials and components into a finished product that is delivered to the end customer (quoting Wikipedia again). In such a supply chain, a manufacturer becomes more an integrator than a manufacturer. Be it a product as simple as my daughters Barbie doll, with just a few components (plastic body, fake hair, clothes, cardboard and plastic box) or a product as complex as a car, with over 20,000 hardware components (see picture), for every component that goes into the final product, the manufacturer needs to make a decision – can another company make the component faster and/or cheaper, in the quantity and with the quality they need? For every component that they answer ‘yes’ for, the manufacturer takes on the role of an acquirer and the company actually making the component that of supplier.

A typical example would be the brakes of a car. It is an essential component in every car; but still the manufacturer has to decide – can someone else make it better and cheaper? If yes, they should acquire the component from a supplier. Another scenario where a manufacturer becomes an acquirer would be for a component where the manufacturer does not have the required expertise to manufacture it in house – say traction control systems or anti-lock brakes in a car. A third scenario may be where a supplier owns IP for some components, making it necessary for the manufacturer to acquire it from that supplier. Say, high capacity batteries in a Hybrid car. As a result of this model, modern automobile manufacturers have become automobile designers and assemblers, acquiring all individual components from external suppliers. In reality, apart from actual physical components that go into the completed product, manufacturers may acquire some of the design or prototyping work too. For example, an aircraft manufacturer may outsource wing edge design to a boutique Aeronautical Engineering firm which specializes in wing edge design work.

This relationship between the acquirer and the suppliers in the supply chain thereafter becomes based entirely on communication and agreements. The supplier communicates design specifications and quality requirements and the supplier provides back the components, typically just in time, with the right quality and in the right quantity. For the acquirer, the cost benefit comes from not having to own the manufacturing – the facilities, equipment and people – of the components they can have someone else supply. For the supplier, the cost benefit comes from their ability to reduce cost as the manufacturing scales.

Software Supply Chain:

A Software Supply Chain extends this notion of a supply chain to software and systems delivery. While the underlying business logic and value of adopting a supply chain model remains the same as that for a manufacturing supply chain, the parallels do not extend fully. As a software manufacturer, it makes perfect sense for a company to outsource parts of its software supply chain – to create a software factory. There are components of the software it is building that others can build cheaper, be it due to lower labor rates, experience in building said components, or for areas of specialized expertise (like mobile development) that the acquirer may not have in house or may not want to have in house.

But where do the parallels fall apart?

1. Requirements: Software specifications (read: requirements) are never as well defined as those of physical components. Think of the last set of requirements you saw for a User Interface on your last software project and compare them against the specs you may see for a car’s main UI, the dashboard – very different…
2. Requirement stability: Software requirements are usually unstable and not well understood by even the acquirers. Requirements evolve over time as the acquirer better understands the application or system being built. (That is why we came up with Agile Software Development practices.)
3. Change: Software changes much more often than physical products. A 2012 Toyota built in January is not that very different from one built in May. Meanwhile most apps on my iPhone get updated every few weeks.
4. Cost: The cost of ‘manufacturing’ a software component does not reduce with scale. When one is selling a million plus cars a year, each of which uses four brake assemblies, making brake assemblies becomes cheaper than it would be for making one set of custom brake assemblies for say a Formula 1 race car. In software, almost every time one writes code, it is custom.
5. Integration: In manufacturing, the interfaces between components are well defined. They are probably based on standards (say, fixed size nuts and bolts) or even if they are non-standard, can be defined in exact specifications, with associated acceptable tolerances, to the supplier. Software interfaces come nowhere close. In fact, when it comes to the integration points between components, the line separating the responsibilities of an acquirer and a supplier is a very fuzzy line. Add to that the complexity of having multiple components suppliers and their various integration points and things get really interesting.
6. Estimation: Once one has built a manufacturing facility to mass produce a component, one can estimate with pretty good accuracy how much material and time it would take to churn out x units of the components. Estimating the level of effort for software development is tricky at best. Unless it is the same team, with considerable experience is building just that type of component, one cannot tell for sure how long it take to develop the component. Changes in requirements and interface specs make estimation even more complex. Practices like Agile do allow for somewhat of a better job at such estimation, but there is a reason they call it planning poker.
7. Quality Assurance: Quality control is another area where software digresses from manufacturing. When an automobile manufacturer receives a component, they can fairly easily test them to see if they meet the specs and tolerances. All they have to do is test a statistically significant sample size to validate a batch they just took delivery of. For software, every component has to be tested for all the use cases that were specified. Rigor of testing is driven by balancing the level of quality required to cost of testing. Defibrillator software needs to be tested more rigorously than a word processor (though enough word processor crashes may necessitate using a defibrillator.)
8. Standard Practices: Manufacturing practices are pretty well standardized and do not vary too much between suppliers with certain certifications such as ISO. Software Development practices on the other hand are not as well defined or standardized. Even when well documented, Software Development practices are difficult to implement and follow to the letter. The dismal success rates of waterfall projects over the past couple of decades are ample proof of that. Agile practices are still evolving and are by definition… agile. Two suppliers with SCRUM certified practitioners may practice SCRUM very differently, with radically different results.
9. Incremental construction: Hardware components are not built incrementally. While their design and even manufacturing practices msy incrementally improve over time (especially for organizations practicing practices like ‘lean’ or Kaizen based continuous improvement based practices), components are built from scratch for each unit. Brakes on a 2012 Toyota Camry may be better than those of a 2011 model, but the ones on my car are not using any parts of an older brake (I hope). In contrast, softwae components are built incrementally. With every iteration, be it within a realease or for a new version of the component, new code is added to old code or old code is modified. With the evolution of re-use and that of open source libraries, even brand new components are now built upon code from other components or open source libraries.
10. Contracts: Agreements to acquire manufacturing components are based on quantity, time and quality SLAs. Given known manufacturing costs and raw material costs, they are typically easy to create and enforce. Contracts in software component acquisition become very complex. Fixed price contracts are an issue as incorrect time and effort estimation may lead to missed deadlines or suppliers taking quality short cuts to meet time based deadlines. Time and effort contracts need complex SLAs and oversight, making them difficult to price and implement.

As the above list demonstrates (and it is in no way an exhaustive list), while Software and Systems development, especially of large, complex software and systems, is rightfully adopting a supply chain based model, one needs to exert caution when adopting practices and success criteria from the manufacturing world. Software Development is still and probably forever will be an art more than a science. While development processes will continue to evolve to more agile and lean practices, the warning to note here is that while manufacturing supply chains have thrived by adopting a ‘lean’ model; ‘lean’ in software supply chains is a radically different concept.

In future posts, I will examine emerging trends in software supply chains and present best practices for adopting a Software Supply Chain model, both for acquirer and suppliers.