We use RIM as an example because these numbers are less apparent in annual reports from Nokia, Motorola, HTC and Samsung. But the numbers carry through. Whether we're talking about a Nokia E61, a Motorola Q or a plain-jane mobile handset, the carrier subsidizes the purchase price of the mobile device in return for a contract.
There are places where this does not happen, but those countries are small and the subscribers are few. And the larger point is the important one: The carriers expect something in return.
What do the carriers expect?
This simple question has multiple repercussions when it comes to mobile device management. In theory, the carriers expect to be able to make money from subscribers. In practice, this means that the carrier expects to manage the handset, the software load and the user experience on a day-to-day basis. This works in several ways:
- User experience: The mobile operator wants to "brand" its look and feel across mobile devices so that users will recognize the carrier from the user interface. This includes custom software loads,
- "skins" that reflect carrier color combinations, and common menu structures. For example, Sprint Nextel maintains a very consistent menu interface across multiple device manufacturers, so a Sprint user can pick up a new phone and understand how it works almost immediately.
- Up-selling: The mobile operator wants to be able to sell additional services to subscribers. These may range from high-margin services like MMS to music and video content. The carrier may wish to steer certain users to certain types of services (e.g., SMS/text messaging) or to content on the carrier's mobile portal.
- Advertising: Managing the user experience is the first step to creating a platform from which carriers can offer advertising services to consumer brands. Mobile advertising is a growing field, and carriers can generate substantial revenues.
- Walled gardens: In return for the handset subsidy, the carrier also expects to be able to restrict user access to particular software and network services. This ranges from VoIP services (that compete directly with the carrier's cellular offerings) to content and services from competing providers. For example, suppose a carrier has a Wi-Fi hot-spot service and the mobile device has a Wi-Fi radio – knowing how carriers behave, it isn't much of a stretch to imagine that the carrier will make it difficult (if not impossible) for users to access competing Wi-Fi services and networks.
- Who updates the operating system?
- Who can install software? Of what type?
- Who controls the Wi-Fi settings?
- What happens when the enterprise and carrier network settings are in conflict?
- Does the enterprise have the sole right to "lock" the device? Or can the carrier do that as well?
- Can the enterprise prevent users from accessing specific carrier services? Under what circumstances?
- How are conflicts between management authorities resolved?
- What happens when the mobile operator wants to push a promotion onto a group of mobile workers?
The mobile operators are currently developing and implementing tools to make these capabilities possible.
Corporate Mobile Management Series Part I: Introduction
Part II: Mobility and enterprise management
Part III: A crisis of architecture and process
Part IV: Mobile-specific management solutions
Part V: Carrier mobile device management approaches in the enterprise
Part VI: Security, certificates and authentication
Part VII: Policy and process
Part VIII: Best practices for corporate mobile device management
Over the air updates (and OMA DM)
OTA stands for "over the air" device management capabilities that enable mobile operators to remotely update software on mobile handsets. Have a new software load for the Nokia N75? Fine, let's push that out to every device on the network. We can do that at 2 a.m. on a Sunday?
And yet there is more to OTA than simply updating software. It's about promoting new services, steering users to content and generating revenues in ways beyond a text message blast. The mobile operator can put a promotion on the device's main screen. It goes further.
Suppose that a carrier has a content partnership with CNN, and a user is accessing Fox News. At this point, the carrier can push a pop-up window suggesting the CNN service. Down the road, when the content partnerships change, the mobile operator can update handset software across its network to reflect the new business model and corporate priorities.
The technology behind OTA is the Open Mobile Alliance's Device Management specification (OMA DM). Virtually every major smartphone and many mobile handsets sold today support this specification, and this means that mobile operators will roll out this capability in the coming months and years.
Here's the rub
We can understand why the carriers want -- and even need -- OMA DM and OTA capabilities. It's their business and they're trying to maximize profits. The consumer market remains a priority, and corporate customers are left to make do. The challenge for IT departments is twofold: to find integration points between OMA DM and enterprise mobility management platforms, and to develop a common set of management "handoffs" with multiple carriers.
OMA DM contemplates the idea of there being multiple parties (e.g., both a carrier and an enterprise) managing a single mobile device, but the specification was designed with neither input nor participation from leading enterprises, enterprise management vendors or mobility management vendors. Sybase iAnywhere wasn't involved. Nor were the teams from HP OpenView, CA Unicenter or BMC Patrol. And thus we are left with a team of vendors selling to the carriers and designing a specification to meet carrier priorities.
This said, OMA DM is real and it is getting deployed today. Where the specification falls short is in the practice of the handoff between carriers and enterprises. As currently designed, OMA DM will not offer the type of seamless simplicity we've come to expect from Wi-Fi. Instead, each carrier will employ OMA DM in a slightly different way, defining handoff and demarcation points in contractual terms. Demarcation and handoff are important because they clarify the permissions that both the carrier and the enterprise will have, answering questions such as:
And so on. OTA updating (and OMA DM specifically) raises as many issues for the enterprise as it promises to solve for the carrier. The OMA has done a very good job so far with the specification, but there are many, many, many issues ahead that an organization of companies selling to the carriers will never be able to resolve without getting enterprises and vendors selling to enterprises involved.
In other words, don't believe everything the carriers tell you. As if you believed everything so far.
The more likely scenario -- at least in the short- to midterm -- is that each carrier will implement OMA DM slightly differently. Each carrier will define demarcation points in a slightly different way. And each carrier will choose to turn each concession of demarcation control into a contract negotiation. For example, one carrier will offer the IT department full management authority rights over the mobile device, but that will require using a proprietary platform; meanwhile, another carrier will allow the enterprise to bring its own platform, but at a price. In other words, get ready to pay for the ability to (1) bring your own devices to the network or (2) manage the carrier-subsidized devices in the ways that you need in order to provide the services your users want.
Fortunately, this is not a matter of technology. Enterprise mobile device management platforms already can manage the same features as OMA DM, and some platforms already have OMA DM client software. The challenge with the carrier will be to define who does what in each and every circumstance. Shared OTA capabilities will take the path of service-level agreements (SLAs) and each carrier will offer something slightly different. IT organizations will be managing numerous shared OTA agreements across several carriers, and they should be prepared to pay in one way or another.
This was first published in July 2007