Earlier this year I joked that perhaps Salesforce.com could use its rival NetSuite's platform to add missing transaction capabilities into its on-demand application suite. While such an alliance was never a realistic possibility, I could easily envisage Salesforce turning to a third party as a means of adding much-needed billing and settlement capabilities to its AppExchange marketplace. Interestingly, the company has now rejected the notion of partnering or acquiring to add those capabilities. Instead, it will do exactly what it berates buyers of on-premises software for doing: it will custom-build its own solution.
Its decision to do so illustrates one of the conundrums (conundra?) when building a loosely-coupled services infrastructure (which all on-demand SaaS implementations are, as I recently explained). ZapThink's Jason Bloomberg has just posted a superb analysis of The Lego Model of SOA in which he uses the Lego analogy to highlight both advantages and drawbacks of service-oriented architecture. Here's the pertinent one:
"The larger you build a structure with Lego blocks, however, the more fragile it gets. In other words, loose coupling comes at a price. While tightly coupled interfaces reduce flexibility and reusability, they also can increase efficiency. Loose coupling, on the other hand, can limit the efficiency of the implementation."
Commerce transactions are such a fundamental component of a marketplace that Salesforce.com does not want to rely on a third party for that mission-critical function. It needs it baked into the infrastructure so it can maximize performance and operational accountability.
But hang on a minute. Isn't that the whole argument in favor of keeping software on-premises? Hasn't Salesforce.com just totally invalidated its 'no software' mantra by insisting that only its own home-built software will do for this core mission-critical function?
Well, yes and no. Let's put it this way. If any organization is going to rely on third parties to run aspects of its operations (which, let's face it, all organizations in the modern world do already to quite a large extent) then it's going to want those third parties to offer world-class infrastructure. If that means the providers have to build their own software from scratch, then so be it. Salesforce.com's 'No software' admonition is directed at customers, not at the company's own development team, as Benioff made clear when I interviewed him back in January:
"People did not realize we had to write a lot of code," said Benioff. "We’re not talking about small amounts of code any more. We’re talking about seven years of code."
AppStore Checkout, which won't be in production use until December next year, is another year's worth of code, which makes it quite an undertaking. Of course it's also a proof point for Salesforce.com's Apex programming language, for which it will be a powerful showcase application.
I'm sure a final factor in the decision to build rather than partner is that it plays better with Wall St. One of the paradoxes of Salesforce.com's success is that the larger it gets, the more it has to look like a conventional software company in order to maintain the confidence of mainstream investors. Pre-announcing yet-to-be-developed products more than a year in advance is certainly torn right out of the Microsoft/Oracle copybook. But Salesforce.com is such an adept player in the fast-moving world of on-demand applications that I suspect it will be springing some more surprises on us over the coming year before we get the full story about AppStore Checkout.