Objective View of MEAPs

7,898 views

Published on

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.

Published in: Technology, Business
1 Comment
2 Likes
Statistics
Notes
  • Hello,

    Reading your slides, I just wanted to point that since April 2012, new MEAP vendors are now on the market. Most of the drawback that you are pointing in your document are solved by integrating standard HTML5, PhoneGap, JQuery technology in a robust back end enterprise class MEAP.

    MEAPs can be now on Open Source and cost much less than 'legacy' vendors. As these new platforms rely on JSON standards and integrate all Web based standard, programming learning curve is highly progressive..
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
7,898
On SlideShare
0
From Embeds
0
Number of Embeds
2,380
Actions
Shares
0
Downloads
230
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Objective View of MEAPs

  1. 1. An Objective View of MEAPsNeudesic Mobility Research 1
  2. 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. 3. Overview of MEAPs 3
  4. 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. 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. 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. 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. 8. Potential Issues with MEAPs 8
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18. An Alternative Approach 18
  19. 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. 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. 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. 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. 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. 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. 25. Conclusion 25
  26. 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. 27. Thank You Simon GuestDirector, Mobility Solutions Neudesic, LLCsimon.guest@neudesic.com @simonguest 27

×