Are MEAPs the answer to all our problems with mobile device development and deployment, or simply a recurring fallacy from what we saw in the mid-late 90's with cross-platform development for PC, Mac, Unix, and the Web? In this presentation I take an objective view on the category, highlight potential issues, and offer thoughts on an alternative approach.

1. An Objective View of MEAPs
Neudesic Mobility Research
1

2. Agenda
 Objective Overview of MEAPs (Mobile Enterprise Application Platforms)
 Where did the acronym come from, and who are the players?
 How do you define a MEAP?
 What problems are they trying to address?
 Potential issues with MEAPs
 Potential issues to watch out for when considering a MEAP
 Conclusion
 An alternative approach to MEAPs
2

3. Overview of MEAPs
3

4. Where did the Acronym come from?
 MEAP (Mobile Enterprise Application Platform)
 Acronym coined by Gartner in 2008 Magic Quadrant report
 MEAP Definition
 Comprehensive suite of products and services that enable development of
mobile applications
 Typically comprising of a mobile middleware server and a mobile client
application
 Mobile clients can be native applications or HTML-based, depending on the
vendor offering
4

5. Who is Playing in this Space?
 MEAP Vendors
 As listed in Gartner’s 2011 MEAP Magic Quadrant
 Antenna, IBM (Worklight), Kony, Pyxis, RhoMobile, Sybase, Syclo
 Not mentioned, but same category
 Red Foundry, Appcelerator
 Neudesic Experience
 Red Foundry, RhoMobile, Pyxis (analysis or previous use with customers)
5

6. What are MEAPs Trying to Solve?
 Write once, run on virtually any device
 Write application in single language and re-compile for native platform
 Take advantage of device hardware
 Provide abstraction layer to take advantage of the device hardware
 Integrate with different data sources
 Set of adapters for XML, databases, Web services, SAP, Siebel, etc.
 Deployment of application
 Hosting of application, manage updates, and analyze usage
 Management of devices
 Asset management for devices, and restrictions for trusted devices
6

7. Haven’t we been here before?
 The History of Cross Platform Development
 Late 90’s provided for multiple cross platform solutions
 http://en.wikipedia.org/wiki/List_of_rapid_application_development_tools
 Embarcadero/Delphi, Smartface, Panther, FoxPro, VisualWorks, XPower
 All had many of the promises of MEAPs
7

8. Potential Issues with MEAPs
8

9. Language Abstraction
 Be wary of MEAPs that offer a language
abstraction
 New language for developers to learn
 Even if “based on Java/JavaScript” it will
still introduce new libraries unfamiliar to
developers
 Developers generally shy away from this
approach
 Example: Force.com / APEX
9

10. Language Limitations
 Understand the limitations imposed by
abstracting multiple languages
 Abstracting multiple languages to a
single language will always reduce in a
LCD (Lowest Common Denominator)
 Methods and properties will become LCD
artifacts
 Especially true in “v1.0” MEAPs where all
of the controls are not covered
 Example: Red Border Example with a
popular MEAP
10

11. Platform Limitations
 Understand what platform limitations
might arise when using a MEAP
 What happens if things change
underneath?
 New devices?
 New OS upgrade?
 New version of the SDK?
 Often have to wait for the MEAP vendor to
catch up in order to use these features
 Example: Bluetooth 4 profile in iOS 5.1
11

12. UI Abstraction
 Does the MEAP vendor force you into
abstracting UI controls and components?
 Often stuck with cookie cutter themes
supplied by the MEAP vendor
 Demo well, but can be difficult to
change
 What happens when one platform
supports a UI nuance that the others
don’t?
 Example: Page curl transition.
 Not supported on any platform
(degrades application)
 Supported only on one platform
(breaks promise of MEAP)
 Hacked solution on all platform (poor
experience)
12

13. Tooling
 Does the MEAP vendor provide the tooling
support to meet your developers needs?
 Often web browser based, something new
or Eclipse Add in
 Looks great in a demo, but often tooling
doesn’t support existing lifecycle
 SCC?
 Unit Testing?
 Refactoring?
 Aimed towards business analysts?
 Tried and failed
 Business analysts should not be
designing UI
 Business analysts should not be
writing code
13

14. Data Abstraction
 Are the data abstraction components
supplied by the MEAP vendors the right
ones?
 Offer integration adapters for XML, DBs,
SAP, Siebel, and more
 You often pay more for the “enterprise-
class” adapters
 Really going to be optimized for your
application?
 Synchronization?
 JSON/REST formatted?
 Subsets of data based on query?
 Can result in poor performance
14

15. Debugging
 What happens when things go wrong with
your MEAP application?
 The application crashes 1 time in 10 – or
one of those difficult to fix bugs?
 Apple/Google going to help?
 Ask other developers on forums?
 Pay MEAP vendor to look into the
problem, to hopefully diagnose and
debug the issue for you
 What happens in you deploy your
application to the AppStore and it gets
rejected?
 Only the MEAP vendor can help you
resolve the issue
 Don’t underestimate the importance of
developer support in the community
15

16. Difficult to Extend
 Does the MEAP enable you to easily
extend applications with non-MEAP code?
 Found a new JavaScript library
 Or a native control/component that’s
really going to help your application
 Is this supported?
 Wait until the MEAP vendor supports
it?
 Use a bridge to native code?
 What happens if you acquire a mobile
application from another department or
company?
 Is this going to use the same MEAP?
16

17. Vendor Lock In
 MEAPs Potentially Lock In You and Your Developers
 Language, Platform, and Tooling is no longer in your control, and often miss
out on language and device specific features
 Developers locked into the MEAP platform using reduced toolset
 MEAPs Can Be Expensive
 Initial platform costs
 “Value Add” costs for additional controls and adapters
 Service and support costs when things need changing
 MEAP Hosting Models May Not Flexible
 Often don’t offer on premise and cloud based offering
 You “give” your application to them to be hosted
17

18. An Alternative Approach
18

19. Reviewing the Potential
 Write once, run on virtually any device
 Write application in single language and re-compile for native platform
 Take advantage of device hardware
 Provide abstraction layer to take advantage of the device hardware
 Integrate with different data sources
 Set of adapters for XML, databases, Web services, SAP, Siebel, etc.
 Deployment of application
 Hosting of application, manage updates, and analyze usage
 Management of devices
 Asset management for devices, and restrictions for trusted devices
19

20. Write Once, Run on Virtually Any Device
 Using HTML5 to achieve cross platform
application development
 WebKit (Safari/Chrome) offer very good
support for HTML5 constructs
 GeoLocation, Local storage, and Offline
supported with no add-ins
 UI Frameworks (such as jQuery Mobile)
can be used to emulate native controls in
HTML
 <native=“true”> attribute can be used to
interact with more native controls
 Multi-headed MVC model allows code to
be shared between mobile and desktop
applications
 Quick developer adoption (especially
those with previous background in HTML,
CSS, and jQuery)
20

21. Take Advantage of Device Hardware
 Using PhoneGap/Apache Cordova to
bridge Mobile Web and Native
functionality
 Open source (Apache MIT license)
framework to bridge Mobile Web and
Native applications
 Supports contacts, camera,
accelerometer, file system, and push
notifications
 Plug in model for additional native
support if required
 Acquired by Adobe, donated to Apache
Software Foundation (Cordova)
21

22. Integrate with Different Data Sources
 Moving to REST/JSON middle out
approach
 Unless exception case, standardize on
REST/JSON/HTTP(S) for all mobile
communications
 Standard and lightweight, and well
supported by mobile SDKs and/or
jQuery/XHR
 Widely supported by server, cloud
platforms, and server-side products
 Two important patterns: Synchronization
(to support offline) and Asynchronous
(e.g. lists in native application)
22

23. Deployment of Application
 Considering best deployment approach
for each application
 HTML5 applications require no
deployment
 Many BI shell applications are updated
via public AppStore and content comes
from internal URL (e.g. RoamBI)
 Native enterprise applications can often
be deployed via simple method (shared
APK or IPA file on file share)
 Solutions for mobile development and
testing in the enterprise (TestFlight)
 If need more, consider dedicated MDM
solution
23

24. Management of Devices
 Tap in to the pool of multiple vendors
offering MDM functionality
 Very active space with a handful of select
vendors (MobileIron, Afaria, Zenprise)
 Most focus on asset management,
application deployment and
management, and application security
 Matter of time before large vendors start
offering products (Microsoft, HP, IBM
Tivoli)
 Key focus is BYOD vs. managed devices,
especially sandboxing
24

25. Conclusion
25

26. Conclusion
 MEAPs are early in the hype cycle, offering to quickly solve five key problems
with mobile application development
 While the problems hold true, be very wary of vendor lock in and taking your
organization down a path with limited future options
 Consider alternatives, including HTML5 and Hybrid model for development,
while solving deployment and management with dedicated products
26

27. Thank You
Simon Guest
Director, Mobility Solutions
Neudesic, LLC
simon.guest@neudesic.com
@simonguest
27