Standards: Conformity at Any Cost?

By Jason Lackey, Marketing Manager, Innopath Software

The world of technology is a fascinating one, filled with multiple competing dynamics.

On the one hand, innovation is the engine of capitalism and it is from innovation that competitive advantage is gained. On the other hand, in order to ensure that your widget plays nicely with other widgets (as few make enough of a solution to play alone in a vacuum) standards are necessary.

With standards, it is possible to do things like build a better browser that will show your favorite Web pages as they are intended to look, but faster and better. With standards one can do things like manage phones OTA (Over The Air) and make support less of a nightmare for your subscribers. With standards a lot of things are possible, but these possibilities come with a cost.

Standards come from standards bodies. Standards bodies tend to be populated by people from companies with a vested interest in some technology but the standards efforts tend not to be a central focus of those people who often have their "real" jobs to do when they are not in standards meetings. The various vendors represented will tend to have different perspectives, goals and desires and this can make progress very slow at times.

In the world of mobile device management, standards are relatively new, just like the technology. Of course, the technology came first and in the absence of standards vendors, by necessity, created proprietary protocols. The first wave of real standardization was from the Open Mobile Alliance in the form of OMA-CP, Client Provisioning protocol. While far from perfect, mostly due to being a one way write-only protocol, CP got the ball rolling and helped illustrate the value to device management.

Recognizing the shortcomings of fire and forget, OMA followed up on CP with OMA-DM, a bidirectional protocol that let you read as well as write, allowing the operator to get feedback after device management actions have been taken. I guess some folks decided that it would be useful to know that something had been fixed by means other than the person holding the device telling you that it had been fixed. I further suppose that folks figured it would be useful to be able to do things like a basic diagnostic ping on the phone.

All this is good, but as I mentioned before standards can move slowly and in many cases the standards don't keep up with the technology, which is where things like a "Standards+" approach come in. A vendor which owns both ends of a client/server solution can do things like support standards such as OMA-DM as a base, but also offer extensions and enhancements above and beyond the standards.

This gives the advantage of interoperability out of the box while also providing additional functionality. Back when the Model T was introduced, it could be said that existing standards for road construction called for dirt or gravel and the car worked fine on those roads. When a road was enhanced beyond being a rutted goat trail, beyond the standards of the day, the car didn't stop running, it ran better and provided a better end user experience.