I’m Chip, from Sonatype. You may know Sonatype for our Nexus Repository Manager. We’re also the stewards of the Central Repository,
and we have a unique perspective around automating the software supply chain which comes from managing the over 30 billion downloads of around 400,000 open source components.
Application development today, being mostly component driven, has become more like application manufacturing. I’m here to ask you to embrace the “next big borrow” from traditional manufacturing, Supply Chain Management and the work of W. Edwards Deming.
If you’d like a copy of this deck, send an email right now to “chip@conatype.com”. You’ll immediately get a response pointing to this deck.
We know that 80% of the code in an average app comes from 3rd Party Components and about 25% of the components contain security and/or license risk.
Most companies I talk with have no way of easily identifying and avoiding those risky components.
Deming said “It’s not enough to do your best; you must know WHAT to do… then do your best.
And these companies clearly have no way of knowing what to do.
We help them find the answer to that question in Deming’s Supply Chain principals. Why Deming?
Because we have an obvious Quality Problem with the Open Source Components we use.
Deming is known as the “Father of Quality Evolution”. His 14 Points for Management have been used by companies around the world to transform their business processes, increasing productivity and overall product quality.
We know that 80% of the code in an average app comes from 3rd Party Components and about 25% of the components contain security and/or license risk.
Most companies I talk with have no way of easily identifying and avoiding those risky components.
Deming said “It’s not enough to do your best; you must know WHAT to do… then do your best.
And these companies clearly have no way of knowing what to do.
We help them find the answer to that question in Deming’s Supply Chain principals. Why Deming?
Because we have an obvious Quality Problem with the Open Source Components we use.
Deming is known as the “Father of Quality Evolution”. His 14 Points for Management have been used by companies around the world to transform their business processes, increasing productivity and overall product quality.
He is credited with launching the Total Quality Management (TQM) movement and core that movement is “Supply Chain Management”,
the management of suppliers and supplies.
Supply Chain Management has three major tenets that I suggest you consider incorporating into your software practices.
After World War II, Deming helped rebuild the Japanese economy by documenting specific, reliable, repeatable processes that can be used by any industry.
1 - Use Fewer and Better Suppliers. Choose your suppliers very carefully. They are the lifeblood of your products.
Don’t buy airbags from 7 different vendors. Move towards a single vendor for each part you need.
Strive to work with the smallest group of high quality, fully vetted suppliers possible.
2 – From this group of highly trusted, proven suppliers, select only their highest quality parts.
There’s a reason the others aren’t the best. Building quality into your product from the beginning and it will pay you back through the life of the product.
3 – It is not enough to use quality parts from trusted suppliers
These parts must be tracked and monitored to ensure continuing quality throughout the products lifecycle.
Imagine trying to recall faulty airbags, without a record of the cars or the owners.
With Software Supply Chain Principles we leverage Deming’s same 3 tenets, but with a software slant to each of them and with one significant addition.
In order for these practices to have any impact they must keep pace with our continuous delivery expectations, and therefore must be automated whenever possible.
DevOps and Continuous Delivery Reference Architectures
http://www.slideshare.net/SonatypeCorp/nexus-and-continuous-delivery
1 – To choose fewer and better component suppliers, we must gain an understanding of the overall quality of the projects each group provides.
How widely are their projects used? How often do they release? How risky is their code? How quickly do they respond with fixes?
It might be free. That doesn’t mean it’s good.
2 – I know of this big bank. The VP had a policy against using all but the latest two versions of a known risky component. The component had 87 total versions in all.
When we scanned their repositories we found each of the other 85 unsafe versions, but we didn’t find the latest two at all. Needless to say the VP wasn’t very pleased.
Nice policy huh? They only work if you can enforce them without being a bottleneck. It’s not easy to govern behavior.
But it’s not that hard to find the newer versions of Java components at the Central Repo. Newer, not newest, is usually better. It’s much easier to pick the better component now, than to fix it later.
There are reasons that software is continually revised. Bugs are found, vulnerabilities arise, improvements and innovation are continually added. Of the many versions that exist for most of these components, again, choose wisely. Find the versions that are free of Security Vulnerabilities and Licensing Risks. Choose those that are more recent and widely used.
http://www.sonatype.org/nexus/2015/06/17/better-and-fewer-suppliers-2015-software-supply-chain-report/
3 – Track and monitor what you use and where you use it. For software that means, produce a Bill of Materials for every application which identifies each component used and it’s Quality as it relates to Security and License Risk, Age and Popularity.
These Bills-of-materials are are very useful, but are only a picture in time.
Monitoring is also essential, because over time new vulnerabilities are found in components once thought to be safe, sometimes years later.
When new vulnerabilities arise, you want to find the problem fast and fix it.
4 – In order to scale, in order to create and manage applications at the speed of innovation with consistent quality and security, automation is essential.
Manual processes are outdated, because they are slow and error prone, posing significant risk to your company and your customers.
Building an Automated Software Supply Chain is possible with tools that exist today.
OK, so this Supply Chain stuff sounds great
but how do we really benefit from bringing Software Supply Chain behaviors to our Development Practice?
What eye opening results should we expect?
Why have we been listening to you for the last 3 minutes?
I think that everyone in DevOps will agree, there’s nothing worse than Unplanned, Unscheduled Work.
Redoing work to pay down technical debt is demoralizing, costly and wasteful.
”Stop-the-line”, “all-hands-on-deck” emergencies are terribly stressful and rob from your innovation efforts.
By building in quality up front we dramatically reduce the waste and expense of Unplanned, Unscheduled Work.
Diagram courtesy of Dibbe Edwards – DevOps and Open Source at IBM
http://www.sonatype.org/nexus/2014/12/11/dibbe-edwards-devops-and-open-source-at-ibm/
We all know that the cost to fix a defect increases significantly over time.
Managing technical debt effectively is difficult. Working on the right things is critical.
By applying Deming’s principals you bring discipline and hygiene to your Software Supply Chain which eliminates technical debt before it is technical debt.
The end result being a lower overall cost of development.
I have yet to talk with a company that doesn’t pay attention to lowering their development costs?
The Cost to DevOps: 27 Mufflers
http://www.sonatype.org/nexus/2015/07/16/the-cost-to-devops-27-mufflers/
The collaborative culture that we strive for within DevOps is supported by these supply chain principals.
Empowering developers with the guidance and insight to make informed decisions as they choose new components fosters a product quality mindset that embraces failing fast without fear of retribution.
Automated systems allow for a focus on finding problems early and fixing them fast without any blame.
<Quick comparison of an automated solution that incorporates security and quality as part of its lifecycle>
Show me an example you say? Who’s doing this.
Let’s compare some statistics for the Toyota Prius and the Chevy Volt.
I’ll first call you attention to the 4th line, Suppliers for each plant. Toyota used 1/6th of the suppliers that Chevy did for the same type of car.
Above that Chevy builds over half of the Volt itself, twice as much of the Toyota with the Prius.
Toyota is long known for it’s supply chain discipline and judging from at the cost for each car and the sales results, that discipline speaks for itself.
Now we’re back to Deming’s original quote. And you now know what to do.
Dive into these principals. Make them you own. And do your best!
For those of you who might still be doubting me, here’s another popular Deming quote you may have heard.
“It’s not necessary to change. Survival is not Mandatory.”
I urge you all to embrace these principals. Make them part of your practice.
Create routine behaviors, Habits… Automate wherever you can.
The tools are out there. Investigate them.
Learn more about how to Manage your Software Supply Chain. And then do it!
Thanks everyone, again, email me if you want this deck or if you’d like to talk more about Software Supply Chains and automating them.
I’ll also be walking around today and tomorrow. Come find me.
Thanks.