On demand is the “next big thing”: every product, every solution has to be available as an on premise and an on demand version. Simplified, on demand means that you can access your solution via the internet, from everywhere you are. For a normal user there is no difference in how to access a new on demand solution and how Google Mail is accessed and used: enter the URL in the browser and start using it. For some solutions on demand is more a cultural shock than for others. Basically the main benefits for on demand are access, costs and maintenance.
SAP Portal users are familiar with web enabled access. Most of the time they are bound to the corporate network; sometimes they can access the services from outside the corporate network, by VPN or even by a “normal” URL. So where are the benefits of an on demand portal (ODP)? Configure your infrastructure right and you can have an on demand version.
The tricky part is the “your infrastructure”. Not every company does know how to do it right or even has the skills to do so in a secure way. The technology stack needed to run the SAP Portal is NetWeaver Java. There are stacks out there that are easier to maintain and that need fewer resources to run. You need a full J2EE stack for you application? Most portal applications only need a servlets container (like tomcat). The framework and standard UI of the SAP Portal are too heavy for Internet usage. Even with the External Facing Portal (EFP) framework, light weighted is defined differently. Licenses for the SAP Portal are cheap when your users are Business Suite users; costs like bandwidth and maintenance remain.
But still: problems that can be solved, so why an on demand portal?
Maintenance is where Basis surely will be reliefed as the task for applying service packs and notes will be delegated and end-users will be happy too as a good on demand solution offers a higher availability than the infrastructure of a normal company can. Setup time and costs are inexistent compared to the on premise portal.
The ODP will be – naturally – an external facing portal (EFP). Considering the problems the on premise portal has when it comes to make it an EFP in regards to:
- Browser support
- Mobile support
- Security
- Speed
- Access
How will the ODP treat and solve these problems? And when you are an EP user, what kind of options will you get to use the ODP as your EFP? And will the ODP be the starting of the end of the EFP of the SAP Portal?
Looks like SAP is going to use the on demand portal to introduce a new stack to run the portal on. Open source based, OSGI support, something more like tomcat. The connectivity won’t be able to compete with what the SAP Portal offers, but as long as your backend exposes the data using HTTP/S it can be integrated; implying that you still have to be able to expose your backend data in a secure manner. If you know how to do that you can still opt for opening your corporate SAP Portal. But you won’t get the new SAP UI5. And that new interface alone justifies the on demand portal. Compared to the “old” SAP UI, UI5 was designed to be used over the internet in mind.
What do I expect from ODP?
A new software stack, cleaner, easier, more open source and support of more and newer standards. The new SAP UI5. If everything works out well SAP will be forced to merge the two code lines of on demand and on premise portal. Refreshing the “real” SAP Portal too. What can be wrong about that? Mobile access is crucial. Of what help is a portal accessible from everywhere and you need a desktop browser? This should also drive the adoption of mobile access to SAP and thePortal on device for the on premise SAP Portal.
As ODP gives us a revitalized portal running on new technology it should attract more developers. Done right developers have the freedom to choose how and with what they want to code: GWT, jRuby, PHP for Java, JSF, Java 5, 6 or 7, etc.
How will the access to information handled? A portal with portlets is just the visible interface to the user, but what about portal services? Everyone that already had to integrate the on premise portal – or the information stored and made accessible there – into another portal or product know that the SAP Portal is meant to be the last point of access. The SAP Portal’s primary design is to integrate content, but not to share it. Specially an ODP cannot be designed that way. As it is available 24/7 to everybody, so has to be the information. Will ODP come with a predefined architecture for accessing portal services and data? A possible way can be XSLT: content templates in XSLT can use portal services and classes to create the content. That way, all the information that is going to be displayed has to be available as either a service or a consumable Java class. And who says that you need a browser to access a portal? With desktop applications or open social the ODP can be integrated to serve the user in an inovative way.
One problem remains: Developers. SAP has shown us more than once that this is a topic where SAP continues to deliver below the expectations. Currently, developing for and learning SAP on your own private environment comes with some constrains: downloading, installing, renewing the license every 90 days, and you cannot create your environment as you wish, you have to use what SAP gives you. (ex: CE 7.2). Not everybody can download several GB of data and install it; the hardware requirements are even today still a challenge for laptops – not everybody has more than 2 GB memory installed. Contrary to this, tomcat is downloaded and running in minutes. No wonder that tomcat is a popular servlets container.
For the developer ODP is portlet development (WAR). It will be interesting to see if portlets developed for ODP also run on a native tomcat or on JBoss or on other competing products or what the effort is to make them compatible.
It lies in the nature of on-demand that access to the software isn’t a real problem anymore. The question is: will developers get free and no time limited access to ODP? To evaluate, learn and code the access does not need to be unlimited in all aspects: 1 or 2 users, limited bandwidth, CPU and memory usage, performance also does not count much, data base can be SAPDB. What counts is: give access to developers, from the very beginning.
