How to make better strategic sourcing decisions for your software supply chain
The market for application components delivered in the cloud using a subscription model is exploding—it spans the software supply chain and it is growing constantly.
Given the high quality of these component services, it can be difficult to determine how to source your parts—should you use a supplier, or build it yourself? There are many different ways to cut this problem, but a valuable mental model that can help you make your decision is to look at code as a liability.
The natural inclination is to think of code as an asset to the business. It’s something you invest resources in to build, and it drives the growth of your business. But an alternate line of thinking looks at writing code as creating risk, as a necessary evil to create value for the business.
Similar to financial debt, the idea goes something like this: You take out a mortgage to buy a house, you only want the house, but not the mortgage. So you minimize the mortgage as much as possible, keeping it around only long enough to obtain the value (the house). And if you move to a new house, you don’t take the mortgage with you. The debt—the liability—is a means to value.
You can think of code the same way: You don’t actually want the code, you want the value it creates. Code has ongoing costs to understand it, to maintain it, to adapt it over time. Those costs are the same as making the interest payments on your house. The scrum master, the two-pizza teams, the agile ceremonies—all are required, but all are simply paying down the interest. And unfortunately, when you move to Version 3 of your application, that Version 1 debt will still be hanging around—you can’t get rid of the principal!
If you have come from a background as a development or technical leader where your role has been biased toward building your own software and systems, thinking about code as a liability is a great way to view your decisions from a business perspective and make good strategic decisions. Applying the model to the build-versus-buy problem, four key areas for consideration emerge. – Read More