Dependency on managed services and external partners is a part of business, and software development is no exception. Relying on internal and/or external people to maintain your software systems – from cloud service providers to offshore development teams – is the norm. The challenge comes in striking the right balance between healthy, manageable dependency and vendor lock-in.
Manageable dependency begins with ensuring portability, easily replaceable components, and flexibility in your custom-coded software. For that, you need to have an accurate measure of interdependencies, interoperability, and an early-warning system for potential risks.
Why overdependence is a hidden risk
Overdependence on external vendors – and/or overreliance on departed technical talent – to maintain business-critical systems is a significant, hidden risk. In fact, sometimes it only comes to the fore in mergers and acquisitions when multiple systems from different entities need to start communicating with each other.
Without the right assessment and monitoring processes in place, dependency can be an expensive and time-consuming issue to put right. So if your operations depend on custom-coded, business-critical systems, you need to be aware of the dependencies, and how to mitigate risks in case something goes wrong. Here are 3 things to look out for:
1 Third-party technologies
Most software systems depend on third-party technology of some kind or another. The risk comes when you’re unaware of the third-party libraries and/or components inside your custom-coded systems. Whether introduced by a subcontractor, or by in-house developers, if you don’t know it’s there, how can you ensure its maintainability and security?
Thankfully, there is a straightforward solution, something insisted upon by many organizations, including the US government: a software bill of materials (SBOM). The SBOM allows you to gain a clear understanding of risks within your software systems.
2 Inadequate documentation
Many organizations rely on in-house software systems that have been expanded and developed over time. Like third-party technologies, that’s not necessarily a risk in itself.
The risk is when the technical talent behind it either exits the organization and/or doesn’t produce adequate documentation. By ‘adequate’ we don’t mean massive amounts of highly detailed documentation. It’s often useful to provide high level, easily readable software architectural diagrams, logs of architectural decisions being made, and above all, source code that is readable in itself (typically with comments in the code itself). Readable code trumps documentation and comments every time.
3 Layers of dependency
Whilst a Cloud Service Provider (CSP) can give your organization all the technology it needs, there is one catch. It’s possible to become overdependent on a specific cloud provider. Again, this may not be an immediate problem, but it might limit your ability to port your system to a different cloud provider; should the need arise from a cost or a business model perspective.
Let’s say your existing cloud provider decides to aggressively increase prices. Do you accept the increase or switch providers? Overdependence could become a major roadblock to a smooth and cost-effective migration to a new cloud provider.
Total transparency over software dependencies
Seeing what’s inside your custom-coded systems enables your organization to manage its dependencies and mitigate risks. A good starting point is to assess your source code and produce a software bill of materials to gain valuable insights. A best practice is to repeat this exercise on a fixed scheme.
A deeper understanding of what’s actually inside the codebase of your business-critical software enables your development teams to prioritize the work to be done in order to ensure systems are – and remain- maintainable and secure.
BonCode’s tool-based consultancy for software quality gives you clear and comprehensive insights into the hidden dependencies and risks inside custom-coded software. To see how it works, book a demo.
