Skip to Content

In a previous blog, I outlined why I thought that the SAPPHIRE announcements about Simple Suite were the equivalent to the move from R/2 (mainframe) to R/3 (client server).

Evolution+of+SAP.png

It means that new approaches are possible for all the layers of the architecture. So, companies will have to consider the following:

In a series of blog over the coming months, I will consider each of the layers in the architecture and the changes that will be necessary for SAP customers to gain maximum benefit from SAP HANA.

This blog will focus on the impact of HANA as a platform, while future blogs will cover changes to the application architecture, user experience architecture, and integration architecture.

One interesting point to note is that, in many cases, things that were “not allowed” in the old world are now “best practices” in the new one!

Screen Shot 2014-09-15 at 12.28.06.png

How to Adopt HANA

First Step:  Understand Where You Will Use It

You must first create a roadmap that maps the benefits of HANA to the opportunities and/or pain points in your organisation. To do this you will need to answer two key questions:

  1. What are the capabilities of HANA?
  2. What are the opportunities and pain points in your organisation?

Depending upon your organisation your enterprise architecture team may already have the answers to the second question. If they don’t, then read the various success stories on SAPHANA.com to trigger ideas. For instance, one common starting point is SAP Business Warehouse performance, where HANA can enable near-real time reporting where a non-HANA system may only be able to deliver results daily / weekly or monthly.

Screen Shot 2014-09-08 at 10.17.10.png

As far as the first question is concerned, SAPHANA.com is definitely your destination of choice as it has many guides on the various capabilities of SAP HANA. At a very high level, you could adopt SAP HANA as follows:

  • Upgrade existing SAP applications – e.g. SAP BW on HANA, Suite on HANA, Simple Finance, and more.
  • Adopt new “HANA only” SAP applications – e.g. SAP Operational Process Intelligence, SAP Integrated Planning, and much of SAP Fiori.
  • Use SAP HANA to develop bespoke applications – Utilise the capabilities of SAP HANA to create “custom” apps that deliver competitive advantage – e.g. Burberry Client Telling App or John Deere Predictive Maintenance App.

Second Step:  Acquire Skills in SAP HANA

The next step in your journey to SAP HANA (and this can be done in parallel with the first step) is to decide how you are going to acquire the skills needed to architect, design, implement, and operate SAP HANA.

How you achieve this will depend upon the sourcing strategy you have adopted as an organization. If you have selected an outsourced model, you’ll have to work with your partner (or perhaps a new one) to ensure they have invested in SAP HANA knowledge. That way, your partner can give you the best advice.

For an insourced model, you’ll need focused training for your architects, designers, developers and support. Again, SAPHANA.com is a great source for free training, as is open.SAP.com. Also look for SAP HANA certification courses.

Screen Shot 2014-09-08 at 10.15.36.png

Architects and designers will need to learn that SAP HANA is more than a “fast database.” They’ll need to understand the various engines that come bundled in the product—and decide how they should or could be used in the organisation. From an SAP-centric perspective, they will need to stop viewing the database layer as a file store that is only accessed via the application server level. In the old world, direct DB access was seen as negative (and in some cases, it was outside the customer’s database licence). Using HANA, you will only get its full power if you DO access the database (and associated services) directly.

For developers, new languages/concepts need to be learned, such as SAP River RDL, SQL, SQLScript, JavaScript, R and OData.

Meanwhile, the operations team will need the skills to monitor, tune, backup, restore and make data highly available.

The degree to which you have to learn any of the above will depend upon the HANA roadmap created in the first step.

Third Step:  Hardware and Software

Based on the HANA roadmap, you’ll understand your usage pattern over the next three to five years. This will help inform the amount of HANA technology you’ll need and how it could be licenced.

A number of options exist. The right one for you will depend upon your usage pattern and your approach to the cloud. At a high level, consider the following options:

  • Your own data centre with on-premise perpetual licence.
  • A third-party data centre with managed cloud as a service subscription licence.
  • SAP HANA Enterprise Cloud with perpetual licence.
  • SAP HANA Enterprise Cloud with a subscription licence.
  • SAP HANA Cloud Platform with subscription licence.
  • Public clouds such as AWS and Azure with perpetual licence.

You should evaluate each option, as your solution could be a hybrid between two models. Using the managed cloud options (HEC and MCaaS) will greatly reduce the need to develop in-house operational HANA skills.

Fourth Step: Create an Implementation Programme

The final part of adoption means creating an implementation plan that addresses your HANA requirements over the long term. This will depend on your current landscape and the versions of software you run. As a general rule, the adoption of HANA under existing SAP applications will require the application to be on relatively new versions of the software with up-to-date service packs.

The other major impact area will be on projects that are in flight, or planned within the HANA adoption window. Any plans for using HANA will need to be dovetailed into these existing plans to ensure you avoid conflicts and leverage new opportunities. (For instance, HANA allows you to use much more of Fiori.)

Conclusion

If you go through the above process, I predict two things:

  1. You’ll find a use-case and business case to adopt HANA.
  2. The final landscape at the end of your three-to-five year roadmap will have less boxes and complexity than you have today.
To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Joao Sousa

    Thanks for the explanation, this is a topic of great interest. I have the following questions:

    • Isn’t SAP Simple Suite also client-server?
    • Does it mean that the new suite will stop supporting DBs like Oracle?
    • Does the simple suite support logistics processes? You put 22 years in the diagram, but I saw no mention of Simple Logistics to integrate with Simple Finance.

    As a remark, more then a question, I have a hard time seeing the “perpetual license” scenario as real, if you take into account the huge maintenance fees that customers pay each year. The maintenance fees for SAP, are higher then most software on subscription licensing….

    SAP has said several times that the perpetual license model is bad for customers and will die out, but I’ve yet to see for example, a comparison for a 10 year investment on SAP ECC (cloud subscription vs on-premise perpetual). And I’m not even going into the way many companies see Capex vs Opex.

    (0) 
    1. Owen Pettiford Post author

      Yes Simple Suite is client server, but more logic is pushed to the DB layer (esp new features).

      Simple Suite only works on SAP HANA.

      At SAPPHIRE 2014 Orlando, one slide showed a high level plan for Simple Suite with Simple Finance being the first one (see Bernd Leukert discuss the roadmap in his Keynote The Future of Enterprise Applications – 2 hours and 16 minutes in).

      With regard to the perpetual license model, I see this as a way to help on-premise customer move to the cloud without changing their commercial model if they want to.

      (0) 
  2. Jelena Perfiljeva

    Thanks, Owen! Great blog, I thought it had more value for the customers than all the SAP marketing articles. Nicely done.

    Some questions. 1) “Less boxes” have been mentioned as HANA advantage on multiple occasions with the examples of SCM, CRM and other 3-letter acronyms. But our biggest “pain point” are the interfaces with the systems providing additional functionality that is not supported by our “core” ECC system. Some of them are third-party, so we can only use the interface options provided (usually it’s a file or IDoc). It seems that HANA wouldn’t really help to get rid of those “boxes” or am I missing something?

    2) It’s not a secret that the implementation partners may vary greatly by the quality of the resources provided. What recommendations would you give regarding the partner selection, so that the SAP customers could get the best guidance on their HANA implementation?

    Thank you.

    (0) 
  3. Joe King

    Great Article: As to ‘acquiring skills in HANA’,  The SAP HANA Academy now has over 700 free tutorials videos  on how to use HANA. These videos have been viewed over 1 million times by over 500,000 unique users.

    We have moved off the saphana.com site to a YouTube Channel to give our customers and partners faster and easier access to find the answers they need to be successful with HANA. Check us out directly on our YouTube channel.  https://www.youtube.com/user/saphanaacademy

    Thanks, Joe

    (0) 
  4. Harris Veziris

    In my mind, this should be marketed similar to what Mercedes-Benz or BMW do with AMG or M series respectively, in parallel to traditional approach with AnyDB.

    (0) 
  5. Abdul Rasyid

    Hello Owen Pettiford

    I am totally new to SAP world, come from client/server world. I  followed self paced SAP Business Suite powered by SAP HANA and Rapid Deployment of SAP Solutions (incoming course). Please advise on road map to begin learning about SAP HANA

    (0) 

Leave a Reply