Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Objective View of MEAPs

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.

  • Identifiez-vous pour voir les commentaires

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

×