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.

Comments

[MikeOliverAZ]

John, I cannot dispute your points of advantage, however there is a way to have your cake and eat it too. A Service Enabled Application Platform (SEAP) that provides a Multi-Tenant Application Development Platform and tools, can enable applications to be built that are agnostic of the underlying database, operating system and even what layers you want between the GUI and the Application business logic.

If you build your SaaS applications (or Enterprise Applications) on such an SEAP then you can start on your own server in a co-lo facility on tomcat and mysql and as you grow you can migrate to Amazon EC2 with WebSphere and DB2 and scale on the public cloud without one line of code changes in your application.

ISVs what want to roll their own, should take head to your guidance that's for sure, but those that want to reduce the risk and reduce the time to market should look for the SEAP vendor that most closely meets their needs, both in the short term and if over the long term they need to outgrow open source.

Ollie

[saas application development]

Good post John... I agree with your thoughts...