SAP HANA in the Cloud? "No way" or "what cloud"?

Being "Cloud" one of today’s buzz words, that is also shaking-up the SAP world alongside HANA, I’ve come across many customer with a strong “antagonism” to any topic with “cloud” on the title.

I see as a root cause to this antagonism, the huge confusion created by all the players that want to be in this market, whom call “cloud” to everything that moves in their portfolio in their struggle to be relevant.

So, when talking with CIOs, Enterprise Architects and other IT leaders, I see still lots of misunderstanding in relation to “all things Cloud for SAP”.

In this blog, I’ll make a brief definition of my understanding of “Cloud”, to then use this definition to do a high level discussion on “what is the right cloud model for each company and business scenario”.

Note that you’ll see that my discussion is generic from a pure cloud perspective, and not very “HANA” specific. The point here is that, all I’ll be discussing in this blog post, can be part of a datacenter wide strategy discussion on which SAP HANA today definitely fit in as well.

SAP HANA is becoming increasingly normal, and so you should consider it as an integral part to your cloud strategy.

I know there are certain limitations in regards to “very huge” HANA systems. But when talking with customers with 70 and more productive systems with full landscapes of more than 300 SIDs, and many multi-terabyte databases, the ones that require special attention are usually less than 10%. So, you can set a rule for the other 90+ %, and then deal with the exceptions.

Let me tell you as well, that I’ve seen companies looking at those huge SAP HANA systems first and using them to define the standard, and it has led to massive costs that could have been avoided. But talking on the benefits of standardization of IT would be another conversation I’ll leave to another occasion!

           What is "Cloud"? 

So, let’s get to it and start putting some names on the “things”.

In fact, Cloud is a buzz word subject to many miss understandings today, and due to that may not be “the first option” many organizations around the world would think of.

Although the “Cloud” buzz word is relatively new, the concept has been around for many years, and it’s all about industrialization of IT.

Looking beyond the noise and the smoke, indeed Cloud not being new, it is indeed real today.

I remember presenting at conferences for another company many years ago about “industrialization of IT” where I knew that what I had was a reference architecture, and that everything would have to be custom built through massive consulting projects. This is no longer the case today.

And industrialization of IT is real because today we have the technologies that indeed enable to manage IT as a Service at its multiple levels.

Hardware has evolved to be able to be managed and configured by software, and most components in the IT stack provide scripting interfaces that enables “automation tools” to manage them.

This discussion has been becoming increasingly confusing for customers because each provider organization abuses the “cloud” word to positon themselves as relevant despite their disparate maturity, standardization, automation, geographic coverage and competitive positioning.

Among the miss understandings of “cloud” there are 2 I consider fundamental to overcome:

• That once a workload is virtualized, it is already in some sort of cloud;
• And the idea that cloud is only “public cloud”. 

           Just Virtualizing Systems is not Cloud !!!

Let me then start setting some foundations by making a reference to the U.S. National Institute for Standards and Technology (N.I.S.T.). This organization came up with a definition of cloud, to which all players in the market can refer to, so enabling cloud customers to have a framework through which evaluate their candidate providers in terms of completeness of offerings.

This standard has been widely accepted by the key players in the “cloud business”, and can be found at: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

If you read through the N.I.S.T. definition of cloud computing, it clearly identifies what are the essential characteristics needed to be in place, so that you can call something “cloud”:

• On-demand self-service;
• Broad network access;
• Resource pooling;
• Rapid elasticity;
• Measured service.

You can read more about them both on the N.I.S.T. documentation and on other documents available in the internet.

From these characteristics you can evaluate that they imply a more comprehensive scenario than just virtualizing applications. Virtualization can indeed be a key enabler of cloud as it enables for example “rapid elasticity” and “resource pooling”, but to be in face of a cloud, you’ll also need a significant level of automation.

Indeed, automation is a key component to any real cloud. If you look at it, Information Technologies came with the promise of automating the business processes of organizations, but the management of the IT systems has been quite manual. In fact, for most organizations around the world (end customers and service providers alike), the cost of labor is one of the biggest items in IT operating expenses.

So, "Cloud" is all about bringing to IT what IT brought to business processes many years ago: minimize the human intervention in regular IT operations. The benefits from this reduction of human intervention has been realized for many years in the manufacturing industries, having demonstrated to reduce defects, improve response times, reduce operating costs and simplifying change.

These levels of automation are implicit in characteristics like “on-demand self-service”, where it is assumed that there will be no manual work behind a “self-service portal”, as it would be fully orchestrated and automated through workflows.

For me a “cloud” that is hosted at a service provider, but that behind the “portal” has a lot of manual work, and because of that has expensive costs and low response times, is not a cloud. Although many service providers around the world advertise cloud offerings for SAP HANA that indeed in the background operate in this way. They will always fall short on the expectations created by the “true cloud players”.

Another key characteristic of cloud is to have a “measured service”, as this is a key characteristic to enable your organization to run IT as a Service, and become an IT services broker to your business organizations.

This would for example enable to, when a business user comes to you asking for a system to start a new project, to check your “private cloud” and “public cloud” costs, security, service levels and response times, and give an the best option to the business user based on the business scenario he will be implementing. Here is where I believe IT really becomes a partner to business organizations in driving innovation and further organizational agility.

I believe we can agree at this stage that “virtualization” and “cloud” are not synonyms. Virtualization is definitely a key ingredient to build efficient clouds, but is not “cloud” just by itself.

           Cloud is not only “Public” Cloud – look for Private and Hybrid as well.

The clarification for the second myth we’ve referred above comes from the N.I.S.T. definition of Cloud Computing as well.

In that document there are also described the “Cloud Service and Delivery Models”.

In terms of service models, N.I.S.T. defines the following:

• Software as a Service
• Platform as a Service
• Infrastructure as a Service

And in terms of delivery models, the following are defined:

• Private cloud;
• Community Cloud;
• Public Cloud;
• Hybrid Cloud.

Again, not being my goal to dive deep on the NIST definition (as you can read all about it online), the point here is that private IT organizations can work in a “cloud operating model”, delivering a Private Cloud to their business organizations with similar characteristics to public cloud offerings.

To do this, what private organizations need is access to the infrastructure components, tools and know how on the processes used by leading public cloud providers. And this is available today!

I’m pleased to have gotten to know some IT organizations that “got their act together” and stepped it up to be competitive in terms of agility and quality of service with public cloud providers! In the end it’s all about the people.

But there is another choice coming strong to market, that might bring together the best of two worlds: what if the “public cloud provider” offered his services to manage a private cloud hosted on your premises (under your full span of control) in the same way it manages his public cloud?

This is what I call the “managed private cloud”.

The point here: cloud is not only public cloud. It’s all about a service model around automation of IT.

I believe then, that we can agree that accepting this definition, “cloud” must indeed be part of every IT organization’s strategy discussions.

           Should I go IaaS, PaaS or SaaS? Soo many “aaS” is so confusing...

Now, looking at the NIST defined service models, what is the right one for each of your business processes / application stacks / organizations?

Let me share what I’ve learned on this topic from working in IT operations myself, and participating in many interesting discussions with the leaders of those IT organizations.

Many organizations look to differentiate themselves through the usage of information. This makes it that an increasing number of organizations see “code development” capabilities increasingly as a core competence as it provides them the capability to manage and analyze information. In the information age, being able to rapidly turn information into actionable insights to the business is a key competitive differentiator.

On the same side, there are also organizations that struggle to get the skills they need at this level, and see themselves many times hostages of “under-performing” IT teams. This has led in many cases to top management decisions to embark on “comprehensive outsourcing deals”, which we’ve seen as very popular through the late 90’s and early 2000’s, as they expected the outsourcer to solve the problems they haven’t been able to solve themselves.

History has shown that most of these comprehensive outsourcing deals apart from the short term financial impact of turning CAPEX into OPEX and providing a cash injection, have come short on most operational, innovation and strategic expectations.

So, externalization of IT functions, being through Outsourcing or Cloud, has been a tool in the hands of CEOs, CFOs, CIOs and in general C-level executives as a way to solve many different problems (strategic, financial, etc), including IT skills and processes problems.

I have worked both on architecting solutions for these “old large outsourcing contracts” as well on the delivery of those contracts, and I have a ton of stories to tell on my learnings from it.

But the point is that these problems haven’t gone away, and still exist in many organizations.

So choosing between SaaS, PaaS and IaaS may also align to where the problem lies in the customer’s IT organization.

I would say that a decision to adopt IaaS, PaaS or SaaS should be based fundamentally on the business scenario to be supported. But I have to acknowledge that on the board room, this is not the only discussion argument.

This is why I say that SaaS may be a way to solve your problems when functional and development teams do not deliver. By going SaaS you externalize all of that to the provider. Of course this should be balanced with an analysis of the application, as going to a SaaS model would be a good fit if the application has mainly standard requirements across the company’s industry.

As for PaaS, apart from providing pervasive access to a development platform, it might be looked as well as a way to cover poor capabilities of DB and OS admin teams, as that would be in the responsibility of the provider.

Remember, these are just examples of discussions I’ve observed, and I believe it is important to put the SaaS/PaaS/IaaS options in perspective.

Associate this previous aspect with the fact that in many parts of the world there are severe technical and regulatory limitations to a public cloud model, and the scenario of implementing a IaaS private or hybrid cloud model is in fact the most accepted one for business critical applications. I see this today, and foresee it will stay like this for the coming years.

           What is the right cloud delivery model for my Business Critical applications?

So what kind of a cloud will you’ll be putting each of your workloads on?

Will everything be public?

It depends on the specifics of each customer / country and use-case, and the following metrics should provide you a good guidance on how to decide: Economics; Trust; Functional.

For example:

• Where is more economic to run this workload? On the public cloud or on my private cloud?
• As internal IT usually does not have a profitability goal, the end cost for the company may be lower running it on-premise. But on the other side, in many occasions private IT organizations do not have either the scale or the most efficient operating model, making it then more costly in the long run. Not all companies are alike, so the result of this evaluation is absolutely unique to each customer scenario.
• What confidentiality and compliance requirements are applicable to this business process/application? It is subject to data sovereignty regulations, or other risk related regulations like "Sarbanes/Oxley" or "Basel"?
• Not all countries have the same regulation, and each organization manages business in a different and unique way. There may be scenarios that either industry, country or corporate regulations impose certain restrictions on "data placement". Also the risk profile of each company defines their approach to risk, and their evaluation on probability, impact and acceptable risk containment/management practices.
• Does the public could provider provide functionality that maps to the unique needs of the organization?
• There are business processes in organizations that are quite standard in the industry, leading to look at application adoption as a way to have access to standard and updated industry best practices. There are as well situations where the business processes and functional requirements are very unique or custom to the organization, being even a unique source of competitive differentiation, situation in which most likely a standardized public cloud offering may not be a good fit.

Again, this is just an example of a reflection, and if you look at this, you can realize that most likely you'll find workloads suitable to public cloud offerings, and other that will be subject to more restrictive conditions.

Apart from this, we have to remember as well that not all the world has today cheap and stable high bandwidth connectivity, and that the increased news on data privacy violations and questionable access by public entities to private data, makes it that many organizations see themselves in the cross-roads of making careful decisions of what should be placed under the organization’s direct span of control (the private cloud), and what is acceptable to be put in a fully public environment.

Let me share one example provided by one customer I met some weeks ago on his reasoning of what we could place on one side or on the other.

This customer gave as an example 2 particular systems:

• one to support employee performance evaluation, career planning and skills development;
• and another system for “order to cash processes” like invoicing and accounts receivable.

If they lose access to the employee evaluation system, the company will not stop operating. Also, the kind of data included in such a system does not contain critical data in terms of the company secrets, which makes that having a reliable public cloud offering it might be the right solution for such a system.

On the other way, for the invoicing and accounts receivable system, if access to such a system might be lost, the business operations would be paralyzed and cash inflows might be negatively impacted. 

Also if in such information there is business critical data, like the markets an organization is operating, its revenues by market, its customers, its planned promotions and new product launches, etc… This is definitely the kind of system that it will be most difficult for an organization to accept being operated outside its span of control, or without access to its own auditing services.

If we remember as well, that apart from the US, Western Europe and certain specific countries in Asia, the majority of the world still has both technical and legal constraints around public cloud, I believe on-premise (or a hosted / managed private environments) will still be the mainstream option for the core business systems of organizations for quite some years to come.

So, we will have cases where a pure public cloud offering where you have no control over the software stack or the data placement location will be an acceptable choice, and also cases on the other extreme where you'll need to keep full control of the software stack and data location. But between these two extremes, there are a multitude of possibilities, like leveraging a local provider providing you an hybrid model like: having the data placed in the local provider within the country's borders, in association with a global provider providing the cloud services on top of that infrastructure, either in a dedicated or in a shared environment.

The point: today there are multiple options, so embrace the discussion and find out what are the best options for your organization from a financial, strategic, innovation and operational perspectives.

           IaaS is the Cloud Service Model that Provides you the most flexibility

Assuming that through your “cloud workload filter” you define what services are acceptable to run on a public cloud and which are not, you’ll end up with the conclusion that you’ll be operating a Hybrid Cloud Model, with certain services running under your span of control (either hosted by your own IT or managed in a hosted managed private environment at a Service Provider).

How do you ensure you do not end up locked-in to a certain vendor, and that you don’t lose the flexibility an hybrid cloud model should be providing you in the first place?

The response would be: adopt a cloud service model that enables you to have control over the “mobility” of your workloads between public clouds, or between public and private clouds.

Today, only Infrastructure as a Service (IaaS) offers this.

Let’s look at it for an instant:

• SaaS: the application logic will be property of the service provider, and if your organization wants to move that process back to its span of control, it will imply a major migration project as it will be needed to configure a new application to support that functionality alongside a migration of the data from the public provider to your controlled environment. This will definitely be time and resource consuming, representing a disruptive change. So we can say, that once you make a choice to adopt a SaaS offering in a Public Cloud, there will be a number of barriers to exit, that must be evaluated beforehand and included in your contract “exit clauses”.
• PaaS: the provider owns up to the run-time platform where you deploy your code. Means that most likely, your data will also be hosted on the provider infrastructure. Here moving these processes from public to private cloud becomes simpler, whenever the platform you’ve chosen to run your code on can be easily deployed on-premise as well. But also in this case, moving functionality from public to private will be a disruptive event which will imply certain costs and application downtime.

Both in SaaS and PaaS, when talking about hybrid cloud scenarios, we are thinking about the possibility of business processes or applications interact and expand between private and public cloud. But in neither of these cases we can talk about “dynamic workload mobility”. At least with the current (that I know of, and foreseen for the medium term) public cloud offerings and technologies, there is NO dynamic / real-time workload mobility.

But this is a reality today in the IaaS model.

When considering Infrastructure as a Service, apart from having complete isolation at the data level with today’s Virtualization Technologies like the ones provided by VMware, the whole stack needed to run your business processes is packed in a container that is the Virtual Machine, that you can absolutely control form a confidentiality point of view and move around between compatible clouds.

But the key benefit here is that if you choose public cloud providers who operate on VMware, having VMware as well as an enabling technology for your private cloud in a IaaS model, you can today use technologies like “long distance vMotion” (check out the announcements on this topic from VMworld US 2015) to dynamically and without disruption move applications from the private to the public cloud and back, avoiding being locked-in to a specific vendor.

There are also storage provider technologies that facilitate the movement and copy of virtual machines between clouds that are in use by many service providers around the world and that can be used in combination with “long distance vMotion”. But to my current knowledge, the scenarios I know are in production still imply a minimal application downtime to do this workload mobility, as “long distance vMotion” is a brand new feature that will still take some time to become widely implemented and integrated with key hardware infrastructure components.

So, from a risk perspective, IaaS is the only model that truly enables you to operate in a hybrid cloud that doesn’t get you "technically" locked-in to one public cloud vendor.

          IaaS is the only true hybrid cloud model without vendor lock-in

Cloud isn’t then just Public Cloud.

Cloud is about industrialization of IT, being its architecture enablers: virtualization,  automation and orchestration software, and most important, people and processes.

Today it is possible to acquire a pre-configured infrastructure, with all the software already deployed on it to provide an out of the box self-service portal, charge back tools, automated deployment workflows, and all those other tools that truly enable a private cloud according to the characteristics of cloud described above as per the N.I.S.T. definition of cloud computing.

Considering the profile of your organization, and the different types of business processes you’ll be supporting, cloud must definitely be a part of your IT strategy conversations.

In many cases, implementing a private cloud and adopting a cloud operating model on your own IT organization may show to be the right solution to your most critical and customized business applications. But in many cases I’m finding out that with the increased security certifications obtained by cloud companies like Virtustream, the option for a hosted / managed private cloud receives a lot of very strong positive feedback.

Having hosted managed private cloud offerings, brings most of the benefits of a public cloud but under your organization’s span of control.

Being Cloud a key topic in your architecture discussions today, adopting a TDI and Virtualized infrastructure for your on-premise SAP HANA deployment will also enable you to be prepared for the adoption of a Hybrid Cloud IaaS scenario, where you’ll be able to have full control of the mobility of your workloads between your private and multiple cloud providers operating under this model.

This scenario will for example enable:

• Higher utilization of private assets: provisioning only for average workload, being able to leverage public cloud for peaks;
• Simplification of operations: by having the same base architectures on-premise and on your cloud provider you can for example setup your disaster recovery to the cloud in a fully automated way;
• Reduction of the risk of change: having a new project you can just deploy a system either on-premise or on the cloud, whatever is more convenient, being able at a later stage to move that system in either direction depending on your “workload filter” and whether the applications will more or less critical and confidential.
• Drive business innovation: one of the key aspects to business innovation is to be able to experiment at a low cost. This scenario provides you full flexibility, so that you don’t have to say no to your business ever. In this scenario you can truly operate as a business broker taking the best of your private infrastructure as well as the public providers you are working with.

           Conclusion

Hope that at this point you agree with me that “Cloud” must be in every organization’s strategy and architecture discussion.

Which one is the right one for you? There is definitely not a “one size fits all” answer.

The good thing is that there are choices that can map to your specific organization, industry, location, and business scenario.

I hope this discussion helps you get started with your own ideas on cloud.

From my side, it is my true belief that an Hybrid IaaS model will be the leading option for mission critical SAP application, being based on SAP HANA or AnyDB.

If you want to get started in engaging with candidate providers to work with you on building your cloud strategy and architecture, being close to me, let me advise the following:

• EMC Federation Enterprise Hybrid Cloud for SAP: this solution makes available a fully enabled cloud infrastructure factory build and fully integrated, delivered pre-configured on your datacenter, leveraging the best technologies from the EMC Federation (EMC, VCE, VMware, Virtustream), so that you can start operating a private cloud without having to build all functionalities on your own from scratch;
• Visit https://community.emc.com/docs/DOC-30532 for more information.
• Virtustream Hosted and Managed Cloud offerings for SAP: Virtustream is a recognized leader in cloud for SAP and SAP HANA and has been recently acquired by the EMC Federation, being as well one of the only 3 SAP Premium HANA Cloud Partners.
• As Virtustream keeps operating as an independent company please visit http://www.virtustream.com/ for more information.

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.

EMC Acquires Virtustream, the leader in cloud for mission critical apps like SAP HANA

EMC has signed a definitive agreement to acquire Virtustream!

This will dramaticaly improve the value of the EMC Federation in the SAP space, and will further simplify the deployment of SAP Workloads, including SAP HANA, for all those organizations looking for an Hybrid Cloud environment, that has the flexibility to adapt to each company's specific constraints in terms of Risk, Compliance, Technical and Financial conditions.

This is a BiiiG topic for SAP customers around the world and for service providers as well, and for that, let me spend some time to share my own personal perspective on why this matters to you.

The news came out yesterday, and you can read more about it, or subscribe to listen to the recording of the press conference at: http://www.emc.com/about/news/press/2015/20150526-01.htm

Virtustream, being already quite known in the U.S. and in particular in the SAP World for providing Cloud Infrastructure as a Service, for enterprise, mission critical, high workload applications, isn't yet a familiar name in many other parts of the world.

To better understand Virtustream's current capabilities, have a look at the following charts from some of the Market Analysts:

Forrester classified Virtustream as the clear leader in "Hosted Private Cloud Solutions", and Gartner recognizes Virtustream's leadership as a niche player. Now with the EMC Federation on its back, Virtustream's (and the EMC Federation) position in Gartner's analysis, will only improve.

The relevance of the names already in Virtustream customer list also confirm their strength: http://www.virtustream.com/customers/list

So, let me share some words to explain my own personal perspective on what is the value for SAP Customers, from having Virtustream joining the EMC Federation as an independent company.

          What kind of applications (workload profiles) Virtustream specializes on ?

First of all, it's important to understand what kind of SAP Workloads Virtustream has been hosting.

So, let's imagine that you have two applications in your datacenter: one to support your "order to cash" process, including billing and accounts receivable, and another to do career planning and performance appraisal for your employees.

Both applications are important, but the impact of instability or even unavailability of these two applications on the ability for your company to keep operating, are significantly different.

If you loose your career planning and employee performance management system for a couple of days, your company will not stop to operate and generate revenues (and some employees may even be happy about it), while if you loose your "order to cash" system, money stops coming in and your company will go into serious trouble.

This is why, most companies can easily buy into the idea of running the "career planning and performance management" system in a public cloud environment (where they have NO span of control on the architecture stability and resilience), and hesitate a lot (not to say that won't even consider) to run their "order to cash" system in the cloud.

So, let's agree at this stage to call the "order to cash" system, a mission critical workload, in the sense that without it, companies loose their ability to keep operating and fulfill their goals, or even if those systems see their performance and stability decay, it will imply an important negative impact on business.

It's all a matter of risk evaluation. For organizations to consider running mission critical applications in a cloud environment, they will need to ensure a set of conditions: availability guarantee, performance guarantee, and ability to audit (and for the service provider to demonstrate) capability to operate such an environment in a stable and predictable way.

The majority of public cloud offerings do not offer such guarantees.

Well, Virtustream having been born by the hands of people coming from the SAP ecosystem, that had experience setting up and managing these mission critical systems, do fully understand the implications of hosting and operating such environments, and have build their offerings to address specifically the needs of the Global 1000 (the 1000 largest organizations in the world) in regards to cloud offerings for their most critical business systems.

Also Virtustream, understanding well the reality of these large global organizations, also understands that for some systems, those organizations - not wanting to engineer and manage them - may want to keep a significant span of control on them. Meaning, having them be operated in a "hosted, managed, private cloud environment". So, it's having the systems under their span of control (or even under their own property), but hosted and managed in a cloud model in the same way public clouds are managed, to reap all the benefits in terms of business agility, operational risk and costs that a cloud model can offer.

These companies may want as well to dynamically choose what systems run on their own private cloud, and which run on a public cloud, dynamically moving (and controlling the movement in real time) of these systems between their private cloud and the public cloud.

          What are the business benefits of the Virtustream model ?

Such a model enables them to manage risk in the sense that they decide which systems are 100% under their span of control, and which ones are not, by being able to dynamically move systems across boarders between their private cloud and the public cloud.

It enables them to manage cost, by ensuring the same efficient management model that exists in the cloud for a better utilization of their assets, while being able to leverage the public cloud for peaks in demand, avoiding the need to over provision capacity for projects, and keeping their "private systems" provisioned just for average workload needs, and so maximum utilization.

Here Virtustream is really unique as they charge by utilization, and not by allocated capacity like most cloud companies do, making them way more cost effective for that reason, and boosting the benefits for organizations from operating in a Hybrid Cloud Environment. This is a part of the Virtustream secret sauce, where they have come up for example with the concept of microVM.

It enables customers to be more agile, as Virtustream has embedded in their Cloud offering and orchestration software, way more than just provisioning of virtual servers. Coming from their SAP background, Virtustream founders have build in as well automation mechanisms for things like systems cloning and refresh (fundamental and usually labor intensive for most SAP customers), making it simpler for IT organizations to keep up with the demands from their business units.

And again, with the beauty of all of this, in having the private and public cloud resources managed through the same tool set, and both able to bring in the same benefits > complete transparency.

Don't want here to explain what is Virtustream, as you can have it explained in 5 minutes in the words of its founder and CEO "Rodney Rogers" at http://www.virtustream.com/blog/2015/05/24/virtustream-technology-overview/

          How Virtustream joining the EMC Federation, benefits SAP Customers in general ?

So, why is this so important for SAP Customers: Virtustream joining the EMC Federation as an independent company.

First of all, Virtustream has been working very closely with SAP (having SAP been one of the early investors in Virtustream) to drive cloud adoption for SAP applications, and SAP HANA in particular. There is a lot more to the collaboration between Virtustream and SAP, which you can read about at the Virtustream site and blog.

On the other side, Virtustream having started as a "Venture Capital Funded Company", would need at a certain point in time to expand their financing capabilities in order to scale and be able to keep up with the significant demand increase.

Also, to expand its reach it would need further access to the supporting technologies of their business model, and access to markets by means of a broader sales force generating demand for them.

Being today the collaboration between Virtustream and the SAP Community inside EMC already very close, being SAP one of the top strategic partners for the EMC federation of companies (EMC Information Information Infrastructure, VMware, Pivotal, VCE, RSA) and running Virtustream most of their operations on top of technologies from the EMC Federation (VCE VBlock, VMware, etc), all of this aligned to the partnering model the EMC Federation of companies fosters, I truly believe that Vistrustream was a perfect match for EMC.

So, joining the EMC Federation as an independent company will provide Virtustream the robustness of belonging to this amazing groups of companies, enabling it to accelerate their growth, expand their reach, and extend their coverage way further from their current market reach and portfolio. By being an independent company within the Federation, it will enable Virtustream "not to get dispersed or diluted" like it happens on many acquisitions in the IT world, and so keep focused on its unique business strategy. That is why it is referred on the announcement that Virtustream is now "EMC Strong".

As I meet with CIOs and their direct reports all over the world (just landing now coming from a CIO Summit in Prague), they all agree with my own experience that, what works for SAP Applications, will work for almost everything else as well. So I would say, that coming from an SAP background, it shouldn't be hard for Virtustream to expand their reach into other application areas.

With Virtustream, EMC completes its vision for an end-to-end cloud offering, from the "Federation Enterprise Hybrid Cloud" which aims to cover the private on-premise needs of customers, with Virtustream covering the on-premise and off-premise managed private clouds, and vCloud Air providing a completely public cloud environment (customer has no span of control on infrastructure architecture/operations), having these three working seamlessly.

In summary, for end customers: this acquisition of Virtustream by EMC, will enable you to implement an Hybrid Cloud model today, with out of the box, ready to use architectures for your private cloud, leveraging all the best practices from operating a public cloud, being able to leverage Virtustream's expertize also to manage your environment up to the SAP Basis layer, including if needed performing the projects to migrate your workloads to the cloud, all with the assurance of a robust global corporation recognized for its strength in the "mission critical world" like EMC.

          How about companies with technical and legal limitations to use U.S. based clouds?

There are 2 additional key aspects to which I'm very aware, as I do also work a lot with customers in Latin America, Eastern Europe, Middle East and Africa, that are very important in regards to customer decisions about any "cloud plans": technical and legal limitations for cloud in these regions.

One of the key limitations of the "U.S. born and based" public cloud offerings, is that they were born to be "public cloud only" and most of the times hosted only on a very limited number of datacenters, mainly in the U.S.

Well, for a U.S. based company, or a company operating mainly in the U.S., this only represents advantages. Even for most truly global companies, this does not represent a problem.

But there is a lot more world than the U.S., and the geo-political environment in other parts of the world, associated with technical limitations like the access to cheap, stable and reliable broadband communications, makes it impossible for certain organizations to consider the possibility to host any of their business critical systems outside the borders of their countries. More, in many countries in the world, there are "data sovereignty regulations" that forbid local companies from placing their data from outside the physical borders of the countries.

There are also the cases of Global Corporations, that having operations in certain countries, are also obliged (either due to legal or technical reasons) to host their systems closer to their operations.

The consequence here is, even if the existing public could offerings based out of the U.S. were reliable enough to host "in-production" business critical applications like SAP (which most are not), due to the technical and "data sovereignty" constraints, those offerings would not be an acceptable (or even possible) alternative for many companies in the world.

One possibility would be Virtustream "managed cloud services", enabling the systems to be in the location of the customer, but being fully managed with all the cloud best practices up to the SAP Basis layer.


          EMC, Virtustream and Service Providers

But there is another perspective here, where both EMC and Virtustream share one common understanding, that they will not be able to reach to the whole world, and maybe it isn't at all a good idea to try and do it all themselves. In most cases there are already local service providers who are building their own local public cloud offerings to attend to the needs of those companies limited either by technical or regulatory limitations in regards to hosting their business critical data outside the country.

Virtustream, apart from providing their own "Infrastructure as a Service" public cloud offering in the U.S.  and Western Europe, and their "managed cloud services", also licenses their software to power Service Providers all over the world.

EMC also has a strong program to equip service providers around the world with "cloud enabled infrastructures".

So, here both companies come together to provide a comprehensive "hardware and software" solution, ready out of the box, either to power service providers or large enterprises looking to build their own private clouds.

Check here the EMC Cloud Service Provider Directory

Having Virtusteam's own IaaS offerings in a Public Cloud model, as well as their managed services targeted at those customers wanting to have a managed private cloud, together with a vast and strong network of service providers all around the world operating on the same architecture, along side with customers having their own private clouds running on this architecture as well, will truly enable IT organizations and their CIOs to become "IT service brokers" for their businesses, procuring the right IT services, being from their private cloud, a local cloud provider or a global cloud provider, according to their financial, technical and regulatory context policy (needed span of control) applicable to each application environment, knowing that they have partners in the public side ready to host and operate their most critical business applications.

          Conclusions

So, I believe these are truly amazing news for the SAP ecosystem (SAP themselves, customers, system integrators and service providers), as the acceleration of the expansion of this model all over the world, will further simplify things like migrating to SAP HANA, and reducing the operating costs of running SAP Applications (including SAP HANA) while improving the performance and agility of existing business systems.

For example, with Virtustream operating as an independent company within the EMC Federation, a Global Company will now be able to have a truly global cloud strategy, that fits its legal, technical, financial and risk model, for their most critical applications (SAP and non-SAP, as what works for SAP will most likely work for everything else), managed through the same model, using public, private, managed or hosted-managed as appropriate without getting locked-in, truly making justice to the principle of "think global, act local" within a Global Hybrid Cloud.

I would invite you also to have a look at the blog Virtustream's CEO, Rodney Rogers published at the time of this announcement with his own personal perspective.

Adding to this fact that I already have some very good friends at Virtustream, it will be truly a pleasure to bring the Virtustream value to my conversations with IT leaders all over the world.

Know more about Virtustream at: http://www.virtustream.com/

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.

Key take aways out of SAPPHIRE Orlando 2015

It's time to say goodbye to Orlando after SAP's SAPPHIRE event, with a week loaded of customer and partner meetings.

The technology related news were few:

   - SAP HANA productive support for scale-out on VMware is now on Controlled Availability

   - New servers based on the Intel Haswell CPU started to appear, promising increased performance per CPU core

But to be fair, and putting my self in the shoes of our customers, it was a very full week, with all the focus on:

   - what business outcomes can SAP HANA enable (S/4, Board room of the future, real time cash management, real time supply chain insight are just few of the many examples through the exhibition)

   - how the Internet of Things can impact business (integration of machine data into business decisions, HANA managing structured and unstructured data under a single pane of glass for better business insights)

But the highlight out of my meeting with customers and partners was an increased awareness and concern with:

   - understanding Data Temperatures in HANA as a way to reduce TCO when integrating massive volumes of unstructured data, and keeping infinitely the structured data generated by the organization

   - realization that implementing SAP HANA as an appliance might have been the only option in the past, and is definitely not the best, and so customers that have already been running HANA for some years, came all over wanting to understand better SAP HANA Tailored Datacenter Integration as a way to reduce TCO and enable the leveraging of existing infrastructures and operational processes for less risk, as well all things about running SAP HANA on VMware as the simplest, cheapest and fastest way to start a SAP HANA project.

So, although the majority of SAP's talking points were targeted at C-level executives, the teams of these executives also came by and they were all about "how to make it happen in the simplest, most cost effective way".

For me personally, this was a massive event! I had an agenda so loaded with customer and partner meetings, and meet so many new faces in the community alongside with an increased interest on the topics I've written the most about, made this week exhausting, but very rewarding.

I' leaving with the strong feeling I've helped many organizations move forward with their SAP HANA adoption plans, by making it simple all things related with SAP HANA Infrastructure Integration.

Topics I would have liked to hear more about and that we're almost non-existent, were:

   - preview on SAP HANA SPS10

   - evolution of the Multi-tenant database containers feature

   - evolution of the Data Tiering feature

   - what is being done to make SAP applications running on top of HANA better for scale-out scenarios

   - more insights in to what is planned in regards to "HADOOP alike" capabilities coming to HANA, for example enabling HANA to natively access and process data available on HDFS stores without need for an HADOOP cluster in the middle.

Well, the plane is coming, and I need to run, but didn't wanted to leave without leaving my first impressions "hot off the press".

It was great meeting you all (customers, partners, SAP friends, SAP Mentors, company colleagues), thanks for all the interesting discussions, or just the fun moments, and looking forward to see you all soon!

   

SAP HANA Storage Whitepaper version 2.6 released

SAP has published quite some time ago their "storage requirements whitepaper" for SAP HANA, which explains at a quite interesting level of detail, how SAP HANA uses storage, and to what extent storage characteristics are relevant for SAP HANA operations.

So far, no news.

What is new, is that with each new version of this "Storage Whitepaper", SAP has been simplifying the SAP HANA Storage requirements (for example on this latest version by reducing the capacity requirements for the /hana/shared/ filesystem), which is a clear reflection of the increased experience on SAP HANA operations, increased stability of the software, and so a clear sign of maturity.

If you haven't read this document yet, I would really suggest you to take some time to go through it in detail.

If you already saw this document at some point in time, be sure to review it and be up to date on the latest.

The SAP HANA Storage Requirements Whitepaper is published at: http://scn.sap.com/docs/DOC-62595

Reference to this and other important documents in regards to SAP HANA infrastructure integration can be found on the right pane of my blog under reference pages: SAP HANA Technical Documentation