Building SaaS

More Virtues of Building Software on One Platform

In a recent post, I described how a huge amount of low-value effort was eradicated by the true SaaS business model - unlike on-premise software vendors who have to spend 30-40% of their development budget porting the software across many platforms like databases, operating systems, and application servers (and supporting ths software across many platforms and versions, and writing abstraction layers), the SaaS vendor can apply those resources to building additional software value for customers.

A related factor in building SaaS software is that we can optimize the software for the platforms. This may not seem like a big deal, but it has a lot of positive effects under the covers.

Analogies often don't work well with software and with SaaS in particular, but let's try one in this case. Imagine that you're designing a car, and instead of designing and optimizing it for one engine, you have to meet a requirement for car to work with four-cylinder engines from GM, Ford, Honda, and Toyota.

What would be the impact of this requirement? Here are a few that come to mind:

• You'd have to design the car's engine compartment so that any of the engines could fit with their preferred orientation - necessarily making the compartment larger than if designed for just one engine.
• If one engine had a unique high-performance feature, you likely couldn't take advantage of the engine-specific feature, but instead you would need to design the linkages to the "least common denominator".
• You'd have to thoroughly test the car with each engine - and do this every year as the engine manufacturers upgraded their engines.
• You'd have to train your dealers' service staff on diagnosing, maintaining and fixing every type of engine and engine version.
• For all the connections with the engine (e.g., transmission, gas, ignition, accelerator, climate control, exhaust, etc.), you'd have to design and maintain adaptors to each engine's non-standard connection.
• For Honda specifically, you'd have to design a special adaptor into your transmission because Honda engines run counter-clockwise rather than clockwise like every other engine provider - except for 2007 Honda 4-cylinder engines, which are their first to turn clockwise.
• You'd have to design the transmission so that it worked well with every engine's torque curve, meaning you'd have to create extra gears to compensate for one engine's low-RPM weakness and another's high-RPM weakness.

Now, this is obviously a ridiculous requirement in the automotive world, but it is typical of on-premise sofware that has to work with multiple databases and application servers. On-premise software vendors have to build and maintain all the connectors to all the versions of platform software that they support, leading to dozens of specific adaptors and hundreds of platform/version combinations.

As a result, the on-premise software is designed to the least common denominator for the platform components, and the on-premise software vendor can't take advantage of any special features or capabilities of one particular platform.

As one specific example, on-premise ERP packages typically don't utilize the integrity constraints in relational databases, because each database vendor has a different way of specifying constraints. This means that invalid data can be stored in the database if there's an application validation bug, leading to incorrect data over time.

This leads to problems like: Every time we integrate with a customer's PeopleSoft HR package, the customer assures us that there are no duplicate "People IDs", but when we actually get the data (e.g., 37,000 employees worldwide for one customer), there are indeed duplicates that we have to sort out on our end.

In practice, what does this mean for customers?  Since the SaaS provider designs and builds on one set of best-of-breed platform components, the Saas vendor can take advantage of the platform's unique capabilities and performance profile, leading to higher uptime and responsiveness, increased functionality, and lower cost.

So in addition to utilizing its chosen database's referential integrity constraints to ensure data correctness, SaaS vendors that utilize the Oracle database can also add Oracle optimizer "hints" to greatly improve performance in some cases.

Writing to a single platform also allows the SaaS provider to become an expert in that platform, how best to utilize it, secure it, tune it and operate it on behalf of their customer base. The SaaS provider can much better deliver and support and optimize their solution with this in-depth knowledge and experience on the platform.

In short, writing for one platform has many under-the-cover benefits for the SaaS provider and for the SaaS product that together provide a better ownership experience and value for customers.

SaaS = Freedom from Upgrade Agony

Well, sorry for the long delay between posts, we've been focusing a lot on getting a couple of releases out with an evolved architecture for the next 10x of growth. Our usage volumes went up by three times in 2006, and our data volumes more than doubled, so I had to knuckle down to stay ahead of the curve. First things first, as they say.

In catching up with other blogs, this one caught my eye about the pain of upgrades of traditional software, in comparison with SaaS.

Vinnie Mirchandani, one of the enterprise irregulars who comment regularly about enterprise software, says enterprise software upgrades "are like refueling in mid-air; they are usually risky and they are usually low ROI."

Why is upgrading enterprise software risky? Upgrading a major release often requires upgrading to more capable infrastructure components, which the IT organization (or their consulants) have to learn all over again how to install, configure, monitor, maintain, and tune. On the user side, mission-critical systems must be upgraded in a way that is seamless to the user communities, wtih no hiccups in system availability, data conversion and accuracy, system performance, or user training.

Why is upgrading enterprise softweare low-ROI? Mainly because the investment is so high - a significant upgrade project can take 18-24 months and cost tens of millions of dollars for the required data mapping and conversion, testing effort, infrastructure upgrades, re-customization, and user training.

It's no wonder that enterprises are so adverse to major upgrades and wait many years before upgrading mission-critical systems, which leads to another cost - the opportunity cost of not upgrading. What new innovations or business value are enterprises missing by not upgrading? This is impossible to measure, and maybe some enterprises are content to stay where they are at for many years. But I think that this is because the only alternative is the agony of upgrading.

Now that SaaS offers another path, here's one way to think about it - what if you could only use 5-year-old Amazon.com, Google applications, iTunes, web email, and Blackberry software? No gmail, no Blackberry browser or Google Maps, no iTunes videos, etc. etc. The new, unexpected, and continually increasing consumer value from SaaS-style upgrades is already apparent, and SaaS is starting to deliver this to enterprises.

Vinnie continues, "SaaS, with its continuous, in background upgrades, is showing customers the alternative to upgrade chaos. Additionally, SaaS vendors are far closely aligned to features customers are actually using and want to be improved in the future."

What's it like for IT groups or enterprises to be freed from the worry about upgrade projects, to not have that distraction and overhang of upcoming pain lurking out in the future? The progressive IT groups we work with have created a SaaS-oversight function that works with their portfolio of SaaS providers to coordinate system integrations, keep up with new functionality that is available each upgrade, and oversee security policies.

This new function delivers continuously increased value to the enterprise as new SaaS capabilities are turned on, the IT group is freed up to focus elsewhere on higher-value projects, and the cost of ownership for the enterprise is reduced substantilly. (Note this isn't simply cost-shifting, where the vendor simply absorbs all the costs of upgrading - with true SaaS, the vast majority of these costs are removed from the supply chain, since the SaaS vendor has only one data migration, infrastructure, and testing effort across all customers.)

On a personal note, late last year I had a couple of months where I was in significant chronic pain, and it prevented me from working as effectively on multiple fronts at once - it forced me to narrow my focus and drastically shorten my priority list. Eliminating that pain was freeing - I could do a lot more, and more effectively, without that loadstone.

For IT groups, my perspective is that being freed of enterprise software upgrade agony has the same effect - they can focus on other areas, direct their efforts to improving the business instead of spending months and millions to make sure the new version works like the old, and get rid of the straitjacket of half-decade-old software versions to deliver continuously more value and innovations to their user communities.