Pillars of a Mobile Strategy

Outlining a B2B Strategy

I certainly don’t have the expertise and experience to embark on a comprehensive discussion about the differences between B2C and B2B. As far as mobile strategies are concerned, there’s only one important difference: B2B often gives you the chance to choose one specific platform and vendor and stick to that. From a software company perspective, B2B means that you’re helping another business set up a mobile infrastructure that will be used to serve a limited and largely controlled audience, such as the network of agents that operate in a given region.

For the purpose of this book, the difference between B2C and B2B is the same as the difference between a public Internet site and an intranet site.

Serve Your (Limited) Audience

Let’s review the main traits of a strategy aimed at serving the needs of just one business. The mobile interface is not open to the public; it’s consumed by special customers, such as employees, agents, and consultants. Although you don’t have to capture a large audience, you instead have a relatively small audience that you must serve in the best possible way. Forcing them to use one particular device or site is part of the deal.

B2B and the BlackBerry Case

What made BlackBerry so successful and BlackBerry devices so widely used? Sure, it offers email, tasks, and calendaring; it may even support web browsing and a camera. You can do some instant messaging and run a few utilities from an appstore that is one-tenth the size of Apple’s. But compared to, say, an iPhone, a BlackBerry device looks like a child’s toy.

So why was it so successful (at least before the iPhone arrived)?

The answer lies in the enterprise-class features that it offers. In particular, a BlackBerry device can connect to an in-house enterprise server—the BlackBerry Enterprise Server (BES)—and receive email updates, news, and task alerts in real time. How is that different from today’s Microsoft Exchange Server connectivity in Windows Phone? It’s not, really; both are basically the same—but BlackBerry was available somewhat earlier, and companies liked its features. As a BES administrator, you can apply policies and prevent a class of users from using the camera or instant messaging; you can force them to use only certain applications or to navigate only certain sites. Moreover, you can install your applications directly to your BlackBerry devices; you don’t need to distribute them publicly to an appstore first.

In a nutshell, BlackBerry was a platform created to help members of an organization collaborate with ease and effectiveness.

Pick One Mobile Vendor

In a B2B scenario, a customer calls the software company and discusses requirements. The advisor has to figure out just one solution that provides the requested services in a mobile way. Most of the time, there are no constraints on existing devices and hardly any constraints to address on the platforms.

If you need a better mobile infrastructure to make employees collaborate, you probably have no reason to build an iPhone application. In addition to the costs of development, you also need to account for the costs of providing an iPhone to all your employees. I can think of a few companies who just did that—but I consider them the exception rather than the rule.

So in a B2B scenario, you should select just one vendor and platform and stick to that. From the customers’ perspective, costs are clearly lower, and development time is traceable. Which vendor you settle on depends on a number of factors, including the existing base of devices, deployment needs, special security or middleware constraints, existing skills, and, of course, overall cost and personal preferences.

I’ll return to this in a moment, but I think it’s important to call attention to that point, because in a B2B scenario, the mobile vendor is not simply—and not necessarily—the vendor of a mobile operating system and API. In some cases, the candidate vendor doesn’t even have its own mobile operating system. Instead, it offers its middleware with a bunch of platform-specific presentation layers for users to consume data and applications. According to Gartner’s Magic Quadrant for 2010, Sybase is an excellent player in a B2B scenario—and Sybase doesn’t have an operating system; instead, it provides a strong and powerful middleware for mobile clients.

Private Applications

When a company’s goal is to build mobile solutions for its workforce, any applications that it develops should be private. A private mobile application is a mobile application that can be installed directly on one or more devices, with no intervening appstore. Consider, for example, an iPhone application written to serve the needs of a particular customer of yours—such as an application for sales agents.

That application is likely built to reflect the use-cases and business processes of that customer. It may have integrated some strong authentication policy. You don’t want it to go to the marketplace, and you don’t want others to even look at it, let alone try it or buy it. You want it to work like Windows—you create an application, prepare an installer, run the installer on the machines you want, and that’s it—you’re done.

Private mobile applications are possible, but the process is not identical across the various platforms. In this regard, Android and BlackBerry are open: you can install just any application on just any device. For BlackBerry, this freedom of installing applications can be controlled and restricted by BES administrators. In Android, the only controller is the owner of the device.

Apple has a special enterprise program that, at the cost of $299/year, allows you to distribute applications freely within the members of your organization, whether through an intranet webpage, a network share, or email channels. Windows Mobile—the predecessor of Windows Phone—is as open as Android; Windows Phone still lacks an enterprise program. Currently, the recommended approach for simulating a private, company-wide marketplace is to make the application public and free and implement logic that unlocks the application only for users who have a specific Personal Identification Number (PIN).

Mobile Enterprise Application Platforms

In a B2B scenario, you typically choose a mobile vendor by analyzing its mobile enterprise application platform (MEAP). A MEAP indicates the entire stack of mobile technologies, products, and services that a mobile vendor (e.g., Sybase) offers.

MEAP vs. Stand-Alone Applications

When building a mobile solution, you could proceed by building a few stand-alone front-end applications that are based on an existing middleware or an ad-hoc back end and storage layer. But in doing so, you will likely end up using tools, services, and technologies from different vendors for the various phases of development.

MEAP is beneficial because by choosing a particular vendor, a company can often build a single back end and front end and deploy them to a variety of devices. The mobile device functions as a terminal that simply mirrors the content generated by the back end. A MEAP-based solution relies on proprietary middleware that you can customize and extend by writing applets using a few programming languages. The middleware serves data to the mobile client and controls both the user interface and local in-device logic.

With a MEAP in place, a company can expand its horizons with less effort—no need to invest in writing a new iPhone application; just deploy the same MEAP-specific application to the iPhone presentation layer. No changes are required to the underlying business logic, and the list of mobile front ends can be extended whenever the MEAP adds support for a new mobile platform.

In other words, a MEAP is an all-round business partner that specializes in mobile solutions. In this context, the classic iPhone or Android mobile application is just the tip of the iceberg—the real meat and potatoes are what lies under the surface.

Gartner’s Rule of Three

To explain the importance of MEAPs and, at the same time, give companies an easy way to check their affinity with a MEAP solution, Gartner developed the Rule of Three.

According to Gartner, a company should consider a MEAP seriously when the implementation of its mobile strategy requires three or more mobile applications for three or more mobile operating systems to be integrated with three or more back ends. It goes without saying that building a mobile platform from scratch with these requirements is a huge effort that probably requires a monstrous budget. In this context, a MEAP can introduce significant savings and—more importantly—keep the company at the forefront of the technology, ready to release new products in a fraction of the time that non-MEAP-using competitors might require.

MEAP and Gartner’s Magic Quadrant

How do you evaluate a MEAP? And more importantly, which vendors are actually MEAPs? Each year, Gartner applies its proprietary Magic Quadrant methodology to competing players in a given area—in this case, MEAP. The result is a diagram like the one shown in Figure 1-3.

Figure 1-3 Gartner’s Magic Quadrant.

The rank the research returns for each evaluated player determines the coordinates in the diagram and, subsequently, the quadrant into which that player falls. In the paper published in 2011, the Leaders quadrant contains companies such as Sybase, Antenna Software, Syclo, RhoMobile, and Pyxis Software.

It is worth noting that, according to Gartner, the MEAP market is steadily heading for a $2 billion volume in sales. So where are the other big companies commonly associated with mobile solutions? To be a MEAP player, a vendor must have a comprehensive set of products and services to develop and test applications and offer security, (cloud) storage, notification, reporting, and synchronization. Microsoft, Apple, and RIM appear in Gartner’s Magic Quadrant but are not considered leaders in this segment.