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.

- 50% of all folks interviewed (enterprises with more than $1B in revenue) are doing cloud computing
- 66% of those do not have a security strategy
- RSA has put together a “Security for Business Innovation” council comprised of 10 security executives chosen by RSA.

Kudos to RSA for taking a customer centric approach. There is a shift happening in enterprise computing, it is becoming Web centric. The Web has been very successful in creating de facto standards without formal standard bodies, hopefully we have learned from it. Much like the Web, cloud computing adoption will have a life of it is own. Instead of trying to control it, lets guide it.

Market/Customer:
This is by far the most important perspective. Let’s take a current example: as cloud computing becomes part of enterprise computing, customers will go with the hybrid approach. if you keep hearing that (as we have), it becomes very clear that having an on-premise and on-demand offering will fit very well with their needs/strategy.

Strategy:
Independent of the technical reasons to do or not to do, there are probably strategic reasons that are more important. For example, Salesforce.com probably got many requests to make their technology available on-premise. Hard to do when the KEY differentiation is ‘no software.’ The other aspect is DNA. Running an on-demand application needs different kinds of folks that the ones traditional software companies usually have.

Technology/Architecture:
- On-premise software is designed to ship, so one has to worry about size of image, install scripts, platform dependencies etc. These factors affect the overall architecture much more than one thinks.
- On-demand software/site is designed for scale, ease of use, zero downtime etc.
- If on-premise software is designed for simplicity and scale, it is much easier to make it available available on-demand – the other way round is much more difficult.
- Much like open source. Technology that was not designed to be open source is very hard to open source.

In general customers want flexibility, too much of which leads to increased complexity. Vendors have to start by answering simple questions like why and how.

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

The operational and business consultant sides of the CIO won’t necessarily separate as Gray indicates. Yes, a lot of operational aspects are handled for you when you move to the cloud, but there is still very real work to be done in maintaining security and control in the cloud that is directly related to C-level business efforts. No doubt we’ll see the position of the CIO evolve, but the role is still vital to business & IT operations.

Highlights include no longer worrying about server power consumption or load balancing. Bob also notes that operating in the cloud keeps you from “Worry[ing] your engineers are spending valuable time worrying about infrastructure and worse physically visiting that infrastructure instead of doing something that gives your company a distinct competitive advantage.”

ZDNet’s Larry Dignan responds that these are great in theory but cloud computing isn’t a reality yet for most companies – I think it’s actually a lot closer than Dignan says and these 10 advantages are an incentive for companies to adopt the cloud sooner.

- Customers think of information technology as a means to an end.
- When they are making IT related decisions (technology and vendor) they are generally making them for the long term.
- Technology decisions are based on many issues like skill availability, how it fits into the technology, standards – portability as it related to standards.
- Vendor decisions are also based on many issues like track record, area of focus/expertise etc. Leverage is also on the list. Portability helps with issue.

At the end of the day, customers are looking for standards based technology that they can work with vendors to implement. Standards not only help them with technology related issues, but also leverage with vendors.