MADP – what is it and how is it different from MEAP?

Is MADP yet another alphabet soup? In today’s landscape organizations may find it hard to know if they need a MEAP, a MADP, a MDM or all of them or none. Let’s see what MADP means and how it stacks up.

Definition of MADP

If you already know what a MADP is just skip this next paragraph, otherwise buckle up:

MADP stands for ‘mobile application development platform’ and it allows organizations to build apps easily across many mobile devices, audiences and backend architectures. Whereas previously apps were developed (or outsourced) as one-off solutions to fix just one problem, with MADP companies have an on-going perspective to add more and more apps by possibly re-using some of their previous code. MADPs further include management of deployed apps which gives IT departments control over the entire lifecycle of their custom mobile solution.

Such platforms are split into two major functions: A mobile front-end framework and a middleware server/service. The middleware server doesn’t store any of the companies’ data but rather ducts the data through to the mobile front-end; while checking requests for authorization.
The integration of various sources on the input side (cloud APIs, on-premise software, databases), and the output to HTML5 or native app frameworks together facilitate a true cross-platform experience.

This allows the client to connect to the data in a secure manner and then read out data and business logic so that it can be changed through the mobile user interface.

In theory a MADP allows an organization to develop any given app just once and deploy it to all of their mobile devices, even if they use different platforms, say iOS and Android.
That’s why it is said MADP is for organizations where the ‘Rule of Three’ applies: A mobile solution is needed that combines more than three back-end sources, to be running on three or more platforms, by using three or more apps, etc.

This is accomplished either by deploying the app automatically as a native app in the respective proprietary formats of each platform, or by resorting to HTML5. HTML5 offers the benefit that virtually any device that has a browser is automatically compatible, as the app is cross-device and responsive-design by default, thus working for all form factors.

TechTarget thinks that the MADP approach “removes much of the burden [of developing mobile apps] by providing everything that is needed quickly and cheaply”. With a focus on re-usable code snippets and drag-and-drop app designers, as opposed to full-on code editors. With their secure access to enterprise data through configurable connections, developers can customize apps without having to worry about manually implementing their backends.

Difference to MEAP

MADPs have a lot in common with MEAPs with one tiny exception. MEAPs are the old-school, uncle of MADPs. Gartner started to drop the term “MEAP” already in 2012, as they see a mainstream move towards one-size-fits-everything MADPs. MEAPs were designed to be enterprise-focused application development tools, and they had a consumer-focused companion called MCAP (Mobile Consumer Application Platform).

MADP tries to be a two-in-one solution basically. And although it seems to be a natural evolution to the separated MEAP and MCAP concept, it also begs the question if a MADP can go just as good a job being MEAP and MCAP then they were individually.

Active Directory not needed for consumer apps

Consider enterprise apps. For B2E (Business-To-Employee) apps you need strong user synchronisation across AD, OAuth and the many flavours of ADFS, SAML and Single-Sign On. As a technologically challenging feature it will drive up the cost of the solution, whereas for B2C (Business-To-Consumer) app it is virtually unnecessary.

Native apps not major in enterprise apps

Similarly there are cases where a B2C app requires different approaches to a B2E/B2B app. If you make a consumer-facing app you want a tool that can easily port your project into separate iOS apps, Android apps or Windows Phone apps. The driver behind this being the easy distribution to customers through the App Stores.

But for a B2E app “native apps” aren’t your first choice: Typically only browser-based HTML5 web apps truly are “develop once, deploy everywhere”. Companies prefer the control and security that comes with HTML5, which in many business cases is just as fast or even faster than native apps. It begs the question: If you pick a tool that does both native apps and HTML5, will both be equally refined and at their most optimized?

Where Mobility Portal has laid priorities

At Mobility Portal we started out with the “harder” Enterprise segement. We have:

  • Prioritized HTML5 with the phenomenally fast Google Polymer Web Components which are just as slick as native iOS apps. But with the extension into the MADP segment we have added PhoneGap integration to our platform so that all apps can be easily ported into native app shells.

  • Created easy-peasy Connectors to all run-of-the-mill enterprise data sources. Today you can connect your apps to anything from SharePoint, Dropbox, SAP, Office365, etc. with just a few clicks. But in the future we plan to add a responsive-design CMS system so you can create amazing consumer-facing apps as easy as a website.

  • Developed a central API Hub that brings all your enterprise data sources securely together in one API that can be integrated into your apps while taking into account secure and authorized access. In the future it will be possible to extend your sensitive enterprise data with highly secure “customer views” that you can easily expose to your consumer facing apps without having to make huge changes to your architecture.

In other words, Mobility Portal has started out as a strong MEAP with a competency to be everything you need to create workplace apps. But in the future taking the best of both worlds will eliminate an arbitrary border between enterprise and consumer market apps, thus in the bottom line reducing complexity for IT as they don’t have to wear two separate hats for their different app projects.