As David Linthicum writes in this blog, should cloud providers stop building features and start building for interoperability?
Add a Reply
Recently Commented On
-
Will case management eclipse BPM in importance this year? (12)
Dave Duggal wrote: Good question to start the New Year... [more]
-
What are your BPM predictions for 2012? (15)
Christopher Taylor wrote: With a new Gartner Quadrant out for... [more]
-
What modeling techniques should be used for capturing case management processes? (5)
Dave Duggal wrote: Hi Peter - Thanks for raising the p... [more]
-
What was the biggest development for the cloud for 2011? (2)
John Michelsen wrote: The biggest development for the clo... [more]
-
How big of a role does BPMN play in today's projects? (18)
Theo Priestley wrote: Depends where you're starting from ... [more]
Tag Cloud
Blogs
- Agilization
- All Things Social
- Anatomy of Agile Enterprise
- Andre Yee's Security Insider
- Anne Stuart’s BPM in Action
- BI in Action
- BPM and the Social Enterprise
- BPM from a Business Point of View
- BPM in the Cloud(s)
- BPM Insights
- BPM: Theory to Practice
- Business Ecology Initiative & Service-Oriented Solution
- Business IT Buzz Blog
- Business Transformation in Action
- Business-Driven Architect
- Cloud Talk
- Column 2
- Data at Your Service
- Dion Hinchcliffe's Next-Generation Enterprises
- ebizQ Mobile CRM Enterprise Integration
- ebizQ's Business Agility Watch
- Enterprise Architecture Matters
- Enterprise Mashups in Action
- First Look
- Governing the Infrastructure.
- Ground-Floor BPM
- Information Architected for Business
- Integration Innovation
- Integration on the Edge: Data Explosion & Next-Gen Integration
- IT as a Catalyst for Optimal Business Outcomes
- IT Directions
- James Taylor's Decision Management
- Kiran Garimella's BPM Blog
- Leadership BPM
- Leveraging Information and Intelligence
- Making Sense of Business Information.
- Manage Tomorrow's Surprises Today
- New Frontiers in Business Intelligence
- Open Source Software Up the Stack
- Pragmatic Software Design
- Process Makes Perfect
- Process POV (Process point of View)
- Putting the ‘M’ back in BPM
- Ronan Bradley's FinanceTech Directions
- SaaS Week
- Security Matters
- SMA's Insurance Transformation, Where Strategy Meets Action
- Smart Systems in Business
- SOA - Integration Industry Pulse
- SOA Visionaries
- Software Infrastructure for Business Value
- Software Test Management and Metrics
- Tech Blog
- Tech for Tomorrow
- Technology Management Insights
- Ted Cuzzillo's BI
- The Architect Insider
- The Connected Web
- The Healthcare Blog
- The Mike Rothman Security Report
- The Performance Principle
- Twenty-Four Seven Security
- Where SOA Meets Cloud
| ADVERTISEMENT |



I wouldn't call it an either / or proposition, but from a balance perspective I would put the ratio of feature development to interoperability development at about 85 / 15. The thinking behind this is twofold - on the one hand, the majority of your users will be leveraging the native UI for accessing the service and will not (immediately) require integration capabilities; on the other hand, the move towards standardization on RESTful or SOAP-based web service API's means that the lion's share of the interoperability architecture is already defined...the service provider just needs to design and implement well-described web services that can be consumed easily and securely (think Salesforce, Freshbooks, Basecamp).
The cloud has enabled long-tail services that provide niche capabilities that were never going to be realistic within the constraints of monolithic, tightly coupled software packages; these services were once only available to companies with budgets for custom development, and now cloud service providers are opening up deep functionality for a much larger audience, and the value being created by this paradigm is exponentially greater than the value of cross-service interoperability.
This is a big quandary for providers. Features allow them to charge money and make a profit. Interoperability allows them to reach the widest possible market.
The more interoperability and the less features you have, the more you're offering a commodity that won't make money.
The more features and the less interoperability you have, the more you narrow your appeal to a narrow, specialist market.
Who'd be a cloud provider?
Interestingly, providers that don't think about interoperability actually get commoditized the fastest. If we look at the cloud infrastructure market, what differentiates Amazon, GoGrid, RackSpace and others? Is it price? Probably not - it tends to be the management control panels. So, it would seem that this extra "feature" becomes the differentiating value add to attract clients. But if these providers focus on delivering better management consoles only for their own services, they will end up getting commoditized even more quickly. There is a whole new genre of uber consoles that are appearing in the market (or are about to appear) that bridge providers seemlessly. These "cross-cloud" consoles will turn many lower-end providers almost instantly into commodity cloud providers. Sound familiar? Just look at the ISP market in the late '90s.
We think it is too early for cloud providers to take this step to stop building features and work on interoperability. At this stage, the platform vendor has very little to gain by providing interoperability. What the platform vendors need to focus on is providing the right set of tools and abstractions and services across the board to attract more customers / data and create a bigger marketplace for all the stakeholders