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.

Let me start by saying every customer that I have talked to in the past 12 months says – that they will be going with a hybrid approach – combination of public and private clouds. The following are few things to think about before you decide on how you want to proceed.

- Type of enterprise – if you are a Web-based business, then public cloud is a no brainer. Regulated industries like insurance and now financial services will have a tougher time to go only w/ public clouds. So you might start with a VMware-based private cloud offering and then as you decide to use or expose APIs/services to customers/partners or your compute cycles for a point project are exponentially high, you might opt for adding the public cloud to your strategy.

- Use case – what you are doing will define how you do it. If the data is very sensitive and cannot leave the firewall, then you might decide to start with the private cloud. Just remember that is what people said about sales/forecast data. Salesforce.com is thousands of customers and their data seems pretty secure. Nevertheless, security of the data will be important criteria in deciding the private vs. public discussion.

- Cloud provider type – self services (l EC2, Google) or high touch (Rackspace, Sunguard, etc.). This is mostly about how you would like to access services. High touch has its benefits, but is also expensive. Over a LONG period of time the lines will blur, but at least for the next decade the difference in approach will be stark.

- Control – this goes back to the use case discussion above. Enterprises will want visibility and control. Granular control on things like authentication, authorization, data masking, etc. As with much of the Web/cloud approach, it has to be simple and has got to scale.

Now for the controversial part. Much has been said about the Google outage. Recently blogged about it here. Rob Enderle recently used the Google outage to assert that private cloud models will win over public cloud models. Even though he makes good points, it is not what our customers are telling us.. This is not an either or discussion. Enterprise customers will do both.

So what can we learn from it, especially the enterprises that are thinking of adopting cloud computing? “Visibility” & “Control” are important. It’s incredibly difficult to control how people are using your cloud if you’re unable to see who, when and how people are accessing it. Once a “traffic jam” is visible, then you manage/limit/route traffic appropriately.

We also see that control – and the perception that you are giving up some of it – is a central factor in cloud adoption. Now all of sudden you have clients writing code to your services that don’t work for you, with good intentions but maybe some occasional bad code. Or… you’re using lots of these services and have no idea what data is moving in and out of your company. I think we’re starting to see progress in a few cases. A lot of the CTOs I speak to are already addressing control – and some elements of customization and policy enforcement up front at the same time that they are addressing other factors like reliability and security. We’re already starting to see these companies on the bleeding edge of the cloud address control.

Larry Schwartz, president of a company called Newstex, approaches the cloud with what he calls a “try first, justify second” approach. This might make sense, but people need to be more cautious when entering the cloud. The urgency is understandable – enterprises are trying to move to the cloud because of its benefits. Be “cautious,” concerns of security, compliance etc. are real. So… make the jump, just use care

When consuming or producing cloud services from the enterprise point of view, companies need to make sure they can handle both the revenue and IT needs such as  access control, data masking, analytics, priority access, scalability, etc. The idea is to find a comprehensive approach for all these concerns.

I agree with the need for what David calls “service expandability,” or what I call service scalability. David says, “Cloud computing services are designed to expand as needed, and those leveraging cloud services do so because they can get the services on demand, when they need them. The ability to expand services within a SOA is typically a painful and expensive process.”

Scalability is a key factor in the consumer experience with the cloud. Consumers have a short attention span, and if scalability does not exist in the cloud services they use, then consumers will quickly lose interest and move on. An example is the scalability and subsequent service problems Twitter has had. Twitter’s “Fail Whale” has proven that consumers need scalability for their cloud services.

Another central issue for cloud providers that David highlights is Service Design. He says, “The reality is that services that are not well defined and designed won’t sell well when delivered on-demand, and thus those who provide services out of the cloud – which are most major cloud computing providers – have to spend a lot of time on the design of the services, including usability and durability.” Why is this?

With SOA, you have a private service with limited users, so for the most part you can make multiple revisions to services and APIs. But, opening services and APIs to the cloud brings new problems to service design. Once you open an API to the cloud you cannot change design as easily because there will be existing developers who have already built out your existing API. If you change the design, these developers’ APIs won’t work. So, David is correct in saying that well-designed service is extremely important from the get-go because you cannot change designs the way you can in the contained SOA environment.

There’s a lot that cloud computing can learn from SOA, and scalability and good service are just two examples. History always teaches ways to improve our current projects so it will be interesting to see the shape the cloud takes from what we’ve learned with SOA.

Mid-sized companies are just trying to survive today’s shaky economic climate and they need the capability to scale with their needs quickly and economically. Agility is really the number one concern for mid-sized operations transitioning to the cloud. The cloud’s ability to scale is a key component of this agility that should drive them to cloud now and is closely tied to the economic benefit of cloud computing.

This is much like the days when Software-as-a-Service (SaaS) was just starting out and it was the mid-sized companies that were able to first adopt on-demand software. These mid-level companies and departments within larger corporations had the ability to, and the definite need for, on-demand computing models. Today, their agility needs will lead them to cloud compute.

David Linthicum recently wrote about conserving capital with cloud computing. Companies today need to have capital on hand in order to quickly respond to the restless economy. This concern is especially important for the mid-sized companies and departments that are in survival mode right now. David notes that cloud computing is a big part of conserving capital because of its pay-as-you-go model that doesn’t require businesses to buy hardware or software. He’s correct in noting business value as the primary reason businesses are jumping into the cloud, since the subscription model was a great motivator for companies adopting SaaS.

The implication here is that when a company needs to tighten the screws and scale back, it can change its cloud subscription to a lower cost model. The subscription provides the agility not found with hardware and software infrastructure, for which companies are still stuck with a bill when scaling back. Cloud computing’s ability to rapidly scale back or build out a business is especially critical today when companies cannot afford to either throw money away or quickly accommodate new business opportunities.

The essential element for building trust around these concerns is visibility. Companies today wouldn’t create a Web page without providing analytics around who is accessing their site, and companies opening APIs to the cloud need to have this same visibility into “who” and “how” services are accessed. Visibility gives businesses the ability to see who their best and worst customers are and figure out how to meter the service for billing, how to enforce SLAs, and tier service levels. This insight allows them to guarantee that any cloud service or SaaS API is just as robust and healthy as any internal application or service.

A good example of how this really affects businesses is a media company that is looking to open up its content to the cloud. This company must have visibility into who will provide a revenue channel for distributing content. Releasing content to the cloud without this visibility and insight would leave them vulnerable to losing possible revenue channels. Here, visibility is crucial to both sides of the service so that the media company can see where to best release its content and also trace who and how people access it in the open cloud.

The takeaway here is that visibility is key for trusting the cloud – it gives insight into API metrics and allows companies to understand and map performance to consumers use.