Technical and economical dependencies

In IT you cannot avoid dependencies. However, it certainly matters how extensive a dependency is and what consequences this dependency can have. A dependency is always a risk. You must know this risk in detail in order to be able to assess the consequences. This is an essential part of risk management and therefore a matter for the management.

Dependencies in proprietary developments

When developing your own products, there is first and foremost a dependency on your own organization, internal processes and available resources. 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 arise in IT with the choice of products and the choice of vendors. And this affects all three areas: (1) infrastructure, (2) communications, and (3) application landscape. Vendors get big because they have a product portfolio that covers multiple areas and in which the products are coordinated 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. Company-specific adaptations and extensions are in-house 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 functionality deficits and vulnerabilities, and further developments. 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 further 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.

Another issue that is often overlooked: The customer is also dependent on the vendor for the security provided. And this is usually massively lower than promised. The only way to find out how safe a product is is to test it for safety. This is time-consuming and causes additional costs. Believing the vendor that his product is "secure", as promised in the marketing, 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 shows this relatively quickly and clearly.

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 would create high costs and have a 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 more lucrative 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. The following principle applies: the greater the lock-in, the more power the vendor has over the customer. Manufacturer-specific de facto standards represent a risk.

The dependencies become greater - the risks increase

The dependencies with regard to IT are constantly increasing. Whereas in the past this was limited to product functionality, product quality, product safety and product availability, today it also includes data acquisition, data storage and data processing. Like Janus, IT has two faces. On the one hand, digitization by means of IT enables new opportunities and efficiency gains. On the other hand, IT creates more and more dependencies and thus becomes more and more of a risk factor. Management should take these risks into account and also factor them into the decision-making process. Service models sound tempting, but they can lead to the "Hotel California" effect: "You can check out any time you want, but you can never leave." Products that are only available as a service can cement existing dependencies, as switching is difficult and costly for the customer. Every dependency is a technical debt that must be paid.