Application Developer Needs Part 2

As mentioned in the previous article “Open Innovation and Application Developer Needs,” in helping operators understand ways they can harness open innovation I’ve spent most of my time with the application development community understanding their needs.  And getting them in front of operators so operators understand what application developers need, NOT what operators think they need.

I maintain a list of about 1000 web/voice/telco 2.0 application developers, described in the article “Web / Voice / Telco 2.0 Application Developer List.”  This list enables targeting of different application categories, business models, enabler needs and geographic base.  In reviewing the results of the past two years I’ve interviewed over 210 developers, gathering feedback through phone and face-to-face interviews, as well as a range of quite detailed questions.  Again, I apologize to the people who spent hours completing the questionnaires, I promise it’s for the greater good 🙂

In examining some of the issues developers have in common with current operator initiatives:

  • No live test environment for end-to-end testing of applications;
  • No developer sandbox;
  • No/limited device independent platform;
  • No/limited embrace of browser based services – this is a critical gap in the industry;
  • Very limited access to key capabilities for providing interesting applications and services;
  • A web of stakeholders within the operator which slows/halts the decision-making and/or approval process;
  • Typically no single point of contact;
  • Inadequate operational support;
  • Little or no support for billing system integration;
  • Lack of support for remote monitoring;
  • Lack of flexibility / willingness to try new business models; and
  • Rigid rules & guidelines for contributing an application.

The list goes on, I’m just picking a sample.  However, some of the problems can be solved quite easilly:

  • Provide a live testing environment / access to test lab;
  • Single point of contact for technical issues;
  • Consistent operational support, e.g. network connectivity;
  • Clear path of decision-making up the chain of command;
  • Real project with full organizational commitment from operators – not a ‘fashion accessory;’
  • VPN access to on-site systems for remote monitoring;
  • Delegate testing and approval to third party testing houses; and
  • ‘Approved developer’ certification for the ability to fast-track approvals, operational requests, etc.

However, the surveys only capture a part of what an operator must do.  Above all an operator must:

  • Implement processes to ensure the ADC (Application Development Community) is used by the operator and not repeat the mistakes of the past;
  • Reverse developer skepticism by listening, implementing what they need, and show the ADC working; e.g. application developers will not pay for capabilities exposed – do not charge them;
  • Customer access is critical, it’s taken for granted on the web;
  • REST and SOAP/XML is the preferred API (don’t talk about ParlayX); and
  • Copy Apple’s App Store – they’ve got the recipe more or less right, copying is OK, we’re not at school; just ‘copy better.’