Objective View of MEAPs

An Objective View of MEAPs
Neudesic Mobility Research

1

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

Overview of MEAPs

3

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

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

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

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

Potential Issues with MEAPs

8

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

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

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

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

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

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

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

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

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

An Alternative Approach

18

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

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

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

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

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

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

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

Thank You
Simon Guest
Director, Mobility Solutions
Neudesic, LLC

simon.guest@neudesic.com
@simonguest
27

Objective View of MEAPs

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Objective View of MEAPs (20)

More from Simon Guest (9)

Recently uploaded (20)

Objective View of MEAPs