As many of you know, last week SAP delivered some new announcements around HANA and mobility.
From a mobility perspective, one of the major announcements (the other being the intended acquisition of Syclo) centred on new partnerships with mobile framework providers Adobe (for PhoneGap), Sencha and Appcelerator. If you haven’t seen the press conference, you can find a recording on YouTube here (kudos to SAP for making it available in high definition – watching it on my home TV made me feel like I was virtually there).
Developer Ecosystems
It was refreshing to see SAP recognize the need to capture the interest of mobile developers. Lets be clear, there is a real need to do this because mobile developers out there have a multitude of choice when it comes to mobile ecosystems to develop for. By embracing open mobile frameworks such as Adobe PhoneGap, Sencha and Appcelerator, battle lines are being drawn to capture the hearts and minds of millions of mobile developers to develop for the SAP ecosystem. Of course, I was thrilled by this news, especially as I am a fan of PhoneGap in particular (as those who have read my blog about it a year ago can attest). One point of interest to me was the absence of any mention of the jQueryMobile open source mobile framework, which was already embedded into the SUP hybrid web container last year and announced with less fan fair by Sybase.
In the developer ecosystem there certainly still are challenges, including some highlighted in the Q&A towards the end of the press release, dealing with such matters as developer licensing, access to software for developers, and ability to easily publish and monetize apps in app stores. There is no need to discuss these issues in depth for this blog, as many others have done so already … SAP Mentor Vijay Vijayasankar writes a good blog on the challenges for developers here, as does Dennis Howlett here.
The Plumbing Problem
Interestingly, developer community challenges aside, I can’t help but draw parallels to the situation SAP was in over a decade ago with the Java community. I recall back then a strategy to leverage the worldwide Java community (which outnumbered their ABAP counterparts by a significant magnitude) and use this community to drive the user interface layer for SAP. Sound familiar? Things didn’t quite eventuate to the intended vision of those times. Many of the reasons why Java didn’t take root as strongly as hoped have no relationship to our current times – for instance, SAP’s focus on a proprietary UI framework in WebDynpro Java had the effect of immediately turning away a proportion of Java purists (right now SAP is looking to embrace open mobile frameworks, so the situation is much better). But there was another reason why Java adoption didn’t take root so quickly with SAP enterprise customers … simply because it took time (in some cases years) to convince customers to purchase and adopt an SAP Java platform (eg. SAP Portal) which was a pre-requisite for coding in the preferred SAP UI framework of that era, being WebDynpro Java.
This is where I roll the clock to today, and think about the parallels. Using SAP’s mobile architecture, a common pattern for online apps is to utilise the SAP mobile platform in combination with SAP NetWeaver Gateway. With this pattern the SAP mobile platform provides services such as device registration and connectivity, whilst SAP NetWeaver Gateway exposes the core business logic and data from the business suite necessary to service the mobile application. The simplified diagram below illustrates this architecture (this is not the only possible architecture, but it is a common one when looking at SAP’s own online mobile apps) …
Note: ‘SAP Mobile Platform’ includes Sybase Unwired Platform, Sybase 365 … (and possibly others?)
This presents potentially two platforms which customers need to embrace before they might mobile enable their business suite functions.
In my mind the SAP mobile platform challenge is mitigated when it is offered as a PaaS as I described in an earlier blog. And as an aside, the constant evolution of this mobile platform reaffirms my belief that the mobile platform should be in the cloud so customers need not concern themselves with rapid evolutionary changes (ie. upgrades) to an on-premise version of this mobile platform.
But this does not solve the conundrum with SAP NetWeaver Gateway which typically needs to be on-premise. SAP NetWeaver Gateway provides a bridge for mobile apps to interact with SAP data and resources using oData REST services. And make no mistake, this is the software product that is doing much of the heavy lifting with SAP’s most recent mobile apps - just look at the table in my blog from January this year. For a large scale SAP mobile ecosystem to succeed, I see SAP NetWeaver Gateway as a critical component because it provides a consistent approach across all customers to achieve lightweight REST-like integration into on-premise SAP systems.
Importantly, you might have noticed in the press release about embracing the open source platforms that Sencha (for instance) had “newly delivered support for the oData protocol”. Read that as meaning “you can integrate your Sencha app to your SAP systems as long as you have SAP NetWeaver Gateway”.
So therein lies the challenge. Now that SAP is in the process of enabling hundreds of thousands or even millions of potential developers to develop for the “170,000 customers of SAP” (as quoted from the press conference), we have to ask an important question. How many of these SAP customers have access to a SAP mobile platform? How many of these SAP customers will have SAP NetWeaver Gateway installed in the near-term? How can SAP entice customers to license SAP NetWeaver Gateway and implement it in their environments quickly? For sure, the adoption rates will need to be fast. Otherwise our millions of newly embraced long haired developers may find themselves with no SAP customers to connect to.
- SAP Managed Tags:
17 Comments
