Everyone seems to love developer programs. They promise that some legion of busy programmers will rush to create stuff using your service or product, thereby driving up your sales while you sit back and rake in the proceeds. What more could you ask? Well, how about a rational developer strategy? For operators in particular, that seems to be illusive. As a software architect and a participant in both some developer programs and some initiatives to create them, I’ve got some views on what might be involved in creating one.
Everyone who wants to start a developer program starts with the application programming interfaces (APIs) they’re going to expose and publish, and those are important at two levels. First, APIs represent features that can be accessed and composed into valuable services. The value of the services will depend in part on the API features exposed, but most important, the value of an operator’s contribution to the program is determined by those features. If you expose useless features then you contribute nothing the developers can exploit, and your program is doomed to failure.
One classic mistake operators make here is focusing on what they’d like developers to do rather than on what developers can actually profit from doing. Often that happens because they simply make an inventory of features that they could expose without much regard for what using those features could mean in terms of benefit to the developer. Remember, the developer is trying to create an application that uses the APIs, and hoping to sell the application or a service/services based on it. It’s important to consider that developer end-game if you want to attract developers.
Most operators look at two areas for feature exposure via APIs. The first is connectivity services, meaning voice, data, or message connectivity, and the second is management and operations services, meaning features of OSS/BSS systems. Both these areas have value, but in today’s market neither likely has enough value to actually assure operator developer programs of success. To understand why, we have to look at the way a developer would build on APIs to create value.
There are two models of developer applications that could exploit an operator API set. The first model is the app model and the second the cloud model. The app model says that the developer is exploiting the APIs in an app written for a mobile device or run on a system attached to the network, and the cloud model says that the developer is exploiting the APIs through a cloud application. Both these models have potential limitations.
One common limitation is that the likely geographic limitations to accessing operator APIs. Where are the APIs actually hosted? An operator-specific API likely has limited value if the user of the developer’s application/service isn’t in the geography of the operator or on the operator’s own network. A limit in the geography from which customers can be drawn means a limit in revenue, and in some cases limited API geographic scope can hinder effective marketing. If a developer has a plan to exploit a wider area than the APIs can be extended at reasonable QoE, they’d need to support multiple operator relationships, which means you’d need either a standard API set or operators in a regional market would have to agree to a common API model. Otherwise developers would need to build versions of the application for every operator.
Considerations on geographic support limits for the APIs also has an impact on the value of the program, and here is one place where the two possible models of service raise different issues. App-modeled developer programs and applications pose a risk in geographically limited programs because the user may roam out of the area where the app will work, or work properly. With cloud-model development, that risk may not be a factor, but the availability of cloud resources proximate to the user has to be considered. An operator’s developer program may require a single cloud provider to provide effective hosting, and if that’s the case then it limits the developer pool to those familiar with that provider and also may indicate that the operator should specialize their APIs for consumption on the available cloud infrastructure for maximum benefit.
If you analyze the failures of operator developer programs, which I think in the last five years have been more numerous than the successes by a good margin, you can trace the majority to a lack of foundation features to expose. Truth be told, connectivity is a given. Truth be told, OSS/BSS systems administer services, and in most cases any real developer opportunities will (as I’ve noted) either be delivered through an app, the cloud, or perhaps both. Both have connectivity implicit in the platform, and the cloud is replete with management, operations, and administration tools.
The final issue on this topic is the problem of having APIs forcing a legacy development model. In theory, an API can be accessed by any suitable programming language in any application. In practice, the way the API exposes assets creates an implicit application structure, and operators need to consider this when designing their API details.
A simple example here is the “push versus pull” approach. Classic operator-think tends to look at getting status information or other data by “pulling” it, so APIs are designed to ask for something and to having it delivered in response to a request. Event-driven applications expect things to be “pushed” to them. More and more modern development is being done based on event-driven principles, so having a pull/poll type of API runs counter to this, and in some cases makes the whole API set and developer program unattractive.
It’s my view that there is no way to make traditional developer programs a success for operators because they rely on exposing those tired old traditional feature assets. If operators want something more from developers they have to contribute more for the developers to work with.