Skip navigation

SAP HANA Cockpit is a web-based user interface for deploying, running, and managing your web applications and connecting them with services on the cloud.  It is a Web-based user interface, which is used to manage SAP HANA Cloud Platform accounts and applications and to access key information about your application on SAP HANA Cloud Platform.

 

Our customers are using Hitachi UCP for SAP HANA converged and Hitachi Unified/Enterprise range of storage platforms to run their physical/virtualized SAP HANA databases.

 

In addition, Hitachi Data Systems has a growing portfolio of SAP HANA management tool integrations (aka adapters) to extend access to the data/ functionality of our storage and converged solutions for SAP HANA database administrators, and to make the job of administration simpler and more effective.

 

Unified Compute Platform for SAP HANA converged-infrastructure solutions help you accelerate adoption and achieve faster time to value of the SAP HANA platform.  The solution provides a foundation for high-speed analytics with SAP NetWeaver Business Warehouse (BW), as well as a high-performance transaction-processing platform with SAP Business Suite layered on the SAP HANA platform.

 

In addition to offering the infrastructure, Hitachi offers an end-to-end SAP HANA solution.  We can bundle a complete enterprise data warehouse solution for SAP Business Warehouse on SAP HANA.  This tighter integration will allow customers to purchase the Unified Compute Platform, the SAP HANA software including the appropriate licenses, and managed services from Hitachi Data Systems.

 

The SAP HANA Cockpit Adapter will complement the UCP for SAP HANA solution by providing the capability to monitor the hardware components and provide local replication, snapshot, copy and cloning features for the SAP HANA system.

 

The Hitachi Adapter is accessed from SAP HANA Cockpit after you install Hitachi HANA Management Service on the Windows management server, and import the delivery unit to the SAP HANA Cockpit.

 

The screen below appears so that you access the tile for the adapter.

 

BD_1.png

 

The following screen shot shows the SAP HANA Server Adapter – Overview of HANA host:

BD_2.png

 

I’ve included more details on the SAP for HANA Cockpit adapter as follows:


The Hitachi SAP HANA Server Adapter for SAP HANA Cockpit

The Hitachi Adapter for the SAP HANA Cockpit is installed on the HANA server and is accessed through the SAP HANA cockpit.  The Hitachi Server Adapter will provide server discovery, and additional monitoring functionality.  Specifically, the adapter:

  • Allows users to discover Hitachi Compute Blade server components (such as chassis, blade, and others).
  • Allows users to monitor the health information of Hitachi Blades.

 

The Hitachi Adapter for SAP HANA runs as a cockpit web application.  When the adapter’s services are needed, the adapter calls the web service.  Then the web service communicates to HCSM (Hitachi Compute System Manager) a systems management software application, and returns server related information to the adapter.


The Hitachi Adapter for SAP HANA Cockpit will support the following features:

  • Discover Hitachi Compute Blade 500, and 2500
  • Display blade servers component information in SAP HANA Cockpit
  • HANA workload mapping
  • Health information for server
  • Capture events from Hitachi blades and display alerts in HANA Cockpit.
  • Display Hitachi blade chassis and blade firmware version for CB500, 2500 servers in HANA Cockpit.

 

The Hitachi SAP HANA Storage Adapter for SAP HANA Cockpit

The Hitachi Adapter for SAP HANA Cockpit will enable the systems administrators/DBAs to take a clone/snapshot of HANA Database HDS storage directly from the SAP HANA Cockpit.  This provides a single user interface to monitor SAP HANA, Hitachi Server Components, Hitachi Storage and Manage Storage Snapshots.


The SAP HANA Cockpit is a web-based tool for administration and monitoring of a single SAP HANA database.

 

The Hitachi Adapter for the SAP HANA Cockpit is installed on the HANA server and accessed through the SAP HANA cockpit. The Hitachi Adapter provides storage configuration, discovery, and additional management functionality for storage local replication and snapshots.

 

The Hitachi Adapter for SAP HANA Cockpit will support the following features:

  • Storage Snapshot (ShadowImage and HTI)
  • SAP HANA supports the creation of storage snapshot, which can later be used for SAP HANA recovery.
  • Cloning: Using Hitachi SAP HANA Cockpit adapter, user can clone SAP HANA Database using Shadow Image replication.
  • Reports: Hitachi HANA Cockpit adapter will show the mapping between HANA database, Hitachi Server and Hitachi Storage.
  • Performance: Hitachi HANA Cockpit adapter will show historical storage and server performance metrics.


This screenshot shows the UI to create the storage snapshots using the Hitachi SAP HANA Cockpit Storage Adapter

BD_3.png

 

The Hitachi Adapter will also show the mapping between HANA database, Hitachi Server and Hitachi Storage and the Hitachi HANA Cockpit adapter will show historical storage and server performance metrics as follows:


The Hitachi Adapter for SAP HANA Cockpit is designed for reports about different storage system components, mapping, configurations, usage, and performance summaries.


The adapter will generate a comprehensive number of reports allowing a deeper understanding of your data and storage:

  • Adapter will show Storage Statistics Report
  • Storage Device to OS Device Mapping Report
  • Storage to HANA Database Mapping Report
  • Replication Information Report
  • LUN Performance Statistics Report
  • Port Performance Statistics Report
  • HANA DB snapshot support using HTI
  • HANA DB cloning support using ShadowImage
  • Support HANA Scale-up configurations

 

The following screen shot shows the SAP HANA Cockpit Server Adapter with storage device mapping to the host:

BD_4.png

 

The Hitachi Adapter supports two Operating Systems: SuSE Linux and RHEL. It also supports the Windows server and Hitachi local replication software including HTI and Shadow Image. The adapter will support all the Hitachi RAID family series including the new series which includes VSP Fx00 and Unified.

 

The following table summarizes the support matrix for the Hitachi Adapters for SAP HANA Cockpit:

 

Management Server OS


OS VersionSupported
Windows 2012 R2X

 

 

HANA Database OS


OS VersionSupported
RHEL 6.6-HANA SPS10 Scale Up Single ContainerX
SuSE Linux 11.3-HANA SPS10 Scale Up Single ContainerX
SuSE Linux 11.3-HANA SPS 11 Scales Up Single ContainerX
SuSE Linux 12.0 HANA SPS 11 Scale Up Single ContainerX

 

 

Storage Models


ModelSupported
HUS-VMX
VSP G1000X
VSP Gx00 (G200, G400, G600, G800)X
VSP Gx00 UnifiedX
VSP Fx00

 

 

Replication Software


SoftwareSupported
Hitachi Shadow ImageX
Hitachi Thin ImageX


 

Host Interface


InterfaceSupported
FCX


 

Volume Type


InterfaceSupported
HDP/HDT/HRTX
Parity GroupX


HANA Multitenant Database Containers, or HANA MDC, is something fairly new in the SAP world. It first became supported in SPS 09 (Revision 90), less than two years ago, in late 2014. Since it’s a new technology, there are relatively few customers using it. At oXya, we do have customers to which we helped implement MDC. In this blog I will describe the technology, what challenges it solves, what issues it actually creates, and which type of organizations can benefit from it.

 

 

Background: HANA before MDC

sap-hana.png

 

SAP HANA is an innovative in-memory database system. We’re taking large database systems, and we’re putting them all in-memory, which is pretty expensive from the hardware perspective – they need expensive hardware, with strong compute power and lots of memory.

 

Before HANA MDC, you had to have a separate SAP HANA instance – possibly on the same hardware, but still a separate SAP HANA instance – for each different database (meaning for each landscape). The meaning was that every time you wanted to install a new HANA system, you either had to buy a new physical appliance; or you had to install a new HANA instance for each different database, on the existing hardware.

 

The challenge is that HANA appliances are installed by the vendor, and delivered to the customer as an already-configured system. The vendor also certifies that the appliance was correctly configured. Now, if you want to install another HANA instance on that appliance, you either have to engage the appliance vendor again, for them to install another HANA instance in a certified manner; or the customer has to go through the painstaking steps of making sure that the new HANA instance is installed correctly.

 

In order to perform the installation, you needed a HANA expert to install the new instance, and that’s often done by the vendor that sells you the appliance. In other words, each new installation of HANA was complex, took a lot of time, and often may have also resulted in the need to purchase a new appliance.

 

All of the above is a rather inefficient way to install new HANA instances, and it obviously generated a lot of extra work.

 

Another challenge, as you probably guessed, was that the above method was very wasteful, with regards to hardware usage. Not only did SAP face the challenge of making the HANA install process quicker and easier, but also the challenge of reducing hardware costs, that was slowing down HANA sales. The hardware needed for this in-memory computing system is very expensive; SAP’s goal was to reduce hardware costs and footprint of the HANA landscape.

 

Let’s use an example, to explain all of the above. Imagine a customer (and we have an actual customer like that), who has SAP ERP and SAP BW (Business Suite applications), and they’re both running on HANA. Each of these applications has Sandbox, Development, Quality Assurance, and Production systems, all running on HANA. Before MDC, if the customer wanted to run their ERP on HANA, they needed to buy multiple appliances, one for each system:

  1. An appliance for Sandbox
  2. Separate appliance for Development
  3. Third appliance for Quality Assurance
  4. Fourth and separate appliance for Production.

 

So far we’re talking about four HANA appliances, and that’s only for their ERP application. If the customer wanted to duplicate their data and also run their BW on HANA, then they would need to buy additional appliances for the BW systems (Sandbox, Development, Quality Assurance, Production).

 

And of course, it’s not just about the hardware costs, but also a matter of license costs. Do additional instances also mean you needed additional licenses, therefore additional license costs?

 

Well, the answer in general is “Yes”, or sort of. As a general rule, HANA is licensed by the amount of memory that the application needs. There is a difference between using separate appliances, and using one larger appliance with MDC; that can affect not only hardware costs, but also (to a lesser degree) the licensing costs. I’ll explain that later on, when referring to MDC sizing.

 

 

So what is SAP HANA MDC?

container-489933 (Custom).jpg

 

SAP released a newer feature, Multitenant Database Containers (MDC), which is supported as of HANA SP9 revision 95 and higher. In a nutshell, MDC allows us to take multiple SAP systems, say 2 sandboxes, 1 ERP, 1 BW, 2 development systems and 2 quality assurance systems, and put them all on the same HANA appliance.

 

The beauty of it: once the hardware provider had provided the appliance and did the initial set-up for the HANA system, we can very quickly and easily create the new database containers for each of our different systems, and allows these different products to cohabitate in the same appliance.

 

The MDC feature provides huge economy savings in terms of hardware, because instead of buying a separate appliance for each system (or perhaps not an appliance for each system, but an appliance for each landscape – possibly have your ERP’s Dev and QA on one appliance, and the same for BW), you can now take all of these, put them all on a single appliance, and better utilize that hardware.

 

Of course, as a general rule, we're not going to mix production and non-production systems. So, we still need to separate the Production system. However, for all of our non-production systems, MDC introduced significant flexibility.

 

 

MDC Challenges

 

MDC does come with some challenges, and we hope that SAP will eliminate these challenges in the future. These are current challenges, so you are aware:

 

First, when you perform replication at present, you take your HANA system and you replicate the databases to another site. There is no ability to replicate just a single database tenant – you have to replicate everything. The replication treats all database tenants as a single database system, as opposed to completely independent database systems. Hence, in the case of a failover to a secondary site, you'd have to perform the failover for all HANA database tenants on that appliance, and not for just one database.

 

Second, there’s a challenge in terms of version maintenance. In a traditional SAP landscape, we apply patches gradually:

  • We apply the patches to our Sandbox, and test
  • Then, we apply the patches to the Development, and we test
  • Then, we apply the patches to the QA system, and test again
  • And only then, after multiple patching is done on non-production systems, plus testing, we patch the Production system.

 

The benefit of the above method is we can test patching in many different systems, before going to Production. The challenge with MDC is that when you apply patches to this multitenant environment – you’re applying patches to all the systems simultaneously, because it’s impossible to perform individual patching for each database tenant. Essentially, once you patch your HANA appliance through the MDC, you have patched all the environments that are on the appliance – all at the same time!

 

“But wait”, you may say, “is this really a challenge? Is patching everything a challenge? Don't you want to patch everything? Doesn’t it save you work and time?”

 

The answer is – take another look at the patching process I outlined above. Our goal is to prevent impact to the Production system. In an SAP environment, we perform multiple tests on patches in non-production systems, before implementing in Production. The way to ensure that patching is successful, and doesn't cause any negative impact, is by performing multiple iterations: first Sandbox, then Development, then QA. By the time you get to Production, you've already performed patching 3 times.

 

However, in the case of MDC, once you performed patching on your non-production MDC system, you’ve done that simultaneously to all the systems within the same appliance. You’re not getting those multiple iterations, which is a huge disadvantage.

 

cargo-449784 (Custom).jpgAlso, there’s another caveat to patching. Let’s say you have ERP and BW on the same appliance, and patching is only required for one product, but not for the other. In the case of MDC, we don’t have a choice – we have to patch them both, at the same time.

 

This patching challenge is not an insurmountable issue, but it is something to get used to. This is also another reason why the Production system must be separate from non-production – you certainly don’t want to do patching on Production without testing it first!

 

But all in all, and despite of the above challenges – MDC is a great technology. We're able to spin up new containers in minutes, with a simple command on the HANA system. This, as opposed to having to engage a HANA expert to install the new instance, or perhaps even purchase new hardware every time you need a new a system. MDC adds significant flexibility, and I believe SAP is working to enable the replication of individual containers, and it will be available in the near future.

 

 

Difference between HANA system and the Containers

 

One important thing to understand is the difference between the HANA system and the containers, as each container has its own SID (system ID), in addition to the SID for the HANA appliance itself. For a customer that is going to use MDC, it’s important to realize that they have to name their HANA appliance uniquely for the entire appliance, and then name each container based on its purpose. In other words, you have an SID for the HANA instance on the appliance, and then you have a separate SID for each container.

 

Let’s explain that using an example. Let’s say that the SID of the HANA appliance would be HA1. Then, we’ll give various names to the containers, usually according to some kind of a key. For example, we will use "Q" for quality assurance, “D” for Development, “E” or “B” for ERP and BW, and an "H" to indicate that it's a HANA system.

 

With the above method, your development ERP container could be “DEH”, and your development BW container could be “DBH”. The QA containers will be “QEH” and “QBH”.

 

 

MDC Sizing

tape-measure-1186496 (Custom).jpg

 

Earlier, I mentioned sizing and said that customers may also save some money on license purchases. In order to explain that, let’s start with the traditional sizing for HANA, meaning separate appliances for each system.

 

HANA is a database, and each database system (Development, QA, Production, etc.) needs its own memory to contain its database. There are no savings in terms of reducing the volume of each database, because they stay the same, whether in separate HANA appliances or when using MDC, on one larger appliance.

 

However, when performing sizing, one doesn’t size just perfectly – you always leave room for growth, meaning a buffer. When you size for separate HANA systems (say one Dev and one QA), you will oversize for both systems, to make sure that you have sufficient space. However, when you do that, you often significantly oversize, and you actually “waste” hardware. In fact, I Can guarantee that if you look around the world, at various HANA systems, there's lots of memory and CPU that are not being used. Customers are paying for this over capacity, not only in hardware costs, but also in HANA licensing costs.

 

Consolidating systems omits the above, and provides great savings. When consolidating HANA databases, we don’t need to oversize for each database separately. We can better utilize the resources on the server, and oversize to a smaller extent, for all databases combined.

 

Basically, what you're saying is that if before we needed 2 appliances, let's say each 1 with half a terabyte of memory, then when we combine them all on the same appliance, we need actually 1 appliance with 1 terabyte, that's 2 halves and you may be able to save a little out of the 1 terabyte, put a little less because you don’t buffer twice or you don't oversize twice.

 

Take one of oXya’s customers, for example. This customer has 5 different HANA systems, with each database in need of 200GB (already includes space for future growth), meaning we need a total of 1TB. If you went ahead and bought separate appliances for each database, as was the case before MDC, then you would buy five appliances with 256GB each (5 x 256GB). This means you’re wasting more than 250GB, above and beyond your needs. These systems will be gravely underutilized.

 

However, when you consolidate those systems, then you only need to buy a 1TB appliance (which again, already includes space for future growth). Then, as some databases grow, those databases that need the additional resources are able to utilize them. Furthermore, not only do you better utilize the hardware and licenses, but you may even be able to add additional systems onto the same hardware, once it's running.

 

Having said all of the above, it’s important to understand that Sizing is a bit of an art (and not really a Science, as some people claim). When you perform sizing, you make assumptions regarding what is going to be once it’s running, and it doesn’t always happen this way. That’s one reason why there’s a tendency to oversize. When we're sharing several databases onto a single system using MDC, we're able to better utilize resources.

 

Come see us at SAP SAPPHIRE this week – stop by the Hitachi booth, look for the oXya team, and discuss your SAP challenges with us.

 

----------------------------------------------------------------------

 

oXya_HGC_logo (Custom 300).jpgSevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Group company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a team of ten SAP professionals, at oXya’s service center in New Jersey.

 

oXya, a Hitachi Group company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs more than 650 SAP experts, who service more than 330 enterprise customers with more than 300,000 SAP users around the world.

Two interesting things happened in the last couple of weeks, that led to writing this blog:

  1. We received a new white paper from research firm ESG, analyzing the impact of SAP S/4HANA on the SAP market and on our own business – Technical SAP Consulting & Managed Cloud Services.
  2. I attended an interesting meeting with individuals from several other Hitachi Group companies, to discuss various things regarding the SAP market and our activities in the coming year.

 

One of the things I realized in that meeting, and this sometimes also happens in conversations with various people working in the SAP ecosystem, is that there’s a lack in understanding some of SAP’s newest technologies in the market. Specifically, I’m referring to the difference between HANA and S/4HANA; what each of these does; and what is the revolution taking place these days in the SAP market, due to these technologies.

 

By “lack of understanding” I don’t refer to fellow technical SAP experts, they certainly understand the above, and possibly also know the “behind the scenes” of the war that is taking place in the last few years. But do your business people, marketing experts, sales folks – all those non-technical experts in the SAP ecosystem – do they know what the difference is, and what’s going on? Or do they think, as I sometimes hear, that S/4HANA is in fact “HANA version 2.0”, or some other variant ?

 

So, today’s blog is dedicated mostly for the non-techi folks in the SAP ecosystem, but all you techi friends are also welcome to read. This will be a story full of emotion about the longtime rivalry between two of the world’s leading tech giants, and a real battle that’s taking place today around SAP customers.

 

For those who want the short version, here it is – SAP HANA is a database. SAP S/4HANA is the new business suite of SAP applications, that runs on the HANA database. That’s it, but there’s so much beyond that. So go ahead and read the full story.

 

And a word of caution – to best serve the non-technical audience for which this blog is written, it is going to be simplistic and high-level, with as little technology deep-dive as possible.

 

 

What is SAP – in 2 minutes

SAP-logo-2011.png

When an organization has a mission-critical SAP system, it actually means they have a system that consists of various layers of software and hardware. Let’s leave the hardware aside for the moment, since it’s less relevant at this point. On the software side, an SAP system has three main layers:

  1. Operating System (OS)
  2. Database (DBMS)
  3. Applications

 

Traditionally, SAP was an applications vendor. Everyone in the industry knows these applications very well – ERP, Supply-Chain Management, Finance, HR, Logistics, Manufacturing, Retail, and many other applications that SAP has been producing over the years, for running an enterprise at all levels.

 

Also traditionally, SAP applications ran on top of third party databases (this is where the actual data is stored), as SAP did not have a database of its own. The main databases on which SAP applications run are Oracle, MS-SQL and IBM DB2, though there are additional databases that SAP runs on, such as Sybase (which SAP acquired back in 2010, for $5.8 billion; here’s an interesting article from that year, on why SAP acquired Sybase).

 

Oracle Corp plays an interesting role here. On the one hand, Oracle is a bitter competitor of SAP, because it’s application suite – Oracle Applications – is a direct competitor of the SAP application suite. On the other hand, Oracle is one of the leading databases in the world, with many SAP customers running their SAP applications on the Oracle database. In other words, the SAP market is a major revenue generator for Oracle Corp on the database side; Oracle database license revenues from SAP customers make a major percentage of Oracle Corp’s total revenues.

 

All of that synergy lived relatively well until 2012 – SAP focused mostly on the applications side and led the market in that category, with Oracle being a distant #2 (here are two Forbes’ articles covering Gartner’s analysis of the ERP market and the Supply-Chain Management market). On the database side, Oracle has been the market leader as far as license revenues; Oracle generated (and still generates) a significant portion of its revenues from SAP customers running on Oracle.

 

And then came SAP HANA.

 

 

SAP Introduces HANA – The In-Memory Database

 

6224518717_976c2ba19a_z (Custom).jpg

SAP officially launched SAP HANA in November 2010. HANA is an in-memory database, which is a revolutionary technology, compared to “standard” databases. In regular databases, all the information is stored on disks that “live” in enterprise storage systems. When a database gets an inquiry, it goes to the disks, searches for the information, retrieves it to the system’s memory, and then performs various operations on (or using) this data. Once it has finished with the specific piece of data, it stores it back onto the disk, until the next time it needs this data.

 

An in-memory database operates differently. The infrastructure for this database consists of an enormous amount of memory and compute power (compared to “standard” storage), the data resides at the memory level at all time, and all actions are performed within the memory itself. Since memory is significantly faster than disk (memory access time is measured in nanoseconds, while disk access time is measured in milliseconds), HANA performance is also significantly faster when compared to that of standard databases. In addition, HANA brings other meaningful advantages – I covered HANA benefits in a blog that focused on Considerations Before Migrating to SAP HANA.

 

The launch of the SAP HANA database was like waving a red flag at a bull; the bull’s name was Oracle. Here, SAP no longer competed only on the application layer of the business; Oracle suddenly saw a direct, potential threat at its bread-and-butter – the database business and the revenues it generates. And it reacted (photo credit: Naoki Nakashima, Flickr).

 

Larry Ellison, Oracle’s Founder, Chairman and CTO (and one of the 10 richest people in the world), launched a series of fierce attacks on SAP and HANA. In a series of keynote speeches and interviews, that started almost immediately after the HANA launch in 2010 and is still ongoing, Ellison has been doing his best to bash HANA and install doubt and fear in the minds of SAP customers. Some of his speeches and recordings have become iconic in the industry, such as this 2-minute video from 2012, or his keynote speech at the 2014 Oracle OpenWorld, to name just two cases.

Larry (Custom).png

Bill_McDermott (Custom).png

 

The bottom line of Larry’s comments – HANA is a brand new system, not yet tested, and not proven for mission-critical workloads. SAP will never substitute their long-time, proven Oracle database, for the HANA database.

 

SAP’s reaction to these attacks was polite and respectful. Here’s an example from a Yahoo Finance 2-minute video interview with Bill McDermott, SAP’s CEO, following one of Larry’s bash attacks.

 

What actually happened in the field? Like with any new and innovative technology – not to mention mission-critical in its influence – adoption has been slow. It takes an Innovator, visionary CIO to be one of the first in the market to adopt a brand new technology for one of the organizations’ most mission-critical systems (SAP). (graphics credit: The University of Arizona).

 

orr7.gif

Overall, HANA adoption lagged behind SAP’s own estimates. Customers did take their time to migrate to HANA. In its FY2015 reports, SAP wrote (page 7 of the PDF) that “In just a few short years, nearly 10,000 customers and startup companies chose to innovate on SAP HANA…”, which means an adoption rate of less than 5% from SAP’s customer base. However, the quarterly reports that SAP publishes also show an acceleration in adoption, as was expected.

 

At oXya, we had the privilege to work with a few such innovative customers, and support them in their migration to SAP HANA. As of May 2016, more than 50 out of our 335 enterprise managed services customers (roughly 15% of oXya customers) are already running on SAP HANA or are in the process of migrating to HANA. We are very proud of this significantly-above-industry-average percentage, and that we are an industry leader in migrating SAP customers to SAP HANA and S/4HANA (and I’ll write on S/4HANA in the following section).

 

Since SAP saw that adoption of the HANA database has been slow, what did it do to accelerate this adoption, and to further innovate in the market? It introduced SAP S/4HANA.

 

 

SAP Introduces S/4HANA – The New Suite of Business Applications

 

In February 2015 SAP introduced SAP S/4HANA, which is “a next-generation business suite designed to provide the digital core SAP customers need to run their entire business in a digitized world.” (quote from SAP’s FY2015 annual report).

 

SAP S/4HANA is not a database. Rather, it is a new and revolutionary application suite from SAP. Research firm ESG writes that “This (SAP S/4HANA) is perhaps the single biggest shift in SAP technology for the last 25 years, since SAP R/3 was introduced in 1992”. Many SAP experts agree with this statement. SAP S/4HANA includes many innovative technologies and features, that all have one common goal – to enable organizations to run their SAP in a simpler, faster, and far more efficient way, while supporting new work processes (such as mobile). With all that, SAP S/4HANA helps customers to be more competitive in the market place, and better align with modern challenges of the digital world. We wrote in the past about some of the new features in S/4HANA, such as Fiori, the new SAP GUI (see the table and video in this blog post, for a comparison of time and efficiency between the old SAP system and the new one).

 

And the kicker about S/4HANA – as its name implies, this new suite of applications only runs on the HANA database!

 

In other words, customers who will want to upgrade to the newest and best SAP suite of applications, will have to also adopt the HANA database and run on it. They will not be able to choose any other database – it only runs on HANA.

 

 

So what does it all mean?

 

There are a few interesting questions to ask, in the aspect of S/4HANA:

  1. What will the adoption of S/4HANA look like?
  2. Which SAP customers will migrate to S/4HANA?
  3. How will this migration cycle affect the IT industry?

 

Let’s answer these, one by one.

 

How will the adoption of S/4HANA look?

Like with any new technology, it will be in stages, exactly like in the adoption cycle graph shown earlier. First come the Innovators, and we already see enterprises who have migrated to S/4HANA, or new SAP customers who performed greenfield installations of SAP S/4HANA. oXya has a few such customers, including in North America – we hope to share their stories in the future. After the Innovators will come the Early Adopters, and then the Majority – Early and Late.

 

ESG estimates, in its paper, that “This (SAP S/4HANA) will become the mandatory standard for SAP customers in the near future, assuming they wish to stay current on SAP product enhancements. At some point, support of older versions will start to become increasingly difficult.”

 

My own estimate is that the “near future” that ESG is referring to will take some time. We are still at the Innovators stage. It will probably take a few good years to cover the percentages “needed” until the market reaches the stage of Majority adoption, but it will come. The reason for that is explained in the next paragraph.

 

Which SAP customers will migrate to S/4HANA?

In my estimate – everyone, eventually, or at least the majority of customers. After all, it is exactly like ESG says – any customer that wishes to stay current with SAP technology, and maintain a competitive place in the market. SAP customers cannot afford to stay behind with old, dated systems, that are less efficient.

 

Customers will want to keep current with their competition, and will eventually be “forced” to move to S/4HANA (which, of course, will continue to evolve and improve). I suspect it’s still 4-5 years away (and possibly a bit more) before we see the large mass of SAP customers migrating to S/4HANA (and to HANA, as a result), but I have no doubt that it’s coming.

 

How will this migration cycle affect the IT industry?

In a huge way. The move from “regular/current” SAP systems to HANA and to S/4HANA affects many facets of the IT industry:

  • Infrastructure for SAP: First, HANA requires different infrastructure than current SAP systems. There are already various infrastructure vendors who are playing in this field, with more who will probably enter the market. Hitachi Data Systems, with which we closely cooperate, is a leading player in the SAP HANA market, with its Hitachi Unified Compute Platform (UCP). And second, as customers choose new infrastructure, they will often want to avoid the high Capex costs that are associated with the HANA hardware; instead, many customers will prefer to move to a cloud system with an opex-based consumption of hardware, such as the one oXya offers.
  • Functional/Design for SAP: The system integrators’ (SI) community will also have its hand full with the transition to S/4HANA; while SAP recommends using the standard applications and creating minimal adjustments, many organizations will probably want to adjust the new applications to their specific needs. Hitachi Consulting (HCC), our sister company, is a leader in this area, and we’re closely cooperating with them.
  • Technical Services for SAP: Companies such as oXya will certainly have their hands full. Most SAP customers do not have the necessary in-house knowledge and expertise in order to migrate to HANA and S/4HANA; They will require external help, from the likes of oXya, who have already done that numerous times, and can help assure a fast and painless transition.
  • Managed Services for SAP: This is another market in which oXya is a major player. As SAP customers adopt these new technologies, they will require skilled personnel to run the new SAP systems around the clock, to make sure the new SAP provides peak performance and generates a great ROI for the organization. This may mean choosing an SAP partner that you can count on, a partner that provides you with a dedicated team that is an extension of your own IT organization, and various other unique features. As you can read in the new white paper from ESG, there is a shortage of skilled technical IT people in the market, across multiple areas. Many of these areas are covered by oXya’s dedicated support teams, once a customer chooses our services for running their SAP – so working with oXya as a partner can immediately solve multiple recruiting challenges, of the following expertise areas:
    • SAP Basis (not in the ESG table, but huge shortage in the market)
    • Server virtualization/private cloud infrastructure
    • Compliance management, monitoring and reporting
    • IT architecture/planning
    • Data protection
    • Database administration
    • Storage administration
    • Server administration
    • Network administration

 

Of course, there’s another potential effect on specific industry players – the database vendors. The main one to get hurt is probably Oracle, which presumably has the largest share of database revenues from current SAP customers. I wouldn’t go out on a limb in estimating that we can expect the level of bashing and attacks from Oracle to increase in the coming years, or at least stay at current (pretty high) level. Oracle Corp have very smart people, and no doubt they analyze the marketplace in a similar way to what I did above – some of Oracle’s core customer base is about to disappear, and migrate off Oracle in the coming years.

 

I hope to see many of you at SAP SAPPHIRE – stop by the Hitachi booth, look for me and the rest of the oXya team, and feel free to discuss your SAP challenges with us. You can also email me at any time, to mduboullay@oxya.com.

 

oXya logo for LinkedIn 300x300.png

----------------------------------------------------------------------

Melchior du Boullay is Managing Director, Americas at oXya, responsible for all of oXya’s operations across North, Central and South America since 2007, when oXya started operating in the Americas. Melchior has nearly 15 years of experience as an SAP Basis admin and technical consultant, SAP project manager, SAP account management, and business development.

 

oXya, a Hitachi Group company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs more than 600 SAP experts, who service more than 330 enterprise customers with more than 300,000 SAP users around the world.