Automation, a new trend?

Share this
Article:

Browse By Topic

• AI & ML
• Automation
• Cloud Strategy
• DevOps
• Featured
• FinOps

Browse By Type

• Article

‘Automation’ has become one of the buzzwords in IT as one of the pillars of another big buzz concept, the ‘Digital Transformation’. But it is in fact the essence of IT, as computers were designed to automate tasks but for many years we seem to have forgotten this premise and neglected the fact that many of the processes that are executed in order to manage our IT estates and develop applications can indeed be automated.

A very straightforward definition would be that a task can be automated when we do not want to do it twice, so everything that is repetitive can be automated. The most direct gain of automation for companies is that if their teams do not have to be running long fixed processes manually they will be able to focus on new initiatives, for example on delivering a much better user experience, and the companies will become much more flexible when it comes to introducing and adopting changes (here we have more buzz concepts pertaining to the ‘Digital Transformation’). Another main aspect of automation is that it helps eliminate human error, since once an automated process has been defined and tested it will produce exactly the same results each time it is run and this also saves the teams many hours otherwise spent in troubleshooting problems induced by mistakes derived from manual activities.  

Most companies already use and have been using for a long time automation in certain areas but this tends to happen in small pockets or silos, for example, we find that the networking team might have written some scripts to change rules in the firewalls or that the development team uses some automated tests, even within a same team we can find different types of automation technologies. All this makes it difficult to share these automation resources across the company and works in a different direction of what the digital transformation suggests.

Automation for SAP too? Yes, of course

The value of automation applies to SAP landscapes as well. The SAP field has been historically quite conservative, following not very flexible established processes to manage and operate its systems and a common thought was that the operations for these workloads were too complex to be automated, a good example can be a system refresh to have the latest data from production in a test environment, that entails many tasks some of them quite dependent on the system and the applications connected to it.

Luckily two major factors are making customers consider the use of automation for their SAP landscapes, the first one, an event, is the deadline of 2027 to migrate from classical SAP Netweaver to SAP S/4 HANA and the other is the increasing trend of moving workloads to the public and hybrid Cloud. The former requires a technical and functional migration and the latter is a replatforming that in many cases is being done as part of the project to migrate to SAP S/4HANA, so both come often hand in hand. Moving to the Cloud is definitely something necessary in the process of digital transformation if companies want to achieve that flexibility that we mentioned before and automation is the best way to dramatically accelerate this move and ensure that the new platform will be completely optimized for the SAP workloads running on it.

Since both the migration to SAP S/4HANA and the move to Cloud require the joint work of various teams (infrastructure, OS, DB, SAP Basis, etc.) it is a great opportunity to start using automation at scale and not only in silos, using a single technology and sharing it across teams. That is why a software tool that provides simple but powerful automation for cross-platform computer support, like Ansible for example, is a good option to automate all tiers of the IT estate and share content that will reside in one place only. Customers can create their workflows to automate processes end to end with just one click, for example the deployment of the target SAP systems when they are moving to the Cloud, with the creation of the VM with storage and network configuration, installation of the OS image, application of all the SAP notes needed to run SAP HANA and SAP S/4HANA, installation of SAP HANA, installation of SAP S/4HANA, configuration of high-availability on DB and application tiers, etc.

Automation is for life

Once this first big project is completed the next step is to keep using this automation at scale and include it in everyday tasks for the management of the SAP Systems like changing SAP profile or kernel parameters, stopping and starting in the right order SAP systems and the applications connected to them (for maintenance activities or for development systems that do not need to be running outside business hours so that customers can save on Cloud consumption), carrying out all type of DB operations, patching the OS or the DB, updating the SAP kernel, SAP system refreshes (as we mentioned earlier), adding and removing SAP application instances when the workload in a system goes beyond or below a certain threshold, … The list is as long as the use cases of a customer and the more they cover the more resilient their systems will be and that will earn the IT teams the trust of the line of business, resulting in more flexibility to perform maintenance because they will have proven that the downtime can be greatly reduced using automation.

Summary

Automation is for all type of devices, systems and workloads and SAP should not be considered as one of a kind, companies need to break that myth and make the most of all the values that automation can add to the whole IT structure and with the need to migrate to SAP S/4HANA now it is the best moment to fully embrace it to ensure that this big change will not be a traumatic process and that management of SAP systems can be a much easier task than what it has traditionally been.

If you are interested in exploring more details of automation applied to SAP and other solutions you can find some portfolio architectures that use it on this site.

Ricardo Garcia Cavero, Red Hat
Principal Portfolio Architect, Red Hat