Archive for the ‘Asset Exposure’ Category

Mobicents ‘ Restcomm is to Twilio what Eucalyptus is to Amazon

December 10, 2011 3 comments

In recent weeks I had the pleasure to talk to the team behind Mobicents. I have been pleasantly surprised by Restcomm. Restcomm is Twilio for the Private Cloud. Telco 2.0 SaaS for private cloud. Tropo APIs are also on the roadmap. Mobicents is starting a revolution by moving away from telecom standards and moving to the new Cloud telecom standards. Telecom engineers are no longer needed to make enticing value-added services. Any web developer can make telecom apps in minutes and integrate them with Web 2.0 and social networks.

Is Restcomm a threat for Twilio? Quite the contrary. Many larger companies did not want to move to Amazon because of fears of vendor lock-in. Eucalyptus brought a way for public cloud apps to move to a private cloud. Restcomm will allow companies to move their telco apps to the private cloud when they become a large hit. Developers could even start from a private cloud deployment and move apps to Twilio when spikes in demand happen, a.k.a. cloud bursting. In general Twilio is very likely going to get more customers instead of less by having a valid open source alternative.

Mobicents is also undergoing large changes. There has been a shift in direction at Red Hat and the Mobicents team started their own company called Telestax. The company is independent from Red Hat, however it will partner with Red Hat for telecom opportunities involving RHEL and JBoss products.


Mobicents is moving telecom development towards the cloud

September 4, 2011 Leave a comment

Although the video seems to be ahead of the software, the vision of mobicents for the cloud is disruptive. The economics of setting up a global communication infrastructure in the cloud and integrate it with Web 2.0, Smartphones, Internet of Things, etc. will drastically change when first-class open source solutions will be available:

Mobile PaaS will be the next big thing in the Cloud

August 18, 2011 1 comment

Are you planning your Cloud strategy for the next 6 months? Do not forget Mobile PaaS on the top of your list…

What is Mobile PaaS?

Several years already people are saying mobile apps will be hot. However how many businesses do you know that are actively using mobile enabled applications? Yes there a few. If you count email on the mobile then almost all of them. However most of them have not mobilized their IT solutions yet. Most managers are travelling extensively. Working from home is becoming more popular. Being on holidays no longer means not thinking about work at all.

To the rescue comes Mobile PaaS. The platform that allows companies to mobilize everything easily. Mobilize their sales, their internal operations, their partner networking, their whole IT strategy…

Companies will want to have access to their time reporting tool from a mobile app or tablet. The same is true for approvals, travel requests, the product catalog, the employee addressbook, etc.

What should a good Mobile PaaS offer?

1) Mobile applications need to be easy to access – a single sign-on and you are able to access a virtual desktop from your mobile, your companies intranet, a mobile app that integrates into a companies backoffice systems, an HTML5 app hosted by a partner, a mobile SaaS solution, a flexible mobile business process designer/executer, etc.

2) A marketplace to buy what is already available – for those mobile apps and SaaS that are already out there companies should pay as they use or a subscription fee. Reinventing the wheel is useless. Being a single point of access will have people come back for more.

3) A mobile enabling platform – put a mobile GUI on top of companies exposed APIs. If a company has a backoffice system that has an API, then a secure API access (e.g. VPN) and a mobile graphical designer application similar to but for the mobile, should allow companies to quickly build custom apps for their existing systems. A step further would be to have third-parties create client apps for those legacy systems that are still out there and sell the apps via the marketplace.

4) Virtual mobile desktop – having a virtualized mobile desktop solution for a tablet or having access to a mouse and HDMI TV would allow people on the go to use their tablet or smartphone as a computer and still access a full desktop.

5) Mobile sales enabler – allow companies to sell their existing products via a new mobile channel quickly. Mobile catalogs for a tablet, instead of paper catalogs. Google is also entering this market now with Google Catalogs. Adding open provisioning interfaces will allow one click purchasing on the go to be linked with existing backoffice systems.

6) Mobile assets and APIs – offer assets and APIs to charge small purchases directly on your mobile bill, APIs to manage a catalog for a mobile store, APIs to deploy a virtual mobile desktop, APIs to integrate a corporate single sign-on solution, etc.


It is five to twelve. Dotcoms are already active in this space. You should think about working together with some established provider that know your legacy systems and a bunch of dotcoms that you never heard of before but that can bring innovative products. The window of opportunity closes mid to late 2012. So if you plan on launching an RFI, then an RFP, selecting a vendor, implementing a waterfall project and launching by 2013 then you better not start…

Creating Telecom Network Apps the Cloud Way: Telephone 2.0!

January 21, 2011 Leave a comment

Ask a Telecom architect how you create a telecom network application, often dubbed as value-added services. He or she will focus on SIP/SS7 standards, service delivery platforms, etc.

The future of cloud-based telecom network apps, let’s call them tapps, is going a totally different direction. For the former telecom architect they probably like open source solutions like Mobicents that allows you to create SIP-based applications on Java. The Asterisks and other types of VoIP application servers are other alternatives.

However for a new generation of Web-based programmers this is all too complex. These are the programmers that like Javascript, Ajax, JSON,  PHP, Ruby, etc.

The majority of them will be fine with whatever Twilio or Tropo offer via easy to use REST APIs or embedded in their favorite scripting language. Which cloud-based application needs more than calling, SMS, answering the phone, getting feedback from the user, telling the use what to do, putting multiple users in a conference, transcribing what the user does, forwarding a call, etc.? 95% of the functionality is covered with a handful of REST APIs.

For business developers that are more used to Java, they can also use Java APIs to access for instance Twilio. To be able to cheaply launch an application and scale it afterwards they could deploy it on Google App Engine. A new alternative has just come around from Amazon: Elastic Beanstalk. A developer can write their app and deploy it on Beanstalk. They no longer have to worry about monitoring, scaling, opening firewalls, etc.

Other alternatives are to extend Cloud-ready telecom applications via plug-ins. An example here could be Twilio’s OpenVBX in which you can easily add new plug-ins.

The conclusion is that 2011 will be the year in which Web 2.0 and the Cloud meet the Telephone 2.0. However the Telephone 2.0 will unlikely pass through Bluevia and other operator initiatives given the fact that they are running about two years late and are very scattered, slow-moving initiatives.

Operators should embrace the new reality and try to help these new applications find new users. The Appstore brought a new eco-system to life. Millions of small and medium-sized Telephone 2.0 applications are waiting to be discovered by Billions of users. Remember that not everybody can pay an expensive mobile with an expensive data plan. However there are billions that can pay for cheap call and SMS-based applications. We need to help the billions find those tapps that are useful to them…

Virtual Telecom Applications and an innovation architecture

December 22, 2010 Leave a comment

I have been looking into virtualization but what I find are mainly operation system based virtualizations. What I am looking for are application, integration and datastore virtualization solutions. Google’s App Engine and  Oracle’s JRocket Virtual come closed to what I am looking for application virtualization. Why do you need an operating system if you could virtualize your application directly? It would save resources and would be more secure. My ideal solution allows developers to write applications and run them on a virtual application server. This virtual app server can scale applications horizontally over multiple machines. Each application is running in a sandbox hence badly written or unsecure applications will run out of resources and are not able to impact other applications. We would need a similar solution for integration solutions. Both would need out of the box support for multi-tenancy in which either a tenant gets a separate instance or multiple tenants can share one instance if supported by the software. Integration should be separated from the application logic and so should data storage.

Integration is key because the virtual applications could be running on a public cloud but would have to be able to interact with on-site systems. Enormous high-throughput, security, multi-tenancy and resistance to failure are key. One API can be linked to multiple back-office systems or different versions. Different versions of an API can be link to the same back-office system to prepare applications before a major back-office upgrade.

A distributed multi-tenant data store should hold all the end-user and application data. Ideally in a schema-less manner that avoids having to migrate data for data schema changes.

All these virtual elements should be managed by an automated scaling and highly distributed administration that can let applications grow or shrink based on demand, assure integration links are always up and get re-established if they fail, store data in a limitless way, etc. But there is more. The administration should allow to deploy different versions of the same application or integration and allow for step-wise migration to new versions and fast roll-backs.

Why do we need all this?

The first company that will have such elements at its disposal will have enormous competitive advantages in delivering innovative services quickly. They can launch new applications quickly and scale them to millions of users in hours. They can integrate diverse sources and make them universally available to be re-used by multiple applications. They can store data without having an army of DBAs for every application. They can try out new features and quickly scale them up or kill them. In short they can innovate on a daily basis.

The Google’s of this world understood years ago that a good architecture is a very powerful competitive weapon. There is a valid trend to offshore technical work. However technical work should be separated in extremely high-value and routine. Never off-shore high-value work. Also never assume that because the resources are expensive, it must be high-value. Defining and implementing this innovation architecture is extremely high-value. Writing applications on top of it is routine at least starting from number 5.

Complex telecom net apps made easy

September 15, 2010 Leave a comment

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?

Are you exposing assets the wrong way?

September 13, 2010 Leave a comment

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.

%d bloggers like this: