We watch the platform-as-a-service space closely here at ServicesAngle, but sometimes interesting use cases for PaaS can be hard to come by. That makes today’s announcement that SuccessFactors is using VMware’s open source PaaS system Cloud Foundry to enable its customers to extend its applications all the more interesting.
SuccessFactors is a software-as-a-service provider that offers employee-performance software and what it calls business execution software. Along with companies like Salesforce.com and Workday, it’s an enterprise SaaS success story.
According to a blog post on the Cloud Foundry site: “SuccessFactors chose Cloud Foundry for the flexibility and choice it provides their customers in development frameworks, applications services and clouds for deployment.”
Services Angle
Over the weekend GigaOM ran a guest post by Mike Jones of PaaS provider Outsystems. Jones argued that PaaS is “eating” SaaS. Jones makes the case that PaaS will overtake SaaS because SaaS requires extensive customization and in the end you don’t “own” the applications you’ve built your business around. He claims that SaaS has been popular because writing custom apps from scratch has historically been expensive and time consuming. He believes that as PaaS makes custom development faster and cheaper, PaaS will disrupt the SaaS model.
I’m not so sure this will happen. After all, PaaS can also make customizing SaaS applications faster and cheaper. SuccessFactors is the latest company follow the model that Salesforce.com pioneered with Force.com – mixing SaaS and PaaS. Even before Salesforce.com acquired Heroku, Force.com could be used to build standalone applications. However, apart from Heroku, Force.com is mostly a platform for building on-top of the Salesforce.com by extending existing SaaS applications, building integrations with other applications and services, etc. Oracle is jumping on this bandwagon by adding Groovy scripting to its Fusion Apps line, along with a full Java PaaS service. Then there’s companies like Podio (see our coverage) that blur the lines between SaaS and PaaS by creating hyper-customizable applications.
Instead of PaaS eating away at SaaS, I see the two models becoming increasingly intertwined as providers adopt Web-oriented architecture principles and RESTful APIs and services like Okta and SnapLogic make identity management and integration increasingly easier.
Hi Klint,
One of the key elements that did not come out in my GigaOM piece is that many of the current PaaS offerings out there, like Force.com, are more suited to ISVs who are building new SaaS offerings than corporate ITs who are delivering 'one of a kind' custom applications. My reasoning is that ISVs have very different characteristics / needs than a corporate IT. The most obvious is that an ISV is targeting their SaaS offer at multiple end customers. While the corporate IT team is only building the application for one customer. While this is a big difference I do’t think it gets to the root of the issue.
If you peel back a layer and think about the nature of the application that ISVs are building vs. a corporate IT you will find two very different challenges. For the ISV they are building an application they believe addresses a process that will be used by multiple customers. Thus the process they are addressing and the supporting SaaS application should be fairly stable or 'commodity' in nature. On the other hand, the corporate IT team is building a custom application because their process is unique. In most cases they could not find a SaaS offer to meet their needs, thus they have to build.
Now to the rub! The corporate IT team's challenge is compounded, as the process they are trying to automate is unique. This means that they (and their business) are in 'invent' mode requiring a development approach and supporting PaaS technology that will support application evolution and rapid change. Note, time to market is critical for both groups. However, the amount of churn in requirements tends to be much more controlled for an ISV than what the typical corporate IT team finds. Of course the difference between ISVs and corporate IT goes further. Some additional differences are the nature of the development teams, how projects are funded and managed, etc.
The end result is that PaaS offerings for corporate IT have some very different requirements than those needed for the typical ISV. They have to make the development process easy and try to minimize complex handoffs from development to operations, etc. They also have to address integration and make it easy to pass the application form one group to another for maintenance. Last but not least a corporate PaaS needs to have change management inherent to the PaaS platform and they must provide the flexibility to move the application at will in order to meet changing demand from the business.
- spam
- offensive
- disagree
- off topic
Like