Thoughts on the current debate about the Sybase Unwired Platform and options to energize the mobile development community
An important caveat: I’m definitely not a Sybase Unwired Platform (SUP) developer and I’m still trying to fully understand the SUP architecture. This blog may contain more questions than answers but I’m hopeful that my explorations move the dialog further.
There will always be a love-hate relationship between enterprise software vendors and the developers who use their products. There are conflicting interests involved and heated debates often ensue. The relationship between SAP and its ecosystem is no exception. Although the relationship between SAP and its developers is quite good and many developers are quite passionate in their support of the company, there are often disagreements between the two – especially regarding licenses and the prices associated with new technologies. SAP wants to monetize its investments in new technology and developers are interested in getting their hands on this technology with as few hurdles as possible.
Recently, there has been resurgence of the well-known arguments concerning Gateway and SUP. Here are some examples:
Fellow SAP Mentor Graham Robinson examines the problem from the perspective as an ISV in a recent Thoughts on NetWeaver Gateway:
So back to my killer app. Why should I take the funds my customer has committed to my app and pass some of them onto SAP? Even assuming I could get a straight answer from SAP on what the price would be – why should I do it unless the benefits outweigh the costs? How can a recurring pricing model on a piece of technology be weighed up against the value of saving me development time on a project I already have approval for? And why should I just let dollars go to SAP for my idea? And by the way my customers’ employees (the target audience for my killer app) are already licensed to use SAP anyway. Why should they pay again? (I have a few other objections as well but you get the idea.)
Returning briefly to the Sublime Unwired Platform – how do I justify the cost (albeit unqualified) of this platform against the benefits of my single, albeit killer, app? I can’t. And even if I could why would I confuse my customer with extra technology and extra licensing when I don’t need to? I wouldn’t.
Fellow SAP Mentor Jarret Pazahanick also Is SAP Using the Right Mobility Strategy a useful analysis of the situation and provides a few suggestions on how to deal with the problem.
No one doubts that the Sybase Unwired Platform comes with a slew of benefits and functionality but I think SAP should consider using the razor and blade business model in which they provide the underlying mobility technology/platform for a small incremental cost ….
Blogger Frank Scavo summarizes the arguments in a well-received blog.
Many of these customers would love to stick with SAP for mobile applications, which by most accounts will become the primary way that business users connect with business applications. If the SUP is low or no cost for the majority of customers, it will encourage thousands of developers, such as Graham, to embrace it, and tens of thousands of customers to make it part of their applications infrastructure. The same economics apply to the Netweaver Gateway. If SAP really wants to lock-in its customers, it should offer these platforms to the majority of its customers at low or no charge. This will liberate business value to SAP’s installed base, ensuring SAP’s relevance for years to come.
Many of these arguments suggest that charging for SUP and Gateway are counter productive to SAP’s interests to expand the mobile developer ecosystem.
Note: There are various other blogs (for example from Dennis Howlett) that also look at the issue from other perspectives (app store, etc).
If you look at the majority of discussions about SUP, you often see SUP being described in very general terms:
- No one doubts that the Sybase Unwired Platform comes with a slew of benefits and functionality but I think SAP should consider using the razor and blade business model in which they provide the underlying mobility technology/platform for a small incremental cost and get their money/benefits …. [Is SAP Using the Right Mobility Strategy]
- If the SUP is low or no cost for the majority of customers, it will encourage thousands of developers, such as Graham, to embrace it, and tens of thousands of customers to make it part of their applications infrastructure. The same economics apply to the Netweaver Gateway. [SOURCE]
This generalization bothered me. SAP was also guilty of this generalization as well – individual components of SUP are often ignored / blurred in marketing material.
Based on my limited knowledge of the product ( I knew that the SUP architecture is relatively complex), I started asking myself: “What exactly do these developers / bloggers want and does SAP have the ability to even meet these demands based on SUP’s technical architecture?” The easy out is to say “We want everything” but this isn’t realistic and limits the ability of SAP to meet the demands of these developers in a manner that is acceptable for all involved.
The impact of the SUP architecture on developer demands
A big caveat: Once again, I’m definitely not a Sybase / SUP expert. I’m basing my analysis on my readings of the material. In other words, my assumptions may be incorrect which would bring the whole edifice crashing down but I’m optimistic that others could build useful blogs/analysis on the remaining foundation / fragments.
If you look at the SUP architecture you will see that it is more complex than just a development environment, it also includes a server component – the Unwired Platform.
Reflecting on SUP’s complete architecture with all those moving parts, I thought: What exactly are these individuals demanding that SUP be free referring to? Are they just referring to the Eclipse-based development environment? Are they referring to the whole thing – server and all? If you look at the SUP Development Paradigm, you will see that the Eclipse-based environment is closely coupled with the Unwired Server.
Here is a different description of Mobile Business Object (MBO) development from the same document [Emphasis is mine]:
- Connect to back-end data sources.
- Connect to Sybase Unwired Server.
- Create mobile application projects.
- Create MBO attributes and “create, update and delete” (CUD) operations.
- Attach MBOs to back-end data sources.
- Edit, rename, delete, move, copy, group and view MBOs.
- Perform additional MBO design activities — create logical roles, search, and so on.
- Deploy MBOs to Sybase Unwired Server.
Based on this tight coupling, it really doesn’t make sense for developers to just have the Eclipse-based environment. This dependence is associated with Web container-based development as well as native application development. Providing SUP to developers for free would mean providing much more than just a development environment.
It is also critical to remember that SUP is not only a development platform – it is a runtime environment as well. The applications created by the SUP development environment usually require the Unwired Platform server to function correctly. For example, an examination of existing Sybase applications on the Apple Store shows this dependence: “Sybase Mobile Sales & Workflow” – “To connect to SAP systems, the client requires use of the Sybase Unwired Platform server and a client access license.” Or another application “Sybase Mobile Workflow” which states “A connection to a Sybase Unwired Platform server is required.” Thus, I assume that customers require Sybase Unwired Platform server to run many applications developed with SUP. If a partner has 20 customers for a mobile application, then if SUP was free for all, that would be an expensive proposition. Of course, another alternative would be to provide SUP free to developers but customers would have to buy licenses.
Note: I have no idea if this association is still necessary when using Gateway-based applications in SUP 2.1 or whether direct access to Gateway without using the Unwired Server is a valid option.
I assume that it would be possible to develop mobile applications on the SUP environment that don’t use the functionality of the Unwired Platform server but there are other mobile development platforms (such as PhoneGap) which are often more lightweight and simpler to use. If you look at the YouTube videos put out by the SUPDeveloperProgram, they all understandably focus on using the functions provided by the Unwired Server (MBOs, etc).
I’m not saying that Sybase / SAP couldn’t or shouldn’t give away the entire SUP platform (Eclipse-Dev environment + Sybase Unwired Platform server component) to jump-start SUP-based development in the partner and/or SI community – just that it is more complicated than providing a few Eclipse plug-ins.
A rhetorical and perhaps heretical question might come in response: “Based on this architectural complexity, is SUP the ideal platform to develop mobile applications that access SAP data”. The current marketing push from SAP on mobile apps is motivated by the desire to acquire additional revenue via Sybase products (SUP, Afaria, etc) as well to allow customers to increase their ROI by exposing more data from back-end SAP systems to a larger audience (either internal or external). The complexity of the SUP architecture assumes a certain level of mobile application complexity to allow customers to recoup their investment – the SUP Runtime architecture doesn’t come for free – in terms of hardware, administration, etc.
The demand that SAP provide SUP free of charge to developers isn’t going solve all problems associated with the necessity of developing mobile applications. It is based on the assumption that SUP is THE tool for all use cases involving mobile access to SAP data. I’m not saying that there aren’t use cases where SUP is the perfect tool – I’m just saying that it isn’t the perfect tool for every use case. SAP and Sybase understandably focus on SUP as THE development platform for mobile. You want zillions of developers developing mobile apps that use SAP data not zillions of developers using SUP to create these mobile applications. To meet this goal, what other development options – besides giving SUP to everybody for free – should be actively promoted?
Option 1: Apache Callback / PhoneGap and other mobile development platforms
As Dennis Howlett suggests, there is a new breed of mobile applications that is emerging and which is based on a development paradigm quite different from that of traditional enterprise software.
However, such models cannot hope to cover all eventualities or for that matter the whole of the market. We can envisage thousands of situational, ad hoc, even one-off applications where the need for fast tracking is paramount or where value comes from volume usage. This is already happening in the Salesforce.com universe where cloud brokers like Appirio are working on a 4-6 week develop/release cadence for proof-of-concept to initial deployments. Having ready access (which has to include easy, clean, cheap licensing) is the only model framework that will encourage those types of developer shop to flesh out the 80% SAP claims it wants to see from its ecosystem. [SOURCE]
Can you meet this new paradigm with SUP? Sybase / SAP will of course, say ‘Sure’. But there will be some mobile applications that are very lightweight and which don’t require the developmental baggage / costs associated with the SUP.
My suggestion to SAP is to select a few other mobile development platforms and actively support them for developers to use to access SAP data. The important word here is “actively”. I’d like to see SAP admit that there are some use cases where SUP isn’t the best choice – based on price or other reasons. Instead of angering developers by restricting their focus to SUP, SAP should proactively embrace a larger audience of developers – many of whom have experience with applications in the consumer market rather than enterprise software.
Let’s concretize this suggestion by looking at the possibilities provided by Apache Callback (which was formerly PhoneGap) and which is a new project in the Apache Incubator. The project has the following goal:
Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. [SOURCE]
What is the relationship of PhoneGap to other mobile development frameworks? “Although PhoneGap gives you a convenient way to bundle a web app as a native app, and hooks into the devices native APIs, you are totally on your own with respect to what web-app framework you use, if any”. [SOURCE] So, a developer may combine Apache Callback and JQuery Mobile, for example.
This approach has already been used by Bluefin Solutions to build a Mobile Timesheet Application that accesses the ERP system via RESTful web services. John Moy also used this technology to Extend your SAP jQuery Mobile web app with HTML5 concepts and Native device features – Part 1 without Gateway, SUP, etc. Thus, this approach is not unknown in the SAP ecosystem.
What exactly am I suggesting then? I expect SAP and the greater ecosystem to work together to define the use cases that fit this new development model. Instead of ignoring this approach, SAP should embrace it and promote it as an accepted option for developers. Even more useful would be to actively work with the Apache Callback project and contribute extensions (for example, Project Phoenix ??, or tools that better support oData processing, etc) that might make life easier for developers using these lightweight development platforms accessing SAP systems. If you look at the original list of contributors to the proposal, you will see that the majority are from Adobe/Nitobi and IBM. They obviously see value in contributing. Hint – hint.
By the way, PhoneGap is currently being downloaded 60,000 times / month [SOURCE]! It is available free of charge. Compare that to the Hey Web Developers! SAP’s Sybase Unwired Platform Wants YOU that often surround SUP (finding it, downloading it, etc) and you have two very approaches to interacting with the mobile developer community.
Option 2: Let’s add some PaaS
SAP is currently developing a Java PaaS that will be going into private beta in Q4 2011. This platform adds a variety of new opportunities for SAP to involve mobile developers in new and innovative ways.
Here is a diagram depicting three possibilities:
- A developer / partner can also create applications with Java, Ruby or Spring that have REST APIs which jQuery Mobile-based clients could easily use to access data from back-ends (either from Gateway or other sources)
- In one description of NetWeaver OnDemand, I found the following curious reference “Over time, SAP wants to make it very easy to do other critical tasks on NetWeaver OnDemand, such as build and integrate mobile applications. Technologies from the Sybase Unwired Platform will be built into NetWeaver OnDemand” [SOURCE]. So I assume that parts of the SUP will move to the jPaas. What exactly will be moved – MBOs? – isn’t described in more detail. I imagine that some version of the SUP Eclipse-based client might be provided that could exploit this functionality in the jPaaS.
In comparison to the first option, this option could be used for mobile use cases that are more complicated – perhaps based on back-end-related requirements (BigData, more performance, etc).
Since we are on the topic of SaaS, I suggest that SAP should take a closer look at BuildGap an OnDemand compiler for mobile apps:
I love the idea and would like to see something similar in the jPaaS as well as a link to the upcoming SAP Mobile App Store included.
Option 3: Sybase’s Managed Mobility Program
As I was researching this blog -especially after I discovered BuildGap – I was surprised that SAP hadn’t put SUP in the Cloud and offered it as a SaaS. I was even more confused when I started seeing quotes about SUP’s ability to support multi-tenancy.
Sybase Unwired Platform 1.5.3 introduced support for multi-tenancy. This functionality enables a hosted cluster of Sybase Unwired Platform servers to service multiple customers from the same cluster. To keep different customers’ applications, data, and administration separate, we introduce the concept of domain [SOURCE]
At the same time, he emphasized that there remains plenty of opportunity for mobile ISVs to customize or build mobile SAP apps that target a specific industry or region.
Moreover, Sybase won’t build apps targeting smaller customers. That leaves room for partners to set up SUP as a multi-tenant Web-based service that hosts multiple apps for different customers with say 20-30 users each, [Jagdish Bansiya, CTO for enterprise mobility at Sybase] said. [SOURCE]
I thought a hosted SUP solution would be the perfect answer for use cases (perhaps for smaller companies) where the full functionality of SUP was required but the customer was unwilling or unable to support the necessary SUP-related infrastructure.
I then found a SAP press release that described a new Capgemini offering based on Sybase’ Managed Mobility technology: Capgemini will host mobile solutions powered by industry-leading Sybase® Managed Mobility technologies and offer them on a software-as-a-service (SaaS) and platform-as-a-service (PaaS) basis.
The first thing I wanted to understand was the Managed Mobility technology. Here was the “eye-catcher” on the Sybase site:
But many enterprises – even large Fortune 500 companies – simply do not have the resources to support mobile services, and the current global economy is forcing them to make hard decisions on which IT projects get the green light. With limited budgets and growing mobility business needs, many of these companies are striking the right balance with a different model: mobility as a service.
This was technology that wasn’t for customers/end-users but rather for partners / SIs. There is a impressive list of partners who offer this service: Orange Business Services, VeliQ, Verizon, Vodafone, etc. What is very interesting about this offering is that SAP or Sybase never moved into this area themselves. With the importance of “mobile” in SAP’s global strategy and the obvious link to the OnDemand world, it would appear to be a smart move.
A deeper analysis of Capgemini’s offer (thanks to Capgemini’s social media team for providing me additional material after my plea for more details on twitter) provided me a better insight into the potential of the Managed Mobility technology. The close link with particular mobility scenarios in the form of application suites in Capgemini’s offer is an excellent idea – the combination of SUP-based hosting and provision of already developed mobile applications gives customers a one-stop shop that gets them up and running quickly.
Although this option focuses more on the requirements associated with the SUP infrastructure, I’ve included it in this list, because it is a viable alternative that developers should consider when proposing mobile solutions to their customers. The idea would be that a developer creates an application using SUP and then instead of having customers host the application; it is hosted by one of the managed mobility partners or perhaps by the ISV itself. This is similar to the idea behind What is the relationship between Sybase’s ‘SQL Anywhere OnDemand Edition’ and SAP’s other OnDemand offerings?. This might be prove an initial entry point for customers with just a few SUP-based applications and reluctant to have pay for the whole SUP infrastructure with such a small number of mobile applications. Thus, developers who are interested in providing a low-cost mobile solution would be able to share the infrastructure-related costs among a number of customers rather than having a single customer bear the cost of the entire infrastructure.
There are other aspects of this story (for example, a SAP Mobile App store) that must also be considered if SAP is going to be successful in this area but I’ve concentrated in this blog on the development platform. A developer’s decision to use a particular development platform is nuanced. There are always various options that are available. Regarding mobile development, this reality has to be accepted by SAP as well as its ecosystem. Indeed, acceptance isn’t enough – there must an active promotion of this variety in order to be able to meet SAP’s goal of broadening its mobile development ecosystem.