A guide to selecting enterprise mobile platforms

Enterprise mobile platforms are tools that provide capabilities for mobile application development as well as services required by those mobile applications. They can address business-to-customer (B2C) and/or business-to-employee (B2E) use cases. Real Story Group has recently released a detailed evaluation of 21 such vendors.

Once you've concluded that mobility is a priority, you'll need to decide whether and how much to invest in specialized enterprise mobile platform services. It's not a trivial decision and like other enterprise software decisions, it requires justification and an understanding of trade-offs.

In this article, we will look at a way to select the right product based on your requirements. The approach results from Real Story Group's research and experience with a large number of customers who have undertaken product selection initiatives.

Identify zones of relevance

Numerous products are out there; it does not make sense to evaluate all of them. So as a first step, we recommend creating a more manageable list of products-a list that is more relevant to your needs.

Consider the analogy of buying a car. If your budget is $15,000, you will probably not test-drive a new BMW (you could still do it, but it won't add value to your evaluation). Similarly, if you wanted only SUVs, there's no point in evaluating hatchbacks.

You can extend the same analogy to enterprise software including mobile platforms. As with cars, in most cases involving enterprise software, some simple criteria can help you filter out irrelevant options. And most often, those criteria are specific to an organization and depend on local factors.

We explain many such criteria in our mobility research. You can directly access Real Story Group's Web-based custom shortlist builder to get a sense of an initial shortlist. Using the wizard, you can filter out products (from our already curated list of 21 vendors) based on some intuitive criteria and create an initial shortlist.

Business scenarios

Based on our research, the most important factor to select the right tool is what we call "scenarios." Think of a scenario as a high-level business use case. Explicitly or not, different products target different use cases. That is usually because the product's initial incubators or customers wanted it for those use cases. The product might have broadened its scope as it matured, but most often the roots are still visible. Identifying business scenarios that fit better or worse for different packages will enable you to see more deeply into their relative strengths and weaknesses for your particular scenarios.

In our scanning of enterprise mobility initiatives, we have found the scenarios listed below to be dominant in the market. Your own scenarios could be a combination of one or more of these:

• simpler business-to-consumer (B2C)‚—like a beer lover's network app,
• complex B2C—like online banking apps,
• location-based—like some e-commerce and delivery tracking apps,
• mobile websites—often a marketing-oriented or informational site,
• offline apps—typically for remote workers like plant floor or delivery staff, and
• business-to-employee (B2E)—workaday collaboration and communications apps, often connecting to packaged software.

Those scenarios can be thought of as lying on a continuum, with more B2C oriented at the top of the list and becoming more B2E oriented as you move from the top to the bottom. Note the distinction between simple and more complex B2C apps, which can be an important vendor discriminator.

Matching features to functionality

Once you have this initial shortlist-and we recommend no more than eight to 10 products-you should undertake an in-depth evaluation of features provided by those products and how they stack up with requirements. While there are many ways to describe the functionality, based on our research, we recommend three broad areas:

• device support and development services,
• deployment and delivery services, and
• vendor intangibles.

Each of those areas is further divided into multiple sub-areas. As an example, we divide device support and development services into the sub-features shown in the image on page 14, KMWorld November/December 2013, Vol. 22 Issue 10 or download Chart 1. here. The example is only top-level functionality within the category. In your evaluation, you would actually go deeper in each of those.

Due diligence

At the end of the step above, you should be left with no more than four or five products on your shortlist. It's time to do a test drive-a closer look at the shortlisted products. This is when you call vendors and ask them to show you the what, how and ifs. When possible, you (or the vendor) should take up a sample of "tricky to implement" and/or complex features that are unique to your scenario and do quick prototypes that show what it takes to implement those features. They are called PoCs (proof of concept) and PoTs (proof of technology).

You must ask the vendor to do a demo of features that may not be completely present out of the box in their products but are important for you. Also, more than just showing out-of-the-box features, it is important for them to explain those features in the context of your requirements.

In the end, you also want to do as much diligence on the vendor (or open source community) as you do the technology. We find "vendor intangibles" comprise a bigger and more critical segment of our published vendor evaluations.

Enterprise mobile platforms are getting more sophisticated. You should employ the same rigor that you would employ while evaluating other categories of enterprise software.

No two implementations are exactly the same; a product that works well for one customer may not be appropriate for your needs. To find out the best "fit" from among a panoply of products out there, you must follow a structured approach for product evaluation. Chart which follows is on page 15, KMWorld November/December 2013, Vol. 22 Issue 10 or download Chart 2.here.