A couple of important considerations for interoperability are the application and data.  Specifically:

Data – not only do we have to discuss application portability, but also have to port the data. you may have noticed it is easy to import, but hard to export. The data world is very “sticky”. One of the biggest issues the US government is having with adopting Google apps – They want to know the format of the data, so if they ever decide to migrate away from google apps, they can do it.  One possibility is have multiple copies of the data.

Application – the application that uses the API’s of the cloud provider has to seamlessly migrate to new chosen one. For anybody that has taken a look at the API of a couple of providers, you will notice that there is no significant overlap!! The providers built their API’s based on use cases and for now believe that they are going after different use cases/audiences. Even if this converges, it will be very hard to get the cloud providers to collaborate on a standard API. Standards have the ‘potential’ of further commoditizing their business, which already has low margins. One possible approach would be for the industry to accept a defacto standard.  But for that to happen, the providers have to start believing that they are going after the same use case/audience.  Another possible approach is to have a standards body define a standard. this one is harder, because if multiple vendors drive it then the standard become complex as it has to solve corner cases across the multiple targeted use cases – just as in the WS* standards process.

One possible approach is focus on small slices like cloud security appliance with security. We at Sonoa are hoping the CSA with its customer centric approach might pave the way.

This is a real issue, that needs to be worked on. thoughts/suggestions welcomed.

Lots of parallels to draw with what is happening with cloud computing and the API economy.

Faster computation: Cloud computing is crushing the time to provision servers from weeks to minutes, and converting prohibitive capital investment into low operating expense.

Quicker Access: Metcalfe’s law is working in APIs… as companies like TrueCredit.com open their apps and make it very quick/easy to consume their services; the value of what they provide grows quickly with each new connection.

Shorter decision cycles: If you are running a business, assume that your biggest competitors are working on opening APIs to their data and apps.  You don’t want read about their API announcement and at that moment be behind.  Else you are the next Chicago Tribune.

Favorite part – they ask the question -  “how do we control this increasingly out-of-control, interlinked world?

Answer?  “online surge-protectors to stop run-ups and panics” and “better analytics”   – exactly how we describe Sonoa API Management

API’s are definitely becoming mainstream. It is certainly mainstream for web companies. So why not SaaS companies ?

SaaS providers serve different customers. As SaaS has become more  mainstream (accepted by fortune 2000) customers, the need for API’s has grown – firstly for integration and secondly to build customer apps. The need for integration has been solved by SaaS integration vendors like CastIron building adapters, but having been in that business for a long time, I know they could use standard APIs from the vendors.

The need for custom applications is also increasing as customers are building composite applications that use data stored in their ERP (on-premise), CRM (on-line) and web 2.0 applications like Google maps.

But at the end of the day SaaS vendors will provide the API’s for 3 reasons:-
1. competitive differentiation – customers ask for it when evaluating similar SaaS providers
2. increase stickiness – to embed themselves in a customer’s enterprise applications
3. new revenue stream – as an add-on MRR (monthly recurring revenue) source.

These are compelling reasons! API’s are becoming mainstream and yes, almost all SaaS vendors need to have an API.

(And of course, once you have one, API management becomes important to differentiate your service and customer sat..)

Business Drivers:
SOA and APIs are very different. They start from very different points with different end goals and most importantly originated by very different people. SOA is a technology approach, one with very sound computer science principles, all of which will get adopted. These projects are mostly originated by architects. API projects on the other hand are driven mostly by product managers. As their applications are getting more adoption they see a new revenue source, new way to satisfy customer demand by making APIs available.

Technology:
SOA and API are different – simplicity and scale. most SOA is based on Web services standards that solve every corner case known to mankind. Complexity increase with flexibility. APIs are mostly REST based. We see this change with our enterprise customers, many of them are adopting REST/Web API approach to solve their SOA projects. Secondly is scale. The same difference that we see in classic enterprise and Web computing software shows up here.

As Dion says there is value in applying API principles to SOA projects:
- Ease of use – as discussed above simplicity make a lot of sense.
- Self Service – as one makes things simple, using non-confidential or classified services/APIs should be easy – not calling 14 people and getting 20 approvals.
- Visibility/reporting – this is important for both the consumer and provider.

Not sure account management, developer community and licenses apply to internal enterprise projects or for that matter for API projects, but that is for another blog.

Cloud computing is bringing simplicity and scale requirements into focus for the enterprise and these differences are getting closer. As always Dion’s pictures/drawing are awesome.

At Sonoa we completely agree with Jonathan’s assessment. As with all inflections points, we will only know after we have passed it, but it certainly fees like we have either reached or close to reaching a maturation/tipping point.

Sonoa provides visibility, control and scale for APIs, feeds and services. We provide this on premise and on demand. In addition to the technology discussions, increasingly we have two kinds of requests from our customers: 1. API strategy – what are the different phases of an API strategy, should I just make them available and see what happens, etc., and 2. API Development – what best practices does one use in order to have simple to use and scalable APIs. As Jonathan points out in his blog creative/media agencies will be of little help. Maybe there is an opportunity for boutique SI firms or for large consulting firms to start a practice.

“Cloud computing” contains the seeds of IT’s next generation – YES. This is real, much like client server and Web computing… in fact probably has benefits of both – cost and revenue.

Cloud’s customers (slide #16) – great customer segmentation. would like to add that almost all enterprise customers are using cloud for revenue or customer service related projects and using time to market/costs as the major drivers.

The systems vendors will not dominate (slide #22). This one requires a double take. James makes the point that for a vendor to succeed, it requires operations excellence in Web scale data center operations and system companies have expertise in managing enterprise data centers – wrong skills. This may seem like Wow! comment for many have not been through this, but for anybody who has built, deployed and managed enterprise apps. vs. Web apps they know the difference. The mindset is very different. The smart vendors are aware of this and will either focus on their sweet spot or acquire/grow into this space.

Security is a problem for IT departments that we keep hearing about again and again – Ogren’s is an interesting and practical take on the issue. Forrester created a checklist of security requirements for any company hosting/opening APIs via the cloud. It’s crucial to execute “due diligence” and upkeep with cloud infrastructure in order to ensure security.

Yes, security is a concern when you move to the cloud, but not every API operation in the enterprise needs stringent regulations. There are many enterprise applications that require collaboration with the extended value chain – not every operation has sensitive data. Because of cost and time to market issues it may be easier to do these operations in the cloud.