Welcome!

DevOps Leadership Series

Derek Weeks

Subscribe to Derek Weeks: eMailAlertsEmail Alerts
Get Derek Weeks via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Software Configuration Management, DevOps Journal

Article

Car Mufflers and Software Industry | @DevOpsSummit #DevOps #Microservices

Multiple software versions don’t make a V8

Imagine that you are designing the 2017 Ford Mustang. Like all gas-powered vehicles, each one needs an exhaust muffler. Ford has already vetted and narrowed in on a preferred provider of mufflers. But imagine what would happen if the designers and factory line workers could pick from any one of 20+ past versions of that exhaust muffler from any provider for the new model year – even if that part is outdated, has lower performance, does not meet current emission standards or has a known defect.

The designer could order it, place it on the vehicle, then ship it.

We all realize this scenario would never happen. No one would select an outdated, defective or poor-performing part for the product they are manufacturing, and no organization would give each of their designers and line workers free rein on procuring, installing and shipping any one of 20+ different exhaust mufflers for a single model year. Modern manufacturing processes would not allow for this approach. Nor would consumers accept cars built this way.

Ford is not taking this approach, but software development teams are.

Multiple Software Versions Don’t Make a V8
Software companies sourced an average of 27 different versions of open source components that they used in development last year. To be more specific, out of the top 100 open source components these companies downloaded from the Internet in 2014, they averaged 27 versions of each component.

Think about it. If they only used the best and latest version, they would only be managing 100 unique components. Yet, on average, they are electively sourcing 2,700 unique components.

While auto manufacturers like Ford have preferred suppliers of vetted parts, the procurement of open source components is often more of a free-for-all. If an organization has 300 developers, they effectively have a procurement department of 300 for sourcing externally developed software components. If you have 4,000 developers, you have 4,000 performing procurement. And that means some major bumps in the road.

Organizations like Google mandate the use of no more than two versions of a given open source component across their development teams. And at the recent DevOps Enterprise Summit (DOES15), Topo Pal, director of next-generation infrastructure at Capital One, said that his organization mandates only one version of each component be made available to developers through their repository managers. This is good practice, but it is the exception rather than the rule.

Speed at Any Cost Hampers Net Innovation
What does this mean for a software development organization – especially one focused on improving its DevOps practices? First the good news: Developers are using open source components to speed time to release and improve innovation. Both good things.

The bad news: Organizations are building mountains of technical debt through poor software supply chain practices – impacting quality, complexity, maintainability, supportability, etc.

Complexity tends to be the enemy of lots of things. Using fewer and better suppliers, using the highest-quality parts from those suppliers and tracking which parts went where can dramatically lower operational costs, improve agility and accelerate prompt responses when something goes wrong.

Technical Debt Grows at the Expense of Innovation
While open source components enable “speed” – a well-worn DevOps mantra – free-for-all sourcing and use practices add to a counterproductive technical and security debt that reduces net innovation and adds to the cost of operations. As technical debt grows, net innovation and business value drop.

Screen Shot 2016-01-28 at 10.31.11

Source: Application Portfolio Management, Quality and improvement by joapen

Organizations like Google, Capital One and other DevOps leaders are able to reap major benefits from stronger controls on component versions in play, resulting in sustained competitive advantages.

Ford has had more than 100 years to perfect the procurement process. The software industry is young by comparison but in terms of innovation moves much more quickly.

The benefits of bringing software procurement under control are very real. DevOps leaders are taking note of proven practices in traditional manufacturing to improve quality and lower costs through improved management of their software supply chains. Where other modern manufacturing industries have benefited dramatically by reducing complexity to improve quality and the velocity of operations, the opportunity is ripe to apply those same principles to software development.

More Stories By Derek Weeks

In 2015, Derek Weeks led the largest and most comprehensive analysis of software supply chain practices to date across 160,000 development organizations. He is a huge advocate of applying proven supply chain management principles into DevOps practices to improve efficiencies, reduce costs, and sustain long-lasting competitive advantages.

As a 20+ year veteran of the software industry, he has advised leading businesses on IT performance improvement practices covering continuous delivery, business process management, systems and network operations, service management, capacity planning and storage management. As the VP and DevOps Advocate for Sonatype, he is passionate about changing the way people think about software supply chains and improving public safety through improved software integrity. Follow him here @weekstweets, find me here www.linkedin.com/in/derekeweeks, and read me here http://blog.sonatype.com/author/weeks/.