Archive

Archive for November, 2010

The intelligent network is death, welcome the dumb network!

November 30, 2010 Leave a comment

SS7 networks or “intelligent networks” have been the core reason why network-based services can not be rolled-out quickly. Specialized skills are needed to launch a new SS7 service.

Currently operators are investing in service delivery platforms or SDPs to move the network intelligence out of SS7. These SDPs will be holding modern copies of the SS7 services.

However do we need intelligent networks? Why can’t we have dumb networks?

The Internet is a dumb TCP/IP network. Intelligence is not in the network but in the applications that run on top of it. Why are telecom networks different? Why do routers have to know if the application is voice, SMS or data? Why does the network have to know about conferencing, numbering plans, etc.?

One example: MSISDN

Why do you want to hard-code an end-user identifier throughout your network & billing systems? Why can’t we have a mechanism like a unique IP address and several DNS names for it. I don’t want to learn a long list of digits to identify a friend. I would like to control my own numbering plan. My direct family starts with 1xx. My friends 2xx. Alternatively I can use their email. I should be able to call a company with its DNS. Ideally I can use the Facebook or Twitter id as well. This would all be possible provided that an internal identifier would be mapped to an end-user identifier instead of using one unique identifier.

Example two: CDRs

Why should every network element know that for every call you need to generate a CDR. However for data, charging is not based on seconds or minutes but data volume? Cannot the metering be done outside the network? Why are we generating millions of CDRs when end-users have a flat-rate or are calling a free number? With software-as-a-service metering can be different per application (pay per GB of storage, per MB of network traffic, per user per month, per company per year, etc.).

The proposal: Define the metering mechanism for each call, SMS or application ad-hoc and use specialized meters outside of the network to meter the service. Time-based meters allow any type of data to pass through to the network but will bill by nano-second, millisecond, second, minute, hour, day, week, month, year, etc. You just configure that this voice application needs second-based billing, that adult entertainment application needs minute-based billing and that compute server needs hourly-based billing. Flat-fee calls would not have to be metered and as such don’t need a meter. Meters could be gateways that scan if data goes through. However they could also be event-based and delegate complex metering into an application to warn them when an event has to be billed, e.g. application download, new user registration, etc.

Simplifying the network by taking out complexity to manage/launch/meter/monitor services would substantially reduce the cost of network equipment. Perhaps to such extend that it becomes too small to meter services and as such also metering can be eliminated. Pure bit-pipe operators could probably do with an Excel or Access database as their billing system.

Advertisements

The CFEO and the nerd make room for the CBIO

November 25, 2010 Leave a comment

At the end of the nineties Sillicon Valley was nerd paradise. Every technically skilled person could have a chance on getting excellent working conditions and maybe become rich. The bubble burst. No more unprofitable dotcoms and the end of telecom innovation paradise. Shorts in the office were replaced by ties.

The new ruler of the world was the CFO, who was first promoted to COO and afterwards to CEO, shortly CFEO. Shareholder value, CAPEX and OPEX were the new buzzwords. Creative accounting the solution to revenue problems. The current crisis is showing the limitations of focusing only on cost reductions and not on growing the business via innovative products and services.

It is time for a new class of rulers, the CBIO. The ideal profile is a generalist with a technical background, knowledge of financials, operating experience and an innovative strategist. This person does not have to be an expert in all domains but have at least a good understanding of each and be able to surround him/herself with experts in these areas. The CCO will understand that there are two types of technical projects: routine and innovative. The routine projects should be executed in the cheapest fashion possible: Cloud Computing, Off-shoring, Open Source, etc. The innovative projects will make the difference between global leadership and bitpipe doom in the next 12-36 months. No single RFQ process has brought innovative results to any operator that got front-page news coverage. So innovative projects should not be handled by an RFQ. The telecom operator should be split in two units: “Business as Usual” and “New Business”. The “Business as Usual” should continue to focus on shareholder value, CAPEX and OPEX and become a best-in-class bitpipe. The “New Business” should launch on a weekly basis new services and features to quickly understand what works and kill those things that do not. If the “Business as Usual” systems are not delivering the results the “New Business” needs then they should be allowed to shop elsewhere, even shop with competitors! The “New Business” should focus both on hits as well as long tail services. Giving end-users the choice between millions of services instead of only Voice and SMS. Focusing on the why people communicate and not the how.

Failure to recruit a CBIO will result in the “Business as Usual” becoming a bitpipe but the “New Business” being called Google Voice, Facebook Seamless Messaging, Apple App Store, etc.

CBIO stands for Chief Bitpipe and Innovations Officer…

My telecom assets are under attack. What should I do?

November 22, 2010 2 comments

The last player to join the attack on the telecom operator’s business is Apple: How to bypass carriers, Apple-style? (Special thanks to Dinesh Vadhia).

Apple never played according to the telecom rules in the first place. They have been the only mobile hardware vendor that could set the rules instead of negotiate them.

Who is attacking my assets?

So which telecom assets are currently under threat:

  1. SMS – instant messaging has been attacking SMS for years but now with the next generation of smart phones the number of SMS killer apps has exploded.
  2. Voice – Skype and VoIP providers have been attacking voice calls for years. However also here smart phones are accelerating decline.
  3. Roaming – Apple’s independent SIMs could easily attack the roaming segment. Also VoIP on Smart Phones will.
  4. Billing – Micropayment solutions from Paypal and Google Checkout are trying to enter this domain. Squared from a former Twitter-employee is attacking the mobile payment terminals in shops.
  5. Spectrum – Google’s CEO is the chairman of the New American Foundation that is trying to convince the American government to open medium-distance spectrum for free. Sort of WiFi but with kilometers reach.
  6. High-speed interconnect networks – Google is paying part of some of the under-sea links that connect multiple Asian countries.
  7. Fiber to the home – Google is rolling out fiber to the home.
  8. VAS – mobile apps are taking over from the value-added services.
  9. PBX like Business solutions – on-site premise equipment is being substituted by virtualized Cloud-based solutions.
  10. The telecom network – telecom operators are becoming bit pipes. New bit-pipe-only companies however are trying to specialize in this domain, making it hard for communication service-oriented operators to keep on making the same profits.

What should operators do?

If there was one simple answer, I would not be writing this post but living on my own private island 😉

However if history can be a teacher, let us look at an industry that has been facing similar threats: Hollywood. Prices of distributing digital content have fallen close to zero. However the industry has been trying to keep on charging €12-€30 for CDs and DVDs. They have hardly embraced digital distribution and are now in a negative spiral of demise.

Telecom operators can easily get stuck in this same vicious circle. History has been cruel in the past: extremely lucrative postal monopolies were destroyed by email. There is no rule that states that economic wealth from one business model is substituted by a similar lucrative business model afterwards. Often analogue dollars are traded for digital pennies.

Accept digital pennies but collect them all

The first survival strategy is to embrace change and to go for digital pennies. This is often hard to do within existing companies. As such the proposed strategy is to set-up a parallel organization whose objective is to focus on these new business models and how to make money with them. Let the main company focus on the telecom hits (Voice, SMS, etc.) and the other company on the long-tail telco services.

Long-tail telco services are all about enabling communities of developers and companies to create new and innovative telecom solutions that they can sell to others. The focus should be on enabling others. Not on building them yourself. Being an App Store for telecom network-assets-based applications and not a builder of telecom services.

This parallel organization should be in close collaboration with partners and even dotcoms. If you can´t beat them, join them. Find ways of enabling startups to become successful with your network and other assets, not on building a parallel solution around your assets.

The music industry never understood this message but hopefully the telecom industry does.

Go IP and forget Circuit

Accelerate IP solutions and forget about circuit networks. The speeds at which services are rolled out in a circuit-based network are too slow to fight off competition. Isolate the circuit-based network elements and put an IP-based front-end.

Use the Cloud to quickly launch beta services.

Avoid building infrastructure and use the Cloud to innovate. In the telecom world services are often not launched until they are perfect. But perfect for who? It is better to launch beta services quickly and get real customer feedback instead of marketing-surrogate feedback. Launch multiple services. Check which are the successful ones. Kill the others and heavily invest in the successful ones. Cloud computing and open source can dramatically reduce innovation costs.

Build long-tail services and a common innovation-ready architecture

If you are going to work with hundreds of partners to quickly innovate then the way to interact with them is via self-provisioning. Build billing, telco network app stores, customer care, monitoring, etc. solutions that allow a third-party to automatically provision and test their solutions. Be open with interfaces and light on approval. Let them approve a web-based contract instead of sign a physical paper.

Also enable innovation via the right infrastructure. Let teams focus on the business and services. Not on storing data, managing users, billing, monitoring, etc. Common service APIs to interact with assets and common ways of building new services should accelerate time to market and avoid reinventing the wheel.

This is a time for innovation together with smart partners. Not a time to focus only on CAPEX reduction. Too many effort is spend on operating as cheap as possible and not on generating new revenues. At the end the best CAPEX reduction is to shutdown a telecom company that does not innovate at market speed and became obsolete 😦

 

Infrastructure automation is key to accelerate time-to-market.

November 20, 2010 Leave a comment

Most telecom projects involve installing an Oracle RAC cluster, a SAN, application server clusters, etc. Only the time it takes to procure and install the basic hardware and software takes months. We are not even talking about the costs…

If you want to launch new ideas every month, you have to use Cloud Computing. This can be public cloud, private cloud or hybrid cloud. However even then too much time is spend on installation and configuration of software.

Infrastructure Automation

Infrastructure automation is about making a team productive in quickly launching new services or updating existing services. Infrastructure starts with having a standardized development environment, automated build tools (e.g. Maven or Ant for Java), continuous test automation (junit but also Hudson or Cruisecontrol), etc. The next step would be to also automate deployment (e.g. Puppet & mCollective from PuppetLabs) of server software and Cloud infrastructure.

This type of automation  is often 90% equal so having a standardized framework would extremely shorten the times to get software development up and running as well as deploying it into test and production environments.

This would however only be the start of the journey. Dotcoms launch new features on a weekly or even daily basis. They monitor in detail what users do and often launch multiple alternative versions of a new feature. Gradual deployment of small features allows to see performance problems strait away and avoids extensive regression tests and fast rollback.

Let’s see how this could be applied in telecom.

The key to success is copying Google. Google is having standardized architecture components that are reused among different teams (e.g. BigTable). By building up a shared infrastructure and the tools to quickly deploy new services onto it or update existing features, time to market can be dramatically reduced.  Infrastructure is a secret competitive weapon that too few companies use.

The power of S4, Yahoo’s distributed stream computing platform, in telco?

November 14, 2010 Leave a comment

In October 2010 Yahoo made another internal system open source: S4. S4 is a general-purpose, distributed, scalable, partially fault-tolerant, pluggable platform that allows programmers to easily develop applications for processing continuous unbounded streams of data.

After looking at the current code and documentation it is clear that this is an alpha project. Yahoo seemed to have stripped everything useful and is rebuilding the product almost from scratch. However this does not take away that S4 can in the near future become as important as Hadoop.

Hadoop is becoming the default standard for extremely large batch data processing. The word batch is important because low latency systems are not getting a lot of benefits from the Hadoop framework. In the telecom domain low latency is exactly the type of processing that is key. You don´t want to have voice or video to arrive late or unsynchronized.

S4 promises to focus on real-time high-volume data streams. It is unfortunate that the current code is not better documented and that Yahoo decided not to open source some examples around computer learning, etc.

The S4 framework should excel at taking rapid computational decisions for event-driven systems. This makes it a possible candidate for a long list of telecom domains: everywhere from network routing decisions, real-time billing, policy control, voice recognition, natural language processing, advertisement, etc.

Of course the S4 design is not new in the industry. Erlang and Scala have an Actor framework that can be seen as a more basic version of S4. Even some java implementations exist.

The power of mixing in Zookeeper and a pluggeable architecture can set S4 appart from previous frameworks. However more developers will be needed, more documentation but more important a re-usable library of processing elements. Having such a re-usable library would allow new applications to be built via configuration of processing elements instead of writing code.

Although S4 is still in an infant state, the potential to be a core compontent in a future telco 2.0 architecture is there…

 

Marketing’s and IT’s loss of power

November 4, 2010 Leave a comment

In Telco 1.0, “marketing” decides what customers want and “IT/Network operations” will take 12 months to roll out the new service.

In Telco 2.0, the marketing department no longer decides what customers want and IT/Network operations have 3 months to roll out hundreds of new services.

Impossible?  What is Telco 2.0?

Telco 2.0 is the age where Internet technologies and business ideas meet the telecom world. What are these new ideas?

1. The customer is always right

No group of marketing experts is better able to predict what customers want then the customers themselves. In the dotcom world, customers are in control. They get an avelanche of services and options and via other people’s rating, comments and collective intelligence are able to decide what best suits them. Instead of launching one new release every 6 months, dotcoms launch new incremental features on an hourly, daily or weekly basis. Often several alternatives for the customer to pick from. It is the customer that decides what is right for them and what can be killed quickly due to lack of interest.

2. Give the customer control

If the customer knows what they want then they should be able to get it and if it is not available build it themselves. The explosion of Appstore apps shows that different customers like different things. In the next 12 months we will see VAS stores and build your own VAS designers allowing users to build or configure their own value-added services.

3. Allow the customer to make money

Whoever builds a great VAS should also see an abundant reward for it. High revenue shares for innovative thinkers are becoming the trend. Consumers selling solutions to consumers is no longer an exception.

4. Be the enabler instead of the break

Trying to stop innovation is useless. The Skype’s, Google Voice’s, Twilio´s, Tropo´s, Ribbit’s, etc. are unstoppable. Join the enemy and enable people to use your assets. Otherwise they will find ways around your assets, sooner than later. Think about what happened to location-based services…

5. Think Global and Volume

Local solutions are likely to be copied by others. This is a winner takes it all market. Think global. If you are not global, find a global partner and non-competing other operators and join hands. The money is in the volume. With 1M VAS people are likely to communicate more than before.

6. Analog dollars for digital pennies

The “Free economy” is changing more than one existing business model. Don’t think that because in the circuit world you can charge 15 cents/message that in the IP world you can charge the same. The music labels have found out that if you keep on charging a high price, piracy will rule. Does it mean that everything has to be free or losses are guaranteed? No, also not. However history has shown that technology (r)evolutions can destruct a business model without replacing it with an equal lucrative one:  think stamps and emails. The new economic rules dictate that scale and long tail attrack money. Google changed the ad industry from high priced TV ads to low priced adwords. However since they fully automated the process, the scale is enormous and so are the gains. So to be successful in the new telco 2.0 world, you need to offer thousands of services and make money with volume not with individual services. Who better can dominate a world for nano payment then the world leader of micro payments a.k.a. billing and charging.

The new role of marketing

Marketing will no longer be about evaluating which services customers might like and at what price.

Instead the focus will be on finding the right enablers for customers to build and configure the services they want. Afterwards these services can be offered on an open marketplace for others to buy and sell them.

Listen to what customers say on social networks.

Use number crunching on large volumes of data to understand hidden trends.

The new role of IT and operations

A telecom architecture is one of the most complex architectures to explain to non-telecom experts. A new generation of dotcoms are coming up with alternative architectures that separate execution from data and application logic. If you don´t know Google App Engine, take a look how applications are deployed onto a “virtual” application server and data is stored in a “virtual” database. Exactly this concept is what is needed for the next generation of telco services. You deploy telco apps on to a “virtual” service delivery framework, with access to telco assets via APIs and to unified subscriber data in a “virtual” datastore. IT should be the enabler of launching services and not the one that focus on building the services.

%d bloggers like this: