Wednesday 8 April 2009

SalesForce's "No Software" - hmmm ....

#cloudforce I've been thinking about the "No Software" msg - It's great, really eye-catching and a very strong message. But are SF being a little bit mischievious? If SF allows infinite configuration, storage, sequencing of operations (worflow), selection and iteration, then isn't that a programming language? If it's not, then every customer has exactly the same system and can't generate any competitive advantage.

I think it is a great message for corporations (big and v. small) where it doesn't make sense to be running commidity applications like HR, payroll etc. on-premise with custom applications and the associated support systems and people. Clearly SF (and their ISVs) have great solutions in that area.

But their proposition of "No Software" doesn't make sense where:

a) An organization already has systems that generate significant business value and are their competitive differentiator. Why would anyone move to standard package offerings (albeit with lots of configuration options) and lose that differentiation? The risks and effort (who in the organization really knows what those existing systems, which may have been running for years or decase, do?) are enormous and rarely cost-effective.

b) Why would an organization using a standard language (Java, COBOL or whatever) rewrite critical business systems in a proprietary, XML based language that only runs on one provider's platform. Surely that's too much too big a risk to take?

c) Once those systems have been highly customized, they need maintenance and enhancement just like any other language. So the organziation will need to keep staff to maintain their systems and supposedly one of the benefits of "No Software" is that you don't need to keep your own IT programming organization.

So, I'll say again, SalesForce have fantastic offerings (the demo at CloudForce of the "genius" feature was v. impressive) but to propose that this is the ultimate replacement for all programming and customized systems is wrong. I would agree that there's less and less reason for those systems to be running in-house but they should stay in the original style (Java, COBOL, C++ etc.) - keep the valuable applications (and maybe start to extend those apps to exploit the new platform) but move them and their systems support out of house.