Thomas Otter goes after salesforce.com in the post above. He argues they could turn out to be the Commerce One of Bubble 2.0…
As regards his argument against scripting, which is that is tends to lead to brittle apps, built by folks that may not have all the experience required, I would pushback.
What makes SAP a momentum play right now? The ability to access SAP core functionality using environments like Ruby On Rails or PHP is one reason to take the German Giant seriously at the moment, given a larger, fast-growing available pool of developers. Just ask Craig Cmehil. Indeed Thomas told me just the other night about an interesting project at a client that ended up using BSP but could have chosen any scripting approach.
Also Thomas, wasn’t JCL more a scripting rather than a systems programming language?
Anne Zelenka argues that salesforce.com should have gone with a more loosely, rather than strongly typed, approach with its new language Apex, chasing Ruby-like devs.
From what I can see though, after looking at this presentation, slickly hosted on Adobe Breeze, something like Apex is going to be potentially very useful for building transactional apps. What if you need to do a rollback, or batch a number of changes before you commit them? I don’t see that kind of function being something we see much of in AJAX or REST-land.
Mashups with google maps are slick and all – but in order to scale, where 2.0 meets enterprisey, you might want mechanisms to throttle access to back end data services. [even if just a lightweight ATOM-“front end” for replication and distribution, say?]
Another opportunity in protecting data is virtualisation and partitioning, which also brings potential performance advantages. Lets remember Apex is built on a virtual machine. I can see these apps running on hardware like Azul, built for VM processing, or Sun multicores, in a high performance dense processing environment. That is goodness in a hosted world.
As far as I know SAP is continuing to invest in BAPI… Well Apex is salesforce.com’s BAPI, not its Rails.
Apex has Code Governors… its got to be good, right?
On Sloppy Wouldn’t Do.
Maybe I am missing something but given salesforce’s ambitions, with incredible quality of service requirements, sloppy just wouldn’t do. A reputation for outages would kill salesforce.com before it could hope to challenge other enterprise software vendors. The endpoints, not the backends, can be brittle. That is where DIY, disposable applications and dynamic scripting will have the most immediate impact. On the Web scale does matter. But different kinds of scale are useful for solving different problems – scale up or scale out are useful in different ways, flat file or relational are important design choices. There is a reason CICS on System z is still worth billions of dollars to IBM. Tuxedo is more scalable than WebLogic. Sometimes you want to extend a Rails app with c.
Mashups and REST work very well in given contexts. Scripting languages are incredibly powerful environments for building interaction-based applications. I don’t think 2.0 is going to change the fundamentals of computer science though. Do you? Optimisation will never go away completely while great programmers exist. Neither will abstraction. I am emphatically not saying Rails or PHP can’t cut it, but I am saying the world needs a variety of tools and approaches, and so fosters exactly that.
Thomas thinks salesforce.com can’t be the host, the app function and the programming language. SAP – pot, kettle, black, missed pot? Netweaver is going to host other firm’s applications, but SAP only runs on SAP? Its really not so long ago though SAP was the plucky upstart. Should salesforce not try and compete by doing something different? Of course it should. Meanwhile Vinnie goes after SAP FUD about multi-tenancy here.
Anyone thinking through the implications of Apex should check out David Berlind’s extremely long but excellent piece that worries about portability and lock-in:
“Apex is a language that is optimized for developing applications that run on and are hosted by salesforce.com. Java is not. Nor are the others. In fact, what do you get when marinate Java with some salesforce.com specific SQL calls in order to make it easier to build salesforce apps? Apex. In the bigger scheme of things, when you consider how staying with one of the other all purpose languages would probably have done very little to fix the lock-in problem (see my earlier arguments), but how it might have sacrificed some of the optimizations that empower developers to more quickly and easily harness the salesforce platform, salesforce.com ultimately made the right choice for itself as well as its customers.”
Its all about the data, not the systems environment (pace Tim O’Reilly).
Talking of Tims – Tim Andersen is another smart voice I admire. He says, bearing in mind that the same API calls are apparently going to be available through SOAP interfaces:
“Although Apex calls the same internal APIs that are exposed through web services, it has the potential for much better performance. Consider the scenario where you want to loop through 100,000 records in code. Doing that with web services will take an age; in fact, that sort of operation is not what web services are designed for. Apex can do it though. The implication is that although you can choose between Apex or Web services, the Web Services choice will not always be viable .”
It’s the Economy, Stupid.
Thomas also points to some interesting questions about the momentum or lack of it for appexchange, which is why you should go check out the opening link above. The key reason I am writing this post is because his post reminded me of some wise words recently spoken by SAP heavy-hitter Nils Herzberg.
“You can only lower barriers to entry if you have gravity… You need to be attractive. You need to attract ISVs… of course only some companies can create successful ecosystems. You need to make sure it makes money. It’s a market mechanism. It has to be the most profitable market though, to be the most successful ecosystem.”
The challenge facing IBM, Microsoft, Adobe, Google, Microsoft, SAP, Oracle, salesforce.com, and everyone else that wants to grow their business is making money for other people. Doing that is the charm.
AppExchange really needs to be a market, not a platform. What matters most is creating opportunities for folks to make money.
With that in mind a tenanted model creates significant opportunities. Traditionally with software development the developer has no idea who actually uses their code. Its one of the issues that has stymied reuse – why should I let someone piggyback on my, or my organisations, work, if they haven’t paid me? Well, if salesforce.com can track who actually uses what then we could see some new economics in the industry, which could see star developers start to take home Premier League salaries. [I actually thought I saw Dennis Howlett blog the “unexpected benefits” idea first…].
But that’s enough conjecture for now.
Finally, you have to give credit for the cool name: Apex (from App Exchange). But then I am sucker for a names mashup…
disclaimers: salesforce.com and SAP are not clients. IBM and BEA, who are, are probably wondering why I haven’t covered their latest announcements yet… this week, guys. Thomas whooped me at pool last week, so if I seem bitter…