History repeats itself
Blue Steel? Ferrari? Le Tigra? They're the same face! Doesn't anybody notice this? I feel like I'm taking crazy pills!Salesforce.com recently announced the launch of Apex, and judging by the early response from the industry, this Apex thing is nothing short of the second coming:
- Mugatu
Marc Benioff calls it “the most important announcement Salesforce has ever made.”
In fact, says Benioff: “Now that anything can be built on demand, no corner of enterprise software is safe.” Muah ha ha ha! (added for effect)
Mark Gorenberg at Hummer Winblad called it “the biggest thing since the stored procedure.”
Nick Carr says “what Salesforce is doing is certainly part of a big tsunami in business computing”
Dan Farber says it represents a “shift in the software landscape.”
Phil Wainewright says “The conventional licensed software market hasn't seen anything like this.”
Forget waiting in line to pre-order a Playstation 3, I’m going to run down to the Moscone Center with cash in hand to get myself some of this Apex! Wait, what exactly am I supposed to be buying?
A programming language.
Based on an 8 year old technology (Java & SQL).
That’s not in beta yet.
Well, maybe that’s still big news. Just to be sure, I jumped into my way back machine to see if our industry has every seen anything like it before:
Oracle has PL/SQL
PeopleSoft has PeopleTools
Siebel has Siebel VB
SAP has ABAP
Now Salesforce has Apex… but somehow this is the biggest thing since client-server.
I whipped up a quick comparison of Apex to a few of today's many application specific languages. I'm not an engineer by trade so any and all corrections are appreciated:
And all of these languages are procedural. None of them are portable to other application platforms.
Mind you I have nothing against Apex, but hearing leaders who average 25 years in the industry promptly ignore their own 25 years of experience leaves me scratching my head.
To Apex itself, credit where credit is due:
Apex is arguably cooler than its predecessors. Things that are shiny and new always are. Of course things that are shiny and new also have no developer community, install base or ecosystem, but who am I to bring facts into the discussion (they call it Dreamforce for a reason I suppose)?
The runtime for Apex purportedly does some nifty stuff to enable developers to write customizations, run code in a multi-tenant architecture, all while preserving upgradeability. This is not easy to do. Over the course of the next year, we’ll learn more about how confining Parker Harris made his sandbox to achieve this and how easy it is to build different types of castles.
Apex makes Salesforce applications much more customizable than before and this will increase their viability in more demanding environments. It will also increase their cost and complexity. Hate to be the guy who says "I told you so," but 6 months ago I wrote how the closer SaaS got to meeting the needs to the large enterprise, the less distinct it would become from on premise.
This was a necessary step for Salesforce to take and I suspect it will make them more attractive in the large enterprise. I seriously doubt however that Marc will get many takers for those $20,000 cubicles. The reason why there are very few blockbuster startups built on ABAP or Siebel VB or PeopleCode is the same reason why you won’t find many on Apex.
posted by Charles @ 12:09 AM
10 comments
10 Comments:
Have you seen Zoho Creator ? http://zohocreator.com. You can actually create an entire application online. It also comes with an online scripting language called Deluge which tries to bring SQL closer to the core application logic
http://blogs.zoho.com/creator
http://zohocreator.com/help/deluge/index.html
I think what is unique here is combining a java/sql language with an Appexchange marketplace and commmunity and no infrastructure required. The concept isn't totally new but so far salesforce.com show signs that it can execute on its strategy, and from the bottom up offer a platform altnerative to companies like SAP, which seems to pooh pooh this kind of idea.
Hi Dan,
I'm inferring from your comment that you agree the Apex language is nothing new. Instead, it's the combination of Apex + Appexchange + no infrastructure required.
In the end Appexchange is a more efficient version of a partner catalog.
There's really a lot riding on this "no infrastructure" part of the equation. I imagine this is a boon for in-house developers, but for your average ISV, I don't think infrastructure is so burdensome that this drastically changes the game. ISV's are usually technically savvy after all. Maybe it's the office space they really need help with.
I don't believe I have pooh-pooh'ed Salesforce's platform strategy. I just wish more pundits would refrain from hyperbole and understand it as evolutionary, not revolutionary. This is an inevitable step in the lifecycle of being a business application vendor, as evidenced by the fact that every major application vendor in history did the exact same thing Salesforce is doing now.
I think it's possible to view an event like this with the perspective of having seen it 6 times before. That doesn't make someone a naysayer, should it?
"That doesn't make someone a naysayer, should it?"
No it doesn't but it does mean you're pouring cold water on someone's hype fire.
Personally, I think you're introducing a level of reality to the situation, something our industry is happy to ignore for the sake of a little excitement. Keep pouring the water as far as I'm concerned!
I don't think it's the tech that's new or even an evolution per se. I think the real interest is in the deployment model/lock-in aspects this brings to the table. It's also putting a new layer of utilities etc on top of the more basic utility models being offered right now. However, that too is an evolution of course.
I do wonder how successful this offering will be given that there is the barrier of learning yet another language regardless of it's similarity to Java etc. It's also going to require a mindset change which may or may not be accepted by the industry.
Interesting times......
Dan Creswell
http://www.dancres.org
This stuff somewhat misses the point – the issue is not simply a technical one. It is also commercial and economic.
All the major software vendors have historically built their extant business around having applications that execute and provide visibility within enterprise firewalls. This paradigm is about to be rapidly broken apart as businesses and governments seek access to applications (built with newly emerging and disruptive technologies) that enable visibility and execution within and across multiple firewalls. This requires ‘multi tenanted’, ‘multi organisation’ or highly ‘personalised’ software services.
Salesforce.com is simply revealing that the emperor has no cloths and it is possible to build to and support the newly emerging business models that are collaborative, involve ‘networking’ and visibility and more importantly execution across and between multiple firewalls.
Salesforce.com is also a glimpse into the future and the emergence of a new business model. This new business model has the potential to fundamentally change, firstly, the software development value chain and secondly, cannibalise existing software delivery business models that underpins companies like SAP. Business history is replete with companies that grew around a specific business model and no longer dominant or exist, or have changed in response to new ways of doing business, new technologies, customer needs, etc.
The question is how do you (SAP) change your business model and operation if all your revenues are locked into a business model that is fast being eroded? Also, how do you actually built these new applications bearing mind all your current IP is embedded in a technical architecture that will become increasingly less relevant as it is enterprise centric and not collaborative? Over to you SAP.
Iain
PS – simply rewriting all the code into a Web technology using the ‘traditional’ software development approach will not produce an answer to the challenge highlighted above.
Ian,dfblog.
Show me anyone that is making money of f appexchange other than SFDC.
It is the commerceone story, just in a different guise.
Iain,
Thanks for your comment. I agree with some of the trends you mention but to my knowledge they have nothing to do with SaaS and even less to do with Apex.
"All the major software vendors have historically built their extant business around having applications that execute and provide visibility within enterprise firewalls"
Yes, most enterprise software products have tackled intra-enterprise processes. This has nothing to do with firewalls however. It's the process that matters.
"This requires ‘multi tenanted’, ‘multi organisation’ or highly ‘personalised’ software services."
These are three radically different concepts. Multi-tenancy has nothing to do with multi-organization. A perfect example is most of the major SaaS companies (RightNow, Salesforce, Netsuite) still tackle intra-enterprise processes. Multi-tenancy doesn't magically change the business problem you are solving.
"Business history is replete with companies that grew around a specific business model and no longer dominant or exist, or have changed in response to new ways of doing business, new technologies, customer needs, etc."
Yes, all things change, especially in software. Still you never actually describe this business model however so I'm left wondering what it is and how it's different than the model we have today.
I think SF's targeting two things: more complex applications and eventually in-house deployement for big companies. More on my blog
They freely admit they are modeling Apex after PL\SQL and also freely admit that what the language will do from a procedural standpoint isn't new. What no one has done before is build this in a way that will work safely in multitenant infrastructure. They're building all the pieces of client-server into an on demand model. That's pretty cool. And your Apex procedures will have web services APIs built for them automatically. Pretty cool, pretty modern.
For more on SAP Functional and Technical Tutorials, certifications, white papers, SAP jobs
SAP Functional Tutorials
FI (Financial)
CO (Controlling)
HR (Human Resource)
LO (Logistics)
MM (Materials Management)
PP (Production Planning)
QM (Quality Management)
SD (Sales and Distribution)
TR (Treasury and cash)
WM (Warehouse Management)
PS (project Systems)
PM (plant Maintenance)
CA (Cross Application)
SAP Technical Tutorials
ABAP
DICTIONARY
INTERNAL TABLES
ALV Reports
SAPSCRIPTS
SMARTFORMS
LSMW
BDC
ALE
IDOC
USER EXITS
TRANSPORTING
ITS
Please visit
SAP Functional and Technical Tutorials
Post a Comment
<< Home