Skip to Content

When I read Simon Kemp’s blog about Portal On Device, I was impressed. I was already planning to write a similar blog and what I found impressing is that I used to work with Simon on a portal project 10 years ago, now he lives on the other side of the globe (Simon in Australia, myself in the Netherlands) and still, we are busy with the exact same ideas. We can stay in touch thanks to the SAP Community. I find it impressive how this global community can keep similar minded people connected.

Now back to Portal On Device. I fully agree with what Simon wrote, I just would like to add to it. I will look at Portal On Device from the following aspects:


Technology trends: The output of Portal On Device is a web application, not a native app. This is something customers should keep in mind. Web apps are, generally speaking, slower and can make less use of the hardware capabilities of the devices. On the other hand, the computing power of mobile devices is growing, the adoption of HTML5 is increasing, the speed of internet access is rising, so the gap between web and native application is closing.

Implementation costs: The portal infrastructure can be reused, the business logic of the applications can be reused, only the front-end of the portal applications has to be redeveloped to optimize it for mobile devices. This is actually not a new product, just a new way of using an existing product. The fact that no extra hardware or license is needed, makes Portal On Device really attractive. When SAP or partner will offer content this equation will be even more positive.

Maintenance costs: It is running on the well-known NetWeaver Portal (maybe in combination with the also well-know load balancer or reverse proxy), which most SAP customers already have, so maintenance of Portal On Device doesn’t require a lot of extra effort for customers.

Requirements vs. features: There are multiple SAP (and non-SAP) technologies to enable mobility and Portal On Device is just one of them. It is crucial to understand the exact functional and non-functional requirements in order to decide if this technology is the right fit. E.g. Portal On Device, as of today, comes out-of-box primarily optimized for smart phones. We can hope that the version optimized for tablets is coming soon.

Performance: As mentioned above, a native app is generally faster, but good enough performance can be achieved with web technology too.

Mobility strategy: Portal On Device can be part of a mobility mix of a customer. SAP is working on combining it with Sybase Unwired Platform. Backend content can be consumed via NetWeaver Gateway. These are only examples for the many considerations to be made by customers, but one is the most important: many customers would like to get started with mobility without immediately investing in SUP.

Release plan: SAP NetWeaver 7.3 SPS5 is required, but SAP is working on the next SPS (scheduled for April), which will offer more functionality out-of-box. This makes Portal On Device even more promising.

To report this post you need to login first.


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

  1. Phil Gleadhill

    Hi Tamas,

    Good article, and good to hear from you again.

    Agree with your comments regarding use/requirement for SUP.

    SAP Gateway to my mind falls into a similar category as SUP.

    Leads to a very heavy mobile deployment.

    Cheers, Phil G.

    1. Tamas Szirtes

      Hi Phil,

      Thanks for your comment.

      There are so many options available to make an application mobile, the number of options is growing, the SAP strategy is evolving, etc. so customers are getting interested in light and pragmatic approaches.




Leave a Reply