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.

So why do you need an API? For one thing, everyone else is diving into the API economy and your business needs to stay competitive. Yes, APIs let your company drive more revenue opportunities, but they also help you stay instep with, and often ahead of, the competition. There’s an awesome post by Kipp Bodnar on this subject and the API as the next marketing platform: http://digitalcapitalism.com/2009/04/api-marketing.

Now that you know that you need an API to expand business, you face certain issues with API development and deployment.

API Design: As always start with KISS (keep it simple stupid). You need simple design to address two basic principles: make your API easy to use and hard to misuse, and make it easy to extend. Joshua Bloch has written extensively on this subject.

API Deployment: lets start with visibility. As one of our customers says, “you need to see the needle to move the needle.” Next comes control: authentication, threat protection, rate limiting, etc. If you’re familiar with Sonoa, this is what we do – we’re helping people expose their APIs by giving them this visibility and control. It’s a great time to expand your services with an API – just be sure to cover your apps before jumping out there. API development and deployment is a critical subject that I’ll be writing more about in the weeks to come.

While there was initially hesitation about SaaS as a new, untested technology, once an enterprise explored the easy of deployment and cost advantages, the move was a no brainer. The same is already happening for cloud computing. Though 10 of the 12 surveyed said the cloud is not part of their current cost cutting strategy, today’s economy will continue to make the ease and low cost of most cloud services more appealing, and will eventually lead more CIOs to migrate to the cloud.

Goldsmith highlights security as the main concern for CIOs. However, he does note that those surveyed do recognize the potential down the line. He writes, “Despite the comprehensive ‘no’ vote, some CIOs expect that the cloud will indeed play a part in their future tech plans. Ben Acheson, IT manager of PADS Printing and Commercial Stationery, believes cloud computing will become part of his strategy once the wrinkles have been ironed out.”

It really just boils down to early adopters and those who will jump into the cloud later on, once they feel more comfortable. Alistair Behenna, CIO at Harvey Nash, was in the minority of the survey, having recognized the opportunity for his current IT strategies. He noted that cloud computing “has to be a viable strand in any IT strategy fabric.” He also said that it is “certainly not the whole solution but it is undeniably useful for specific areas of the infrastructure and service delivery.”

It’s always valuable to hear the concerns of those making the IT decisions. Survey these same CIOs in a year and you will see many more saying that cloud computing has become part of their cost cutting IT strategy. Survey again in three years and cloud computing is sure to be ubiquitous. Once the early adopters see that that “wrinkles have been ironed out” there will be no question that cloud is to stay for quite some time.

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.

Jeff, why are more companies migrating to the cloud?

Jeff: Companies of all sizes are moving to cloud in response to today’s turbulent economy and the need to accelerate the rollout of new IT/application capabilities in a more economic and agile fashion.

Why use a cloud-based service to help them get there?

Jeff: Not only do today’s cloud computing services offer more economical and flexible alternatives to legacy hardware and software, they are also more responsive to an increasingly mobile and Web-centric workforce which needs to access applications, data and computing resources from anywhere at anytime.

What are the revenue opportunities?

Jeff: There are tremendous revenue opportunities at all levels of the cloud ranging from horizontal and industry-specific business applications to service delivery infrastructure management tools and resources.

What are the pitfalls and risk considerations?

Jeff: Reliability, accessibility and security (RAS) are the primary customer concerns, but the risks and pitfalls go far beyond these areas, including service level assurance, compliance and management control. But, most importantly is that the business model for building and sustaining a financially viable cloud computing service is yet to be developed. Therefore, long-term vendor viability in the face of an inevitable industry shakeout is a key issue.

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.