For a long time now, I have been opposing intensive centralism. I have always favoured freedom, independence and responsibility for oneself. Yet unfortunately, all too often economic advantage works against a distributed organisational structure.
Here’s a ridiculously small example but one that is revealing of our situation: in the canteen I met a former tennis partner of mine who now works in central IT purchasing. He told me about the disk-drive framework for our IBM servers and Fujitsu servers. The framework takes up 2.5-inch SAS/SATA disk drives and consists of a little bit of metal, a lot of plastic and a sealing mechanism. From our listed German distributor, one unit costs substantially more than EUR 100. A San Francisco-based supplier is now offering exactly the same part for not quite USD 20. An apprentice in Purchasing located this source via Amazon.
These are nice anecdotes but they did give me reason to reflect: we have a redundant IT-infrastructure with several suppliers of electricity, servers, storage and diesel – the latter for the emergency-current assemblies. Our list of second-suppliers and third-suppliers would quite easily fill up a whole E-3 magazine.
Breakdown security and disaster game-plans are a matter of course in our global IT architecture. And naturally this is not a topic solely affecting IT. Facility protection, security, plant managers and many others are summarised in disaster-recovery teams here. Yet there is no plan for the breakdown of a unique cloud platform, such as SuccessFactors, Ariba, Concur, HEC or HCP!
The situation is more complex than it may at first seem to be: a redundant computing-centre architecture can be operated globally, even one that reacts in ꞌreal-timeꞌ. Yet if there is a software bug brings the algorithm to a halt, hardware with breakdown-safe functionality is no help. Of course, there are solutions for this too, albeit ones that cannot be organised and financed in the normal commercial environment: one can get an assignment completed by two independent programming teams.
It is very unlikely that both teams develop precisely the same algorithm, containing exactly the same errors. Yet not even this doubled expenditure solves all problems. In the event of one algorithm collapsing, the other one hopefully continues to work – and there is sufficient protection. But what if both programmes do not break down but produce different results? Then you would need a third programme to get close to establishing what the correct end-result could be.
Unfortunately, here I cannot present a solution for the SAP community and can merely pass on some thoughts that emerged from our internal discussions: in view of current technical developments and feasibility, a case cannot be made in favour of an established customer being fully dependent on software-as-a-service, as constituted by HEC, HCP and many SAP subsidiary companies.
It appears to be feasible to have an IoT-application with HCP. But what happens if there is a meltdown? Where are the data backups? After a download: can the data be reused? What form does the data then take? Which software is there, loyal and on-premise, at the ready to be able to read the data?
Naturally, there are good reasons for cloud solutions such as Business ByDesign and HEC or S/4 in the cloud. Anyone not needing an IT infrastructure, needing few resources and wanting a solution straightaway is probably well-advised to opt for these instant solutions: cloud computing also has its raison d’être!
But those who have been faithful established SAP customers for 30 years, have acquired a lot of knowledge and experience, and can also call the necessary SAP architecture their own, will give SaaS models a wide berth. Hybrid clouds and hyper-converged infrastructure – yes, but probably not cloud computing with SuccessFactors, Hybris, Concur etc.
Many years of professional experience have shown me that many problems allow themselves to be solved by viewing them from a different angle. We will take our time and rethink the second-source problem for software. But likewise our SAP should take or grant itself some more time.
There are still horror stories told about Hana and in-memory-computing anomalies. No IT executive is surprised – good software goes through a process of maturing. To this day it ranks among the SAP community’s greatest puzzles why the aim is to force Hana into the market by using strongarm tactics. To put the deadline back from 2025 to 2030 and to grant S/4 Finance and Logistics the necessary reviews does not amount to a sign of weakness but a sign of self-assurance and of vision.
As I write these words, the TV news is broadcasting the report that Volkswagen has no second source for particular Golf parts. Up to now, I couldn’t imagine an automotive manufacturer without a second supplier – yet such a thing exists. SAP has already had to learn painfully that it has no second source for SuccessFactors.