As SOA Collides with SaaS
SOA Equals Software Sooner
SOA represents a significant change in development methodology. It requires that software be built in modules and that these modules be built to an appropriate SOA standard so that multiple modules (perhaps from multiple sources) can be combined into applications.
The idea is simple and satisfying. Many of the modules can be reused, reducing development time. The ability to create a new application from a library of existing modules (and perhaps a little new code), offers the organization substantially more flexibility to rapidly create new applications to support changes in the business.
Although SOA is a relatively new concept, businesses and their IT organizations have been quick to notice its value. About 75% of firms surveyed either have an SOA project under way or plan to start one this year.
SaaS (Software as a Service) Climbs the Ramp
SaaS is not a new concept. The idea of implementing applications in a remote, central data center and accessing them from a terminal or personal computer has been around as long as time sharing. More recently, in the late nineties, high profile attempts to start an on-line software market, under the label “ASP” (Application Service Provider) mainly failed.
But SaaS is a compelling idea. It allows users to have access to function immediately without the need to buy hardware, select and implement software, or provide ongoing support. Users can be added or subtracted as needed. In many cases, the user organization can choose to continue to support users on the SPs system or to bring the application in-house for broader implementation (but we believe this will happen less over time).
Third Times the Charm
So when the SaaS market appeared again a few years ago, many wondered why it would work this time. We’d note a number of differences between the ASP market of the late nineties and the SaaS market that is building now.
- Customer Readiness: When the ASP market was struggling to get started, we surveyed 100 potential user firms. More than half had never heard of using software as an on-line service. Today, more than half are already using at least one SaaS application.
- Customer Expectations: We always want to give customers more than they’re expecting, to insure a good result. During the early days of the ASP market, ISVs were much more interested in building data centers than building great applications. Customers didn’t understand that using an on-line application meant giving up customization; they’d lobby their ASP for an individualized version. If he gave enough customers what they wanted he probably went right out of business. This time, customers understand that for many SaaS applications, what you see is what you get.
- Business Models: Early ASP business models (if they had one at all) ignored reality. They emphasized technology (what the ISVs understood) and played down (or ignored) issues like marketing and profit margins. Today’s SaaS providers make use of hosting partners who can manage large data centers with economies of scale and offer the synergy of providing customers with a portfolio of applications.
- ISV Offerings: An individual ISV generally offers only his own application. But today there are many ways to be more appealing. We like double-dipper Intacct which hosts their application on IBM’s SP infrastructure (IBM has a portfolio of SaaS offerings) and then they provide their offering on the SalesForce.com site, providing exposure to a growing audience. (SalesForce.com users employ Intacct on an IBM site, although they would be unlikely to notice.)
- SP Offerings: SPs have learned that their job is to provide great infrastructure and first level support – and then to look for a way to differentiate themselves. (Early SPs tended to all look alike.) An SP might collect ISVs who sell to a particular vertical market, so that the could offer a complete portfolio and focus marketing efforts. Or an SP might provide some level of integration among applications or provide a platform for offering higher level function on top of his own (or a partner’s) offering.
We spoke with Treb Ryan, CEO of SP OpSource (www.opsource.com). He told us that about one third of their customers are switching from the traditional ISV model to SaaS. But he notes that how they move to the SaaS model counts: “The ones who really excite me are the ones who really get it,” Ryan says. (by getting it, he means understanding that you need to build software that fits the model and you need to market and compensate your sales staff to fit the new model, too. OpSource’s real goal is to build something that every ISV can put into their product and embed as a service so they can get revenue not just from the sale of their own product, but also from their sale of other companies’ software.
Ryan says the biggest problem of successfully moving to an SaaS model from a traditional one is sales rep compensation. Reps are used to being all up front for every sale. For high ticket products that can be a big number. Ryan suggests that you have to determine the life-time value of the sale and compensate based on that value, although I suspect that ISVs who are struggling to move to the new revenue model won’t be willing to pay 100% of the sales compensation for a three-year contract up front if they’re collecting it monthly (or even annually).
With SOA-based software, the problem is even harder. Now we have to track the software through the SaaS distribution system in piece parts, charging for some parts only as they’re used, with compensation following revenue. The problem’s more complicated on every dimension.
SOA, Meet SaaS
Customers and ISVs are moving to the SOA development model at the same time as customers are increasing their use of SaaS as a means of providing IT functionality to their users. All of us need to think through the implications of this for everyone – each of the players – in the marketplace – customers, service providers, ISVs, as well as systems integrations, VARs, and consultants.
Some of that will be solved by selling the SOA-based solution in sets of related modules – bigger bunches are easier to track and easier to manage from a revenue and compensation aspect. But, in other cases, the very charm of SOA will be the ability to compile the application from a variety of sources – or to build it up over time, on an as-needed basis. In that case, we’ll need:
· Very strong standards to make putting SOA-applications together in the SaaS environment a matter of selection not complex integration and custom coding.
· Excellent industry and public catalogs of SOA services so that we all know what’s available and on what basis. Of course, customers will want to buy everything from anywhere, but that won’t be practical as a starting point.
In some sense we will need to determine the center of the SOA/SaaS universe. Is it a platform and catalog of services provided by the SP? In that case, is the SOA universe bounded at any time by what a particular SP is willing or able to offer?
When an ISV decides to provide his application via SaaS, he has to do everything – from developing to selling to running a services business complete with data centers and help desks. Aggregators can help by providing the data center and much of the support, but the ISV still has to provide good products and much of the marketing. If the ISV chooses to develop in the SOA model, he may ease his development (and revision) costs and be in the market more quickly, but he will have to find an SP who is prepared to host SOA components and to exploit them.
For the customer, SaaS provides nearly everything; it’s what they don’t have to by that is compelling: hardware, systems management, software, data bases, back up facilities, and support. All of that is priced in a highly modular fashion, ideally on a per user per month basis. But to take advantage of this appealing offer, the user gives up two things:
(1) Control: Applications and data are running on someone else’s system at a remote location. Of course, SaaS should only be purchased from a highly reliable provider and guarantees as to the security of your data and the service level should be part of any SaaS contract.
(2) Customization: SPs have to be very disciplined about offering to customize applications for individual customers or their business model, designed to leverage the application across many customers, will disintegrate. Most SPs simply offer a single version of a software product, customized only by its connection to the customer’s data and directories. Some offer customer-driven customization via dialogue boxes (essentially, the customer may choose between defined selections). Now, we are seeing a few SPs who are creating their own platforms which ISVs or customers with IT capabilities may write to (offering a level of customization). Generally, these do not meet the SOA standards.
Forming an SOA Component Ecosystem
Exploiting SOA to offer more personalized solutions, we believe, will be the next step for the SaaS market. Rick McGee, IBM Vice President in IBM’s ISV hosting business, notes that as the SaaS market is developing and its software ecosystem is forming, it is creating a component model based on SOA. In order for this to work, Rick says, someone will have to provide a trusted brand as the settlement provider for the component makers. This might be a strong SP, providing a more general component market, like IBM, or it might be an applications provider, like a SalesForce.com, focusing their ecosystem around a particular market. In either case, the brand is designed to provide credibility for the components for potential buyers.
Questions still remain. Who does the marketing? The SP, for the portfolio of applications, of the ISV, for his own application. McGee thinks this should be the ISV’s job, allowing him to build his own brand. We suspect that each will do marketing, but in different ways. We’d also guess that in a more mature SaaS/SOA market an ISV who sells other ISVs components through his own ecosystem will be rewarded.
There is an inherent contradiction in the SOA/SaaS mashup. SOA clearly starts in big enterprises. SaaS is targeted at the SMB market. We’d note, however, that many enterprises take advantage of SaaS for their road warriors, value chain partners, remote offices, and “we need it right now” applications. And SOA is likely to show up in the mid-market and below as the methodologies and components are used by ISVs who sell across the market.
SaaS is climbing the ramp. We expect to see it used broadly by enterprises and SMBs for both commodity applications (Email) and for all types of applications that are fidlly to implement or hard to support. It is unlikely to ever replace in-house IT which will continue to be used for mission critical applications and data, but the percentages will shift, freeing up skilled resources to consider performance, new applications, and new technology. As SaaS is increasingly based on SOA modules, it will become more useful to business organizations because it will be able to handle a broader range of more individualized applications.
It’s a good thing.
Factors Affecting Use of SOA in SaaS Applications | ||
Factor |
Pro SOA |
Con SOA |
Age of Application |
New |
Old – Low Usage |
Old – High Usage Application – Rewrite or Componentize |
||
Age of ISV |
Start-Up – Nothing to loose |
Established – How to change revenue model? |
SP Focus |
· Aggregator · Portfolio Builder · Wants to Offer a Platform for Development |
· Strong Technology · High QoS · Traditional Enterprise |
