Imposed maintenance, unclear roadmaps.

SAP customers are dissatisfied, and many lines have been written about how and why. Imposed maintenance, high license fees and unclear roadmaps are just some of the points that are mentioned again and again. But isn't it precisely at this time that the guild of technology consultants is making an important contribution?

The underlying technology of an SAP system has not changed over the years. It consists of an operating system, a bunch of executable files, and a database. That's the way it is, that's the way it was, and that's the way it will stay for now. Even the trend towards cloud and S/4 will not change this for the time being. An SAP system remains an SAP system.

Good conditions

Software is still installed manually, step by step, by many companies, whether in-house or consulting. Only very few use automatic tools, and if they do, then for good money. Open source tools and their possibilities are not used. Especially in Germany, good solutions always seem to cost something. Is that still in line with the times? Or do we have to take the next step?

Docker has existed since 2013, Ansible since 2012, and Kubernetes since 2015. Nevertheless, SAP technology often seems to lag behind the trend toward more agility and flexibility. Automated provisioning is rudimentary, and the rolling kernel switch is rarely used. Infrastructure as Code and Containering seem to have completely bypassed SAP until now. Yet an SAP system actually offers good conditions for implementing such an approach.

So the questions are simple: Have we all just been asleep? Can't we already deploy SAP systems automatically today? And how deeply integrated is automatic deployment already? Let's just take a look at various aspects of an SAP system. At the beginning of an SAP life, there is always the question of structure and configuration: How many users are working on the system? How many systems do I connect to my SAP system and how? Do I only need a production system or are testing and development also needed?

Particularly in medium-sized companies, it usually comes down to a 3-system landscape consisting of a combination of database and application server. Often, only one application server is used, also to reduce costs. With regard to Hana, calculations are often made on a knife-edge basis and the main focus is on costs. Many companies are currently still planning with their own data centers or outsourced hardware.

This often overlooks opportunities to the right and left of the mainstream. Imagine the following scenario: You are a medium-sized retail company that wants to migrate its SAP ECC 6.0 EHP 7 from AnyDB to Hana in a future-proof manner. The sizing reports give you a storage requirement for a Hana instance of 1.5 TB and there are supposed to be around 500 users working on the system worldwide.

Since you trade worldwide, you naturally want your productive system to be highly available. You have already outsourced development and your colleagues only work during normal business hours anyway. Of course, you could now implement a new virtualization solution and purchase the corresponding hardware. Data, setup and maintenance are in your hands. If necessary, you have still brought in an external partner to provide support.

Unexpectedly, your department asked for a business warehouse system. However, your hardware was not designed for this at all.

What to do? Think ahead!

Option 1: You create new hardware. The procurement process will take you some time and you need the appropriate space in the data center.

Option 2: You build the systems externally. You will definitely save yourself the tedious hardware procurement process and put the responsibility for the hardware in other hands. Whether it's Amazon Web Services, Microsoft Azure, Google Cloud Platform or another host, the hardware responsibility lies elsewhere. Many hosts also take the responsibility for the operating system and database off your hands. Congratulations, you've entered the service jungle. You are only allowed to use the system and every change needs its own change.

Option 3: You think ahead. Up to now, you have operated your ERP system with a system replication and you want to keep this as a mandatory requirement. How about outsourcing the replication side to the cloud? This gives you space for the desired business warehouse and at the same time you can still benefit from the advantages of the cloud.

"But the costs!", some will surely think now. Cloud is not cheap, none of the Big Three will provide you with infrastructure for free, and of course they still want to earn something. But if you now use System Replication without Memory Preload, you first of all only pay for a relatively small virtual system and the database storage.

In the event of a failure of the main database, the Cloud Virtual Machine can be automatically adapted and booted up within seconds. Only now do you pay for the full size of the Hana database.

If we pursue the idea a bit further, we could also implement application servers and a highly available ASCS instance. If we distribute these globally, the employees in Japan and the USA will also be happy about shorter GUI runtimes. Of course, you can sketch out further variants forever, but you will unfortunately end up relatively quickly in regions that are no longer sustainable and usable for a medium-sized company.

In a company, there are always periods when the end user wants more performance from the system. Quickly adding an application server is certainly a simple but effective solution. The steps required are straightforward, but even savvy technicians can spend a day on provisioning, installation and configuration. What if you could automate a large part of the provisioning and installation?

You can't? Yes you can!

Infrastructure as a Code, Ansible and Unattended Installation are the magic words. The whole thing is not limited to one of the hyperscalers, but can also be easily run on any ESXi with VSphere.

Let's start with the creation of the virtual machine. On VMware, the VM is usually created from another via cloning or from a template. Then you create the necessary SCSI controllers and hard disks and mount them in the operating system. No matter if with commands or Yast, you are busy for two to three hours with this step alone.

With Ansible automation, we can complete this first step in just a few minutes. In addition, we can already load our installation media for the application server from a central data store and start the software provisioning manager in the same step. It also doesn't hurt to take a look at the GitHub repositories of Google and Amazon. Here you can certainly learn a thing or two for your own scripts.

The scripts are not witchcraft in the case of Linux and anyone who has already dealt with them will be able to cope with them. Downloading and configuring the required SLES packages, for example, becomes a very short shell script. Even providing the necessary mount points or volume groups and logical volumes is done in a few commands familiar to most Linux aficionados. Windows and Linux have taught us the pretty and colorful GUIs, but many things could be done in a few commands. Since you can also save and combine them, future deployments will be faster and faster.

Stumbling blocks

Now that the VM is deployed and the operating system is configured, the required installation media and SWPM are downloaded. In the case of the Google Cloud Platform, we store the required data organized in a cloud bucket and can now load the data from the cloud bucket to the new VM via simple gsutil commands. Of course, this approach also works with AWS and Azure, as well as a simple NFS mount in the VMware environment.

After placing and unpacking the Software Provisioning Manager (hereafter SWPM), it is time to start. Here lurk smaller stumbling blocks, which one must circumnavigate. First we need a so-called inifile.params as well as the instkey.pkey file. The inifile.params contains the content and with which media and passwords should be installed.

The passwords are encrypted with the key from the instkey.pkey. To get both files, you have to perform the installation manually and stop it in the installation overview of SWPM. Then save both files and keep them in a safe place. For subsequent systems, you can simply change the inifile.params and thus perform installations and, above all, system copies much faster.

As a second important point you need the product ID of the system to be installed. This can be found in the inifile.params and is, as the name suggests, product specific.

Now we know that it is possible to install systems automatically with SWPM. But how does that help us in day-to-day operations? Let's go back to our initial case study, the decision of what to do with the new BW and the old ERP.

We simply assume that during the Hana migration, the ERP systems will still be migrated to one of the three major cloud providers right away. If we recall the structure of an SAP system, we can use the knowledge to significantly accelerate the migration to Hana.

Automate deployments

An SAP system basically consists of a few executable files, the required profiles and a database with the version information. For a successful migration, only the kernel has to match the information stored in the database and our system runs on the new hardware or database. The goal must be to install the cloud systems as quickly as possible via automatic deployment. Afterwards, it can be converted to the corresponding source system by a database refresh via export/import.

We can, of course, automate the deployment of systems even further. Thus, the Ansible playbooks are a worthwhile occupation for the current crisis. Even for an experienced SAP consultant, this topic will be completely new territory at first, but the community and Red Hat have fully documented the most important functions.

The basic functions for deploying a system are defined in a playbook. Colloquially, it is a collection of tasks that are to be executed on the corresponding host. From the creation of volume groups, to the creation of users and groups, to the launching of scripts, virtually anything is possible. Without further intervention, we can thus install systems or application servers, perform system copies or even uninstall things.

As you can see, I have not given you a complete guide to the automatic deployment of SAP systems here. Nor is that possible, since every system landscape and every requirement is different. The path and the decision to transform to the cloud are as individual as there are possibilities. All the options described are also possible in your own data center and with VMWare and do not require a large cloud infrastructure. Ultimately, as is so often the case, it will be the hybrid system landscape that we find.