Recalling many technology waves in the past, having a large number of tools, platforms and environments is predictable by nature. The Mobile technology wave is no different. The amount of work just sifting through the available tools to use can be overwhelming. There are several ways to build a mobile solution: Native, Native Cross-Platform, HTML/Native Bridged and Responsive Web App. So what technologies do Mobile Enterprise Application Platforms (MEAP) use? All of them.
A little disclaimer here. I have never used a MEAP to build an app. I have done research and reviews of MEAP environments I have done primarily native Android and iOS development with some PhoneGap development sprinkled in there. I can identify with the market’s need for cross platform environments.
If you are reading this article, I am going to assume you have some understand of the differences between cross-platform development tools. If not, feel free to read this post on Stack Overflow. The poster gives good short a sweet on each platform.
What is a Mobile Enterprise Application Platform (MEAP)?
The niche market MEAPs attempt to serve goes beyond just developing an app once for many plaforms like PhoneGap, Appcelerator, Xamarin and Sencha Touch. They attempt to solve a wider scope of problems that enterprises encounter with integration and data. Using a concept developed by Gartner, MEAPs target customers where this “Rule of Three” applies:
- Support three or more mobile applications
- Support three or more mobile operating systems
- Integrate with at least three back-end data sources
MEAPs are targeting customers that are managing many applications on many platforms with many source systems and need to do this with quick turn around. The mobile apps need enterprise data integration, authentication to the organizations identity providers and do this without writing the same user interface client multiple times. So, essentially take a cross-platform development tool, authentication provider and add your middleware services to it and you will get MEAP, sort of.
Many Enterprise Resource Planing (ERP) vendors offer their flavor of MEAP. It only seems natural for them to offer such a product. SAP offers a their mobile plaftorm. Oracle released their mobile platform a couple of months ago called Oracle ADF Mobile. Given the rapid growth of mobile devices and their usage in the workplace, ERP vendors have every reason to provide these offerings. However, some are better than others. Some are offered just to compete and others are marketed as the best. One thing is curtain is vendor lock. Don’t expect to run your company on SAP but use Oracle’s MEAP offering. You might be able to do so but you will loose all of the benefits you would gain with the integration and middleware.
Everyone is an expert with mobile apps
The problem with most cross-platform tools is that they create sub-par app experiences since they don’t confirm to each device’s Human Interface Guideline . MEAPs are no different. One reason companies are supporting multiple platforms is because there a allowing their employees and customers to use their own devices. These individuals know how their device and ecosystem from experience. The, “something is not right with this app” comment is typical with cross-platform. Organizations will have to live with sub-par app experience when building with these tools.
Marketing efforts should continue with native development
Only 22% of all apps on the market are ever used more then once (App Retention). Most of the time people try an app once and never try it again. I would not recommend building out any apps with a MEAP that will be used for marketing. Again, people are experts when it comes to their phones. Your target market will generate perceptions about your company based on the UX of your apps. If a company has the budget to implement a MEAP there is no reason to cheap out on your brand recognition.
Imagine going to a convention hosted by a large automotive company. They advertise that their attendees can download an app on their Android or iOS device that will help them around their event and give them useful information about each speaker. Fiddling with your phone you decide to download and install the app. It looks nothing like what you are use to and the navigation of the app doesn’t feel organic. You have a android phone and it looks like they built it to look like a iPhone App. You are not impressed and you lack the patience to understand the android iPhone looking app so choice to remove it to save space on your phone.
Talent to develop mobile is already thin.
Finding someone that knows iOS, Android or even cross-platform technologies is hard to come by. Finding someone with a mobile background and experience working with your choice of MEAP is going to be harder and more expensive. Don’t let anyone sell you on “Our platform allows you to develop mobile apps without writing code”. This is usually a true statement but the chances of accomplishing anything useful without writing any code is low.
Should We Use a MEAP?
Yes. If you are a large organization what will need to create a lot of line of business mobile applications (looking at the rule of three) for BYOD cases then it would be more efficient to manage this effort via MEAP. Aside from the cross-platform device support, your organization will benefit from the middleware features included with the platform. One of the time consuming tasks of any application it is architecture and MEAP strive to implement this for you on day one.
I did read an interesting article by Caperiza. The author made a valid point when it comes to building your UI’s using a technology that is inherently cross platform. I like to think of HTML as the C/C++ for the front end. The HTML standard is cross platform for 98% of the devices available. If you are just in need of displaying data then perhaps just creating a mobile responsive application is sufficient. But that still leaves the middleware and backend providers that you get for “free” with MEAP implementations.
There is no easy way around this one. ERP systems are flexible by nature. That makes integration flexible as well. You still need the integration expose data to mobile platforms. With MEAP’s they vendors implement for you authentication/authorization, data set to mobile data contract mapping, transport standards (HTTP/JSON) and this is available during design-time in their IDE.
If you live inside your vendors platform you may not find my problems with building using their MEAP. Take one step outside of that realm and you see the time required to implement those cases are enormous. For example, many enterprises have multiple systems handling different lines of business. Your organization wants to add a real-time inventory metrics on the mobile app. Real-time inventory data is not maintained on the MEAP’s ERP system. It is maintained in the inventory management system, lets say WASP. In this scenario you are required to implement this call as you would if you build your own middleware/proxy environment. MEAP’s do not buy you much where edge cases like this arise.
If you have a MEAP or plain on implementing one, make sure the talent pool exists to support these efforts. This isn’t at technical problem, it is a human resource problem. Understand there are limitations with the ease of development. The UI’s created don’t conform to each device’s platform Human Interface Guideline since they are required to be cross platform. Expect people to have a negative first impression with this apps do to this reality. Marketing should stay away from using most cross-platform solutions, not just MEAPs. Keep your expectations inline when building out an app with these platforms.
These platforms are not the be all end all. Use them as an extension of your ERP systems, not the replacement for mobile development.