SaaS : Limits to Growth

Back in 1972 and then again in 1992 and 2002, Donella Meadows, Jorgen Randers and Dennis Meadows have published a book cautioning about the Limits to Growth – the ecological footprint of mankind exceeding the amount of resources available without intensive (and certainly not currently practiced) reuse, recycling and renewal. Its in that spirit that I would like to examine what Infoworld is calling, The Next Big Thing: SaaS-Software as a Service. Is SaaS really the next big thing and are there natural limits to growth for the phenomenon. Here is what Infoworld is saying in its March 20th 2006 cover story:

“..SaaS ecosystems are emerging such as on-demand SOA-based platform developed by Reardon Commerce… Salesforce.com new AppExchange Platform … etc. All this activity, however, does not mean the SaaS wave is poised to engulf traditional licensed software. SaaSs share of the business application market today is more like a drop in the bucket. And enterprises have been slow to embrace SaaS, raising objections over reliability and availability, underscored by recent Salesforce.com outages. Yet the arrival of big enterprise software guns, the emergence of integrated business communities in the cloud, and the increasing desperation of on the part of IT to minimize application deployment and maintenance hassles suggests that SaaS is on the verge of much faster adoption.” This prognosis has all the sounds of Field of Dreams, many time replayed with very mixed success in the IT business – “if you build it they will come”.

However, it behooves us to make a distinction between SaaS, ASP, and MSP. As the Wiki entry points out, ASP-Application Service Providers are primarily in the business of providing specific IT services over the Internet to clients replacing some or all of their internal programs and systems. MSP-managed Service providers in contrast manage a portion or all of a clients IT Shops remotely using Web based remote connections and supplimenting the clients systems with their own, particularly for spike-in-demand needs of the client. So MSP becomes ASP when the supplimentary computing power provided by the MSP becomes the majority or even total computing power of the client.

Now a user with a background of 10 or more years in computing will recognize both ASP and MSP as variations on a time honoured process in IT provision – outsourcing of IT services. Go back 10 years and ERP based ASPs were starting to proliferate; go back 20 years and there was a wave of payroll (ADP etc), backup/recovery and other specialized IT service firms; go back 30 years and it was time sharing services; go back 40 years it was remote job entry and batch services provision; go back 50 years and it was alternate data centers. SaaS, which has its roots in ASP/MSP, is as old as shared computing and make or buy. So what makes the new fangled SaaS different from ASP/MSP and all that has gone before?

SaaS Difference

SaaS like ASP/MSP is Internet based. SaaS providers offer a broad range of services that Oracle, SAP, and a host of other ASP service providers also have available. So what is unique about SaaS ? Here are some of the differences in Saas Offerings.
1)Low cost of ownership – this is the same as existing ASPs in many respects. Complete provisions of systems for CRM, ERP, or other business operations with no need by the client to invest in hardware, networks, software, security, backup and recovery and all the other requirement of IT delivery. Most of the initial development investment and ongoing operational costs are captured in the per connection and other predictable charges. But unlike ASPs and outsourcing services of the past, many SaaS providers are gearing themselves for the peaks and valleys of on demand services. So the low cost of ownership in the SaaS world is deliberately designed to accomodate a wide range of demand that may or may not be incoporated in the ASP/MSP business and or technology models;

2)Lowered cost of trial entry and uptake – this is a big but likely temporary difference with existing ASP/MSP providers. Using a broad spectrum of new technologies ranging from Web 2.0 AJAX and/or Java/Flash on both presentation delivery and help/training to XML and new object persistence and messaging frameworks on the back end, plus SOA design principally for data integration and interfacing; SaaS vendors have a temporary but notable advantage in delivering relatively fast, easy-to-use/easy-to remember-how-to-use Web GUI services. Because these services are delivered through a browser anywhere a laptop or PC or thin client can run – only security, access privileges, interfacing to other in-house and external clients systems remain as significant tasks to most SaaS users. Both SaaS and ASP/MSP providers are experimenting with appropriate ongoing support to individual clients including online help-yourself through mentoring sessions to web captured click and error log “activated and informed” training sessions. Some SaaS vendors may have a temporary advantage because their AJAX-powered Internet interface is inherently easier to use and they may be further down the road to delivering “context sensitive or activity” based help and training. But in the long term all ASP/MSP delivery will have these SaaS components.

3)Shielding an IT shop fom the upgrade treadmill – this is the most contentious of advantages to both SaaS and ASP/MSP providers. In the here and now and as long as the underlying software meets the clients needs both SaaS and ASP/MSP providers do a very good job of shielding clients from at least server-side upgrades and economy of scale changes. These upgrades include reliability and maintenance fixpacks and the current flurry of security patches required now that online computing has reached the frontlines of criminal intent. On the client side, SaaS is only as good as the firewalls and browsers the desktop or mobile users are working with. The problem here is that Microsofts IE browser still has 75-85% market share (depending on who you want to believe) and that browser just had 3 critical patches in the first 3 months of 2006 – and has all the security risks of ActiveX components. Fortunately for SaaS and ASP/MSP vendors there is one ass to kick when things go wrong and itto for their users.

So as can be seen here there are not a lot of permanent differentiators between SaaS and ASP/MSP. These delivery vehicles will never quite merge because client and users will see specific advantages each. Meanwhile even in the recently hatched SaaS here are divergent trends.

SaaS Divergence

Within the SaaS community of providers there is a divergence on how to go about delivering SaaS. The SaleForce.com and Rearden Commerce people argue for multiple tenant systems. In multiple tenant, all SaaS users share the same massive server farms, the identically same software image, and the same control and operation center. This allows delivery of the same operational economies of scale, on-demand responsiveness to clients changing demand needs, and ease and frequency of SaaS software upgrades.

But single tenant SaaS vendors, like Oracle and SAP, maintain that providing each client with their own devoted server increases reliability, reduces security risks and allows the SaaS client much more flexibility in configuring their systems. In fact, single tenant Saas is demanded by clients for their specific configuration and customization purposes. The problem is distribution of upgrades and third party add-ons in the single tenancy model – each server has to be upgraded while taking into account and the delays inherent in individual server configurations made by or in behave of the SaaS single client. Third party suppliers of add ons to SalesForce.coms AppExchange like the fact that their services and upgrades are instantly available to all SalesForce.com users.

Now the single tenant vendors like SAP with Net Weaver and Oracle with its new Fusion middleware argue they can provide similar across the board upgrades to their hundreds of users and servers (or selectively not as per their users requests). And all this is done automatically. But the multitenancy SaaS shops shoot back – that this is the problem. There are costs, timing , and other multi-target inefficiencies that even with the most automated of operational delivery systems, cannot help but become complicated and costly to run. So then the single-tenancy SaaS vendors must charge more or take the loss for other purposes – downstream selling of their licensed Oracle, SAP, and other software.

Obviously SaaS is still too new to get a definite market ruling on this; however the contending strategies just highlight some of the other divergent business models that are appearing in the SaaS space. A lot of SaaS software is appearing in the single user/consumer marketplace. Writely for example has made its Web Word Processor free and now that Google has bought it out – the business model is to be Google-free. Google-free gives away the software for free and monetizes through advertsiing, bundle and subscribe, or other third parties pay for the service.

But Yahoo has taken a different tack with its Flickr photo album service. Third party printing and other photo delivery services pay a fee to Yahoo/Flickr to be on the pulldowns and dialogs for printing. As well Flickr has a Pro account at $25US per year that nearly 40% of Flickr users pay for. Finally, with its open APIs there is a rapidly growing set of third party tools and suppliers who also are making a wide range of business model decisions on how they charge for the Flickr add on services.

So one of the distinguishing characteristics of SaaS is the open APIs. Many are SOA and Web Services based but others use popular and/or open frameworks from C/C++, Java, PHP, and others to offer not just data integration but also some fairly extensive extendibility. Same aim – but very different tools and divergent approaches. These local APIs frameworks might be thought of as a reaction to the monolithic OS frameworks, where innovators have seen their markets controlled and eventually absorbed into serving the Windows and other monopoly market money machines. Watch for more IT ecosystems to spring up around search/discovery, product forecasting/analytics with optimizations, distribution and response. Also watch and see who is first to properly SaaS these markets.

SaaS Deficits

The SaaS deficits, much like ASP/MSP, are threefold and are associated with change, change and change=> Change in the circumstances of the SaaS user organization, change in the technologies underlying the SaaS vendors stack, change imposed by external agents. Lets look at each in order.
First change in users organizations means that over a fairly short period of time, many clients usage of the SaaS service can change – large growth, new markets, acquisitions and spin-offs can change the demand for services quite radically. Fortunately, some SaaS vendors are geared up for volume changes(“on demand services”) both upside and downside. However, for changes in the way clients need to do business=> RFID support, new workflows to track, a new marketing campaign that emphasizes warranties and servicing support, etc, etc. Here the SaaS provider and its AppExchange may only be able to partially support for quite a period of time. And in fact that time may be when clients competitors are demanding the same functionality in order to respond to the first clients competitive thrust. In sum, SaaS may be a convenience and a cost saver; but it may also take IT out of the competitive advantage equation. Thus one can see the attractions to SMBs who dont want to be bothered with the IT overhead and distraction; but the leeriness of many large organizations except for specific well defined segments where on-demand or quick entry and exit may be the major attraction. Finally, there will constantly be a tensions between the SaaS clients and the SaaS provider, particularly the multi-tenancy ones, on how and to what extent configuration, customization, and cross system integration can be done.

SaaS vendors, like their ASP/MSP counterparts, thrive on making the IT world look simple, safe and only gradually changing to their users – “taking clients out of the security, reliability, maintenance and upgrade treadmills”. However, SaaS organizations are still subject to them. And n-tier computing, though not a terra incognita of just a decade ago, still has a lot of profound changes coming down the pike. We have said it before (but it is still worth noting again) the GUI/Presentation layer, the Storage/Persistence layer and the Messaging/Communication layers are all undergoing profound changes right now. Vista, multi-core chips, hardware assisted virtualization, massive criminally motivated security breeches and DOS-hostage takings – any one or all of these changes may very well test the limits of the SaaS SLAs-Service Level Agreements.

Finally,like all IT vendors, SaaS must respond to externally mandated changes. This sounds like government legislation – and indeed Sarbanes Oxley, HIPAA, Basel II, change to Euro, NAFTA, and a dozen other major process changes have been government inspired. But Y2K, the energy crunch versus wattage eating data centers, terrorists bombing/disabling network infrastructure, etc are regional and world events. The vulnerabilities of the SaaS model – network dependencies, massively uniform software image, huge server farms among others will be stressed in “hard-to-connect-the-dots” ways in the years ahead. Risk analysis and a rock solid SLA will be essential for organizations that cite SaaS computing as a critical success factor.

In sum, the same “limits-to-growth” that has confronted ASP/MSP providers face SaaS vendors.
Organizations that go SaaS have taken a portion of their management and control infrastructure out of the distinct competive advanatge equation. For example, the economies SaaS client achieve are largely available to their competitors; while as noted above the ability to incorporate unique IT capabilities into a marketing thrust are more limited. But on the other side of the coin, the ability to use SaaS to provide quick, non-available IT infrastructure – and therefore speed up market entry time profoundly may be an attraction – particularly with those SaaS vendors that can truly provide on-demand computing and service level agreements.

Also SaaS can provide invaluable and relatively low cost benchmarking for how well the IT shop or license software vendor(s) are doing in meeting a customers needs. But as noted above, SaaS vendors thrive on uniform, massive software and hardware farms which will inevitably clash with local configurations, scripting and other cuatomizations, and interfaces and integration to processes utside the SaaS API windows. Its the old agility versus simplicity and cost savings variation on the proverbial make or buy decision that will in the final analysis determine the SaaS limits to growth.

(c) JBSurveyer 2006

3 thoughts on “SaaS : Limits to Growth”

    1. My only excuse is that I was using this post as part of a bid for a consulting contract so I did not want to suggest a bias in the conclusion. Needless to say no contract was achieved.

Comments are closed.