The evolution of cloud service offerings by network operators poses two parallel challenges: defining the cloud infrastructure that can serve as a platform for new revenue-generating services, and defining the business ecosystem that can produce those services. Apple's iPhone proved that even the flashiest marketer in the industry can't develop applications fast enough to keep the market interested. The problem is that Apple presents two models at once -- a retail storefront and a developer ecosystem. Operators will have to choose one, at least in terms of priority. Surprisingly, the only logical choice is the cloud developer ecosystem.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Retail cloud services are clearly the goal of operators, and some have taken steps to acquire software to supplement their cloud platforms and convert Infrastructure as a Service (IaaS) into Software as a Service (SaaS) offerings. Even in these early stages, two major challenges have emerged with this approach. First, operators lack the vertical market expertise to acquire and sell services on a large scale, and they're not the players small and medium-sized businesses think of as natural partners. Second, there is little cloud deployment data to validate just which market segments might be fruitful to pursue. Picking a few wrong segments to target can cause a whole cloud campaign to be lost.
High hopes for developer partnerships and programs
European operators have believed for some time that developer partnerships are key to their future in services. Some have even formed special cloud/Internet units (Telefonica Digital, for example) not only to address these opportunities, but also to build the tools needed to attract developers and create service and application partnerships in the cloud. From these experiments, we can derive some basic rules for cloud developer ecosystem success and even show how these ventures can aid in the future creation of "cloud shopping malls," or a means of selling software through operator portals.
At the technical level, developers need a set of functional application programming interfaces (APIs), meaning they need network and cloud services presented in a simple and logical way -- not as a complex set of low-level tools. Standards for mobile call control, for example, expose a dozen interfaces, and most of these interfaces are exposed to elements that application developers have no familiarity with. All the developer wants to do in most cases is make an application available to a mobile user, so the developer needs an architecture that can link a cloud image of their application to an app in a mobile device. It should utilize all of the features of both the operator's cloud infrastructure and mobile environment, but it should not expose the details.
Operators should give special consideration to developing cross-application APIs to encourage symbiosis between applications and partners. A provider of clinical software might be encouraged to link to the services of banking or accounting packages, for example. This will strengthen the cloud developer ecosystem and create demand among developer partners.
An error operators often make during the first step in defining a developer program is assuming that just one program is the goal. Operators will need to have several "levels" of development-- one level designed to support Web and device app developers at a high level, one designed to let expert and trusted partners build pieces of a cloud ecosystem, and a few in between for vertical and horizontal market application software integrators. Each level would have its own tools, APIs and business relationships with marketing support and shared revenue plans. Trying to fit all the developers into a single mold is not compatible with program goals.
The importance of lead and risk assessment
The business side of the cloud developer ecosystem is interdependent with the technical framework. As businesses themselves, developers will typically look for two things from a senior partner such as a cloud or network operator. First, they will look for leads -- the marketing channel that will uncover prospects and help convert them into customers. If there is no retail storefront in the cloud program, leads are even more critical. This is because the leads then become the key to helping developers and integrators build up their business as well as the business of the cloud provider.
The other requirement is compensation. The revenue-sharing aspect of a developer program is fairly well understood, but there are other forms of compensation as well. In particular, developers and integrators fear risk. If they are asked, for example, to shift from an installed-system to a cloud-hosted business model, they'll want protection against any business risk. In this scenario, an operator-funded marketing program would be one way to encourage developer participation.
The risk of any cloud strategy driven by a developer program is a potential lack of unity. In these cases, it's possible to end up with 50 law-practice packages but nothing in healthcare. Having a mix of developers can dilute the opportunities for everyone involved through excessive collision and competition. To avoid this conflict, it's best to do an advanced demographic analysis of the service area to identify the best verticals and to help direct marketing programs toward them. Special incentives can help encourage developers to pursue a broader range of opportunities, and enrollment limits can also help to reduce overpopulation in some market areas.
Timing is everything
More on cloud developer ecosystems
Build ecosystems within cloud data centers
Building an ecosystem with open source software
The final and perhaps most significant issue involves deciding when to open a "shopping mall," meaning when to actually brand or sell software through an operator portal. To achieve this, it's not sufficient to just promote software partners by listing them on a website. Instead, providers would sell software through a portal and take on billing and contractual responsibility. As soon as a cloud operator buys a developer/integrator partner or sells a partner's wares directly, it simultaneously offers encouragement to others that want the same opportunity in other sectors while demoralizing those who were competing with the acquired player. It's a step that has to be taken carefully, and when it's taken, it may be necessary to change marketing and compensation programs. If all that is done, then a cloud operator can build a software service future that includes the best of the cloud developer ecosystem and shopping mall worlds.