Why we build SAP S/4HANA from code
During our most recent Experts’ Forum our Head of Engineering, Dr Ben Moss, walked the room through a customer project where Centiq delivered an automation framework to enable the build of S/4HANA on Azure. The room were all agreed in the value of automation of the Azure infrastructure (stuff that you would otherwise configure in the Azure portal), and the OS and cluster configuration (RedHat in this example), but were struggling to see the value in deploying the S/4HANA and Netweaver platform on top. The perception is that in an SAP product lifecycle, the SAP product “Install” process, typically happens only once every 5 years – so why would you bother automating it? – Hold onto that question while we introduce the CMDB.
According to wikipedia a Configuration Management Database (CMDB) is
“an ITIL database used by an organization to store information about hardware and software assets (commonly referred to as Configuration Items [CI]). This database acts as a data warehouse for the organization and also stores information regarding the relationships among its assets. The CMDB provides a means of understanding the organization’s critical assets and their relationships, such as information systems, upstream sources or dependencies of assets, and the downstream targets of assets”.
This concept is a valiant attempt to bring some structure into IT documentation, to help with the ongoing support of IT systems. But in my experience, it is often an ambition that never quite delivers against the promise. Always incomplete and often out of date, the CMDB creates bottlenecks in the release cycle as changes go through a slow Change Advisory Board (CAB) process in order to validate against and update the CMDB. Any CMDB is better than no CMDB, but I think it is time to improve on this idea with something a bit more dynamic (and I don’t mean a discovery tool!).
Introducing Infrastructure as Code (IaC)
Define, build and run your IT systems with code, then every configuration item (CI) every tunable, every configurable, every design decision is captured in code. Or in some form of configuration file, version controlled and audited in a tool like git and backed with a service like GitHub. If I have a problem associated with config – I can see when it last changed? I can see differences between versions? I can rebuild from code and get the same result over and over? And the CAB? If you can run through the change and backout multiple times using IaC automation before the production release, implement automated tests to check the before state and the expected end state of ALL known dependent systems as the change is processed, and share the results with the CAB, does that not improve the success of changes? Should the CAB be the team that spot dependencies of a change? Should they not be built into the system as tests?
The better we get at IaC and the more testing we build into the system means less work for the CAB, less need for a CMDB.
So let’s return to that SAP build question
Why automate deploying the S/4HANA and Netweaver platform? – Well, think about the config that is captured as part of that process. Much of the complexity associated with clustering or application to database tier relationships starts at the point at which you do the installation. It is often the basic stuff that trips you up later in the life cycle – e.g. DNS names in use, service addresses, file system locations. We estimate that when an S/4HANA system is built manually you make in the region of 2,000 different decisions and interactions – many of them relate to hundreds of configuration items. When you build out the entire landscape that number of steps looks more like 50,000, which might equate to a thousand different configuration items. Assisted by automation, we capture them all in code. Do you store all that configuration and information on dependencies in the CMDB? I doubt it. Does it keep a history of previous settings? Does it cope with a dynamic scale out of your on-demand cloud-based app tier? Does your discovery tool capture the relationship between cluster nodes and the app and DB servers? (If it does, then it’s almost certainly to be manually entered data, prone to human error!)
So if we hardly ever “Install from SAP media” again, when does this pay off?
Think about a few key operational processes that cause you pain that might benefit from runbook automation:
- Recovering from High Availability (HA) cluster failover
- Invoking Disaster Recovery (DR)
- Recovering from a DR invocation
If you already have the key information that defines a clustered HA pair with tests that understand the cluster state in code, it will be easy to code the process to recover from an HA fail over. Again, DR process automation becomes an easy addition when you already have the build and tests defined in code. The need for CMDB “discovery” tools only exists because the information was not captured at source.
With all of that troublesome SAP system configuration defined in code in a version control system, we can regularly test that what’s installed reflects what we have in the codebase – to ensure that changes to the configuration are noticed and either rolled back or adjusted in the codebase. With this level of governance who needs a CMDB? Well I have to admit that having a friendly view of the IT estate is going to be useful for many of today’s operational challenges so I concede that the CMDB is not quite dead, the IaC automated workflows will populate it and keep it breathing for a few more years.
Read more in our Thought Leadership pages.