Archive

Posts Tagged ‘app store’

What comes after SaaSification?

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?

Application design is changing. Traditional Web applications are built on a LAMP architecture. New Cloud-Ready applications should be Big Data ready and should be looking at SMAQ architectures.

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.
  • 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.

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 :-(

 

Follow

Get every new post delivered to your Inbox.

Join 274 other followers

%d bloggers like this: