Things needed to change
Centiq has migrated hundreds of SAP systems from one platform to the next since the early noughties. Until Azure became our focus it was from one generation of hardware/OS/DB to the next.
During this evolution we started to notice that it did not matter how good the architecture and build quality was, the systems reliability decreased over time as changes were implemented. The build gradually degraded as the quality of configuration slipped from the original state. Customers would loath upgrades and other changes adopting an “if it ain’t broke don’t fix it” attitude to IT.
Each time the hardware was replaced the cycle started again with a step-change in platform and software versions, taking all the pain in big batches once every five years. We knew this had to change. As IT became front and centre of business transformation, the need to adapt to change or be displaced by faster-growing, more agile businesses became the risk that needed managing. Limiting the risk of outages by limiting change could no longer be the order of the day.
OK, so you want the SaaS experience, but without the SaaS trade-off?
There are still some barriers stopping customers from adopting the SaaS offerings over the traditional on-prem license/deployment model. Sometimes the functionality isn’t quite mature enough, sometimes they can’t take all of the valuable historical data, sometimes their existing customisation is just too valuable to discard. Whatever the reason, most SAP customers that come to us have a reason for not adopting the latest SaaS replacement. These customers want the pain-free, hassle-free, always up-to-date SaaS experience, with the flexibility and competitive advantage that their on-prem customised deployments can achieve. They don’t want a trade-off, they want the best of both worlds. So our mission has been to try and achieve this by improving the way we deliver and maintain systems.
Stability issues cause millions in hidden costs and lost opportunities
Accelerating the rate of change alone is not going to improve your business. Large central systems like SAP, that are core to the organisation, can potentially cost the business millions for every hour they are out of service. Hours of time wasted waiting for systems to come online, impatient customers going elsewhere or even expensive development projects stalled by problems with test systems.
This tension between the desire to accelerate change at the same time as increasing stability needed a new approach. We looked outside the SAP ecosystem and started to see the other ecosystems adopting a DevOps culture. This tension between throughput (of change) and stability is core to what the DevOps movement tries to address. So we hired outside of SAP to bring some of this thinking to the SAP world. A key part of this story was the definition of the build process and configuration being captured in code and version-controlled – commonly referred to as Infrastructure as Code (IaC).
The Infrastructure as Code for SAP journey began
Even before we started to work on Azure, we were starting to build systems using repeatable processes. Some of it was provided by the HANA appliance vendors, some from the Linux vendors and some from our own team as they started to become familiar with technologies such as Ansible and Terraform. The game-changer for us was back in 2018 working with the Thames Water cloud team who shared the same vision for SAP systems as we did. With some encouragement from Microsoft, we set sail on a brave voyage to create a codebase to implement on Azure both S/4HANA and BW/4HANA systems using Red Hat clustering with DR in a secondary region. We still support this code-base today and are very proud of all that we have accomplished for this customer. It’s a reference that has enabled us to win further SAP on Azure migrations.
Meantime, in a coffee shop somewhere in Seattle
At some point midway through the Thames Water project, we discovered that Microsoft Engineering was also developing an open-source code base for building SAP systems on Azure published on GitHub that supported SUSE. The next Centiq project after Thames Water required a SUSE build instead of Red Hat, so we took the decision to use the new open-source code base from Microsoft as a foundation for our next build. However, we found it needed a lot of work to make it production-ready. Not all of the Microsoft recommendations that are part of the reference architecture were reflected in the codebase at that time and we knew that the work we had done for Thames Water covered more ground in terms of testing and simplifying the end-user experience.
But what should we do? Continue to develop our own and compete with Microsoft?, or join forces with Microsoft to help them refine what they have to make it easier for organisations (or customers) to use it for production use? As a growing investor-funded organisation, Centiq is always looking for opportunities to create intellectual property and keep a competitive edge in the market. Competing with Microsoft’s efforts was not going to achieve this so we flew to Seattle in 2019 to agree on our involvement in the open-source collaboration. (To our surprise, when we arrived most of the coffee shops were closed at 17:30 on a Monday, and we were forced to go to “Top Pot Doughnuts”, where there were clearly some techies that used it as their primary office space).
Together with Microsoft, we are improving the SAP on Azure experience
We’ve enjoyed working with Microsoft on the latest codebase and are excited by the future plans they have in this space. What’s great about this opportunity for Centiq is that we are no longer trying to solve all of the basic problems on our own. This gives us more opportunity to focus on the customer and solve some problems that are specific to them. Every customer is different and they bring with them a specific set of challenges that can rarely be solved with a single generic solution. Centiq’s cultural strength has always been the ability to help and advise customers on best practices, but always being customer-driven and allowing them the freedom of choice. We make sure we meet the customers’ requirements, which are a combination of real needs and desires.
This individual customer experience and varying customer requirements mean that using the open-source codebase will always be a great first step on the path to success with IaC, but to get all of the benefits from IaC there is a lot more work to do. We help customers evolve by simplifying the pipeline for changes in their SAP platforms to enable high rates of change whilst maintaining high levels of stability.
We can take the open-source code, add in the custom requirements and then build a complete system for configuration management, the version-controlled pipeline of change with quality assurance built into the system itself,
improving the service of the SAP platform for life, not just the migration.
Robin Webster, CTO
Accelerated, sustained transformations.
