Posts Tagged ‘Asset Exposure’

Five new businesses for Telefonica Digital

September 21, 2011 3 comments

Telefonica recently restructured its business units and now has a separate business unit called Telefonica Digital that is ran from the UK and has several offices around the world: Sillicon Valley, Madrid, etc.

Telefonica Digital is a clear sign that the traditional telecommunication business is no longer going to be the growth engine for Telefonica. So what should Telefonica Digital focus on. Here are five ideas. Some are already partially in progress but ease-of-use, consistency and completeness often can be improved.

1) Become the European Netflix

Google and others are likely to enter into the European market for all-you-can-eat video-on-demand, a.k.a. pay a monthly fee and see all movies, music, series, documentaries, etc. you want. Netflix is the American success story however there is still a window of opportunity to become the European one. Having great content is key in this market. However the most important competitor is not a company but a protocol: P2P. Some European countries have high piracy rates. People are getting accustomed to downloading movies and music for free. The longer Hollywood holds on to high prices in the digital age, the more chances there are that people will not want to pay any more for content. Even when all-you-can-eat service becomes available. Sometimes it is better to have every family pay €15/month then to have almost nobody pay €20/DVD.

2) Long-Tail Partner Eco-System

Open system for partners, big and small, to easily integrate into Telefonica’s back-office systems. Partners should be able to:

  • charge customers and handle recurring subscriptions
  • have single sign-on solutions and access to user profiles
  • update Telefonica’s inventory and CRM systems without magic
  • provision Telefonica’s base services (e.g. numbering plans, VLANs, etc.) in one-two-three
  • long-tail monitoring and alarming
  • long-tail settlement engine
  • long-tail support systems
  • Escrow and standardized contracts
  • Standard revenue sharing arrangements in which partners get the lion share.

Having a long list of long-tail partners will boost innovation at a relatively small cost. A regular operator takes 12-24 months from idea to production launch. In the digital era, new services should be launched daily. Without partners this is impossible. Telefonica should focus on lowering the entry level so two people in their garage can benefit as well.

3) Telco & Mobile PaaS

Offer easy to use telecom APIs to key assets like billing, network quality of service, user profiles, micropayment subscriptions, etc. Allow developers to integrate these telecom APIs into SaaS and mobile apps/SaaS. Have tools to easily create mobile SaaS and native apps. A cloud-based environment to host SaaS. Have a marketplace where customers can easily buy and provision the combined solutions. Solutions to support customers that need help for solutions they have purchased.

4) M2M PaaS

Similar to Telco PaaS but for machine-to-machine and the Internet of Things. Specific hardware plug-and-play functionality, backoffice plugins for monitoring/alarming/management interfaces, etc.

5) The Paypal of Mobile Payment

Operators have a limited time left before alternative systems will disrupt the micro-payment “oligopoly”. NFC solutions, micro-payment subscriptions, mobile payment, etc. are still not standard. Mostly not because of technical limitations but because the whole eco-system wants to see a high margin business. High-volume low-margin would however change the potential of short-term success. What if a micro-subscription (€0,10/month) would leave a merchant with €0,09 instead of €0,05 or less? The window of opportunity is closing fast however…


Ten Times Faster Time-to-Market for Telco Innovations

September 27, 2010 Leave a comment

Google has changed very little to its basic architecture building blocks over the years. Everything runs on top of the Google File System and Bigtable. Except for Google Instant which is reversing Map-Reduce usage, new services have been reusing their existing architecture.

Similar observations can be made for the rest of the main players. So why is it that Telecom operators have not invested in one architecture to launch multiple services? No idea.

One architecture for VAS

The concept is simple. Create one common architecture. This architecture should have multiple components:

  • A high-available real-time data store – stores all application and user data
  • A right-time data analytics service – allows collective intelligence and data mining
  • An asset exposure layer – applications can re-use network assets and get isolated from internal complexities
  • Presentation layer – facilitate mobile GUI and Web 2.0 development
  • Application Engine – allows applications to run and focus on business logic instead of scaling and integration
  • Continuous Deployment – instead of monthly big-bang deployments, incremental daily or weekly releases are possible, even hourly like some dotcoms.
  • Unified Administration – one place to know what is happening both technically and business-wise with the applications.
  • Long-Tail Business Link – all business and accounting transactions for customers, partners, providers, etc. are centralized.
  • etc.

Having such an architecture in place would allow telco innovations to be brought to market at least ten times faster. Application and service designers would have to focus on business logic and not on the rest. Administrators would have one platform to manage and not a puzzle of systems. Integrations would have to be done ones to a common integration layer.

Building such an architecture should be done in the dotcom style and not a telco RFQ. Only by doing iterative projects which bring together the components can you build an architecture that is really used and not a side project that starts to have its own life.

It even makes sense to open source the architecture. Telco’s business is not about building architectures hence having a common platform that was started by one would benefit the whole industry. It even would give a competitive advantage to the one that started the architecture for knowing it better than any competitor. Of course for this to happen, a telco has to recognize that their future major competitors are not the neighboring telco but a global dotcom…

Complex telecom net apps made easy

September 15, 2010 Leave a comment

Too many people in the telecom industry are still discussing which API is the best: Parlay, JAIN SLEE, Sip Servlets, GSMA OpenAPI, etc.

The Web 2.0 world is moving away from all these APIs to create telecom network applications a.k.a. Net Apps. If you want to see easy APIs to create Net Apps then look at Twilio or Tropo.

However even these APIs are too complex for some people. In this case you can use graphical drag-and-drop environments like for instance QuickFuseApps. You can also opt for flash modules that give you all the functionality you need. Ribbit has some nice ones.

Also on the phone side, drag-and-drop is coming on strong. Google´s App Inventor for Android is a good example.

What does this mean? More and more developers and end-users will be able to create Net Apps themselves. These Net Apps will quickly become complex applications that will often bridge the gap between mobile devices and server & cloud solutions. They will very likely also span every aspect of daily life, e.g. social networking, business, entertainment, etc.

What does this mean for an operator? All the effort that is now put into creating attractive services will no longer be useful. A one-hundred person marketing team can not launch more and better services than a one-million net app creators community.  So instead of focusing on finding and developing the next killer app, operators should focus on two aspects:

  1. Making sure all the building blocks are in place for the net app creators community to be productive.
  2. Connecting end-users with the proceedings of the net app creators community. In other words: make sure people find the right net apps.

 The stakes are high because this is a winner takes-it-all game. Speed, easy of use, direct community feedback will be key. What are you waiting for?

Are you exposing assets the wrong way?

September 13, 2010 Leave a comment

The standards API myth

In the perfect API we talked about how to expose assets. Simplicity is key. The general telecom thinking is to go for standards. However in the dotcom era standards are set by the one that innovates quicker and better then the rest.

The iPhone does not support Java or Flash [yet]. Skype did not build a SIP-compatible service. Facebook does not expose a standard Opensocial API.

Many operators are focusing on the GSMA OpenAPI and other API standardization efforts. However all these standards often are designed by “experts” that have not programmed in the last years. Startups focus on making it simple. Launching something quickly and making incremental changes and extensions on a weekly basis. The only way to create a successful API is to constantly listen to the community of programmers that are using it.

Dotcoms are bitpipe creators

Many operators still consider their most fearsome competitor the other operator that shares the same country borders. Unfortunately it is not this competitor that will potentially render them into a bitpipe.

If you are exposing assets, it should be because of two reasons:

  1. You want to make some extra money.
  2. You are afraid that if you don´t expose your assets, then some dotcom will find a way around them, e.g. Google Latitude and location assets.

What are you exposing?

Ok, we finally got the agreement from management to expose APIs so let´s start with SMS and MMS… Wrong! There is absolutely no shortage on the Internet for ways to send an SMS. Additionally MMS is becoming less important with all the email enabled phones.

What should be exposed are those assets dotcoms are not offering yet! Why? Selling something that others already offer cheap is not a guarantee for business success. Selling access to assets that only are available through you, makes for a great differentiator.

Offering assets as-is will not be very successful either. One example: If I can only generate standard numbers which follow the official numbering plan, why would I need an API. Any VoIP DID provider can get me a phone number. It would be different if I could generate “un-official” numbers that don´t cost me €5/month but instead can even generate revenue. Send an email to maarten at telruptive dot com if you want to know more!

One-stop shop

Developers of telecom services want one thing. Fortunately this one thing is not new. A developer wants to make an application that they can easily sell to as many people as possible. Several startups exist that allow developers to create very advanced call-control, conferencing, etc. applications. However this is only one side of the story. Even if I can build the best voice conferencing bridge, that does not make me a millionaire. Developers need the channels to market their applications and make money with them. They need a “Net App” store.

Open versus Closed

If we are not competing against another operator but against dotcoms, why can´t we work together? American Airlines build their reservation system and afterwards allowed other airlines to use it. It quickly became the standard.

An open platform in which developers can write ones and sell everywhere, will prevail over closed platforms. Facebook allows companies to extend its platform. By being the market leader, it attracts a disproportionate number of partners to its platform.  The iPod has probably more extensions and add-ons then the next five competing products together. If you are not willing to open your platform then you are probably not going to be the market leader.

Try often, kill quickly

September 8, 2010 1 comment

When the words “technology and innovation” come to mind, most people think about Google, Apple, Amazon, Facebook, Salesforce, etc.  Just a few think about telecom operators. The biggest telecom innovation has been mobile voice. SMS was never a technological innovation but an unplanned surprise success. MMS never got close to SMS. The iPhone and Android did not come from any telecom operator or provider.

Why is it that five people with a limited budget in months are able to stun the world whereas massive multinationals with deep pockets are not?

The reason is simple: “To innovate you have to try often and kill quickly”.

Google launched Wave in the beginning of this year. Google “killed” Wave about 6 months later. Every day Google makes a change to their search algorithm.

The current process

The cost for a telecom operator to innovate is massive. A simplified process would be the following:

  1. The marketing department receives calls and visits from every possible telecom provider on a daily basis.  New ideas are thrown on the table to see if they stick.
  2. The marketing department selects the best ideas.
  3. These ideas are scanned by the different other departments, e.g. operations, finance, legal, IT, etc.
  4. A multi-disciplinary team is assembled to write the requirements for the new service, a.k.a. RFI.
  5. Several possible telecom providers receive the RFI and provide a response.
  6. A budget is allocated based on the responses and an RFQ, request for quotation, is organized.
  7. Several telecom providers respond to the RFQ.
  8. A bidding war is started and one or two winners are selected. If there are no clear winners then a proof of concept is requested.
  9. The winner develops the solution. Operations, IT, marketing, legal, accounting, etc. all work together to launch the new service.
  10. The service is launched.

The whole process easily can take a year or more and costs multiple millions. If this would be your money, you would be very careful how you would spend it as well. The end result is that only a handful of new services are launched. Only those that are expected to be immediate successes.

This process is a very “useful” process for driving down large integration and network equipment costs. However it is not an innovation stimulating process.

How can you bring innovation back to telecom?

The first step is to avoid a small set of marketing people to take decisions on what is a good service or not. The only person that can legitimately decide if a service is good is the end-user.

The dotcoms therefore launch very often incremental and new services. They monitor in detail which ones, users like. It is even possible that different alternatives are launched in parallel to see which of them the users prefer. Direct feedback is critical. If a service is not picking up or users complain about it, it gets killed quickly. Services that get good feedback are continuously improved, based on user´s feedback.

How to apply “try often, kill quickly” to the telecom world?

The major show-stopper is the telecom architectural complexity. Although a marketing person has a good idea, it often takes months to update all the systems. The reason is that network operations, business logic and user data are scattered over multiple systems and departments.

To solve this problem, services and data should be separated from the network. Google´s technological differentiator is their generic data store a.k.a. Bigtable. Bigtable is an in-house developed generic high-volume, always-available data store. More than 60 services are reported to be using this common data store. Services as different as docs, maps, app engine, etc.

Google has over a million servers. Maintenance and operations are fully automated. Software is written in such a way that failure of hardware is assumed. Hardware are not top-end but instead commodity  rather low-end servers. Software can easily extend over hundreds of servers.

Applications are isolated and use the servers and data through standard interfaces.

I can´t throw away my legacy

Of course an established operator can not throw away their legacy systems. So until we have a common data store and isolation between software and hardware what can we do?

The trick is to start small, move quickly and use asset exposure. Isolate the legacy systems and expose simple APIs to the telecom assets. Via asset exposure a lot of the “hard-coded” SS7 services can be substituted with network intelligence in the cloud. Mini applications can be written by anybody from a large multinational to an individual developer. As long as users can pick their preferred services and applications from the “net app store”.

Data should also be transitioned to a common data store. In the beginning this might mean nightly synchronization of different silos. However little by little the common data store should become the master of the data. Dotcoms are no longer using sql database as a one-size fits all solution. Google, Yahoo, Facebook, Twitter, etc. all developed their in-house solutions and some even open sourced them.

Applications should be running on public or private clouds hence scaling up demand for the top applications during the day and well as scaling down during the night. This should control CAPEX of the hardware. Too much logic is packed into proprietary hardware. Software should be separated from hardware and written in such a way that it can scale to hundreds of servers.

Development teams should not have a contract of 12 months with a waterfall of requirements. Teams should be small (5-6) and have short iterations to deliver small incremental innovations. The dotcoms have a tendency to release new features multiple times a week. Even some multiple times a day. Get immediate feedback and kill if not successful. For telecom innovation teams to do the same, they should be multi-disciplinary. Ideally a mix of people from the operator and strategic partners. It pays off to have a common architecture to deploy the individual services quickly. It pays off even better to have an open API so the innovation team works on the infrastructure for others to innovate.

The small teams should have at least one person that is business and marketing focused and that has the commercial responsibility to make the service a success. Different small teams that have high pressure of time, innovate quickly. Pressure of time is also important. If there is no external pressure of time, then it has to be build internal. A simple technique is to allow people from all over the organization to take a break of their day job and to take part in an innovation team. They should have clear milestones. One month to come up with an idea. Two months for a prototype. Three months to launch the first beta. Two months to get user traction. Any milestone missed means the project is stopped or at least potentially stopped. Failure is not a shame. Quite the opposite. People will go back to their day to their day to day job with new ideas and new energy. After a while they might try again and have success. Innovation and failure go hand in hand. If you can not afford failure, you can not get innovation…

The perfect API

September 8, 2010 1 comment

Asset exposure is a hot topic in the telecom industry. Everybody is talking about opening up telecom assets for others to create new services. However I haven´t seen any successful asset exposure by the established operators yet. Why is this? Let´s look at the four major European players.

Vodafone calls network asset APIs,” enablers” and is offering mobile payment and location services. More is announced. Then again there is also betavine, oneapi and vodafone network apis. And we are not talking yet about widgets and mashups.

Telefonica has the movilforum, O2 litmus and the movistar developers platform.  A list of separate APIs is available with exotic names like “Manage Post Pay Bolt On’s API”.

“Orange developer” gets you in Google to all you need to develop. Unlike Vodafone and Telefonica.  A long list of APIs is available, including the personal profile api and the personal richprofile api.

“T-Mobile developer” also worked. Unfortunately there was no information for network assets API only mobile apps development.

There is one red line in this short test: “being a telecom developer is a hard job”.

Finding the sites with development information is hard. You would think that “operatorname +developer” should be enough to Google you there.

Understanding which API to take is even harder.  I don´t want to imagine writing an application with the APIs.

It is clear that European telecom operators would like to have an active developers community but they would need to understand some basic principles:

  • out of sight, out of mind
  • 80-20
  • simplificationality
  • eat your own dog food
  • make one millionaire
  • collective
  • compete against the dots

Out of sight, out of mind

If I can´t find your API in the first 5 Google items when I look for developer and your company name, then I will probably never write an application for you. SEO, search engine optimization, is the first mandatory step when a developer portal is launched. Your portal can be the best in the world but if I can´t find it then I can´t use it.


80% and even 95% of all applications only need 10% to 20% of the functionality. The telecom industry has made a habit of “over-standardizing” APIs. A simple example: sending an SMS. What does an application developer wants to do in 95% of the cases? Send “text A” to “number B”. Only 5% of the applications need a receipt that you actually read the SMS. Even below 0,01% would like the operator logo, the internal port for message delivery in the device, etc. to be available. So the trick is to have a very basic high-level API and if required a more detailed low-level API.


Why use “simplificationality” if you can use “simple”? Developers want to keep things simple. Programming is already hard enough. Standards bodies in the IT industry have designed the XML and SOAP standard to share unstructured data between as many systems as possible. Developers are neglecting both and are migrating to JSON and REST. A JSON document is a lot shorter and holds the same info. A REST API you can call from the command line. There is an interesting startup that has taken this simple principal and applied it correctly:

Eat your own dog food

A lot of startups are using the slogan: “eat your own dog food”. If you create something for others to use, then the first user should be you. Amazon created their web services stack for internal use and afterwards opened it up to the world. Until your services are not written with your API, then you should not open it up for others. After writing some services with your own API, you can be sure that it is fully functional, well documented and no longer has awkward glitches.

Make one millionaire

The economy is moved by the invisible hand which in human language means: “people are selfish”. I am prepared to suffer and write an application with your API as long as I have a change to become an overnight millionaire. Apple´s App Store has made for sure somebody a millionaire. As soon as there is one, there will be a million others trying. Make sure you share your revenue is based on the value contribution (Apple sells => 30%, developers invents and writes => 70%). If people feel they have an honest chance of becoming rich, then they will go the extra mile.


99.99% of all the apps that developers will write with your APIs will be rubbish.  However as long as users are able to easily find the other 0.01%, the operator will make money will all 100%. For users to be able to find a needle in a haystack, you need collective intelligence. People need to be able to benefit from viral marketing, recommendation engines, top 25, etc. in order for them not to have to waste their time. Early adopters will try out the bulk of the apps but they are only a minority. The rest of the mortals need to be helped. If I am looking for the coolest game, then it should be first in the list of games.  Apps needs to be automatically clustered, categorized, recommended, etc.

Compete against the dots

An operator´s competition for asset exposure is not your-next-door-operator but a dotcom that offers a way around your assets. For years operators sat on their location assets without exploiting them. Google came and wiped most of the value out with its Latitude, Maps and Goggles. Copy the dotcom technology and ways of doing things.

%d bloggers like this: