What is still missing on SAP's S/4 HANA Vision

As I'm flying to Amsterdam today, on the plane I saw myself thinking on all the meeting I had during SAPPHIRE a couple of weeks ago in Orlando. And one topic that came across in many of those meetings was: how to make HANA and S/4 become a reality in a cost effective way in my datacenter. So, let me take these two hours of flight to share a bit the raw thoughts that are coming to my mind on this topic.

There are no questions these days that the future of SAP is S/4 and that it runs on HANA.

In the words of a good friend that was already around when SAP migrated from R/2 to R/3, "it's a completely new application stack and solution set".

Also on his words, like it happened with the R/2 to R/3 migration which started in 1992, many working in the SAP world, will take some time to realize and accept that this is the way and there is no way back.

So, for all of those in the ecosystem, the word is: refresh your skills to the new era!

So, applauding the initiative from SAP in reinventing its core Business Software Stack, I still see some aspects missing from the architecture vision, that if not considered will make this transformation fall short on expectations and market potential.

Through this blog post I'll share some of the desires large organizations around the world shared with me, associated with my own interpretation of the situation, in regards to how the reengineering of the SAP Business Suite should look like, as we transition to the new S/4 HANA world.

Let me say upfront, that I agree that what I'll say is not simple to implement. Can say either whether there is someone within SAP thinking about this already as I have NO privileged information. What I can say, is that if SAP really wants to be up to the principle of "Run Simple" these aspects would be major in making it happen.

So, let first have a look at what we know at this date.

We know that SAP is redesigning its applications according the following principles:

   - simplify the data model and reduce the data footprint by eliminating data duplication within the SAP Aplications Landscape.

   - rebuild those applications for Fiori and UI5 for better user experience and productivity;

   - enable guided configuration for simpler startup through configuration wizards and "rapid deployment" easy to consume business scenarios.

All of these will make SAP Applications definitely easier to consume.

To these aspects that SAP announced we can also add other aspect we already know that come from the fact that S/4 is running on top of HANA:

   - pushing calculations down to the database layer, leveraging SAP HANA realtime capabilities to speed up processing;

   - merge OLAP and OLTP on the same platform, enabling real time operational reporting, elimination of data availability lead times and data duplication;

   - enable the processing of structured and unstructured data on the same platform, making it possible to get business insights in real time out of machine, social and other types of unstructured data.

Again, all great here!

So, what am I missing? What are some customers asking about?

I've written a lot about TCO. This is engraved in my reasoning from the days I worked on IT operations and on Management Roles, where I realized in the flesh the weight of OPEX in the agility of organizations, and their resilience to unforeseen events.

And let me reinforce the business agility and ability to react to unforeseen events, as over the last 15 years, with the increased globalization driven by global communications, not only of data, but of people and money as well, we have been going through a series of events, that the majority of the economic players were unable to predict.

Things like the burst of the .com bubble in 2000, the terrorist attacks in the U.S. on 9/11, the SubPrime crisis in 2008 due to real-estate speculation, the European Debt Crisis that we are still struggling to come out of, and that has been having a significant impact on the global economy affecting companies all over the world, and making us see banks considered references for decayed break in the U.S. and Europe.

All of this makes it that - like I read in a McKinsey Quarterly article in 2003 - the only way for companies to survive is either to shape markets or to be very agile in adapting to changing market conditions. Would even say, that in today's economic environment, being able to do both, and reinventing business models is a must to be a player in the future.

As a side note, this is definitely what companies like SAP and EMC are doing by disrupting themselves at their core to get ready for tomorrow.

Not all companies in the world are as prepared for this, and the fact that information technologies, that provide faster and better business visualization to management boards are today slow to react and adapt is a key contributor to that lack of business agility by many organizations.

It is today an absurd that having Information Technologies came to "automate the business processes of organizations", their management and change is still so manual. There is a dramatic need to change in paradigm.

So, one thing that should be included on the reinvention of hardware and software stacks for this new world of uncertainty and rapid change, should be the premise that the systems and architectures should be designed from the start to enable simple and fast change from top to bottom.

This may seem an obvious aspect, and some would argue that this is a lady being done now.

My point of view, and the one of some customers and partners I've had the privilege to discuss this with, is that SAP is still missing some important points.

Why?

One thing we will never be able to fully eliminate will be the human intervention in IT. it can definitely be reduced by increased automation, but at least for the next 10 to 15 years, there will still be a significant human intervention - at least - in two critical phases of the IT lifecycle: when you set it up, and when you need to change it and evolve it either due to obsolescence of the underlying components, or due to dramatic shifts on companies business requirements (maybe driven from change forces in the market.

And this leads to a series of principles that should be though, as a consequence of understanding the human mind.

I believe it was Jack Welch that said that a company who needs super mans to be managed is condemned to failure (forgive me if I quote the wrong author... hope not).

I would say, that an IT Landscape or architecture that need brilliant brains to design it, implement it, manage it and change/evolve it, is condemned to drag down its company's business agility.

So, how do we solve this equation?

I would add two variables: use standard and modular building blocks accross the board as much as possible.

And this goes down to the infrastructure! Some by reading this will think on what is today called the 3rd platform applications as described by IDC. No, I'm not talking about that implicitly.

What I'm thinking about is: look at what infrastructure components are today the most standard, more broadly used components in the market, and design your applications to leverage those!

This is what I though SAP had in mind when they came up with SAP HANA Scale-out architecture, now enhanced with Multi-tenant database containers and Dynamic Tiering, these last two features announced with SAP HANA SPS09.

Let me start to tie in all of these together.

When I asked to some SAP employees involved in the HANA and S/4 roadmap discussions internally at SAP how were they planning to manage the ERP redesign to HANA, the answers I got disappointed me.

Maybe... And I have to repeat... Maybe, they could not disclose anything more than that at this stage. Don't know. I might even speculated that this isn't even yet in the table of discussion today.

Well, I developed my question as what I was looking for would be any hint that SAP would take this opportunity to go deeper into the data model and application architecture redesign.

Talking about the existing SAP Applications (ERP, CRM, SRM, etc), each of these applications is composed by a number of components. SAP started splitting the development cycle of these components still in the R/3 era when they started to provide support packages in separate for HR and the rest of the R/3, back then integrated in the "APPL" component. Today we have even more: these is the Basis, ABA, BW, etc, etc, etc.

Back then the logic SAP communicated for that change would be to simplify the application evolution, since HR had a lot more fluent updates due to legal requirements than the FI/CO/MM/PP/SD/etc modules. And it evolved to keep breaking each application stack in multiple components that led later to the Business Suite running on top of the WebAS. 

Small curiosity: I was teaching SAP Basis academies for SAP when this happened, observing closely the evolution from R/3 3.1i to 4.6d where JAVA was first introduced.

Maybe I'm asking too much, but my expectation now would be for SAP ago further reduce the size of the monster (ERP is still one of the largest and most critical databases in many customer environments, the larger it is, being more expensive and difficult to manage/evolve).

So, I was "dreaming" of a split of the ERP in its fundamental components, being each component installable as a separate entity, and within a separate database.

For example: if SAP delivers as they are saying, that communication between Database Containers within the same SAP HANA Database Cluster, will be almost as fast as if they were in the same database, then it would make all the sense to split logistics, finance, HR, etc... down to all the industry verticals into a separate database container.

This would make each of this pieces "so small" according to today's standards, that it would then make it very simple for customers to install scale-out clusters, with all these applications split accross the multiple scale-out nodes. Here I'm imagining that one application would be able to call data accross containers, leveraging the massive paralel processing of the scale-out, shared nothing cluster architecture.

But, what I've been told so far is that each of the existing SAP application components will keep existing together as a single database.

And this is not good, because even with the data model simplification, and increasing number of customers will see their database sizes such, that they won't be able to use today's most commonly used infrastructure components. For example: in terms of servers, a 4 socket server that with Intel x86 Ivy-Bridge CPU can host up to 3 TB of RAM.

Do, coming from the infrastructure upwards.

The idea would be to take the assumption that whatever SAP redesigns today must aim to fit in a 4 sockets Intel server. So, for example, the ERP would be split into a number of independent modules (the smallest installable modular unit), that could then be distributed in a Multi-tenant, scale-out SAP HANA Cluster.

This would enable simpler and faste backup times for each of the components in paralel, faster restart times enabling bette Recovery Time Objectives (RTO) t a cheaper price, would enable simpler evolution, for example through the usage of the capabilities of VMware...

And by using the most commonly known infrastructure components in the market, the probability for organizations to have a ton of people inside with that skill set would be higher, making it simple to do a risk assessment when change needs to happen, and evolve faster and cheaper.

Again, thine se are the principles of what is called 3rd platform applications, where you design your application through "micro-services" each of them existing in a container, all loosely coupled and hosted on a cheap, standard, massive paralel scale-out cluster.

SAP, where are you on this journey? If you are working in this direction, I'll bet you would win more in sharing this with the community sooner, as it would build more confidence and gain further support to help you through this transition.

So, I hope that something is already happening, and I'm just not aware yet. As otherwise, SAP is missing here a massive opportunity to lay take its application stack to the next level in terms of future proof architecture.

Tying in the Data Temperature concepts, would then make sense for me as well, while we move to a world of OLAP, OLTP, structured and unstructured all in the same platform (SAP HANA), that all this application modules could be able to also consume and push data to a series of "different storage containers" based on the business value of the information.

So, it would make sense for SAP HANA to be able to access and manipulate unstructured data directly from HDFS storage, which would provide "infinite storage for lower value, higher volume" unstructured data.

Then for those slices to be able to use as well a "warm store" ( here relating to the extended store announced with Dynamic Tiering on SAP HANA SPS09), to park structured data that being important, doesn't need to be accessed by the business so often and so fast.

Would also make sense to have a 3rd store that I would call "frozen" archive, that would be read-only in nature for compliance reasons. And this could just be an export to a file in a file system, as there is a ton of technologies today in the market to take care of this.

Leaving to be stored in memory, realy the most critical data which is needed more and faster by the business.

Then coupling flexible storage, with modular application components, distributed in a cheap server farm (Intel E5 - 4 socket severs today), would realy make the core SAP Business Software be set for the future (beyond the next 15 years), while enabling organizations to have it in cheaper, simpler and faster do change infrastructure architectures.

As a conclusion:

I know that what I'm saying here is not easy, and may take SAP quite some effort to realize.

I also understand that they need to show something valuable fast, to be able to monetize the development investments and reduce the profitability impact of reinventing themselves.

So, I would accept that migrating the ERP to HANA as is might be a good first step.

What I did not like was listening from the people I talked with, that just redesigning the ERP for Fiori and HANA, while keeping the monster ( and maybe even adding some other monsters like BW, CRM, ETC) was the end arrival vision.

If this happens, if we make a paralel to More's law to the volume of data an organization will generate with HANA speed, the problems customers came to feel today due to the gigantic databases they come to build, just give it 5 to 10 years for those problems to be back again.

One final comment to cloud: public cloud will still take some years to be an option in certain parts of the world. Either due to technical, legal, confidentiality, competitive or economic restrictions. Not all the world looks like the U.S., Northern Europe or Japan. There is a lot more world contributing to SAP's revenues. So private cloud environments will still be around for quite some years, and hope SAP remembers that as they design the medium term vision.