Building SaaS

Is SaaS the next IT "Big Thing"?

As a thought-starter to the MIT/CIO Magazine Symposium on May 20th, CIO Magazine's Publisher Emeritus Gary Beach recorded a short video introduction where he posits that "IT beats to a 15-year drum".

Starting in 1950 with the mainframe computer, he says, every 15 years a platform transformation comes along that disrupts IT: the minicomputer in 1965, the PC in 1980, and the browser in 1995. That makes 2010 the witching hour for the next disruptive IT platform transformation - what is the next IT Big Thing?

While IT trends like mobility/wireless, cloud computing and virtulization will all cause big changes for corporate IT, I'm putting forth the case that SaaS is the next IT "Big Thing". Rather than just accomplishing incremental change or doing the same things better, SaaS is fundamentally disruptive to both IT's role in the enterprise and the end-user experience with IT:

• IT's Role: IT's role will evolve away from building data centers, selecting & buying servers, purchasing infrastructure software (eg Oracle, WebSphere), developing custom applications, and learning how to install/configure/manage/monitor/optimize all of this, towards SaaS vendor diligence/management, service coordination/integration, and data control/management.
• User's Experience with IT: The typical corporate user's experience with IT will evolve away from the effects of IT's lock-down mentality (no upgrades or changes, must standardize everything) and often glacially slow responsiveness, towards IT quickly delivering new services, granting end-user control and configurability, ongoing change management, and continually increasing/improving service capability with SaaS's ongoing pain-free & cost-free upgrades.

Like Gary's other game-changing platform transformations, IT is resisting the SaaS trend due to perceived less control, influence, and mission-criticality. Nevertheless, the fundamental economic advantages and end-user advantages of SaaS will cause it to take over more and more of corporate software services over the next decade.

In my view, that makes SaaS the next IT "Big Thing".

Defining SaaS? Focus on the Business Benefits

Thomas Otter, a Enterprise Irregular software blogger who works for SAP, says he can't figure out what SaaS is.

His main complaint is "What is or isn't 'allowed' to be called SaaS seems so arbitrary" - does SaaS have to include multi-tenant, hosted, subscription-based, web 2.0-enabled, etc.?

SaaS isn't some vague concept that's hard to define - it's just that many definitions miss the point by focusing on the delivery method or infrastructure or software architecture or pricing, when the definition should be based on customer value.

SaaS is defined by the business benefits it delivers to customers - faster time-to-value, lower cost of ownership, and increasing value over time through ongoing free upgrades. Secondary business benefits include better support (since all customers are on one version of the software and the SaaS provider knows the user's data, configuration, and usage), easier deployment (since SaaS providers are paid based on usage, they are motivated to make the software easy to use and adopt), and lower hidden costs (no upgrade projects, patches to apply, databases to back up and restore, etc.)

All the key components of SaaS architecture and infrastructure - multi-tenant, single-version, shared infrastructure, fully webified, configurable, metered and actively monitored - simply serve to deliver these benefits.

Software offerings that don't deliver these benefits aren't SaaS - and there are many examples out there, especially on-premise software offerings that are hosted and pretend to be SaaS, called "Same old Software, as a Service" by Phil Wainewright. On-premise-only software vendors try to muddy the waters by adding hosting and subscription pricing rather than modifying their software to deliver faster time-to-value, lower cost of ownership, and ongoing free upgrades.

In fact, even well-meaning observers miss the point, as Nicholas Carr did in his comments on Thomas Otter's post. Nicholas brought forth Glovia as a SaaS example - a company with 1,000 on-premise customers but no SaaS customers, who just released a simpler version for SMBs hosted by Deutsche Telekom's T-Systems unit. This isn't SaaS, it's on-premise software trying to become SaaS by issuing press releases and renting a cage at a data center rather than re-architecting the software to deliver more value, as pointed out by Phil Wainewright who takes Nicholas to task.

Another counter-example to SaaS is the first-generation ASPs that emerged in the late 90's trying to host on-premise software. Thomas says ASPs were the same as SaaS, but I don't know why we have to keep explaining the difference over and over and over again. Here it is, once more with feeling: ASPs died because they offered no business benefits over on-premise installed software. They simply hosted on-premise software in an offsite data center as a single-instance installation, which didn't reduce the time-to-value, didn't reduce any cost of ownership (it required the same per-customer infrastructure and operational costs), and didn't offer any increasing value over time - upgrades were just as costly and painful and infrequent as for on-premise installations.

Thomas ends his post on a positive note, however, comparing SaaS to the old service bureaus, specifically ADP. Let's see, does ADP's software-enabled payrolling service offer fast time-to-value, low cost of ownership, and ongoing free upgrades? Yes - so that makes it SaaS, in my view. Payrolling is a back-office process so full web-enablement and end-user self-service don't matter as much, but the business benefits are compellingly SaaS-like.

And I can assure you that ADP's software is multi-tenant, shared-infrastructure, single-version, and frequently and automatically upgraded for free.

Memo to the Skeptical CIO

Skep: Thanks for your participation in the "Skeptical CIO" panel at the SaaSCon conference in San Francisco.

Phil Wainewright captured the key points of this discussion, which I wanted to address here since your and your fellow CIOs' conclusions seem to indicate that SaaS pretenders and the big ERP vendors are dominating the discussion about SaaS in your offices so far.

To directly address the "Skeptical CIO" conclusions:

• "[SaaS is] not any easier to implement and use. Nor should it pretend to be." Well, as a SaaS vendor, when we're asked by a customer to install on-premise, we simply say "Ok, here's the CD and installation instructions, please call us when your IT group has assembled and installed and configured the servers, database, application server, and other infrastructure for our application. Or, here's the SaaS implementation login which we can start using RIGHT NOW." SaaS eliminates all the time and effort (and cost) to cobble together the components for on-premise software installation, which for an enterprise application can take an IT group months - at least, that's what the business buyers tell us. Plus, most SaaS vendors don't get paid until the software is being used, so they've built their SaaS software to enable fast implementation and to minimize training.
  
  Aberdeen Group's surveys have repeatedly shown both that SaaS implementations are faster and that SaaS's dramatically faster time-to-value is the most important benefit to the business buyer (here's one of their studies in our space). So, I'm not sure why you dismiss this SaaS benefit - surely you and your colleagues have endured plenty of multi-year on-premise software implementation projects?



• "Vendors should stop harping on about how, if you don’t like a SaaS solution, you can just unplug it and go elsewhere. That’s ludicrous." This comment is accurate; this claim isn't one that we make. Switching a SaaS application is really a new implementation - much easier and faster with SaaS, but not trivial.



• "The cost model is not necessarily any better. Customers amortize upfront costs anyway." SaaS creates economies of scale by sharing infrastructure across many customers - and it's true that a large IT shop with a pre-existing infrastructure can gain many of the same economies of scale.
  
  The faster and much smaller implementation project is a real cost savings, however, especially for large enterprises. As RightNow Technology's CEO puts it, you'll save the consulting teams that "camps their tents in the parking lot for three years while they get your application to maybe work."
  
  Another cost savings of SaaS is far less obvious. Ask your on-premise software vendor, "How much of your company's time is spent supporting old versions of your software across all your infrastructure ports (databases, operating systems, etc.), and porting and testing each version and maintaining the compatibility matrix?" If they have a significant customer base and are truthful, it'll be a large part of their development and support effort - according to The Economist, "as much as 70-90% of what programmers do in a large enterprise software firm is maintenance: upgrades, minor enhancements and bug fixes". True SaaS solutions reverse this proportion - spending only 10-20% of development effort on maintenance - because only the current version is maintained on a single platform, and every fix is automatically delivered to all customers. So the vast majority of the SaaS vendor's development effort is applied to new innovation and customer value.



• "On-demand vendors shouldn’t bother to portray themselves as partners in achieiving business results. They’re just software vendors selling products." Well, this may be true for some vendors - especially the SaaS pretenders who are telling you that SaaS is just another "deployment option". According to Jeff Kaplan, "The first thing CIOs have to look at is how any SaaS system is truly architected. Some vendors are still selling legacy apps but simply hosting them and offering them at a different pricing model." For a checklist of questions to ask a potential SaaS vendor, see the whitepaper Why Technology Matters.

Again, thanks for your participation - hopefully this gives some perspective from a true SaaS vendor's point of view.  The bottom line is that SaaS delivers a better ownership experience on factors that business buyers care about, driving SaaS adoption for new purchases and putting CIOs in the position of leading its adoption or being left behind. Embracing and driving the key benefits of SaaS - lower up-front cost, faster implementation and greater vendor accountability - will lead to higher/faster ROI with lower risk for both CIOs and the business.

What is "Building SaaS"?

Software-as-a-Service (SaaS) delivers a much different and better customer ownership experience for businesses than deployed software - no up-front technology costs, fast time-to-value, low cost of ownership, ongoing free upgrades.  There are many commentators that are tracking the many SaaS customer benefits and emerging software providers - investors, consultants, analysts.

This blog will look more from the SaaS vendor point of view - building, operating and supporting a SaaS solution.  The processes, development approaches, and architecture of SaaS are fundamentally different than for deployed software - trying to build SaaS software the same as deployed software will hobble your solution in the market, as some of our competitors have found out.

I run development, product management, QA, and technical operations for IQNavigator, the market-leading Services e-Procurement provider based in Denver, Colorado, USA.  We have been doing multi-tenant single-version SaaS from the start six years ago, and I feel we have a unique perspective on what makes SaaS solutions better, and how to build a successful SaaS software solution.

I hope you agree.