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…

A mobile virtual network operator, a.k.a. MVNO, is a telecom operator that does not have its own network. However what would happen if companies or even groups of friends could create their own MVNO.

These micro and nano MVNO’s would need tools that are directed at the size of their “customers”. A micro MVNO would span all employees of a company. Why would you want a micro MVNO? Enterprise contracts exist that have virtual numbering plans and a lot of more features. However you could extend the number of business and enterprise features a lot more and with a micro MVNO you would be able to provide a personalized experience to every company:

• Companies would be able to centrally define the pricing plans that best suite them. Even make custom pricing plans. Calling cheaper during working hours, even if those working hours are different from the “normal” data plans. Cheap pricing to call to customers and partners. Calling from the network cells around the office, would be equal to fixed line prices. As a perk, each employee can provide a list of five phone numbers that can be called for free after business hours. Roaming between employees in different countries could have very low tariffs…
• A common address book with all employees, customers, suppliers and partners.  Common virtual phone numbers to send group SMS to a department, to all customers, to all partners, etc.
• Pre-loaded mobile apps and auto-provisioning of applications to all employees.

Nano MVNO´s would be focused on groups of friends, associations or family. Except for virtual numbering plans, custom pricing plans, a common address book, group messaging, auto-provisioning, etc. there are other services that could be of interest:

• Joint reward points, so the group decides what to do with them.
• Know one another’s location so you can easily do friend-finder type of applications.
• One-click group conferencing
• Group ringtones, operator logos, etc.
• etc.

These lists of services would be just the beginning, especially if you add mobile applications, social networks and cloud computing offerings to the mix. However there is one base principle for these micro and nano MVNO’s: “More customized services, combined with group pressure, will make churning harder and group spending higher”.  It will be harder for an individual to churn. Also the “alpha” member of the group will push others towards using new services.

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?

Any operator that has not started a project on Cloud Computing is late. The typical data center at an operator is filled with servers that are under utilized e.g. application servers and database servers are running at 30% of memory, disk and CPU. Just by doing step one of getting to Cloud Computing: virtualization, operators are able to save substantially in the cost of hardware, electricity, maintenance, etc. Virtualization means decoupling software from hardware. This allows to run multiple operating systems on one server.

However this would only be focusing on the tip of the iceberg. Cloud Computing is so much more…

Private Clouds

Automatic Scaling

Let´s first focus on the internal systems of an operator. After solutions have been virtualized, then you are able to scale them to more or less servers. The first step is to automate this process. If you have an application server cluster, do you need 8 nodes all the time? You probably only need them the week before Christmas or during some other peak period. So the ideal is to be able to measure the load and to automate the deployment of more or less cluster nodes based on load. The same can be done with the database. During the night you have 2 nodes. In the morning 3. During the day 4. During peak moments 8. In the evening 3 again. You could save massive amounts of money if application servers and databases can be scaled in this way. You ideally also are able to pay licenses based on what you really use and not on your maximum number of nodes during a yearly peak.

Redesigning Applications and Data

Both Amazon and Google found out that if they redesign their applications then they can get even more gains than pure virtualization. Amazon´s S3 service is a clear example. However internally they started with services like Dynamo on which S3 is build. The first step is to build general data stores. Multiple applications should be using a common data store instead of needing a separate database cluster each.

Unlike popular believe in the IT world, the dotcoms are not filling their data centers with Oracle RAC clusters. The dotcoms are designing special purpose data stores. The data volumes any market-leading dotcom has to deal with are so massive that a SQL database can not keep up. SQL databases are very good at running efficient queries on structural data or making sure transactions are consistent. However they fail when data is unstructured, write operations are massive or data volumes grow with terabytes every data.

Relational Data

So for all low-volume applications that need transactional data and read more than they write, you could still use a unified Oracle RAC cluster to serve multiple applications. An alternative approach are the data stores that have been build by Amazon (Relational Database Service or SimpleDB) or Google´s App Engine (Datastore with JDO).

What other alternatives are there?

Read Mostly Data

Data that needs to be read a lot and is not updated frequently can get an enormous performance and scalability boost by using an in-memory data store. The dotcom standard is memcached. Facebook (800 servers and 28TB) and Twitter are addicted to memcached.

Documents, Images & Videos

Binary and media files are best stored outside of a database. In small numbers they are often stored on a file system. However they occupy a lot of disk as well as network bandwidth when moved around. The ideal is a document store with a content-delivery network or CDN as a front-end. Amazon´s S3 and CloudFront are examples. Storing them in a compressed format, e.g. LZO can save valuable space. Also transcoding into different formats, e.g. thumbnails or preview can help save network bandwidth.

Unstructed Realtime Data

Data that is unstructured and needs to be stored and accessed in real-time in high volumes are best stored in special purpose data stores. You can write a book about the latest NoSQL solutions. Write an email to maarten at telruptive dot com if you are interested.

Analytics Data

Twitter has described most extensively how they use all the unstructured data they get from their logs and other sources. They use technology from Facebook to stream it into a high-available file-system from Yahoo. There they run massive parallel map-reduce operations to get to know a lot more about what users are doing and who is influencing who, etc.

Social Graph

The social graph is about who knows who and what kind of relationship you have. This data is best stored in graph data stores.

Collective Intelligence

Again a chapter by itself but dotcoms are also heavy users of collective intelligence which often means dedicate systems.

Accessing Data

Instead of stove pipes with data, the dotcoms are making data accessible to all their applications. Either via search interfaces, web technology to access data (e.g. REST and JSON) or efficient binary interfaces (Thrift and Protocol Buffers).

Messaging and Notification

Amazon is having a simple queue service and a simple notification service to make sure applications communicate in a uniform matter.

Applications

If applications have access to all the above services then the architecture of an application is simplified enormously. Most of the famous dotcoms don´t use middleware. They prefer the SOA principle. However unlike the IT SOA solutions, a dotcom would take an application and make it into a chain of reusable services. Let´s take an IVR application as an example. There would be a service to do voice recognition. Another one for voice transcription. Another one for text-to-speech. A transcoding service to transcode between different media formats (e.g. high-quality voice and low-phone-quality voice). And so on. Each service has independent load-balancing and can be scaled separately. Services can be re-used between applications. An application is very short because it just need to define which services need to work together and how.

Application Deployment

The dotcoms deploy new features on a daily and even hourly basis. This means that all application deployment is fully automated. When a new feature is deployed it does not necessarily overwrite an existing feature. It is possible that a new functionality has been solved in 5 different approaches. Dotcoms would split the total user base and let small parts of users try out the different approaches. Depending on the user´s feedback they would take the preferred approach and slowly scale up from 1% to 100%. If they detect that the feature has a performance problem or a bug then they would be able to roll-back or decrease the load, fix it and deploy gradually again.

The Network, OSS and BSS

There is a substantial effort needed to redesign a network to be cloud-aware. Some components need latencies lower than 10 milli-seconds (e.g. antennas), hence most of this logic will have to be processed locally. However all systems that can live with 100 milli-seconds latencies benefit from a cloud make-over.

Especially in the area of OSS and BSS there is room for optimizing applications and making them cloud-aware. Global services like a network inventory service, a user profile service, a device profile service, etc. would mean simpler applications and less data duplication.

Opening the Cloud

So the network and IT infrastructure is being redesigned to allow for faster innovation and lower costs. However Cloud Computing can also be used to increment revenues.

Being a Cloud Infrastructure Provider

Many IT consultancies and software/hardware vendors will tell an operator that they could be a Cloud infrastructure provider. On slides this really looks nice. However unless an operator is not using the cloud computing principles for their own systems as described in the first part, they are lacking substantial knowledge about how to manage such an infrastructure. Without this knowledge it would be hard to have a very optimized solution and as such be price competitive with the existing players.

Being a Cloud Platform Provider

Although closer to the operator´s core competencies, being a cloud platform provider would still be for those operators that are Cloud experts. A Cloud platform provider would allow others to use the infrastructure services to create applications on top. The complexity lies in the fact that malicious users try to break the platform which could have a very negative effect on the infrastructure if not handled correctly.

Being a Cloud Service Provider

This is the default option most operators should explore first before moving into the other areas. Being a service provider also has a roadmap:

Reselling SaaS

The easiest step is to be the storefront and to resell IT applications from others, e.g. cloud backup storage, security solutions, etc.

Offering Telco SaaS

The next step would be to offer specific telecom applications. Applications that are build for the operator or even better applications that can be build by others based on the operator´s assets. An example would be a PBX in the Cloud.

Open Market for SaaS

Building all telecom applications yourself is hard. Attracting others to do it for you is easier. However just putting a “Net App Store” and an SDK on the web will not get you to dominate the market. Only an open market with a large eco-system of companies and developers can generate large quantities of “Net Apps”. If you are thinking about building an open market, why don´t we talk first. Send an email to maarten at telruptive dot com.

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.

March 2012

Google Voice has changed the mobile broadband industry in just three months. Who would have thought that Google would start offering free mobile broadband and even give away 10.000 free mobile phones and access points?

It all started with a small governmental change in the summer of 2011. After years of lobbying, the New American Foundation convinced the US government to open some of the previously military spectrum to free wireless communication. The New American Foundation chairman, Eric Schmidt, declared the act a step towards universal broadband access.

Two days before the new spectrum was opened on January 2012, Google surprised the world with the announcement that they would give 10.000 free Nexus Goomax phones if people installed a new sort of device at home called the GooPoint.

The Goopoint turned out to be a new generation of a femtocell network device that was on one side connected to fixed broadband and on the other side was a Goomax antenna.

Goomax, the next generation of wireless connectivity improves on the WiFi and WiMAX standards by allowing Google´s servers to remotely and dynamically control the network and the different Goopoints, a.k.a. Cloud-based network management.

The end result is that the US in two months time had an extra mobile network provider. However this network provider did not install any antennas. Neither did they pay expensive spectrum licenses. The new network was formed by home devices that allowed people within 5 kilometers to connect to mobile broadband for free. Goopoint owners that contributed fixed broadband capacity could earn points and exchange them afterwards for Android Apps among others.

Disclaimer: This is an invented story but could one day become reality.

In the telecom domain a scalable real-time architecture means paying a lot of money in hardware and licenses. You buy the Oracle RAC solution, build a Weblogic cluster, set-up a storage area network, etc.

In the dotcom world things look differently. Facebook, Google, Twitter, Yahoo, Amazon, etc. have more active users then any telecom system. However they have build their architecture on top of open source solutions and average servers. Some even build their own software and sometimes open-sourced it.

Some of this software has very exotic names: Hadoop, Bigtable, Cassandra, Pig, Elephant-Bird, Dremel, Pregel, Dynamo, etc. Additionally design decisions are taken that would surprise every IT teacher: “do not normalize”, “do not expect immediate consistency”, “no transaction support”, “store in memory instead of on disk”, etc.

However if you can support 500 million users, 100 million daily hits, 130TB of logs, 20 billion tweet messages, 1 million servers, etc. then something you should be doing right.

The telecom software industry seems to have been isolated from the Internet during the last five years. With the shift to IP it is expected that more IT companies will be able to provide telecom solutions. Is this the solution? Not sure! Also IT companies are still playing catch-up in the cloud computing domain. Few IT solutions providers are demonstrating, they now think Map-Reduce instead of Middleware.

Google Voice is coming and most operators seem to be still more worried about churning subscribers. Google Latitude and Maps demonstrated that with new technology and innovation you can destroy the telecom monopoly  on location-based services overnight…

If you are a telecom operator and you are worried, perhaps it is time we talk.

P2P, short for Peer2Peer, allows computers to communicate directly instead of having a central server managing the communications. P2P became (in)famous for (illegal) file-sharing. Skype was the first company that understood the potential and used it to revolutionize PC to PC communication.

A recent list of dotcoms is starting to find new uses for P2P. Wuala is an example whereby cloud computing and P2P is combined to offer an innovative backup solution.

Also the academic investigations into P2P are very active, an example is the chord project.

Why is P2P interesting?

P2P runs locally on a computer and allows direct communication between other computers. From an operator´s perspective this means that communications are direct between PCs which reduces long-distance routing to central servers.

For the user the big advantage is the redundancy and resilience of a P2P network. Have you ever uploaded content by mistake? On a cloud computing or client-server solution this can be easily removed. If the content becomes popular on a P2P network then it is virtually impossible to remove it.

What are the disadvantages of P2P?

Too much file sharing means that a small set of broadband users are monopolizing the operator´s network. Operators prevent this by reducing the bandwidth an individual user can take up with P2P connections. This bandwidth reduction results in unreliable speeds for legitimate uses of P2P.

How can the operator make money with P2P?

If P2P bandwidth can be reduced, then it can also be increased. These changes in quality of service can be a premium offering. Who would be interested in purchasing them?

By itself they are useless. However if the extra speed resolves real business and consumer problems then there is a market.

Peercling = Peer2Peer + Cloud Computing

Cloud computing is an over-hyped term.  Software-as-a-Service is a subset of cloud computing and focuses on providing services in a remote manner on a pay-as-you-use basis. A good example is Salesforce that offers customer relationship management, among other solutions, via remote access on a pay-as-you-use basis.

Remote access is important here. What if a sales director is not connected, e.g. in the car, on a plane, etc.? Cloud computing is often useless if you are not connected.

Peercling to the rescue. Peercling is the combination of P2P and Cloud Computing. A local P2P client allows users to access a local copy of the data while not connected. Afterwards this data is synchronized with other peers, servers or cloud computing solutions.

Why can´t we use client-server?

P2P is important to Peercling. A lot of server or cloud computing solutions have vast quantities of data. A single PC might not be big enough to store this much data. P2P comes to the rescue when applications might not be able to connect to a remote system but are able to connect to local PCs. When does this happen? If the internet connection is down but the LAN is still working or when the server or cloud computing solution is down.

The power of having access to multiple peers allows vast amounts of data that are stored in cloud computing solutions to be distributed over a large number of peers. If the cloud computing solution is not available then the user can continue working because the information can be retrieved from other peers. Afterwards changes are synchronized when the cloud computing solutions is accessible again.

P2P also allows computers to communicate and collaborate together without the need of a server. Sharing documents between a group of people to work on them collaboratively is possible via P2P. Afterwards Cloud Computing can be used as a backup of these collaboratively edited documents.

Show me the money

A lot of Cloud Computing solutions would benefit from having a local client available in case the user is not able to connect. Instead of having individual fat clients, there is room for a general platform that isolates the complexity of P2P and connecting to external services like clouds. Given the fact that these applications need a good internet connection, the safest bet is to have the operator offering this platform. The operator can make sure network speeds are optimal. On this platform third-parties can then offer their “P2P-Cloud Applications”. Think of it as an iPhone (=Peercling client) and an App Store for P2P Apps.

If you like the idea but need some more details, why don´t you contact the author at maarten at telruptive dot com?

Facebook is hot. Google is trying to create an equal successful social network. There are specialized social networks like Linkedin, Plaxo, etc. focusing on specific social networking aspects.

If you are not social, you are not Web 2.0!

Why are telecom operators not social?

Telefonica launched Keteke and bought Twenti so operators must be social. However launching or buying a social network does not make an operator social and web 2.0 ready!

Social networking is all about the social graph and what you do with it. Operators have had access to one of the best social graphs for years. However they have chosen to ignore it: the mobile social graph.

If I call you and you call me then we know one another. If the both of us call a third person then we have relationship to a person in common. It is true that the operator does not know what the relationship is between two persons that call one another. But that should not stop them from asking!

What can I do with a mobile social graph?

As soon as I provide an operator with the type of relationships I have with the people I call or send a message to, my mobile social graph will become useful both for me and the operator.

There is a whole list of applications that can be build on top of this mobile social graph. Let me give two examples.

A social addressbook

Just by telling which of the calls are business, family and friends, collective intelligence can do the rest. If I have two colleagues that marked a person as a colleague and I call that person then my addressbook can suggest to add this new phone as a colleague. There is a lot of more advanced features that could be added, but the basic idea is that a better addressbook generates more calls and SMS.

Find the influencer

This service is more advanced. The assumption is that if I call on Friday night a restaurant and during the next two weeks five of my friends call the same restaurant then I might have influenced my friends. Knowing who influences others is already used for churn analysis.

In our case the restaurant owner might be willing to pay a premium to contact me about a new promotion. Afterwards he or she can follow up if I or one of my friends made a call in the weeks after the promotion was send to me.

If you want to learn more about the mobile social graph don´t hesitate to contact the author at maarten at telruptive dot com.

Head of Cloud and Disruptive Innovation at Nokia Siemens Networks

Maarten Ectors is the Head of Cloud and Disruptive Innovation in Europe at Nokia Siemens Networks. Maarten helps telecom operators to understand  disruptive technologies (SaaS, PaaS, IaaS, mobile SaaS, big data, NoSQL, collective intelligence, M2M, OpenFlow, Virtual Switches, Computer Vision, etc.)  and business ideas (long-tail marketplaces & partner eco-systems, micro-payment subscriptions, telecom assets exposure, working together with over-the-top players, revenue sharing, freemium, support as a revenue stream, etc.) to jointly build new businesses around them.

Maarten has 13 years of telecom and IT experience. He worked together with major telecom operators like Vodafone, Telefonica/Movistar/O2, T-Mobile/Deutsche Telekom, Orange/France Telecom, etc. Maarten has delivered keynote speaches on Cloud Computing and Disruptive Innovation at several NSN innovation days. Maarten has been negotiating at C-level both within operators as well as partners. At Nokia Siemens Networks he previously was leading a global startups program around Cloud Computing and a European off-shoring/outsourcing change program.

Previously Maarten has been leading professional services programs, solution sales engagements, product development and research & development.

Maarten started his career at Accenture as a Java programmer / analyst. He build up strong technical and management skills which afterwards he applied at a dotcom. He also worked for Telcordia as a director of professional services.

Be sure to check-out Maarten’s profile on linkedin.

Maarten Ectors – Curriculum Vitae – 20120326 – Business
Maarten Ectors – Curriculum Vitae – 20120326 – Technical

Maarten is currently looking for new challenges in a company that wants executives that can generate new revenues based on disruptive technologies and business innovations. Relocation is negotiable. You can contact him via: maarten at telruptive dot com.