What/Who SalesForce enforces by Apex?

The news that SalesForce.com announced its new language Apex has been echoed in the blogosphere for last week and the idea of yet another language has gained lots of criticism. People chew over the last step of the king of the SaaS world from all possible sides: how innovative it is, how significant it is, how known and repetitive (hinting to the ABAP success), and  even how SAP reacted to the news. I didn't read everything in the net on the topic but the ones, apparently, forget to answer the question why SF had no choice but to come with such an idea and what long-term targets SF sets for its business. I'll try to share with you my bet here what I suspect SF had in mind when it made this decision. Disclaimer: This blog, as all others published here, represents only my personal opinion and has nothing to do with SAP:-)

SF started its business and has been trumping its competitors with the SaaS philosophy. The impressive achievements of 0.5M users and 400 applications (regardless what we count as an application) makes the big guys (on-premise enterprise software vendors) nervous but, at the same time, leaves them and opponents of the on-demand application a few strong arguments why the SaaS model can't be accepted by some companies (at least for some applications and markets). I think the major obstacles on the way of a SaaS provider to grow are: 1) low customizability - I would call what they offer rather configurability, 2) high TCO for a big number of users, and 3) resistance of customers to deploy their data and/or processes outside of their data centers.

To address first problem a SaaS vendor has to equip its partners by some mighty tools. Nobody started a controversy on the reason for a language. But all platform providers have eventually to lock users by something: proprietary language, custom extensions, out-of-spec improvements - there must be a catch to not to let the users easy to go. SF decided to develop its own language (I doubt it will be as complex and powerful as Java or ABAP) but that's the ultimate level you can offer the lock mechanism to build on. It's always a trade-off between high bets with high risks and low bet with low risks (in case of SF to extend or directly use any of the widely adopted languages but not to gain a strong and short leash for the users). I don't want to discuss here merits and demerits of Apex and don't think it's really important. The step SF undertook to develop, promote a new language and empower the ecosystem (concurrently building it) deserves laudable comments from a business point of view. We'll see soon how successful its adoption will be.

To resolve the last two problems (high cost of ownership for a big user base and out-of-house deployment) SF eventually will need to offer on-premise solutions. Although they build the success on the anti-in-house applications thesis the pie of in-house developed applications is huge not to dream of it. I think it will be a hybrid model of both options where a dominant role of SF will maybe remain on the hosted side. But similarly to our move with CRM on-demand and Oracle's on-demand solutions SF and other hosting vendors will have no choice but to invade our patrimony of in-house deployment and start selling their platforms with a "buy-own-and-maintain" principle. Without a powerful [enough] language even to dream about that is a sing of a disease.

To reiterate, I think SF has a very ambitious targets on scaling up their partner ecosystem and building together with them new solutions for in-house deployment. The current success of 0.5M users may vanish as these users are not locked by SF's services at all. They got them fast and easy and they can lose them with the same epithets. To build a new level of success and become a player equal to the big guys they must accommodate the needs of customers equal to the big guys' ones. Without a powerful and locking mechanism it's impossible.

Comments

[Thomas]

Roman,
Interesting post. Couple of comments

SFDC is the king of SaaS salesforce automation, but not anything else. HR SaaS is a bigger market, and they dont feature, ditto accounting etc...

SFDC tells a fabulous story. It is simple, easy to understand and compellingly delivered. Compare that to our employer...

[Roman Rytov]

Hi Tomas,
I thought you're on a trail at 8AM at Saturday and not reading blogs:-)

Agree 100% with what you wrote. They're the king in a very small kingdom. But instead of going horizontally to other fields (HR is one of many tens) they have to cement their success and shoot vertically. Infrastructure, isntall base, users that will think twice before changing the vendor, whatever.

They're after the same hook as SAP/ORCL/MSFT did in their times.

By the way, SAP with the SOA story is looking for answers to the same questinos. We could have developed many new applicatinos for the areas where we aren't today but we're looking for new options to scale up and conquer new markets and users hearts (wallets?).

Love their messaging and marketing seductiveness too:-)