2015-06-13

SAP HANA, S/4 and IoT - why you should care

These are the most challenging times most SAP customers and service providers have lived in the last 20 years, since SAP transitioned from the mainframe world to the client-server world through the evolution from R/2 to the next generation of software announced in 1992 that was the R/3 system!

And the challenge comes associated with the fact that with the announcement from SAP that the future SAP ERP will be called S/4 and will only run on HANA, customers get faced with the fact that, wanting to keep using SAP Software for the long run, the adoption of SAP HANA is no longer a matter of “if” but rather a matter of how and when.



Also the emergence of Cloud and the multiple of options it entails, pushed by very different and sometimes conflicting messages from all the providers in the market, further adds to the challenge of making decisions on what is the best IT strategy and architecture to serve the business needs for the future.

Mix these with a very complex economic environment, with an increasingly de-regulated economy, where the easiness of movement of information, capital, people and goods across the globe is unprecedented, demanding for organizations to step up their business models to survive, in a way that they become prepared either to build and shape markets or to rapidly adapt to fast changing market conditions. In such an environment Information Technologies are more than ever a critical component of competitiveness.

No business organization can live today without information.


IT organizations need to make sense of all the “noise” happening in the market to find what is the most appropriate choice for their particular situation - today and for the future.

Through this post, I’ll share my understanding on a number of changes happening, in a way that IT leaders can leverage them for a pragmatic and business wise decision process.

This is the first part of a series, being this part focused on starting to reflect on SAP HANA, S/4 and IoT, why they matter and their architecture implications.
This blog aims to demystify these concepts to those readers not yet familiar with this topic.


          SAP HANA, S/4 and the Internet of Things


In fact, it’s this reality of increased competitiveness that is driving for the emergence of new paradigms like “real time” and “automated machine-managed” business decision making.

As information, and the knowledge derived from that information, become increasingly critical for organizations, the next frontier is to be able to set rules for a business that – based on real-time data – makes it possible to steer decisions towards what is happening now or even what are the most likely future business conditions, and not only based on the information of what happened in the past.

Multiple events over the last decades have demonstrated that in just a few days, the business environment may observe changes so dramatic, that what might be a good decision based on the information of just 1 week ago, may now lead you to the abyss.

Also, the evolution of technology that enables today most devices to have communication capabilities and to generate data on their status and activity, associated with the increased availability of “public relevant business information”, like online exchange rates and whether conditions, makes that the volumes of data available for the organizations to analyze and decide upon, are exploding. In this space the buzz words of the moment are:
  • Internet Of Things (IoT): referring to availability of “data generating devices” connected online and generating information to be processed by business systems;
  • Social: referring for example to data on users activity on the internet, that represent as well massive volumes and variety of data;
  • Big Data: that refers to the massive volumes of data, its massive variety and different value, which organizations need today to tackle with generated by all of the above.

All of this comes tied in to the massive growth of “mobile”, another buzz word that highlights the fact that today business users want – like private users – to have access in real time at their fingertips about what is happening with their businesses, where waiting hours or even minutes for the information to show up on the screen is not acceptable.

S/4 is SAP’s response to this need for organizations to operate in real time and to manage in an integrated way, not only the structured data that business systems have managed for the last two decades, but also the big data generated by Social and IoT. And S/4 is only powered by SAP HANA, as traditional databases are not able today to provide the capabilities to respond to this new reality.

It is no longer enough for business managers to know what happened in the past. Today is fundamental to know what is happening now – in real time – and based on trends and the inter-relation between multiple variables – internal and external – to forecast what the future may be, enabling a “what if & future looking” decision making.

It was because of this reality that SAP has come up with SAP HANA, a platform that merges transaction processing, operational reporting, and prospective analysis – all mobile enabled – on the same platform.

As you know, SAP HANA is way more than a database; it is indeed a data management platform architected for the current business environment of “uncertainty and fast pace of chance”.

To be able to tackle with this business reality, SAP broke with HANA a quite some long time computing paradigms:
  • In-memory computing: store large volumes of business data in-memory for faster processing and “second grade” response times for mobile apps;
  • Merge OLAP and OLTP: do transaction processing and analytics on the same platform enabling real-time prospective analysis upon current transactional data;
  • Social and IoT: Integrated processing of structured and unstructured data, merging information from machine, social and the existing business structured data, to drive new business models and faster “time to action”.

Not wanting to cover all these in detail, as they have been widely communicated by SAP and each of these three aspects bring new variables to the table that SAP Architects haven’t faced until now, let us just spend some paragraphs on it, to explain their implications.


          In-memory computing


In-memory computing has been the most communicated characteristic of SAP HANA, as the basis for “faster data processing”.

Why is that?

In the late 90’s, one of the key barriers to enable computer systems to analyze and process larger amounts of data faster, was the limited computing capacity of existing systems.

In the end this is all a matter of affordability, as the cost of IT cannot be higher than the benefit IT brings to the business.

So, if you want to process a certain volume of data, you might need to spend such amounts on computing capacity, that a certain scenario wouldn’t just be sustainable, as the market might not pay the cost of such a solution.

This has made that for many years, a significant level of innovation brought to computer systems was targeted at increasing the computing power (the ability to process larger amounts of data faster) reflected in aspects like the increase of CPU clock speeds, increased capacity of RAM chips, reduced latency and increased bandwidth on the communication between CPU and RAM, alongside with a significant increase size in the CPU internal cache (working memory inside the CPU itself).

As the volumes of data managed by organizations increase, alongside with this massive increase in computing capacity, the bottleneck in computing systems has moved to data movement and transmission.

So, this movement opened the space to change paradigms: instead of storing data further away from the CPU, why not starting to store it as closer as possible? Instead of using the RAM just as a temporary buffer to hold data being processed, why not use RAM as a permanent store for data?

SAP was visionary in seeing the opportunity for this paradigm change, by bringing to market SAP HANA.

For organizations using RAM as a permanent store of data, that is accessible by the CPU faster than ever, means that with SAP HANA, they’ll be able to analyze more data faster, and so it opens the possibility of streaming in real time information from what is happening in the business, and make “automated” machine managed / rules based business decisions in real time.

Being the bottleneck these days on data transmission, but considering that the ratio of analyzed data for a business decision may only imply that less than 10% of it is newly generated data, we are definitely up for some significant paradigm shifts.

Note as well, that this idea has a significant lateral implication: now it’s possible to make this data accessible on mobile devices with “second grade” response times.

In an economic environment where uncertainty is the only thing businesses have as certain; this is definitely an edge for many organizations. But it will have implications on IT infrastructure requirements, which will translate in impacts on other business variables like risk and cost for example. We’ll explore these impacts further ahead in the document.

As SAP HANA stores data in RAM, which is a type of non-persistent memory and is internal to a computer, questions come up like: how do I protect this system from disaster, or how to I recover from a failure, what volume is affordable to store in memory for my business scenario, how do I operate and evolve such an environment, what communications architecture will I need to put in place to tackle these new volumes of processed and transmitted data.


          Merge OLTP and OLAP


The other characteristic communicated in regards to SAP HANA innovation, is the merge of OLTP and OLAP on the same platform.

In the past, for the same reasons referred on the previous point of affordability, software vendors designed two different platforms to make different types of processing for the business.

OLTP stands for online transaction processing. This system processed the transactions of what is happening in the business.

OLAP stands for online analytical processing. These systems were meant for data analysis and decision support.

Why were these two separate? Because, considering the limitations of past computer system architectures, it happened that performing the processing needed for the business analysis consumed all the resources on the system, making it that being both on the same platform, your business operations (transaction processing) would be negatively impacted. So, I would say this is one of the big reasons SAP has come up with the BW system in the early 2000’s.

So, vendors came with 2 different platform designs each one optimized to a type of processing, and built processes both to keep them isolated and minimize impacts of one on the other, while keeping them as aligned in terms of information as possible.

Again, this was another situation of computer systems innovation driven by business needs, but at the same time business functionality limited by technology limitations.

The exploding volumes of information organizations are managing for decision making, and the need to have increasingly more up-to-date information, has taken this model of OLAP and OLTP on separate systems reach its limit. And is clear that the “OLAP and OLTP on separate systems model” has reached its limit by observing the number of organizations where the 24 hours of a day are no longer enough to extract data from transaction processing systems, load it into analytic systems, and report on that data.

Here, SAP, leveraging a number of technology innovations saw also an opportunity to innovate, and by leveraging the massive computing capabilities that today’s systems have which have evolved a lot faster than the improvements in data communications, and by realizing that what makes today the separation of OLAP and OLTP reach its limit is the limitation on data movement and transmission, SAP designed a system that would be able to perform both simultaneously.

You may argue that SAP is going back to the model that existed 20 years ago. And we would say you are right. But 20 years in terms of business, is a lot of time. And the fact is that today the limitation is on data transmission and not on data processing like it was 20 years ago. So, who knows how long it will take for this balance to chance again.

This will also bring some questions like: how do we scale these systems to ensure we don’t fall again on the problems that led to separate OLAP and OLTP in the first place? How do we avoid these systems to become so huge that become unmanageable or that making them resilient becomes simply unaffordable.


          Big Data generated by Social and IoT


The last topic we want to touch is the growth of importance of unstructured data.

There has been processing of unstructured data for many years. For example, in the manufacturing industries, machines brought automation systems that generated files with logs of their activity. And in the 90’s there were already organizations that integrated this data in to business systems, for example to have automatic information of the produced quantities of goods.

The challenge with this data, generated by machines or by social media, is that it usually is not structured, unlike the business data we are used to process in the SAP world through tables and field definitions.

In this new world of Social and IoT we may be talking about images, audio files, videos and log files.
Being able to act upon these types of data, and integrating the knowledge extracted from them with the structured business knowledge we have on our transaction processing systems, may enable organizations in many industries to achieve cost savings and develop business innovations that set them apart from their competition.

The challenge for SAP architects is that the volumes and variety of data involved here are massive compared with what we were used to deal on the SAP Netweaver ABAP type of reality.

Just as an example, in the Netweaver world, to ensure performance, availability and resiliency on a database of 50 to 100 TB was a nightmare, noteworthy as most organizations work hard to contain growth and only very few in the world reach such volumes. In the non-structured data world, we may easily reach volumes in the “Petabyte scale”.

So this brings questions like: if it was challenging to ensure performance, availability and resiliency to SAP Application Landscapes in the Netweaver world, how to we respond to these needs when dealing with petabytes of unstructured data? And what is the most affordable way to store and process this type of data? Can it be in-memory? Will its volume overwhelm the transaction processing so impacting business operations?


          The challenge for SAP Architects from S/4, HANA and IoT


It is clear that there will be new challenges coming up to the hands of SAP Architects, and challenges that involve variables that most SAP Architects haven’t dealt with up until now.

There is then the need to make sense of all of this, and understand in what ways S/4 systems, and in general SAP HANA systems being or not in IoT scenarios, need to be architected to respond to the ever challenge of architects: design systems that respond to the business needs in a sustainable and affordable way.

The contraints are the same IT architects have been asked to respond to so far:

  • Cost (of implementation, of operation and of change);
  • Performance / stability;
  • Availability;
  • Security / recoverability.


Then the question is: what solutions respond to these constraints in the reality of S/4, SAP HANA and IoT?

Let's continue this discussion on my next blog post.

No comments:

Post a Comment