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…
apex, salesforce.com, Berlind, RubyOnRails, Java, SAP, Cmehil, SaaS, CICS, Mashup, AppExchange, SOAP
Thomas Otter says:
October 16, 2006 at 7:02 pm
James,
I’m up for a rematch at pool anytime, although perhaps we should play doubles against all comers. Actually a bloggers pool tournament for charity might get more takers than the cycling did…one to ponder on.
I’m not sure that I said that scripting languages are brittle.
My point about the JCL example was not on the scripting language flexibility or otherwise (the JCL just kicked off the various programmes and helped merge 7 rather large flat files I’m remembering more about this than I really wanted to), but about how difficult it is to predict points of failure. Unintended consequences abound.
The series of extracts and date updates that I wrote in an SQL scripting tool were tested numerous times (not just by me), went through a major signoff process and I still nearly managed to crash the production system, because of a minor error.
If SDFC think that they can deliver an environment where everyone’s script runs in perfect harmony, in a production environment, then brill. No-one else has ever come close. So I was expecting more folks to question this than did
I’m not an expert in programming languages, but the irony of SAP constantly being battered about the proprietary nature of ABAP isn’t lost on me.
I have a lot of respect for SFDC, as you’ll see in my posts. They grew when the C1’s of this world were dying, so respect is due.
But I think it is tough to build world class business applications, it is tough to build great tools, it is tough to build world class hosted service 24/7, it is damn tough to entice others to a platform or market and profit from it.
To do all of these simultaneously on the R&D budget of sfdc would be in the realm of fishes and bread and 5000 hungry developers.
Anne says:
October 16, 2006 at 7:05 pm
Likely the reason they chose a statically typed, compiled language is not because of the safety but because of convenience. Essentially they’re offering up the ability to put stored procedures onto their host, into their database. The easiest way to do that is with something PL/SQL like. That’s the language of Oracle stored procedures, and Salesforce.com apparently uses Oracle RDBMS. Then, not wanting to call it PL/SQL-like–how dull–they called it java-like because with PL/SQL object extensions, java and PL/SQL are not too dissimilar.
Maybe stored procedures are what a developer would want and need, if they were going to build a from-scratch enterprise-scale app on the salesforce infrastructure. However, I suspect most developers aren’t going to do that. They’ll extend and customize salesforce itself, which may or may not require the performance, safety, and transaction control of a database stored procedure language. Scripts stored on the middle tier might be sufficient.
At any rate, the interesting thing is not the details of their “on-demand” language but rather the possibility of creating an app marketplace. I can’t see how Salesforce will grow beyond the CRM space given that’s where their dollars come from. Any real investment outside of that might get distorted or swamped by the core business thrust towards gaining and satisfying the CRM customers. But if they do succeed in creating a marketplace–wouldn’t that be exciting.
Craig Cmehil says:
October 24, 2006 at 4:22 am
Those “interesting projects” are turning up more and more as developers begin to use core functions within SAP system in a scope not really thought of before. The idea you can take a basic ABAP class file turn it into a simple web service using REST and passing data to 3rd Party apps or receiving data into your SAP system and passing it around your landscape thanks to trusted system setups while securing your environment from harmful code is really start to evolve and some very sweet apps are starting to pop up. Tie those into robust scripting languages like Ruby on Rails (framework, it’s a framework I know but hey come on stay with me here) and PHP and there seems to be little in terms of limitations on what can be done.
Food for thought!
Craig