Software Developer Guidelines from the Mobile Telecoms Industry? Worth a Look

The first announcement came in Feb 2012, at the industry conference Mobile World Congress: The industry association GSMA has been working on software development guidelines for smartphone applications. This work is continuing. Does it mean that mobile network operators are now aiming at becoming software development consultancies? Not exactly.  There is a more significant rationale behind this.

In early 2012, the GSMA published their first version of developer guidelines for smartphone apps developers. Under the headline of “Smarter Apps for Smarter Phones”, several network operators produced a significant educational document for the mobile apps developer communities. In essence, these are recommended best practices in software design. They aim at striking a hugely important balance, namely making three different parties happy: a) millions of consumers, b) network operators, c) apps developers.

The software engineering guidelines can be downloaded from the GSMA. Demonstrating creativity, the GSMA has produced a variety of collateral to convey the purpose of these engineering guidelines, including an introductory video. In Spring 2012, the GSMA accelerated outreach to mobile software developers through a developer competition. It called for demoing apps which would be judged against compliance to the new guidelines. The competition concluded in June 2012 with announcement of winners at the GSMA Mobile Asia Expo in Shanghai.

What sort of developer guidelines are we talking about? Well, the smart apps guidelines address a key issue which network operators have been experiencing. This issue emerged with the phenomenal rise of smartphone apps, app stores and the increasing smartphone penetration. Many of these apps generate a significant amount of small messages. They are sent to application servers for the purpose of checking for news and status updates(e.g. of people in the case of social network applications). Often messages are sent to simply tell the application server that the client application is still alive.

The “chattiness” of such smartphone applications has a negative effect in two respects, both having the potential to impact revenue and the bottom line of network operators.

First, the repeated sending of small messages from the phone to the application service provider often without the consumer being aware of it rapidly drains the phone’s battery. The simultaneous use of many popular apps on a phone (e.g. news apps, social network apps like Facebook, instant messaging apps, social mobile games) exacerbates this effect. Improvements in battery technology don’t seem to be able to keep pace with this growing, energy-consuming messaging pattern emanating from smartphones. A side effect is consumers who are puzzled as why their batteries are drained by lunchtime and wondering whom to blame: the device manufacturer, the network operator or somebody else unknown to them.

Second, the frequent sending of independent small messages leads to an uneconomic use of mobile network resources. In simplified terms, quite often mobile radio resources have to be “powered up” and signalling and data channels be established for the purpose of sending a message. Later, these resources have to be released to not occupy them unnecessarily, only to request renewed allocation of such resources again for the next message wanting to be transmitted. This overly consumes mobile network resources and can lead to signalling overload. This impacts mobile voice and data users. In the worst case and upon failure of application servers outside the control of network operators, an application installed on thousands of smartphones may run wild and move into a mode of frantically trying to access the application server when the server is actually down. Such events have caused “signalling storms” in the past. They led to mobile service outages in various countries, including South Korea, Japan, USA and others (see e.g. [1], [2]).

Though chatty apps are one root cause for short lives of batteries and network congestion, chatty mobile operating systems and middleware are an additional cause.

Because of above two key effects (one via the battery on user experience and one on network and service availability and indirectly on capital expenditure of network operators), it’s adequate to take action to improve the situation through any practical means. Assisting developers in understanding the problem and advising them on how best to design and program their “apps” is one pillar of a more comprehensive solution.

The GSMA’s software development guidelines are not of poor parents. The guideline documentation is comprehensive, explaining to developers both what the real issues are and how the issues can be mitigated or largely avoided. The guidelines are hands-on, and come complete with best practice software code, currently for three mobile operating system platforms (iOS for iPhone, Android for the smartphones powered by Google’s operating system and Windows Phone from Microsoft). The GSMA also went an extra mile to serve the guidelines up in a more attractive, creative, and inspiring way including a colourful document, video collateral etc. These software engineering best practises are further promoted by several network operators (see e.g. [3]).

A natural challenge is getting the message across to the right audience. Though many mobile network operators run their own developer programs, the pool of developers is large with their attention often focussed on the developer ecosystem most closely related to the mobile operating system they are working with. Examples are the developer ecosystems of Apple (for iPhone) and Google (for Android phones). To raise the awareness to a wider web community and seek feedback, the GSMA and the World Wide Web Consortium have set up a dedicated Community Group run by W3C. This is only one additional outreach channel. Other channels are e.g. renowned developer conferences, “hackathons” and developer blogs.

Given the symbiosis of device and device operating system manufacturers (like Apple, Google, Microsoft, Samsung, Nokia etc.) and network operators, one would assume that it’s in the interest of all parties to achieve a situation that benefits them all. This means better designed mobile applications that improve the user experience and don’t severely impact the mobile broadband networks. In this regard it’s surprising not to learn about a closer collaboration between network operators and the likes of Apple and Google yet. Various factors may be at play here, amongst others e.g. the competition between these companies for dominance in the high-end smartphone OS sector. The platforms namely are of course different. The bundles of apps designed to run on those platforms taken together with the phone’s middleware and operating system tend to behave differently in terms of chattiness and network traffic they generate. A better, more network- and consumer-friendly design of applications, phone middleware and operating system would raise all boats together. This might not be in the interest of those fierce competitors. Thus, even in the absence of significant, public endorsement of the GSMA developer guidelines by such vendors and their developer programs, we may expect to see improvements forthcoming in smartphone middleware and operating systems – the individual players polishing their platforms silently on their own.

Given the high commercial relevance, the GSMA is continuing to work on enhanced software design guidelines for smartphone applications and the key players (device manufacturers, operating system vendors and network operators) can be expected to drive improvements in the months to come.

Acknowledgements: Thanks to Kamran Kordi for good discussions on this.

References

[1] http://www.bloomberg.com/news/2012-01-27/docomo-to-spend-164-billion-yen-on-network-after-service-outage.html

[2] http://www.telecomasia.net/content/tackling-outages-smartphone-age-part-1?page=0%2C0

[3] http://developer.vodafone.com/blog/2012/03/29/gsma-smarter-app-challenge/