Blog post

Expect More Native Mapping Capabilities in AppFabric and Force.com Soon

By Benoit Lheureux | April 23, 2010 | 0 Comments

Last night I attend the MIT Enterprise Forum of Phoenix event on Cloud Computing. These events target entrepreneurs and this one featured speakers from IBM, Microsoft and Salesforce.com with a panel that followed moderated by David Bennett of Axway. It was a very interesting event, well attended and with compelling presentations — and it was a lot of fun meeting with the entrepreneurs, which ranged from providers of various niche SaaS solutions to general-purpose Cloud virtualization.

In side conversations I caught up separately with Joe Shirey, Microsoft, and Peter Coffee, Salesforce.com (for anyone who who is curious, yes — Peter lives up to his family name — quick thinking, animated). I asked each about their company’s strategy regarding Cloud services integration, and the curious (to me) choice not to incorporate strong translation capabilities directly in their respective Cloud implementations, AppFabric and Force.com. (We recently published analysis on the integration capabilities of solutions like AppFabric — see Solutions for Cloud Services Integration / SaaS Integration Proliferate).

While each can handle simple translation requirements in their development environments, the emphasis on Cloud-2-Cloud or Cloud-2-On-Premise interoperability is on secure API consumption (the driver of promiscuous Cloud interoperability) so when it comes to semantic reconcilliation for the most part the assumption is that “he who executes the verb accepts the noun”, meaning service consumers accept responsibility for handling returned values directly, in whatever form they’re delivered.

Its a remarkable fact of Cloud computing that in most cases service consumers are happy to consume return values from service calls directly. Service consumers implement their own application logic, pull down a menu to select and incorporate calls to required services (implemented locally or in the Cloud), and natively handle return values, manipulating individual values or records as needed in their code. But what about more complex information like business transactions such as purchase orders or insurance claims? As nouns become increasingly complex it is increasingly likely that — at least at times — it won’t be convenient or desirable to manipulate the noun directly in its native, delivered form. That having general-purpose mapping functionality readily available within the Cloud development environment would be useful to developers.

Today when strong general-purpose mapping functionality is required in conjunction with AppFabric and Force.com the vendor-recommended solution is to use external mapping capabilities — for AppFabric, Microsoft recommends BizTalk; For Force.com, Salesforce.com recommends any of its many third-party Cloud services integration solutions providers such as Cast Iron or Pervasive (follow link above for references to more of these vendors – there’s many!).

So far this approach appears to be acceptable to most clients since I don’t get many complaints about it. But we also know that many users deploy BizTalk and the various other 3rd-party integration tools quite often, both for general-purpose mapping capabilities but also for suites of adapters to connect to various on-premise applications and systems, and Cloud API’s. In fact, we’re just about to publish our forecast for B2B integration solutions, which will reveal very strong growth in adoption of Cloud serviccs integration solutions — look for “Market Trends: Multienterprise/B2B Infrastructure Market, Worldwide, 2010” soon.

If you accept the growth in adoption of 3rd-party integration solutions it exposes a conundrum: at what point do Cloud providers such as Microsoft and Salesforce.com acknowledge their user’s need and simply incorporate strong mapping capabilities directly into their own Cloud offerings, rather than referring users to external mapping and integration tools? Not as a result of my conversations from last night — or in fact any specific conversation with anyone at Microsoft or Salesforce — but strictly as a result of my own musings I figure it is inevitable that these providers will simply close this functionality gap. Why not? Its not like a mapping tool is rocket science, and its not like they need to offer the best capabilities on the market — with an 80/20 solution they can address many of the more basic mapping and connectivity requirements, while still referring to 3rd-party Cloud services integration solutions and partners for heavy-lifting mapping and more comprehensive adapters suites — no point in fully re-inventing the wheel.

So, that’s my prediction… and musings from a fine Cloud computing event here in Scottsdale last night. What do you think?

Cheers,

– bjl

Comments are closed