Enterprise Mobility (Part IV): Mobility Platforms

If you are in the middle of selecting and/or researching for mobility platforms, it is very likely that you may come across variety of vendors offering platforms types such as:

  • Mobile Enterprise Application Platform (MEAP)
  • Mobile Cosumer Application Platform (MCAP)
  • Mobile Application Development Platform (MADP)
  • Mobile Device Management (MDM)
  • Enterprise Mobility Management Suites (EMMS)

Should an organisation have all these platforms? Or are these platforms just buzzwords? These terms, on one hand represent the evolution of the mobility platforms, while on the other hand to a certain degree, creativity of the analysts who coined and keep coining these terms.

Mobility platforms are evolving from 2 broad sets of enterprise mobility requirements:

1. Platforms for developing and managing mobile applications during run time, and
2. Platforms for managing administration and security of data and devices

At the beginning of their evolution cycle, mobility application platforms, were referred to as MEAP or MCAP and more recently this family is referred to as MADP. Similarly, the mobility admin & securliy platforms which were referred to as MDM earlier, are now referred to as Enterprise Mobility Management Suites by Gartner in their 2014 Magic Quadrant report.

Mobility application platforms typically offer the following:
– Development Environment, which can be used to build cross platform apps
– Run time environment or server-side environment for data routing, transformation and movement / integration / syncing between mobile devices hosting the mobile apps and back-office applications
–   Mobile Apps Administration in terms of user management, version management, etc.

Mobility Admin and Security Platforms offer the following features:
– Mobile Devices Lifecycle Management: Registration, Administration, Retirement
– Device Trackinig
– Data Security & Encryption
– Data back-up
– Remote data wipe-off
– Private App Store
– Remote support

Considering that Mobility application platforms offer much more than development toolkit, one wonders as to why they should be called as Mobile Application Development Platforms.

A lot of platform vendors from both the families of these platforms, are already offering overlapping functionality, particularly, Mobility Application Platforms are fast encroaching into the area of Enterprise Mobility Management suites. I expect these two types of platforms to consolidate into single platform. So, in case you are in the middle of choosing either (and particularly) the application platform or mobility management suites, then make sure to check the product roadmap of these platforms.


Enterprise Mobility, Part III B

Non Functional Requirements, Part B (To read part A, click here)

vii. Device Registration

In case mobile apps are built for employees, organisations typically want better control on who the users are and what devices these apps are accessing from. So, while mobile app can be downloaded from a public app store and installed, by default, user with valid username and password may not be able to use the app. The device’s unique id registered with the with organisation so that it can be authenticated that only valid users have access to the application and corporate data. Even in cases, where the mobile apps are for customers and partners, restrictions on no. of devices from which the app can be accessed can give comfort to both the users as well as the organisations and protect privacy and confidentiality of data.

viii. Private App Store

There are multiple ways, in which, enterprise mobile apps can be distributed. Mobile apps can be published in public app stores or can be distributed through corporate IT infra, or apps can be hosted in private app stores. Establishing private app stores can give organisations much better control on what employees can install on the devices, especially if devices are owned by the organisation. It is expected that, as  mobility initiatives become enteprisewide, organisations would naturally opt for private app stores and hence it may makes sense to plan for one right for the initial stages of the initative.

ix. Device Deactivation / De-registration

Mobility initiatives face a major change management risk. A long with the ease & empowerment they offer to the employees particularly in the field, they tend to enforce discipline, bring about uniformity in processes, and also at times increase in efforts in the hands of the end user. One of the ways by which this risk can be mitigated is by threatening deactivation of the app in case of non use. So, one of the requirements we encountered was to deactivate the user login in case user did not login into the app for 3 continuous days. The reactivation in this case would require users to give explanations to supervisors and super bosses. Permanent device deactivation is also required in the form of device de-registration when the employee leaves the organisation.

x. Device Tracking

Device tracking is critical for organisations where mobile device is owned by the organisation. Mobile devices like smart phones and tabs are expensive investments, and hence it becomes necessary for organisations to track them so that they can be recovered in case of theft or loss. One of the requirements, that I had encountered was to recommend optimum path for sales or service executive while addressing customer sales / service requests and compare the actual path and deviations. Also, send real-time alerts to the executive to address urgent customer requirements in case of irate or priority customers.  Thus device tacking may be become an important risk mitigation mechanism as well as means to achieve tactical benefits.

xi. Remote Back-up

Remote back-up of the data on the device can be useful in case the device is lost or damaged or is required to be reset. Hence organisations may seek mobile apps to have a feature to take back-up of the critical mobile app data and have it stored on the central servers.

xii. Remote Wipe-out

Remote wipe-out is the last option in case the device is lost. This can at least ensure that critical organisation data does not fall in the wrong hands.

These are some of the non functional requirements, which mobility initiative architects and analysts may or may not hear from business users but certainly may have to consider while implementing their respective enterprise mobility initiative. The list of these requirements above may not be comprehensive and also may not be applicable to all the mobility initiatives. One would be required to carry-out cost benefit analysis then decide whether the solution being implemented should design for these non functional requirements.

Enterprise Mobility, Part II

Defining Enterprise Mobility Initiative

Many organisations look at their Mobile initiative as a Single App initiative, especially in the initial phase. They tend to equate the initiative as one point application like any other enterprise class system. Mobility project starts as a pilot or POC project with time and budget constraints. As the POC initiative gains momentum and takes the shape of larger enterprise wide initiative, requirements for basic foundation, typically non-functional requirements need to be addressed. Else, the initiative starts imploding giving rise to data issues, scalability issues and so on. So it is essential to address these non-functional requirements right at the inception stage.However, before we discuss these requirements, lets define the criteria for Enterprise Mobility Initiative.

Mobility initiative should be considered of Enterprise class, if it meets any of the following criteria:
1. 3-5 mobility apps are built/required to be built
2. Users group include any of 2 of the following groups: Employee / Customers / Business Partners / Suppliers
3. No. of users exceed 500
4. Mobile Device strategy for employees covers BYOD
5. Integration with back end systems involves more than 2 back end systems

Once the organisational mobility initiative meets, any one of the above criteria complexity in areas listed below increases many folds:
– App support for Multiple Mobile OSs,
– User Experience on multiple devices / OS / form factors,
– User Management,
– Device Management,
– Data Management,
– Integration Management
– System Administration
– Time To Market

And this increased complexity requires a platform based approach to develop and manage run time environments of these mobile applications.

In case of large enterprises, it is only a matter of time, that the initial POC or pilot project takes shape of Enterprise class. Architects responsbible for mobility initiatives in these organisations should either plan for platform based approach right from the beginning or alert organisations of rework.

Lets look at some of the critical non functional requirements, essential in building this platform based approach in the next article.

Enterprise Mobility, Part I


Business organisations have spent their energies on leveraging mobile devices for delivering businesses value for over a decade now. Initial mobile apps were simple SMS based apps running on feature phones. Some organisations even had custom-built POS (Point of Sale or Service Devices) fitted with mobile sim card and running simple new business or payment collections apps. Easy to carry, Mobile devices were and are seen as a very potent device in the hands of customers or mobile employees engaged in sales and customer service activities. Self service apps running on mobile devices can deliver instant gratification to customers and improve productivity of mobile employees. Despite the advantages, enteprise mobile apps did not see as much popularity or serious thought amongst corporate think tanks, as early mobile technology posed challenges in terms support for multiple OSs, user experience and device & data security.

Organisations started thinking seriously about mobile apps after the launch of iPhone in 2007 and particularly in 2009 when Android based smart phones started becoming popular globally. Smart phones allowed organisations to build apps with rich user interface leveraging data connectivity. The corporate mobility initiatives received a real impetus in 2010, when iPad and Samsung Galaxy Tab was launched. Tablets overcame the limitation of smaller screens issue that smart phones posed and are light & rugged enough for mobile employees to carry them along with themselves. I implemented one of the early large scale mobility initiatives for an insurance company in India, one of the toughest and challenging assignments of my career.

Most critical success factors (CSFs) for the successful implementation were completely non technical such as CEO sponsorship & support for the project, CEO driven Change Management within the organisation, Big bang implementation approach, An incentive programme for the users, and a Support Center to monitor the application utilisation & provide technical support. However, technical design & architecture and technology selection & implementation approach were perhaps the most critical factors for successful implementation of the project. Some of our technology design and implementation choices were very deliberate, while others were based on our view about the future of mobility.  In the following blog entries I’ll focus on the technical aspect of the enterprise mobility initiatives discussing questions such as:

  • How does one Define Enterprise Mobility Initiative?
  • What should be the approach to implementing Enterprise Mobility Initiative?
  • What critical business/ technology requirements that enterprise mobile apps need to meet?
  • What are various mobility platforms such as MEAP, MCAP, MADP, MDM, EMMS?
  • What are the architecture components of Enterprise Mobility Solutions?
  • What OS should the mobile apps be supported on?
  • What is the right mobile app: Native or Hybrid?

While I pen down my thoughts, it would be interesting to hear your views. Do share your experience. Also do not hesitate to write to me in case you have questions or need clarifications.