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.
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…
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:
- 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.
- Voice – Skype and VoIP providers have been attacking voice calls for years. However also here smart phones are accelerating decline.
- Roaming – Apple’s independent SIMs could easily attack the roaming segment. Also VoIP on Smart Phones will.
- 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.
- 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.
- High-speed interconnect networks – Google is paying part of some of the under-sea links that connect multiple Asian countries.
- Fiber to the home – Google is rolling out fiber to the home.
- VAS – mobile apps are taking over from the value-added services.
- PBX like Business solutions – on-site premise equipment is being substituted by virtualized Cloud-based solutions.
- 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 😦
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 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.
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…