16 Aug 2012

Realising the true potential of APIs as game-changing in telecommunications

By Laura Merling, Senior Vice President, Application Enablement, Alcatel-Lucent   

Laura Merling, SVP, Application Enablement

Today we announced the launch of the API Lifecycle Methodology, a new application programming interface (API) consulting and professional services practice and an associated methodology. 

This announcement comes on the heels of several projects with our customers ranging from detailed competitive analysis across the API landscape to architecture and design work, as well as API performance optimization.  We have taken the best practices across telecommunications and merged them with the lessons learned from the global API ecosystem to create an offering that allows communications service providers to identify new revenue opportunities and deliver new services to market faster.   

The new consulting and professional services practice is built on the back of our uniquely qualified and experienced team of veterans in API implementation, strategy and operations, as well as the key lessons learned and best practices gleaned from our engagements over the past years. 

Coupled with the API Lifecycle Methodology – which we have licensed under Creative Commons and made freely available to the larger API community - the new practice is designed to address the challenges developers, internal or external, face when integrating APIs and to help optimize an API program for success. 

APIs are no longer new to the telecommunications industry, but their true potential as a game-changer remains untapped. Operators are looking to APIs as a strategic means of internal innovation, shortening time-to-market and lowering costs for delivering new services while identifying new revenue streams in the process. With application providers having seized the end-user experience, now is the time for operators to redefine and reinvigorate their role in the value chain.  

When thinking about APIs, the most important thing to remember is that they are not a technology for squeezing revenue out of existing business models. They engender new ones. No company gets it right all the time, but the most successful of them are continuously improving their API ecosystems.   

APIs are the glue that ties together all the elements of the data economy – apps, the cloud and big data. But launching and supporting a dynamic API strategy is not easy – these programs need to be monitored, nurtured and directed as they evolve over time.   

A quick scan of recent related media coverage reveals a wealth of stories about the challenges developers have faced with using third party APIs, regardless of whether they are cloud infrastructure providers or Social Networking sites. From scalability, to business models, to the deprecation (end of life) of an API – it is evident that a clear, concise framework is needed across industries to change the way businesses think about APIs and to define a set of best practices.   

We are committed to the betterment of the community and to fundamentally shifting the way operators and enterprises view the ecosystem.  As a result, we have licensed the API Lifecycle Methodology under Creative Commons. What does this mean? This means, we have essentially “open-sourced” the methodology – we have released it into the wild and opened it up for scrutiny, feedback and reuse. If we truly want this methodology to gain traction among all stakeholders in the API ecosystem, open-sourcing it is our only option. This move (arguably unprecedented in the telecom industry) showcases our commitment to open collaboration to drive the success of our customers.    

The trailblazing in other industries has already been done, and it has become clear that winning with APIs is about building a repeatable process and structure just as you would for any other part of your business. There are a vast number of processes to implement and best practices to put in place. However, at the simplest level there are three key phases to consider when building out an API program: definition, design and deployment. These three phases can be performed regardless of using our software (OAP), and create an opportunity to sell in our products and services.  Here’s a quick breakdown of each phase:   

PHASE ONE: DEFINITION   

This phase is focused on API strategy and prioritization. Establishing the correct business objectives to drive your API strategy requires a comprehensive understanding of your network assets, competitor capabilities and existing ecosystems. From there you identify the service(s) to be created; select the business model(s) to implement; define the value proposition to the ecosystem; and finally document a baseline for Key Performance Indicators (KPIs).   

PHASE TWO: DESIGN   

Design is vitally important. How developers inside or outside your company access your business will play a critical role in its success. Thoughtful, deliberate API design, including simplification of complex services and sample code is critical to the long-term success of your program.   

PHASE THREE: DEPLOYMENT   

The rigor applied to the business planning applies in the deployment phase as well. This phase is focused on operations and optimization. The service(s) created in the Design phase are now deployed and undergo continuous analysis and improvement. Systems integration, testing and production deployment are at the front end, while performance optimization and deprecation planning are critical as your program matures.   

In parallel we have componentized our product offering, the Open API Platform, to be able to address the needs of our customers in support of the API Lifecycle Methodology.  For example, in the Design phase, there may be a need to create complex services, which require customers keep track of status or data throughout the transaction.  To support this, the customer may leverage the Service Composition Framework.  In the Definition stage, the customer will be evaluating business models across their user base and will need a product that supports flexibility in pricing.  The Business Management Engine supports not only industry standard models, but also the ability to define unique billing units.   

We are very excited to announce our expanded AE portfolio along with our new API Lifecycle Methodology. Leveraging these new assets, we can continue to lead carriers in creating an effective end-to-end strategy, while also establishing a repeatable process that maximizes efficiency, cost-savings, and revenue. 

To read more about Alcatel-Lucent’s new API Lifecycle Methodology, please click here, and the press release announcing the practice can be read here.

 
 

13 Responses to Realising the true potential of APIs as game-changing in telecommunications

Feed For This Post
  1. Monique Francois says:
    August 18, 2012 at 8:49 AM

    Bonjour,
    Actionnaire d’Alcatel-Lucent, j’apprécie tout ce qui pourrait contribuer à sortir Alu et mes actions du gouffre. En particulier, je me réjouirai si vous arrivez à faire, de vos clients les opérateurs, de véritables centres offrant des tas d’applications, comme Google par exemple.
    Je vous signale quand même un obstacle.
    En tant qu’utilisateur lamba d’un contrat triple play, je constate une chose que vous oubliez un peu trop : cette prestation est médiocre : pannes, aide téléphonique uniquement, problèmes non résolus, personnel mal aimable ; ainsi, il m’a été impossible de faire remplacer par Orange une box à bout de souffle. J’ai du changer d’opérateur.
    Le client triple play est en permanence en train de chercher le moyen d’obtenir un service correct à prix correct (le triple play, soi disant bon marché, est en réalité très cher si on y ajoute de prix de la deuxième ligne téléphonique nécessaire quand la première est en panne, et le prix du prestataire de services auprès duquel il faut s’abonner puisque l’opérateur ne se déplace pas).
    Dans un tel contexte, le client veut pouvoir changer d’opérateur et il veut éviter de se retrouver “marié” : c’est ainsi que j’ai changé ma mailbox orange contre une mailbox google (plus apte à la migration). De même, j’ai été destinataire de la pub d’Orange pour mettre mes documents personnels sur leur cloud. Heureusement que je ne l’ai pas fait ! j’aurais été bien embêtée au moment de la migration vers un autre opérateur !
    Donc, pour ce qui est d’utiliser des applis “carrier” plutôt que Google, méfiance !
    Pourtant, Google n’est pas satisfaifant nonn plus, pour d’autres raisons.
    A une époque, j’ai écrit des articles sous pseudonyme sur leur produit Knol, maintenant disparu.
    Non seulement mes articles ont été perdus (ils ont abandonné le produit Knol), mais mon anonymat n’a pas été respecté et, pendant un temps, mes articles écrits sous pseudo dont parus sous mon vrai nom, associés même à des photos de famille mises imprudemment sur Picasa.
    Le chemin est encore long avant d’aboutir à un produit pouvant être regardé par le consommateur comme simplement correct, mais il est clair que, si vous réussissez à le créer, vous gagnerez des clients.
    Bien cordialement.

    Reply
  2. Monique Francois says:
    August 19, 2012 at 9:29 AM

    Je poursuis mes réflexions.

    Qu’est-ce qui pourrait faire que moi, consommatrice lambda, j’utilise mon opérateur téléphonique comme l’équivalent d’un Google, d’un moteur de recherche, d’un fournisseur d’applis ou d’un navigateur ?

    Je pense que je le ferais tout naturellement si mon ordinateur et mon téléphone fixe convergeaient vraiment pour ne faire qu’un seul objet QUI MARCHE (l’idéal serait se de débarasser de la box au passage). Actuellement, le “triple play” n’offre pas une vraie convergence. Les objets sont distincts, envahissement tout l’appartement avec leurs fils, et multiplient les occasions de pannes non résolues.

    L’objet fixe idéal pour moi : un vrai ordinateur avec un vrai clavier et une vraie souris me permettant d’écrire une vraie lettre, et de lire un vrai site internet sur un écran d’une dimension suffisante pour pouvoir véhiculer une vraie information.

    Le téléphone pourrait ne faire qu’un avec ce vrai ordinateur. Ce n’est pas le téléphone qui prend le plus de place. Il faudrait que la fonction téléphone de traduise par un simple bouton à pousser sur l’ordinateur, ce qui ne devrait pas être très compliqué puisque nos ordinateurs ont déjà le son.

    Dès lors que l’ordinateur fixe et le téléphone fixe auraient convergé, c’est tout naturellement que cet unique objet pourrait fonctionner avec un navigateur, un moteur de recherche, des applis, fournies par l’opérateur téléphonique.

    Je distingue cet objet fixe, que j’appelle de mes voeux, du “smartphone” qui, certes, est à la fois un ordinateur et un téléphone, mais trop petit (même les tablettes) pour lire un vrai texte ou pour écrire confortablement.

    Sauf dans les pays émergents ou chez les gens très pauvres, le smartphone ne peut remplacer l’ordinateur.

    C’est un objet d’appoint pratique par se mobilité, mais ça reste un objet d’appoint. Qui peut d’ailleurs être utilisé dans le bonnes conditions de confort si l’on joue la complémentarité avec l’ordinateur/téléphone fixe (au lieu de viser le remplacement). Par exemple, il est très pratique de remplir les coordonnées s’un contact sur l’ordinateur fixe dans de bonnes conditions de confort, et de trouver ce contact déjà rempli accessible d’un clic le jour où l’on a besoin d’envoyer un mail de son portable alors qu’un est en déplacement. Car évidemment, même si “faut pas le dire”, chacun sait que c’est une vraie galère d’utiliser l’écran d’un smartphone pour remplir ne serait-ce que le nom et l’adresse d’une personne.

    Reply
  3. Stephen Percoco says:
    August 21, 2012 at 1:30 AM

    Laura,

    This really sounds like an impressive effort and a valuable service to offer to your customers. I was just wondering, though, how Alcatel-Lucent measures the success of this effort, especially since it is making this freely available to the API community? I understand that anything that helps your customers make money and drives greater usage over their networks is beneficial to you. I am sure that they appreciate Alcatel’s efforts here. Still, unless you have some way to measure your success. it seems to me that it is difficult to justify the effort. If the service is valuable, won’t the users pay for it? If offering it for free helps drive usage, can you point to specific examples where Alcatel-Lucent has won new business that it probably would not have received without your service offering? Sorry to sound like one of those corporate types who can make your life miserable, but without clear and tangible payback, your competitors are simply getting a free ride. You probably have had these internal discussions already (at least I hope you have). Of course, you need not provide me with the details, but hitting the high points of this issue would be useful to me (an analyst who follows Alcatel-Lucent).

    Reply
    • Laura Merling says:
      August 27, 2012 at 4:00 AM

      Stephen – all very reasonable questions. The high level summary below should provide some answers to your questions.

      Measuring Success
      We built the methodology on 2 years of extensive customer engagement and interaction. We measure our success of our methodology and services based on our customers’ success. They want a partner, not just a vendor. Through the methodology and focusing on real problems and identifying opportunities, our customers will have clear metrics.

      As an example, using our methodology, one of our customers has identified 4 measures of success and is tracking them closely. We are actively tracking their goals in parallel. The first measure is the ability to reduce time to market for new service offerings from 18 months to 6 months. The second measure is to reduce cost of delivering new services to market by 20%, the third is to increase usage of different aspects of the network capabilities, and finally, and what they deemed import but not primary, is to see an increase in revenue over time for particular network capabilities/investments.

      YouConnect is another great example of leveraging the methodology to partner with our customers and where we have identified tangible measures of success. We assisted our customers on identifying the real world business problem to solve for a vertical industry, we continue to assist them in building the mobile retail ecosystem, and lastly, we leverage our technology and services expertise to execute the strategy. The initial milestone was the launch of the beta program itself with a few key retailers. Ongoing milestones range from adding members to the ecosystem to revenue targets.

      Value of the Service Offering
      People are willing to pay us, and have been paying us, for the consulting and professional services leveraging the methodology. We have made the methodology available under Creative Commons to realize the parallel benefits to the Open Source model. As we have seen with the Internet, open infrastructure delivers tremendous value to commercial players who then add value with proprietary elements.

      Over the last few years, we have not only been building the skills and expertise of our people in our product organization to support Application Enablement and Cloud Computing, we have also been building software assets that map to each phase of the lifecycle. A few examples of value added elements unique to Aclatel-Lucent include our Business Management System and our Service Composition Framework. The Business Management Engine is built on the core principals of cloud and has the flexibility to support highly customized and complex billing models that will address the network as service models of today and tomorrow. The service composition framework (SCF) asset is used as part of the design process for reducing the complexity of network services such as call control or quality of service so they can be easily integrated into third party software or platforms.

      A Free Ride
      The methodology is only part of the equation. The skills, the products, and putting together a cohesive set of offers takes a tremendous effort. With the methodology we have given our customers control over their destiny. Service Providers now have a set of standardized best practices they can leverage to drive their success. If the industry can agree on a methodology, it puts the onus on each vendor to provide the software and services that align with customers needs. The launch of our new consulting and professional services practice and related API Lifecycle Methodology expands the reach and relevance of the product portfolio and creates greater opportunities for differentiated services-software offers as part of our overall Software, Services, and Solutions Group.

      Best regards – Laura

      Reply
  4. Monique Francois says:
    August 23, 2012 at 6:02 AM

    @ Stephen Percoco,
    Vous êtes surpris et choqué que cette solution soit placée sous une licence ouverte, c’est à dire qu’elle ne soit pas protégée par les droits d’auteur.

    Moi, au contraire, cela me rassure DANS C CAS PRECIS (bien sur, en général, il faut se protéger par des brevets, mais ici c’est un cas particulier.

    Je ne suis qu’une petite actionnaire, pas du tout dans les secrets des décisions de l’entreprise, mais je me rends compte qu’Alcatel Lucent se bat très fort (et pas toujours avec succès jusqu’ici) pour promouvoir son idée de High Leverage Network, c’est à dire de réseau qui peut rapporter de l’argent. L’idée est de prendre la place des “over the top”. Dans ce contexte, il faut être ouvert. Pas question pour le client de ne pouvoir communiquer qu’avec des clients du même réseau. Et pas question non plus d’être “marié” à son fournisseur d’accès, et menacé de perdre ses données mises sur un cloud en cas de changement de fournisseur.

    Il faut que les applications soient transportables d’un réseau à l’autre, ce qui suppose aussi une forte standardisation pour pouvoir être lues confortablement sur toutes tailles d’écran et dans toutes sortes de contextes.

    Dans un tel contexte, il faut être ouvert. Du moins, au niveau de la conception des applications.

    Je ne crois pas qu’Alu ait de l’argent à se faire sur la conception d’applications directement. Ce qui compte est que la facilité de développer des applis serve de levier à la meilleure compréhension de l’idée de High leverage network.

    Reply
  5. Simone Longoni says:
    August 24, 2012 at 11:35 AM

    Thanks Laura for the interesting article!
    Being it in English, I would have appreciated also comments to be in the same language.
    Cheers, Simone

    Reply
  6. Letacla says:
    August 24, 2012 at 4:48 PM

    Bonjour,

    Alcatel-Lucent étant une société francaise, j’apprécie les articles en francais ainsi que les commentaires dans la même langue.

    Cordialement

    Reply
  7. Monique Francois says:
    August 24, 2012 at 5:34 PM

    @ Simone Longoni

    Je suis l’auteur des commentaires dont vous regrettez qu’ils ne soient pas en anglais. Votre remarque s’adresse donc à moi.

    Je me permets de vous répondre que cette remarque est déplacée.

    Je suis française, je parle français, et je me demande bien à quel titre vous faites remarquer que cela ne vous convient pas.

    Mes remarques ont pour but de comprendre mieux la stratégie d’Alcatel Lucent, ceci dans un contexte assez anxiogène pour moi : je suis actionnaire, je m’inquiète de la chute continue de l’action et je me demande si l’on peut espérer un redressement.

    Dans ce contexte, je serais parfaitement fondée à dire que je ne suis pas satisfaite d’Alcatel Lucent (à cause du cours de l’action et de la stratégie souvent illisible).

    Ce n’est certes pas à Alcatel de me faire la leçon (de me dire en quelle langue je dois parler). Je ne suis pas une salariée d’Alcatel et je ne lui dois obéissance à aucun titre.

    Reply
    • Simone Longoni says:
      August 27, 2012 at 9:48 AM

      @Monique,
      Sorry but even Google Translate was not enough to help me in completely understanding your reply.
      Good luck with everything.

      Reply
  8. Adam Wilson says:
    September 7, 2012 at 1:28 PM

    Hello Laura,
    I’m very interested in your article and believe this to be a positive activity in light of the challenges faced by the operator and developer communities. I’m now wondering if your message to the mobile operators especially could be extended to the management of the software assets they generate and make available to a wireless device, such as a Smartphone? My company has a rich heritage in providing firmware over the air updating and recently launched an offering for service providers to help them manage (push, update, remove) and monitor their software assets (service applications), so I’m curious to evaluate if this could be complimentary to the API lifecycle methodology from Alcatel-Lucent? I would be grateful for your initial thoughts and reflections on the subject. (Rhetorical question being, if you’re helping them expose network-assets and create services quicker, could the story be extended and potentially even enriched by offering them the possibility to manage and monitor the lifecycle of the resulting software asset/service application?)
    Regards,
    Adam Wilson.

    Reply

Post a comment

Comments are moderated and will be published/addressed upon review. Your email adress will not be published.

Required fields are marked *

*

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Legal disclaimer
People posting to this web site, including moderators and authors, may include employees of Alcatel-Lucent. Opinions and comments expressed herein are the personal opinions of the commenter, not of Alcatel-Lucent. The content provided here is for informational purposes only. It is not intended to be an endorsement or representation by Alcatel-Lucent or any other party. This web site is publically accessible. Do not post any information you consider confidential to this site. Do not post any personal data related to others unless you have their consent. By posting content to Alcatel-Lucent's The Blog, you agree to be solely responsible for all information you contribute and thereby release Alcatel-Lucent from any liability related to your use of this site. By contributing a post, you also grant Alcatel-Lucent all rights to any original content you provide.