I attended a session on SAP's mobile EAM solution (enterprise asset management) yesterday. In it they demonstrated how the mobile app integrated with SAP and extended SAP fields out to the mobile device. However, there was no SDK (software development kit) that would enable the user to customize the app for their specific requirements and projects. It is basically a generic hard coded solution that extends SAP EAM functionality to the field. There is value to that, but not transformational value.
I asked the SAP person if they used the SAP's mobile SDK to build the mobile EAM solution and they said no. This seems very odd to me. Shouldn't SAP's mobile SDK be robust enough to be used by SAP to develop their own mobile applications?
When I was the CEO of a mobile application's company a few years ago, we had a MEAP and an SDK robust enough to be used to deliver all of our own custom mobile applications. We then made that SDK available to our clients so they could use it in the future to edit and support their apps. That SDK was built to be used on top of Sybase's iAnywhere solutions. I don't understand why years later SAP/Sybase has not dramatically improved upon that model.
I am a strong advocate that companies should select a MEAP and IDE (integrated development environment) and use those to deliver as many of their mobile solutions as possible. That doesn't mean you need to develop them internally, it means you can develop internally, buy off-the-shelf or contract with third party mobile experts to develop solutions for you - just insist they use your selected MEAP and IDE.
Today it seems that even if you purchased all of SAP's mobile apps, you would get a plethora of applications developed in many different ways and with many different development tool kits, styles and manners. This is exactly what you want to avoid. How can you support that kind of collection long term? The TCO (total cost of ownership) would be high.
SUP can solve the MEAP issue if you can afford it, but there needs to be a standardized software development kit sufficient to support the majority of your mobile solutions, and that permits you to make edits and updates to your own solutions. Mobile apps should not be held hostage to service providers or ERP vendors.
Through my many years of enterprise mobility experience I have come to realize there are many, many projects in the field that would benefit from mobile solutions. Many of these projects are unique and their needs for unique data and mobile data collection require the ability to rapidly develop and deploy mobile solutions that may only be used for 6 months (the duration of the project). Robust mobile SDKs should be able to deliver that. Without a good mobile SDK you are again in bondage to a vendor, and your project based work suffers.
Kevin Benedict, Independent Mobile Industry Analyst, Consultant and SAP Mentor Volunteer
Follow me on Twitter @krbenedict
Join the SAP Enterprise Mobility and Sybase Unwired Platform Groups
Read The M2M News Monthly
Full Disclosure: I am an independent mobility analyst, consultant and blogger. I work with and have worked with many of the companies mentioned in my articles.
Hi Kevin,
ReplyDeleteInteresting insights. Could you elaborate on why the said person didn't use SAP's mobile SDK ? Are there any particular issues/challenges.
On a separate note - are there any good resources to compare the different MEAP's available ? (Sybase, Antenna etc.) in terms of usability, features, cost etc.
Thanks,
Rohan
Rohan,
DeleteSAP's Mobile SDK was used to create the data access and business logic components - just not the user interface layer. These were written as native iOS apps in XCode, to create a more compelling user interface than was capable with HTML5 at the time they were published.
-Paul-
For a technology company that wants to have competitive products, it is very important to eat their own dog food (when applicable).
ReplyDeleteGreat post, excellent questions. Frankly I'm seeing this across the board with enterprise systems. Mobile apps are coming out of the woodwork to extend ERP, CRM and every other corporate system.
ReplyDeleteUnfortunately what I'm seeing however is they are being looked at project by project and not as an overall corporate strategy. I understand why and in most cases it's due to a lack of overall mobility ownership within organizations. Rather than having an overall mobility strategy and applying that across the various organizations and systems, it's project by project. Owned by a person or group that knows their specific system (SAP, Oracle, MS, etc) versus someone that understands mobility in an enterprise.
There will continue to be a lot of mobile work, but more than that, a lot of mobile RE-work.
Cheers,
Brian
When SAP announced its acquisition of Sybase, it stated -- proudly -- that it would have frameworks for mobilizing SAP... in nine months. Plus, those frameworks would only work out-of-the-box with SAP (any other vendor's enterprise software would require custom programming for the frameworks to function). So, it's not surprising that a traditional enterprise firm with a traditional approach to development would be a little myopic about the alternatives.
ReplyDeleteWebalo and, to a lesser extent, Catavolt avoid all of that, as you know. Instead of nine months, Webalo users like University Hospitals Birmingham create mobile enterprise capabilities in less than nine hours. Those direct-to-enterprise connections are no less powerful and no less secure, but they offer on-demand fulfillment that, contrary to Brian Smith's perspective, is very characteristic of the mobility mindset -- east, flexible, and immediate.
Enterprise organizations will always want to understand and control their mobile capabilities. Security, asset management, device compatibility, app delivery, etc. will keep IT fidgeting for ages. Yet the alternative to SDKs and IDEs -- the direct connection to existing enterprise data and applications -- eliminates the time devoted to establishing requirements, developing and testing prototypes, ensuring cross-platform compatibility (in a BYOD world), maintaining and updating both the SDK/IDE and the apps it creates, and training.
As John Bedlek acknowledged after winning a Digie Award last year for Inland Group's mobile capabilities, he can create, deploy, and make multiple changes to an enterprise-to-mobile connection in the time it takes to hold a requirements meeting. That turns mobility from a time and labor intensive expense into a real time solution to employee needs for access. Without creating a new layer of applications, mobile connectivity becomes almost like a macro -- an easy way to encapsulate multiple actions into a single trigger -- that works from a smartphone or tablet instead of a desktop or laptop. In other words, same resources, same security protocols, just a different piece of hardware with an easier UI.
Kevin,
ReplyDeleteLet me clarify one point in this post... Specifically, this statement: "I asked the SAP person if they used the SAP's mobile SDK to build the mobile EAM solution and they said no."
The "Mobile SDK" of SUP really consists of two components: the first connects to the backend resource (SAP, DBMSs, SOAP/REST services, etc.) and generates the Object APIs for retrieving and updating data. For all the apps in the SAP Mobile catalog, this was the OData SDK.
The second component is the UI tooling that generates the cross-platform HTML5/JS/CSS code that runs inside the Hybrid Web Container.
So, only the UI layer of these mobile SAP apps were created "outside" of SUP using XCode and Objective-C. The Mobile SDK was used to create the connectivity layer to SAP on the backend through OData service.
Hope this helps,
-Paul Horan-
SAP Global Mobility SWAT team