There’s an old saying in information technology circles when the discussion turns to platform-level shifts and massive sea-change, watershed moments of development. People will inevitably ask: When is the next big thing? The safe answer is always, “About five years.”
The next Twitter, the next Internet of Things (IoT), the next cloud computing model, the next resurgence of interest in artificial intelligence (AI) and the next quantum computing revolution typically come about in roughly half-decade cycles. That is why the five-year plan is so often used to describe the shape of so many strategic road maps.
As we stand in 2018, SAP probably has a variety of five-year plans playing out throughout its combined software stacks, but it is the seven-year plan leading up to 2025 that may be of higher interest.
A Plug-Pulling Moment
What SAP wants to do between now and 2025 is to prepare for a time when it will end mainstream maintenance on all instances of ERP installations that were originated in the era before SAP S/4HANA. This plug pulling moment impacts software including SAP Business Suite with its constituent elements of CRM, SCM, PLM, and SCM functions. SAP also wants to bring an end to its current maintenance program for SAP ERP Central Component (typically known as SAP ECC) as the previous generation of the company’s ERP software.
This should come as no major surprise. SAP clearly wants to bring its user base forward into the SAP HANA and SAP Leonardo years, which themselves, by convenient coincidence, are two brands that came into being roughly five years apart between 2012 and 2017 respectively. So as SAP plans to have all its applications delivered as SAP S/4HANA apps by 2025, what kind of mechanics will it need to focus on?
Some of what happens on the road to 2025 is played out in defined subspaces of the SAP universe. As a suitable example, it was back in July 2016 that SAP entered into an agreement with authorized reseller Appeon to allow the firm to develop a new generation of the PowerBuilder rapid application development platform, originally acquired from Sybase. Users of this technology can already think about a stand-alone future.
SAP still has an interest in its installed base of legacy contracts that span technologies not quite as fashionably fabulous as SAP HANA and SAP Leonardo, but the firm has not been without criticism in this space. We all know where its favorites lie and it has been openly discussing its road to 2025.
Substrate-Level Computing Fabric
Other elements of this story play out as rather more upfront surface level developments, even if the technology itself is still essentially lower-level computing fabric and operating-system-level engineering.
As the preferred operating system for SAP S/4HANA, SUSE global alliances team members Dirk Oppenkowski and Sabine Soellheim insist that SAP has chosen open-source, open platform computing as a key strategic move going forward.
“Only an open-source infrastructure can assist with the scalability and reliability needed for digital transformation now—and in the decade to come. SUSE and SAP have years of collective history and the move to SAP S/4HANA is the right technology at the right time, as migration is an inevitability that should be realized sooner rather than later,” insist Oppenkowski and Soellheim.
Key factors for the digitally transformative seven-year road ahead include open platform skills and plain and simple usability. System administrators need a console-style user interface to be able to perform system authentication integration actions. These same users will benefit from guides that help system administrators quickly adapt to system operations.
Prescribed Preconfiguration Prerequisites
SAP customers may now have a few tough decisions to make regarding which legacy platforms they maintain, regardless of SAP’s plans. They also need to consider which 2025 SAP S/4HANA road map technologies they will start to bring online (or get ready for) now in 2018. Not all platforms are created equal, so it will be important to look for automated tools and optimized preconfigured solutions that speed up deployment and lifecycle management on premise, in a private cloud, or a public cloud.
Some of those tools will be SAP tools and some may reside with legacy software providers: This is a big ask and a complex job, so it will be important to look for these automated software layers (tool sets or wider platforms) where they exist.
To put all of the above point in simpler terms: This is technology infrastructure shifting, so a cookie-cutter approach will almost certainly not work.
We’re moving from a world with SAP R/3 where there was a choice between IBM DB2, Oracle, Microsoft SQL Server, or indeed Sybase ASE to world of SAP HANA. SUSE’s Oppenkowski has said that, certainly for large organizations, moving a huge chunk of NetWeaver deployments off R/3 is a gargantuan task, even in a seven-year time frame.
POC First, Infrastructure Second
As in the famous Gary Larson cartoon, this is a case of “First pants, THEN… your shoes.” Except this time, it’s first to develop a proof of concept (POC), THEN shift to the infrastructure. The actual nature of the technology in this instance (clue: we do mean the cloud here) should (in theory, at least) make the proof-of-concept work easier and more achievable.
The cloud gives us the ability to spin up sandbox test-beds far more quickly and fluidly than traditional computing infrastructures did. So perhaps now is the time to start the POC planning processes along with the hunt for the right preconfiguration and automation tooling.
The plug is ultimately being pulled, but for now, the bathwater is still warm. So start spinning the rubber duck through some new routines.