Those who do not want to depend on cloud providers such as AWS or Microsoft need a thorough analysis and an exit strategy. […]
In enterprise IT, platforms offer a promising basis for storage, computing or application development. The Google Cloud Platform, SAP HANA, Microsoft Azure and Amazon Web Services (AWS) are just a few examples. Above all, they offer scalability and cost efficiency.
However, those who want to take advantage of the benefits should also consider the question of what dependencies could be associated with it. Once data and applications are transferred to the platform, the possibilities of controlling adjustments, further developments and security aspects are also reduced. In the worst case, the often cited lock-in threatens: The provision of IT services is then dependent on a platform provider.
Against this background, the reluctance of many IT managers is understandable. If you still decide to use one of the large platforms, you should recognize impending dependencies at an early stage and counteract them. The following recommendations for action are available for CIOs:
To prevent a lock-in, it is important that you recognize dependency potentials. When selecting suitable platform providers, an evaluation of the lock-in potential should also be carried out. From a technical point of view, compatibility and portability are essential.
The assessment of the dependency potentials should be based on the exchange costs. Several components must be considered. First of all, you should analyze the portability of the data. Data transfer involves high costs when data extraction is complex and incompatible formats are used. In a further step, it is necessary to check the compatibility of the applications. Non-standard interfaces and individual adaptations of the platform environment to special needs of the company make a change of provider even more difficult.
Also evaluate the cost of changing the downstream infrastructure. For example, if an alternative provider uses components that are not available for the platform originally used, this can cause problems. Ultimately, the know-how of the employees plays a central role here. Platform-specific knowledge that your own IT team has acquired is often no longer useful when changing providers. For example, AWS Lambda supports Java, C#, or Ruby programming languages when creating functions. In the Google Cloud, this is not the case.
Based on the roadmaps provided for the platforms, you can assess the expected benefits and potential. Future updates should not only be evaluated according to their functional potential, but also in terms of whether they can cause a lock-in or even increase it. You should keep in mind that platform providers are inclined to develop their own solutions that deviate from the standard in order to retain customers more closely. Although such features can be very attractive, for example by increasing performance or reducing costs, you should critically evaluate such updates in terms of dependency.
Also, be aware of the vulnerabilities of the platforms. Cloud platforms in particular generate their income via the masses: Only if the platform provider succeeds in achieving sufficient paid use of the platform is it profitable. At the same time, a large number of providers compete for the favor of companies, especially on the storage and computing layers. They should use this market situation to negotiate better terms and long-term benefits. Strengthen your negotiating position by obtaining counter-offers!
In order not to be trapped in the ecosystem of a single platform, you should also think about a multi-cloud strategy. Such a strategy provides for several providers and specifies the use of special components of one provider for selected areas of application. Even if the use of multiple platforms does not seem to make sense in terms of efficiency advantages, the associated flexibility and risk reduction can compensate for these disadvantages. A multi-cloud strategy enables you to take advantage of different platform providers, such as Azure analytics applications or AWS machine learning, while reducing reliance on a single provider.
In order to represent your interests vis-à-vis platform providers, a merger with other companies and a joint approach is often recommended. Since the needs of companies are usually very similar, it is possible to formulate common demands. Standardized file formats and interfaces can also be enforced, which ensure the compatibility and portability of your own applications.
One example is the German-language SAP user group DSAG, which gives user companies the opportunity to sustainably improve SAP software based on a reconciliation of interests. As one of the most influential user associations worldwide, DSAG reliably represents the interests of companies, while members benefit from a network and access to relevant knowledge. In this way, the user group can actively promote the development and optimization of existing and future solutions. Various successes become visible again and again, such as the maintenance guarantee of S/4 HANA until the end of 2040 or the integrated solution of SAP HCM and Travel Management in S/4 HANA.
In order not to face unpleasant surprises in the event of a change of platform, you should think about an exit strategy even before deciding on a particular platform. Evaluate the costs involved and keep an eye on the market. It is also helpful to organize your own data and applications in such a way that a migration is possible at short notice. This is the only way to ensure your decision-making ability in the end.