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 with a deep pedigree in software supply chains. While "software supply chains" may be as new a term to you as 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 in seeing the intersection of 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 surprised to see that many, if not all, of the core Supply Chain Management principles have yet 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 customers? That seems logical. It is how a team is supposed to work.
This is why I was so surprised after reading the 2015 State of the Software Supply Chain and The Phoenix Project. It seemed that the idea of collaborating to create value was a foreign concept for 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, "okay 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 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 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 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, visibility and traceability into their supply chain are crucial. If a part of their product has a defect, they have to see where the part is and where they got it from. Once they find it, they can 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 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.
Traditional manufactures have such effective visibility into their supply chains 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 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, which are common sense in many other industries (collaboration, visibility and traceability through BOMs), are still not fully utilized across software supply chains and DevOps toolchains.
I realize that applying these principles is 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 this, I see the move to managing software supply chains as inevitable.
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.