My Software Supply Chain Internship
I’m a senior at the University of Maryland, majoring in Supply Chain Management and Marketing. This summer, I landed an internship at a company that has a deep pedigree in software supply chains. While “software supply chains” may be just as new a term to you as it was me, an estimated 11 million developers rely on software supply chains, consuming billions of software component “parts” every year.
Being a newcomer to the software industry, I was particularly interested to see the intersection of the traditional Supply Chain Management principles and how they were used in the software world. After reading the “2015 State of the Software Supply Chain” and “The Phoenix Project,” I was astonished to see that many, if not all, of the core Supply Chain Management principles have yet to be or are just starting to be applied to the software industry.
The definition of supply chain management that I learned in school was “the collaboration, planning, execution, control, and monitoring of supply chain activities with the objective of creating value.” Probably the most important part of that definition is the collaboration between supply chain activities to create value.
Real World Classroom
After taking my introduction to supply chain management class, I thought this stuff was pretty much common sense. If you work in manufacturing giants like Toyota, Apple, or Hershey — collaboration with the objective of creating value is second nature. Why wouldn’t a company collaborate and work together to create value for their customer? That seems logical. It is how a team is supposed to work.
This is why I was so astonished after reading the 2015 State of the Software Supply Chain and The Phoenix Project; it seemed as if that the idea of collaborating to create value was a foreign concept to many software development organizations.
In “The Phoenix Project,” the main character, Bill, is thrust into being the head of his company’s IT department. He immediately realizes that his team is swamped by literally years of work. His development, operations, security, and change teams basically hated each other and blamed each other for every mistake the department made.
I thought, “ok this is just a book it is probably stretching the truth a little.” However, after spending over a month at Sonatype I realize that many company’s IT departments actually do have these problems. That is where the DevOps movement comes in. In a nutshell, I like to think of DevOps as the software industry’s application of the traditional Supply Chain Management principle of collaboration across an organization to create value. It provides a perspective that IT departments — across Development and Operations — can start working together more closely as a team in order to deliver great value.
The Importance of Traceability
The other core principles of traditional Supply Chain Management I learned from school were traceability and visibility into your supply chain. Again, I was very surprised to learn that these principles were not being utilized in the software supply chain. The 2015 Report stated that the average application includes 106 open source components. Further analysis revealed, that by the time the applications are developed and released at the end of the software supply chain, an average application has 24 known severe or critical security vulnerabilities and 9 restrictive licenses.
For a manufacturer, the ability to have visibility and traceability into their supply chain is extremely important. If a part of their product has a defect they have to be able to see where the part is and where they got it from. Once they find it, they then have the ability to recall and replace it. This practice should be no different for software development teams.
In fact, in a 2014 survey of 3,300 development professionals, 63% stated that their organizations have incomplete or no records of the components used in their applications. This lack of traceability means that even when good components go bad, development and IT teams have no way to quickly find the defective component and replace it with a better, safer version.
The way traditional manufactures have such effective visibility into their supply chains is through a bill of materials. Software development teams would be wise to adopt a software bill of materials. According to the 2015 State of the Software Supply Chain, “A software BOM is useful both to the development organization (manufacturer) and the buyer (customer) of a software product. Builders often leverage available open source and third-party software components to create a product; a software BOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities.”
A Transformation Like No Other
So after a month of being immersed in the software industry, I am astounded to see that the core principles of traditional Supply Chain Management that are common sense in many other industries (collaboration, visibility and traceability through BOMs) still are not being fully utilized across software supply chains and DevOps toolchains.
I realize that applying these principles are easier said than done, but am excited about the future. If software development organizations can embrace lessons learned from other high velocity, six-sigma manufacturing practices, the result will be a transformation that only happens once every 10 to 20 years. The kind of stuff future generations will read about in their text books. While I might be new to all of this, I see the move to managing software supply chains as inevitable.
