Customers frequently ask me which applications they should migrate into the Cloud. The answer is quite often “It depends”. Whilst this isn’t necessarily what they want to hear, this post will explain why it is indeed the right answer.
Cloud systems are generally not geographically located near their users or other systems that the customer has. This creates both challenges and opportunities across the following areas:
- Application architecture
- Network architecture
- Legal and compliance
- Business continuity
Putting an Enterprise Application, like an SAP ABAP stack, up in an Infrastructure as a Service (IaaS) Cloud is pretty easy. However if you want it to continue to ‘talk’ to, and provide data or interfaces to other systems, then you have to ensure that the architecture supports a distributed architecture. For example, one customer had a custom developed application for warehouse functions which had to be on the same subnet as the SAP system which meant that either both applications went to into an IaaS Cloud or neither of them did.
Separating two applications which are ‘chatty’ network-wise, like ECC and CRM, is not a good idea. Even the running of a large number of small packets can lead to horrific latency. I worked with a utilities customer which uses SAP CRM in its call centres, each customer record in CRM is linked to a customer billing record in SAP ECC. Any latency in this connection causes issues with the centre agents and vastly reduces their effectiveness. Similarly, it is not a good idea to move applications which transfer a large amount of data. The textbook example of this is SAP BW – although this is not as cut and dried as it seems. Provided the bandwidth between the sites is large enough, and there is enough time in the data loading window, this can be accomplished.
Legal and compliance
As above, a Cloud provider is unlikely to be geographically centred near the existing on-premise or hosted environment. It might not even be in the same country. This raises interesting legal and compliance issues which must be investigated with respect to live production data. There are rarely issues with development data or test data, the main concern with these non-Production systems would be intellectual property related to applications and or processes being seized by authorities in the hosting country. If it is possible to place non-Production systems in a Cloud, it may be necessary to have a small Pre-Production system in place to account for any architectural differences between on-Premise/Hosted environments – for example non-Production on X86 chipsets and Production on Power chipsets.
Business continuity is an interesting use case coming from a previous exercise with the customer, during a cost optimisation exercise, it was noted that the customer had never invoked DR – they had a separate DR landscape for their Production servers which was effectively standing idle. Looking at IaaS providers, a proof of concept (PoC) was executed which created a similarly sized Production landscape. In this case the application servers were shutdown, saving on cost and the database server was created and database log shipping was enabled. This created a copy of the system which could then be turned on and scaled as required in the event of a DR. There were other considerations around DNS and SAP Gui configuration which were out of scope for the PoC, but the PoC was successful.
Let’s not forget internal politics
Another consideration is internal politics, which I intentionally left off the above list. In every endeavour this must be dealt with - however only you, the customer, knows your internal politics and the impact this can have on choosing your system. You have to have a strong executive sponsor during the process. Without one, your efforts can be derailed easily – unless you are doing it in secret!
Ultimately, the choice of which application to pick is the convergence of three factors – technical, complexity and politics.
In my experience, the Cloud PoCs which have worked best where those which took a reasonably complex system, or systems, and migrated it to an IaaS service. They usually started out small with limited publicity and only once the projects have some momentum and clarity do they then became full projects. All of them had a strong executive sponsor from the start which helped to steer the politics and the project to a successful conclusion.