Software Supply Chains and DevOps

During our induction into the IBM family, one of our new colleagues told an anecdote about a firm that outsourced its mobile application development. Managing the relationship of outsourced work with what is being developed in house is a challenge similar to what manufacturers face with their supply chains. While this is a topic the folks at IBM having been talking about for a while, it’s new to me.The implications however are both clear and profound.

Lessons from Supply Chain Masters

Consider the lessons that Toyota learned through its Lean efforts. Being Lean, and working in small batch sizes does not work unless suppliers are also able to react quickly, producing small batches of exactly the parts needed for the vehicles that were in demand. Liker’s book The Toyota Way recounts their work with Trim Masters where seats are ordered when a car begins its four hour trip down the assembly line. With Toyota’s help Trim Masters was able to produce the seats and deliver them just in time to meet up with the rest of the car a few hours later.

Or consider Walmart’s famous supply chain agility. While maintaining very low costs, Walmart is also able to react very quickly to changing market dynamics to rarely need to put items on clearance.

Applying Supply Chain Lessons to Software

Software companies that would decide to make a change and release it hours later are few and far between. However, we serve businesses that increasingly expect to be able to change plans often to exploit immediate or transient market opportunities. Speed of innovation is key.

Continue reading

Configuration only Deployments: reduce outage windows by 90%

Configuration only deployments were one of the big features added in the 4.7 release of uDeploy. The idea is pretty simple. If your application code didn’t change, but a setting you track in uDeploy (such as a timeout, url to a web service, or thread count) did change, then you should be able to deploy the configuration update without redeploying the application.

I don’t think I fully understood the impact of this capability until I talked with a release engineer last week. On one of his projects, the full automated application deployment takes about 20 minutes. However, if he only deployed the configuration, the process could be reduced to 2 minutes. That’s a factor of ten faster. When a typical release impacts upwards of 50 different applications in this system, the improvements multiplied. This was really exciting, since outages were painful and configuration changes much more often than application code. For this team, only one out of every five deployments modified the application.

Configuration only deployments meant that they could reduce 80% of their outage windows by 90%. That’s just awesome.

There are two good lessons here:

1) When a new version of an application you use comes out, really look for opportunities to exploit new features.

2) If you’re doing automation, regularly look for waste in there and try to eliminate those extra steps. We have a whitepaper on using Lean techniques in build and deployment automation that might point you in the right direction there.

How experiment cultures lead to continuous deployment

In past webinars we’ve talked about Lean startups and what the enterprise can learn from them. We’ve pointed to these guys as examples at the extreme doing crazy things like deploying an app to production 50 times a day.

The standard explanation for lean startups movings towards continuous deployment is that they walked a path of removing wastes. Automated deployments were effective in removing errors and wasted effort. The endeavored to speed features to production because features written but not delivered to the customer is seen as wasteful “inventory”.

This is no doubt at least partly true. But when you read discussions of the practice there’s generally a heavy emphasis on monitoring deployments and rolling them back if Continue reading

Going Lean: Deferring Commitment

Lean teams will defer commitment on high risk decisions. Generally this means that instead of putting a lot of time and effort into making sure they make early, risky decisions correctly, they avoid the high cost of incorrect decisions by finding ways to defer making the commitment.

An Example from Development

Applications teams can benefit from delaying some large architectural decisions. For instance, by taking a standards based approach, they might delay the need to select the message broker used by their communication systems. Instead they might develop with the messaging layer abstracted so that several brokers would be compatible with the system and could be benchmarked as the system matured and its needs became more clear. This way the development team doesn’t end up making a bad, expensive decision early in the process when they know the least about their needs. Instead, they keep their options open at the cost of adding an abstraction layer. Continue reading