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 scum 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.
1. Technical debt
Good technical practices act as insurance on your asset (customer value), making sure it doesn’t arbitrarily disappear into spaghetti code, broken workflows and buggy UI. If you have good product management and agile development workflows, you will be using a system for flagging technical debt as it is created, with time allocated to continuously refactor the codebase. Likewise, a solid application delivery pipeline that makes heavy use of code review, test automation, CI/CD, and scanning tools allows you to hedge against dark debt. If your processes are not clear, your application is still early stage, or you are contemplating major change in your application delivery systems, adding more code is probably taking on bad debt.
2. Cultural debt
Is it worth hurting your team to build a new module when you can buy it as a service? The second liability to consider is cultural debt—this occurs when the benefits of your decision have long term impacts on the culture of your organization. It’s necessary to consider whether you are going to hurt your ability to deliver value if issues crop up across your most valuable resource: people. Disconnection, discontent, and uncertainty will abound when you cut people off from data, information, processes, or each other. Put your people first! Make sure you aren’t taking on cultural debt with your technical decisions.
3. Knowledge shortfalls
The third consideration is whether the component you are looking to build requires highly specialized knowledge. The primary examples here are modules with security implications: file handling, authentication, encryption, and user management. Unless you have strong expertise in-house to build these securely, it is better to transfer the risk to a third party. Other examples include analytics and integrations. It’s too easy to fall into the Dunning-Kruger effect with these specialties. They seem like very solvable problems, but the reality is that analytics is highly complex, and integrations can be tricky to set up and very difficult to maintain over time.
4. Vendor volatility
The final consideration is the vendor itself. Your vendors need to be evaluated carefully to ensure reliability of their services and conformance with your own legal and contractual obligations. Some key points include:
- Certifications like ISO 27001 or SOC2 provide a easy shortcut to arrive at your decision on whether to trust the vendor’s technical chops. But if the vendor does not have them, you can do your own diligence to provide assurance.
- For small or new companies, you should ask for references from other customers in the same segment as you. Ask for local customers, take them out to lunch, and get an idea about what it’s like to work with the vendor.
- Ideally, pick vendors where you have the opportunity to work together, drive their product roadmap and develop features with them. See if you are able to have a relationship with their product managers to get a transparent view into how their service works.
It pays to work with your vendors and support their growth—it reduces the risk of creating a new dependency in your software supply chain.
Conclusion
“Code as liability” thinking adds strategic value and provides a greater depth into planning the decisions your organization is making. It implies that you need to think twice before handing off work to the development team. Using a service to deliver a component that you don’t need to manage actually starts to look reasonable compared to the cost of maintaining it over time. The market for third-party code and application delivery services reflects this, so get out there and see how you can leverage the market opportunity.
This article is published as part of the IDG Contributor Network. Want to Join?
