The good news is that he is driving the agenda with a focus on time to solution and costs.

The hard part is going to be to get folks set in old habits to see the art of the possible. Success stories in private and public industry will go a long way to help. Sonoa is and will continue contributing to make this transformation possible.

There is clearly a need for cloud brokering technology and probably a business around cloud brokers. Cloud brokers will be a combination of the support (think Rackspace’s fanatical support), technology (Sonoa and others will be technology providers) and consulting (networking and application level setup – even if it is just of SLA’s etc.). Cloud brokers will also need to understand how to sell and service enterprise customers. Telcos might step up, but others like pure consulting companies (cognizant, infosys) and possibly product/services companies like IBM, HP and even Cisco might want to capitalize on this opportunity.

Cloud brokering technology and brokers serve a real need. the drum beat is going to increase as cloud computing takes hold in enterprises.

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

Her point with the original post:  SOA got sold as a thing in itself, when really it was just set of principles to free up IT to be more responsive to deliver something of value to the business.  Go back to the definition – it’s just a service architecture – a means to an end.

The part of the talk I liked:  Technology people love to talk about the means, not the end – or as Anne said – “Don’t sell architecture to business people.. that is what gets you into trouble.”

Sometimes we make the same mistake talking about cloud computing.  Lots of focus on the ‘how it works’  but do the business people really care if it’s public, private, open source, built on microsoft, force or run by hamsters spinning in a cage?

A recession isn’t good for anybody – but maybe it forces us to think of cloud computing in cold hard business terms – how are you going to survive by either finding new ways to make money (sell your old data or new services via APIs) or blow away your existing cost structure?   There are business people putting pressure on the cloud computing vendors to talk in these terms – not about architecture.

Cloud computing offers new opportunities for the indirect channel (VARs, resellers, system integrators) – where enterprises buy technology/services from an intermediary instead of the original technology provider themselves.

The indirect channel generally (they are exceptions) are focused on small/mid size companies or departments of large companies. They have recently transitioned away from being a demand generator (proposing innovative solutions) to demand fulfillment. It use to be that if you got the channel you had it made – Powersoft, Citrix etc. are a few companies that build very successful businesses by seeding and growing the channel. But as information has become readily available their value to technology companies and to the end customers themselves has reduced. However some have continued to thrive, by reinventing themselves as system integrator or value added resellers.

With cloud computing, the opportunity for the indirect channel increases, especially ones that are focused on medium size companies. The know the customer environment well, and there is enough noise, that they can help sort things out and make recommendations. The issue is one of skills. Their value add will require them to focus on different issues then they have focused on. Security, compliance, SLAs and other operational issues become higher priorities. Channel companies that make the transition will do very well.

Recently there has been good back and forth on this subject by Larry Walsh and John Cowan. Interesting points of view. This is all part of evolving the business. The opportunity to help medium size companies is definitely there, the remains to be seen is how many channel partners take up the opportunity.

Why should customers care ??

As a consumer, I have no idea what tools or fabrication process was used to build my car. The percentage of people that want that level of detail is very small. I think the same is true for cloud customers. Do they know what language the EC2 load balancers were written in, I don’t think so.  Nor do they care. Different vendors will take different approaches. Like everything else, all that customers will care about is what are they getting and how much does it cost ?

Open Source is great for innovation and interoperability (de facto standards). Enterprises started adopting OSS because it was “accessable”. Much easier to get a copy of MySQL then a copy of Oracle to start a pilot. Same was true for JBoss vs. weblogic/websphere. Enterprises have successfully used open source for pricing pressure w/ existing vendors. Open Source has a GREAT future. It is mainstream, it has and always be part of our the technology fabric.

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

Michael Healey recently wrote “8 questions to ask before going live in the cloud“. Good read. We see customers going through this  general thought process:

• what is the business driver (generally time to market or costs) ?
• what is the ‘pilot’ application (new application are easier)
• select team, infrastructure/platform provider.
• focus on the security/compliance/visibility
• deliver project
• measure ROI (generally not required, as it is obvious)
• move to mission critical application

Most enterprise cloud applications are being driven by business/IT folks are focused on helping their business counterparts on time to market. it is important to approach w/ caution, but try to jump in fast…the water feels fine after you are in . No big bang approach about replacing data centers etc., just start with baby steps.