Mobile operators are at the top of the list of companies customers complain about. Their prices are abusive. Their services usable at best, but often horrible. Have you seen T-Shirts saying “I love my voicemail!”? When you call them for support, you end up adding inadequate support to the list of complaints. So writing a blog post about how unhappy people are with their mobile operator is not valuable. What if the crowd could fix all these problems?
How to build a dream mobile operator?
From a technology perspective we have come a far way in recent years. Lime Micro, Yate, Nuand, Fairwaves, Telestax, Metaswitch, etc. have all been working on little puzzle pieces. There are relatively cheap micro base stations and very likely we end up below $100, and even $50, in the next two years. Shortly there will be open source LTE. There are open source value added services app stores. Open source and scale out communication management solutions. Open source software defined networking. It is time to start putting the pieces of the puzzle together.
Don’t you need an LTE license? In countries like the Netherlands and Sweden it is legal to put a mobile base station as long as you stick to some limitations around height, strength of signal, etc. In Mexico you can put up a base station in areas that are not covered by the traditional mobile operators. You have LTE-U, an unlicensed part of the spectrum that new mobile phones support. White spaces database can technically allow LTE spectrum that is not being used in a geographical area to be repurposed while the main license holder does not use it. So if you use the unlicensed spectrum and white spaces in most countries and start with normal spectrum in a handful of other countries and focus on making customers happy, then governments will get persuaded by happy crowds to change laws on spectrum licenses and make voters happy. What is needed is a better model that can be copied by many countries.
What does a dream mobile operator look like?
Should a mobile operator allow communities to build out their own networks and have federated models in which communities can interconnect? You can use my network, if I can use yours. Or alternatively is there only one network? Perhaps a peer to peer model?
If you don’t host an antenna, would you pay for data and if so how much? What if somebody does not pay? Prepay vs postpaid? Should bitcoin be the preferred form of payment? Should data caps exist to avoid abusive behaviour? Can certain traffic be given less priority if it improves overall experience for everybody at the cost of some? What services would be needed? How is support provided? What about governments and operators trying to use laws to go against what the crowd wants?
There are still a lot of questions to be answered. And with enough people trying to find solutions, they are all solvable. However there is one fundamental question:
Would you use a crowd funded mobile operator?
If there is no demand for a crowdfunded mobile operator then this is just another blog post. But the first step in a crowd funded mobile operator is to validate that the crowd wants it. How do you do this? Simple! Tweet, retweet, favour any tweet with #dreamcoms. Vote up on Hacker News any articles about Dreamcoms. Tell your Facebook, Google+, etc. friends about Dreamcoms. Blog about how Dreamcoms could solve certain problems. Make viral Youtube videos about Dreamcoms. Make T-Shirts. Campaigns. Anything that brings Dreamcoms into the spotlight.
If you are unhappy with your current mobile phone operator and you want to dream about a communication provider that is awesome, you tell the world about Dreamcoms. Enough social media traffic will enable to form a community that can work on Kickstarter and Crowd funding initiatives that solve every aspect that needs to be put in place. At the moment it is a dream but wouldn’t it be awesome to make it real. It is in your hands now to tell the world that you want Dreamcoms to happen…
The Internet of Things (IoT) is impersonal. My lamp, dishwasher, heater, sprinkler, etc. are all islands with a closer border policy than North Korea. Even the first generation of IoT devices is still autistic. Current devices only know how to talk to “their app” or “their cloud”. The solution is not to have open APIs or standards but to go a step further. We need IoT apps everywhere. When you buy a phone, it is the same phone as millions of others are having. However something magically happens when you connect it to its app store/marketplace. The phone goes from an iPhone/Android to a miPhone/mydroid. We need a dishwasher, vacuum cleaner and heater to be personal as well. The easiest way is to create a MyIoT experience with IoT apps everywhere.
Why would your vacuum cleaner need apps?
Your vacuum cleaner should be able to know your house the moment you unpack it because your alarm system and your heater should tell it how big your house is. Your Smarthub should guide your vacuum cleaner from day one. Your smart phone and Google calendar should tell it when you are away and when it is a good moment to clean. Your smart watch should tell it that when it jumped on while you where there that the spike in your heartbeat means that its sound is annoying and it should stop immediately. No single company will make solutions this complex. So what we need is the ability to add apps to every sort of thing. This way the Internet of Things becomes My Internet of Things.
Canonical is the company behind Ubuntu. Ubuntu powers up to 70% of the public cloud and 64% of OpenStack private clouds run on top of Ubuntu. Today, Canonical launched Snappy Ubuntu Core! Snappy Ubuntu is a revolution in how software gets packaged, deployed, upgraded and rolled-back. So what is it and why should you and your business care?
What is Snappy Ubuntu?
Snappy is allowing developers to build Snappy Apps – called Snaps – like mobile apps and deploy them to the cloud, any X86 computer or a fast growing list of any form of IoT or ARM v7/8 based board. For more info on IoT see ubuntu.com/things In the past developers would make a software solution, afterwards a maintainer would take often weeks or months to create a packaged version. This would mean that fast moving projects like Docker would never be up to date inside any of the big Linux distributions. Snappy changes this by allowing the developer to package their solution on their own and publish it through the Snap Store to all users in minutes. Since all Snaps run in a secure and confined environment, they can not harm other Snaps or the operating system itself. Quality, speed and security can now all be combined.
Snappy upgrades are transactional. This means that you install a new version in one go but also easily roll back to the previous version if required. Snappy manages a super small version of Ubuntu called Ubuntu Core. This means you can run it very cost efficiently and fast everywhere. Since Ubuntu Core is a lightweight version of Ubuntu, teams don’t have to be trained when they want to go from the cloud to embedded, it all works the same.
Why is Snappy important for Businesses?
Snappy allows solutions to be packaged and published by the software vendors in minutes instead of months. Users can deploy and roll back very easily. Trying new innovations becomes cheap and fast.
Snaps can use any license. Snappy Ubuntu was born as a spin-off of the Ubuntu Phone operating system. Canonical is working on commercial Snap Stores with different groups like the ROS Robot Store, the Ninjasphere Store, etc. Unlike traditional mobile app stores, the Ubuntu Snap Stores are a lot more open. You can use the generic Ubuntu Snap Store but you are also able to get your own branded Snap Store and govern it. For large companies there will be even an OEM version that they can manage locally and host federated Snap Stores for their large customers. Be sure to reach out to Canonical if this is of interest to you.
With Snappy, the vendor packages the complete application, including its dependencies. Less moving parts mean less chances of something going wrong and cheaper to support customers. Updates are incremental so only what changes gets pushed, saving bandwidth costs and time. Urgent security patches can be easily distributed, with high confidence.
Existing Docker or other container apps can be Snappy deployed. Building your Docker containers or other commercial Snaps on top of Snappy Ubuntu makes good business sense. In the future you can get optional commercial support from a company that has been supporting Linux for 10 years and is trusted by Amazon AWS, Google and Microsoft Azure with the big majority of their Linux workloads.
Snappy Ubuntu is open source and has some great example Snaps, so make sure your teams don’t get “Snapsassinated” by a competitor…
After years of virtually no innovation from telecom operators, 2014 will be different. Not because telecom dinosaurs have all of a sudden become lean mean innovation machines. Quite the contrary. Most operators are still focusing on rolling out THIS YEAR’s (instead of today’s) “innovative” service which will be just a copycat of some famous dotcom.
So why the excitement?
2014 will be the pivot year. The year that will be marked in history books as the year old school lost and innovators won.
The first Ryanair-like disruptive telecoms will leave their borders and start bankrupting “traditional telecoms”. Cross-platform voice/video 4G apps will reach the tipping point. Cloud Telco PaaS will be reality. Individual communication solutions or iCommunication will be a reality. Web 3.0 will include voice & video communication. NFV will be driven by non-telecom players. WAN SDN will be deployed by more than only Google, Amazon, etc. Cloud Media Streaming will reach the tipping point. Internet of things will meet Cloud will meet Big Data will meet Mobile will meet disruptive communication solutions. Early adopters paradise…
2014 will be an exciting year for those that love telecom innovation!!! Bit pipe nightmares becoming reality for others.
Fujitsu just presented SaaSification on Cebit. Existing applications can be easily brought to the Cloud and sold via App Stores and SaaS marketplaces. IBM is also working on SaaSification and even adds multi-tenancy.
What is next?
Everybody wants to have a full App Store or SaaS Marketplace, so SaaSification is the next step after launching your store. However converting a client/server application to the Cloud is only step 1. Step 2 is creating new services that are specifically built for the Cloud.
What does Built-for-the-Cloud means?
Cloud-Ready applications should also accept the new reality of APIs. Both for exposure as well as consumption. This means that applications need to be redesigned according to application slices.
So if SaaSification wants to be successful then it needs to add quick enablers for multi-tenancy, big data, integration with external APIs as well as API exposure, etc. This integration concept can be called iPaaS or integration platform-as-a-Service. iPaaS should not only focus on exposing or integrating APIs but on providing complex services by integration multiple SaaS solutions together.
Other enablers should be added as well. Basically 80% of a SaaS solution consists out of the same elements or tries to solve the same problems. These could all be provided via a SaaSification PaaS:
- Blog – to describe the newest ideas.
- Forum – for people to get answers from the community.
- IT PaaS – where you run the actual business logic and UI. Data storage is assumed to be provided by the Big Data elements.
- Portal and Mobile Portal – allows to quickly define the “static” content for the web and mobile site.
- Deployment management – ideally continuous deployment or integration tools that allow fast feature by feature deployment.
- A/B testing – allow new features to be deployed to subsets of users and check which version of a feature has the highest impact on the bottom-line. A/B testing was made popular by Amazon.
- Automated testing – lots of testing can be automated but especially end-to-end and performance testing are the harder tests that should be focused on.
- Configuration management – manage the version control of the code.
- Metering and billing – be able to meter the resource usage by users, companies or any other element you want to meter and be able to bill users both for subscriptions as well as for usage, ideally with advanced set-up with overage, etc.
- Marketplace listing and provisioning – automate the listing of products on the marketplace as well as the provisioning of new services.
- Single sign-on & identity management – allow companies to use their own user credentials (e.g. SAML), authorization for third-parties (e.g. oAuth), etc.
- Reporting and data warehousing – this can be part of the big data stack but especially being able to create ad-hoc reports for instance for A/B testing . Of course regular business reporting needs to be included as well.
- ERP – accounting, resource management, etc.
- CRM – sales and lead management
- Operations & Maintenance – automation of back-ups, monitoring both for the performance and fault management but as well business monitoring.
- Support – helpdesk, ticketing system, SLA management, etc.
- Social integration – tools to add social aspects like Facebook apps, Twitter feeds, etc.
The idea is not that a SaaSification PaaS offers all these solutions by custom development. Instead the SaaSification PaaS should allow startups to assemble an ideal architecture by combining different solutions from different providers. For example you would be able to select the support solution you prefer, e.g. desk.com, zendesk.com, etc. and this solution would be completely integrated into the overall stack, e.g. CRM integration with help desk and fault management together with sign sign-on.
SaaSification 2.0 should focus on making sure that 2-5 people can start a new dotcom solution and focus on creating a killer service and not on building up yet another stack of solutions for configuration management, support, billing, etc. If a SaaSification PaaS can shorten the time to launch with months and reduce the needs to operate the solution with several people then startups will see the value. Instead of SaaSification PaaS a good term could be Incubation PaaS, to incubate SaaS solutions. Once the business model and solution is proven, there will be money to move to a custom-build stack but during incubation and crossing-the-chasm enterpreneurs should be able to focus on delivering value to their customers and not on re-inventing the startup wheel.