Skip to Content

For the past 9 months or so, I’ve been exploring the SAP HANA Cloud Platform (SAP HCP) and seeing what it has to offer as a PaaS solution. Now that I’ve had a chance to collect my thoughts, I thought I’d write a quick blog to share my findings. This is by no means meant to be a sales pitch, but rather a simple commentary on my findings. I hope you’ll find it useful.

Some Background Information

In the interest of full disclosure (and to better understand where I’m coming from), let me briefly describe my background. I’m an independent consultant who’s been working in the SAP space for 13 years. During that time, I’ve bounced back-and-forth between ABAP-based solutions and Java-based solutions. When SAP introduced NetWeaver, I was very excited about the prospects of developing business applications using Java technology. Since that time, I’ve found myself more and more disillusioned about the Java-based solutions at SAP which, to be quite honest, paled in comparison to ABAP-based solutions. Indeed, it became hard to be a Java evangelist when customers started ranting about legitimate shortcomings with the AS Java and the products hosted on it (e.g. SAP NetWeaver Portal).

In more recent years, I’ve found myself doing some Java-based development outside of the SAP space using Amazon and Google’s cloud platforms. I was very impressed with these platforms and the functionality they provided.

So, when SAP first started talking about their own PaaS offering, I was both intrigued and skeptical at the same time. I certainly hoped for the best here but, as a relative late entrant into the PaaS landscape, I braced for the worst: a simple port of the AS Java into the cloud and little more. What I ended up finding is an open and well-designed solution that’s a breath of fresh air for Java developers working in and around SAP. If you’ve had a poor experience with SAP-based Java offerings before, I’d submit that you’d probably scarcely even recognize the SAP HCP. In the sections that follow, I’ll hit on some of the highlights of what I think SAP got right with the SAP HCP.

1) Openness

Perhaps the most welcome aspect of the SAP HCP to me is its openness. From its core APIs to the Eclipse-based development tools, you’ll find that SAP utilized open standards and technologies across the board. Gone are the proprietary deployment descriptors, painful NetWeaver Development Studio installations, and all of the SAP-specific nuances of Java-based application development. This also extends to software logistics as there’s no longer a dependency on the SAP NWDI and SAP-proprietary build tools. Now, customers can choose their preferred revision control system (e.g. Git), implement automated builds with Maven/Ant, and even move towards continuous integration with tools like Jenkins.

What this means for many organizations is that you can engage pre-existing or external Java resources for SAP HCP development and there really won’t be much of a learning curve. The technology is freely accessible, and using the SAP HCP SDK, a developer can begin dabbling in SAP HCP development on their local machine in a matter of minutes. This is not to mention the fact that developers can also create a free developer account on the cloud to try this out on a (mostly) real-world cloud environment.

2) Simplicity

As evidenced by the plethora of “Create an SAP HCP application in 5 minutes”-type tutorials here on the SAP SCN, the SAP HCP is a very easy platform to develop on. Using the Java EE 6 Web Profile, developers can jump right in and begin creating Web applications using classic Servlet/JSP/EJB/JPA technology in a matter of minutes. Or, if they prefer to develop using one of the infinite Web frameworks out there (e.g. Spring), they can drop those frameworks in and work from there. Deployment is streamlined using the Eclipse WTP, and the online account cockpit is very intuitive and easy to use.

The latter point is, in my mind, a huge advantage over other cloud platforms. For example, if you’ve ever tried to set up an Amazon EC2/AWS Elastic Beanstalk instance for Java development, you’ll note that there are many more steps required to set up the OS, provision resources, install application servers, and so on. With the SAP HCP, all of these tedious details are abstracted such that instance provisioning is almost turnkey.

3) Access to HANA and In-Memory Technology

In many respects, this is one of the key areas where SAP has set themselves apart from the competition. No other PaaS offering can really boast such tight integration with an in-memory database such as SAP HANA. The raw speed and power of HANA also goes a long way towards evening out application performance for companies that are on the fence about deploying applications to the cloud.

4) More than Just Another Java Platform

As a corollary to point #3, we should point out that SAP HCP does more than just provide JDBC-based access to SAP HANA. Developers have the capability to build applications from scratch using native HANA technologies just as they would develop such applications on-premise. This means that developers can tap into rich APIs such as the Predictive Analysis Library (PAL), quickly develop OData services for consumption from SAPUI5 applications (which can also be deployed on the SAP HCP), and more. Over time, the list of libraries and APIs will only continue to grow and expand.

5) Useful Services for Accessing Resources

Aside from the core application foundation, the SAP HCP provides a number of useful services which make it easy to implement persistence, store unstructured data, and even access services deployed on-premise. These services make what would normally be highly-complex development tasks remarkably easy in my opinion. For example, in the old days, the prospects of exposing an RFC/BAPI to an external Web application was a logistical (and political) nightmare. When I compare that experience with that of setting up the SAP HANA Cloud Connector and securely exposing an RFC function, it’s pretty remarkable how much easier things are with the SAP HCP.

As an added bonus, the instrumentation layer of these services is generally provided in the form of industry standard APIs. For example, Java developers can access the Persistence Service using either the JPA or JDBC API. To call a BAPI, you use the JCo API. This is yet another example of openness in the platform.

6) Integration with Mobile Technologies

Besides being a general-purpose PaaS, SAP HCP also does a good job of integrating with other related technologies such as the SAP Mobile Platform (SMP), Gateway, and so on. As these products continue to meld together, I envision the SAP HCP as becoming the glue that unifies cloud solutions with data that remains on-premise.

Conclusion

All in all, I think that the future for the SAP HCP could be pretty bright if SAP continues to follow through with their cloud strategy and begins developing commercial applications on the platform. SuccessFactors extension development is a good start, but there has to be more I think for customers to feel the incentive to adopt the platform on a widespread scale. At this point, all the tools are in place; customers just need to have a reason to jump on board.

As a developer who’s come to enjoy developing on the platform, I’m very hopeful that the platform takes off. If nothing else, the next several years should be interesting to say the least.

To report this post you need to login first.

16 Comments

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

    1. James Wood Post author

      Hi Tobias,

      So you know those times when you write one thing and mean to say something else? This is one of those times. I had meant to mention Elastic Beanstalk there, but suffered from a sudden onset case of brain flatulence. 😉 Thanks for pointing this out.

      In looking at the link you provided, it does seem that Amazon has simplified this offering quite a bit since I last played with it. I’ll have to run through another setup to see how things compare these days. In the early days, provisioning an Elastic Beanstalk instance was a pretty painful exercise IMO.

      Thanks,

      James

      (0) 
  1. Dobromir Zahariev

    Hello James,

    yes the technology level is well described here, but what you think about the prize?

    According you – should SAP need to consider small (cheaper) packages, or should continue to target only large enterprises?

    Best,

    Dobri

    (0) 
      1. James Wood Post author

        Agreed. The most tiers available, the more I think customers will be compelled to dip their toes in the water and launch HCP pilot projects, etc.

        (0) 
    1. James Wood Post author

      Hi Dobri,

      I don’t know that they necessarily have to target businesses of a particular size. In my mind, the SAP HCP is uniquely suited to delivering add-ons, xApps, etc. on top of the existing SAP Business Suite applications. For example, I think an add-on like EHSM would work great deployed on the HCP. SAP would obviously have to pick and choose their spots here, but I see the possibilities for sure.

      In the end, I think it comes down to identifying any strategy that will get customers to begin using HCP in productive ways. Technology-wise, I think the product is very solid and I feel that most customers will agree if they’re compelled to take the initial plunge. Short of that, I fear that HCP could follow in the footsteps of NetWeaver CE: a promising platform that nobody ever really used all that much.

      Thanks,

      James

      (0) 
      1. Tobias Hofmann

        I guess that with EHSM you mean Environmental Compliance. The rest are ABAP applications that need Business Suite.

        There are several use cases where HCP as an extension to EHSM (ABAP + Java solutions) makes sense, specially when you have external users, a varying number of users or peak usage

        (0) 
        1. James Wood Post author

          What I meant was that a product like EHSM could be developed on the HCP instead of positioned as an ERP add-on. MoC is another application that comes to mind in this space. I’m not saying SAP should refactor these applications by any means, I’m just saying that I’m hopeful that they’ll at least consider HCP as a platform for delivering applications like this going forward.

          The rub to all this I think is integration. Can they identify applications which have minimal (or even no) touch points with on-premise business suite applications? Or, can they package Gateway content in much the same way that they provide PI content to shorten the integration cycle and make on-premise integration less scary for customers?

          (0) 
            1. James Wood Post author

              In my mind, the dependency requirements for products like EHSM and MoC are pretty minimal. To a large degree, these are standalone products that (optionally in some cases) happen to consume data objects from HR, BP, and EAM. Since these products are already designed to consume such objects via proxies, I don’t think it’s such a huge jump to consider utilizing the cloud connector/Gateway to consume this data from an on-premise ERP system. Of course, I’m not advocating that SAP should re-imagine these products for use on the HCP; I’m merely using them as an example of the types of new dimension applications that could be built on the platform.

              (0) 
  2. Matthias Steiner

    Hi James,

    thanks for sharing! Your post really brought a smile to my face, because it reflects the goals of the team behind HCP. 🙂

    Seeing our vision validated by an outside voice is certainly a pleasant reminder that we are on track…

    Cheers,

    matthias

    (0) 
  3. Beata Ciepiel

    Hi James,

    Thank you for your review – it is very useful 🙂

    The SAP HCP is clearly very open to the standards. I wonder if you have any information about possiblities to develop applications in other languages than Java,.e.g. in Ruby, and still use all the services provided by SAP HCP in a straigth-forward way.

    Or it requires extra development?

    Best regards

    Beata

    (0) 
    1. James Wood Post author

      Hi Beata,

      Right now, there are three standard options for developing applications:

      • Java
      • Native HANA (and all that that implies)
      • HTML5/SAPUI5.

      As far as developing applications in other languages goes, I expect it’s possible to achieve this to a certain extent using some of the open source language implementations that sit on top of Java such as JRuby or Jython. The trick here is that you have to find cloud-friendly distributions of the language implementations that can be deployed without having to install anything on the application server host. For example, with Ruby, there is a gem called Warbler that packages your Ruby/Rails application into a WAR file. I’m not super familiar with Ruby, but I expect you could make this work with a little massaging.

      This, of course, leads into your second question: is it straightforward? My guess here is that it will be a little more work and you may have to think outside of the box a little bit when it comes to the consumption of services, etc.

      Hope this helps,

      James

      (0) 
    2. Tobias Hofmann

      There is a document available that contains a lot of information about HCP

      SAP HANA Cloud Platform – Content Overview

      Running other languages on top of HCP is not a problem (Java VM allows that). For jRuby:

      A problem can be the integration of the HCP services. As long as they are accessible via REST it should be doable.

      (0) 

Leave a Reply