Dependencies
In IT there is no way to avoid dependencies. However, it certainly matters how many dependencies there are, how great these dependencies are and what consequences these dependencies can have. A dependency is always a risk. Without knowing the risks in detail, the potential consequences cannot be properly assessed. A risk assessment is an essential part of risk management and therefore a concern of the executive management.
Dependencies in proprietary developments
When developing your own products, there is first and foremost a dependency on your own organization, the internal processes and the resources available. In other words, an organizational dependency that has a direct influence on the fate of the product. Then there are the product-specific dependencies. Software developments rely on platforms, frameworks and libraries and use programming languages. DevOps (development operations) tools are also embedded in the development process. The platforms, frameworks and libraries used are independent third-party products that are either further developed or become obsolete. In-house development must adapt to this. The same applies to the programming languages and the DevOps tools. In-house development is therefore never complete, but must always be adapted to the latest status of the platforms, frameworks, libraries, programming languages and DevOps tools used.
Dependencies with commercial products
Dependencies in IT come with the choice of products and the choice of vendors. And this affects all three core areas: (1) infrastructure, (2) communications, and (3) application landscape. Vendors get big because they have a product portfolio that covers multiple areas and where the products are aligned with each other in such a way that they work in combination, but do not necessarily work equivalently with products from other vendors. Each vendor has its own product policy and the customer must come to terms with that. Every vendor has its own world, and the customer must find his way around in it. This requires that the customer builds up the appropriate know-how in his organization and provides the corresponding resources. This is what is needed to guarantee operation. Given the breadth of the offerings of many vendors and the fact that each has its own name for products and technologies, this is not exactly easy.
If a customer uses both the platform and applications of a vendor, there is a double dependency. Operation-specific adaptations and extensions are proprietary developments, which in turn are tied to the vendor's products.
In the case of commercial products, maintenance costs are incurred for support, elimination of vulnerabilities and ongoing product development. This is charged to the customer through a maintenance contract and sometimes through higher costs. These costs can also be part of monthly usage fees (Platform as a Service - PaaS, Software as a Service - SaaS). For on-premise products, the costs of the maintenance contract over five years can exceed the initial product costs. Higher costs can additionally be incurred by the customer due to the ongoing development of a product by the vendor, because the upgrade is subject to a charge. Or because certain existing or new functionalities are made dependent on the use of a cloud-based service and this service is only available as a subscription, leading to unplanned additional costs.
There is an additional issue that is often overlooked: The customer is also dependent on the manufacturer in terms of the security provided. And this is usually massively lower than promised. The only way to find out how secure a product is, is to test it for security. This is time-consuming and causes additional costs. Believing the vendor that his product is "secure", as promised in the marketing messages and materials, is much easier and cheaper. But then you don't know the risks, and that's bad for risk management. It is also incompatible with an ISMS that fully supports ISO 27001. A gap analysis will provide ample evidence.
What is the best way to deal with standards and de facto standards?
Stefan Thiel is CTO of Altoo, a company that both deploys products from other vendors for its operational IT infrastructure and develops and offers its own product that runs in a private cloud. Thiel's insights from the field:
"In administration, we use Windows and Microsoft 365. In this setup, there is always a latent risk that company or even customer data will end up in Microsoft's cloud services (for example, OneDrive). That's why we make sure that all sensitive data stays on our own hardware in our racks in a data center that meets the highest standards.
For development, we need developer tools, and that inevitably leads to dependencies. The vendors of these tools have their own interests and want to increase their revenues. Developer tools: More and more vendors are trying to push prices up with "broader", more comprehensive products, and most importantly, push customers more towards cloud offerings as well. For example: GitLab is now also a build server - and not just a code repository - which however offers less support for specific technologies than other build servers (in our case for scala/sbt).
Or JetBrains also offers all-in-one for developers: wiki, issue-tracking, source repo, build server, ... but just as a cloud offering. So if we rely on on-premise to reduce dependency and use our own resources, we are limited in the choice of products. If we rely on a combination of products from different vendors, each of which specifically serves our purpose, this would lead to a cost explosion, as the individual components are no longer available, but the increased price of the all-in-one product must always be paid.
Therefore, there is not much choice but to rely on a single vendor and accept this dependency. If one relies on a single vendor, one is then fully dependent on this vendor because the definition of the build processes - i.e. their dependencies, sequences, branches, ... - is not compatible between the products of different vendors. So in this example, you can use the cost of migrating to another vendor as a metric, so to speak, to quantify the lock-in risk. Unfortunately, not every risk is so easily quantifiable."
Effects in practice
Lock-in effects are present in most enterprises and are exacerbated by the inclusion of cloud-based services. Switching to another product from another vendor would generate substantial costs and would have - at least initially - negative effects on operations. For vendors, this is a good starting point to raise prices from time to time. In addition, cloud-based services are cheaper for vendors because products no longer have to be adapted to a wide variety of platforms. Established vendors of on-premise products are therefore interested in combining on-premise products with a cloud-based component as well. There is a general principle that applies: The greater the lock-in, the more power the vendor has over the customer. Vendor-specific de facto standards represent a substantial risk.