The first part (Part II) of this blog series described the opportunities for software as a service (SaaS) or on-demand applications, especially in the current difficult economic milieu. Part IIa then analyzed the top five SaaS assumptions (misconceptions) recently outlined by Gartner.

Before any vendor can embark onto delivering a SaaS offering, it must thoroughly consider a number of harrowing SaaS technology choices and their implications. Thus, Part IIa also analyzed the decision’s impact on the functional footprint (scope) of the future SaaS product, after which the aspiring SaaS vendor must identify gaps within its in-house skill sets and define how to fill them.

This part continues with the other major remaining technical considerations before any vendor can embark on delivery of a SaaS offering.

The Tenancy Decision

While the true multi-tenant design approach for SaaS is the best in terms of highest scalability and lowest operational overhead (and it allows moderate to extensive software modifications), it also requires the highest initial investment. Thus, in some cases, the traditional single-tenant hosted/application service provider (ASP) model or partial/hybrid (something in between) solution may be appropriate. Namely, the application virtualization approach enables single-tenant solutions via tenant management (virtualization) tools from Wrapped Apps Corporation, Parallels, or Citrix Systems.

The major considerations here for independent software vendors (ISVs) (not necessarily end users per se, although everyone should be informed at least) are the following: whether there is legacy code that could be somehow leveraged (or that would be difficult to rewrite), how many new SaaS implementations per year are forecast, and whether the SaaS model has been proven in the target market. In any case, it is critically important to get the product’s architecture right up front, since making any corrections and rectifications along the way will be complex and expensive.

In addition to the tenancy considerations, one must address the questions of scalability (in terms of load balancing and routing), availability, performance, and configuration-driven customization (both to accommodate personalized look-and-feel and special functionality). Other architectural factors are system integration, information security (including identity management), usability, communications (e.g., via e-mail, short message service [SMS], instant messaging [IM]), global (multinational) capabilities, audit and compliance, and system backup and recovery.

The above overwhelming combination of factors influences not only the SaaS applications architecture but also the underlying infrastructure (platform) architecture. I would also add the cost of full time employees (FTEs) charged with handling all these issues.

While there are costs with multi-tenancy, over time the costs to handle each of these architectures can and probably will exceed multi-tenant design costs. Current macro-economic conditions are making one or the other approach seem cheaper right now, but as the economy rebounds, the question will come up about long-term strategy.

Finally, the costs for compliance are very high (and can be so high that it is out of reach for new entrants) to get enterprise-class services and certifications and audits, such as ISO/IEC 27001, SAS 70 Level II, Systrust, etc. Each part of the system must be audited and these audits can cast to the amount of US$100.000 and higher. Thus, multiple components in any architecture will lead to higher compliance costs, but that’s another blog topic.

Forget Not About the “SaaS Plumbing” Thingies, Either!

But even solving these multiple pieces of the architectural puzzle is only the beginning, since one also must include many SaaS-specific “must have” pieces of functionality, such as a pricing engine, a billing engine and payment processing, tenant and subscription management, service provisioning, system usage and performance (uptime) monitoring, and subscriber management and self-service. Creating all these “SaaS plumbing” components requires significant effort (in addition to the necessary “know-how”), and the company must thoroughly plan for it.

During the Webcast mentioned in Part IIa, Scio Consulting International claimed that this functionality takes from 20 to 50 percent of the research and development (R&D) effort for an entire SaaS application. The conventional wisdom is to leverage commercial SaaS components and services for time-to-market (TTM) reasons.

For example, commercial SaaS billing applications options would be OpSource Billing CLM (Customer Lifecycle Management), Zuora, or Vindicia, whereas SaaS customer management applications would be OpSource Billing CLM and Aria Systems. While PayPal has become the standard for online payment processing, uptime service level agreement (SLA) monitoring can be done via TrustSaaS, Absolute Performance, and the SaaSMonitor.com offering from MVP Systems. Last but not least, SaaS enterprise applications integration (EAI, including links to on-premise applications as well) is offered by Boomi’s AtomSphere suite, and Cast Iron Systems. Sonoa Systems provides analytics, management, and IT governance solutions for cloud services and application programming interfaces (APIs).

PaaS The Hosting, Please!

This brings us to the discussion about choosing the technology stack (with the following technical layers: application, deployment platform, and infrastructure) in a do-it-yourself (DIY) or other fashion. Namely, as ZDNet’s blogger and SaaS connoisseur Phil Wainewright explains well in his recent blog post, there is a plethora of platform choices for vendors, including commercially available platform as a service (PaaS) options.

Some examples of available PaaS offerings would be the following: SaaSGrid from Apprenda, Force.com from Salesforce.com, Google App Engine, Bungee Connect, Facebook’s Platform, Apple’s iPhone Platform, pieces of Microsoft’s still upcoming Azure Cloud Platform, and so on. In the case of Salesforce.com, there are three main ways that ISVs can partner with the vendor as a platform: build, market, or sell.

Force.com is designed for those that want to build applications (without bothering with porting, integration, security, hosting, infrastructure, etc.), while the AppExchange directory is for ISVs that already have an application of their own and are focused on marketing it. The upcoming Checkout service (currently in the pilot phase) will be for those who want to fulfill sales using Salesforce.com’s infrastructure.

Force.com is also flexible, so that developers can use Salesforce.com’s Visualforce presentation-layer development environment or other toolkits such as Eclipse (Salesforce.com has an Eclipse plug-in), or other third party development environments to create custom applications that do not look like the traditional Salesforce.com user interface (UI). In addition, Force.com has its own programming language, Apex, which can be used to create highly customized applications via the Java-like language.

Indeed, selecting the right PaaS may simplify the technical decision process, accelerate time-to-market, and reduce development and operating costs. A PaaS takes care of software components (services) creation (via managing metadata and portals), deployment (i.e., ordering, provisioning, and metering), and execution (via SLA management, billing, and subscription management).

In fact, the abovementioned necessary SaaS add-on plumbing applications (monitoring, billing, provisioning, etc.) also come bundled within a PaaS, and can save time and money while adding value to the vendor’s operations. Finally, a PaaS also provides the necessary components for reporting, alerts, and dashboards.

Two Force.com Endorsements by ERP Veterans

Salesforce.com’s Dreamforce 2008 user conference, which coincided with the historic US Elections, was marked by exuberance, confidence, and an overall upbeat feeling, in sharp contrast to the ongoing market sentiments. Ray Wang and Vinnie Mirchandani have described the event in their respective blog posts.

What really caught my eye there was seeing the two longstanding enterprise resource planning (ERP) players, CODA (now part of Unit 4 Agresso) and Fujitsu Glovia, opting to write brand-new products on Force.com. Salesforce.com’s blustery chief executive officer (CEO) Marc Benioff even (half-jokingly or not) taunted SAP (during his intellectual debate with SAP’s co-founder Hasso Plattner in early 2008) to rewrite the SAP Business ByDesign on-demand product on Force.com, rather than to “further torture and embarrass itself” (and the rest of the traditionally stodgy on-premise vendor community).

Even though this challenge might sound ridiculous for too-proud SAP to acknowledge and succumb to, that suggestion begins to make sense to me, in light of the giant’s initial faltering with SAP Business ByDesign. Well, maybe SAP could acquire Salesforce.com and solve its SaaS conundrum once for all, but that might be a bit difficult to pull off (at least during these days of limited spending)?

I concur with Dennis Howlett, who in his recent blog post on CODA wondered why a company with a 30-year history of writing world-class finance applications and with 2,600 renowned customers would entrust its on-demand future (i.e., the CODA 2go SaaS product) to a new, relatively untested platform. According to Jeremy Roche, CODA’s CEO, the attraction came in the following four distinct forms:

1. Access to a pre-built infrastructure that includes a security model, workflow, reporting, and multi-tenancy.
2. The ability to gain immediate access to  Salesforce.com’s customer and partner ecosystem.
3. The ability to have the Coda 2go product run from Salesforce.com’s datacenters, reducing the need for infrastructure and gaining access to massive painless scaling.
4. The inheritance of Salesforce.com’s credibility in maintaining a world-class service since Coda 2go runs on the same servers and infrastructure as Salesforce.com’s.

For its part, Glovia had initially ported a cut-down on-demand version of its established glovia.com ERP product. The vendor named its erstwhile SaaS product GSinnovate, but has apparently not sold a single license since 2006. In our recent discussions, Glovia conceded the need for the SaaS channel (and more), and thus the decision to go for Salesforce.com’s AppExchange and Force.com. Glovia plans to deliver on-demand products that will address one business process at a time, starting with the generally available glovia.com Order Management product.

There Is No Such a Thing as a Free Lunch PaaS

At the end of the day, a PaaS platform is not a charity that is free of charge, but rather a significant cost item that will cut into the SaaS vendor’s bottom line ever after (as well as will all the other necessary individual SaaS plumbing components). Thus, many SaaS aspirants might still opt for the grueling DIY approach by using some free and open source software (FOSS) LAMP (Linux, Apache, MySQL, Perl/PHP) bundle or Ruby on Rails (RoR).

On the commercial software side, there is always Microsoft’s stack, which consists of Windows, Internet Information Services (IIS), ASP.NET, and SQL Server. Progress OpenEgde, Oracle SaaS Platform, various SaaS programs from IBM, and so on are other SaaS platform (but not necessarily all-inclusive PaaS) alternatives.

In any case, the DIY vs. PaaS dilemma should take into the account whether there is a match between the technology requirements with the SaaS vendor’s available in-house expertise. When leaning towards PaaS, the SaaS vendor should ascertain whether its target market is part of a particular PaaS marketplace (ecosystem), as well as the time-to-market and R&D cost savings vs. the costs of using the PaaS. Certainly, there is a trade-off between the abovementioned benefits of a PaaS and the dependence on the PaaS provider (i.e., what happens if the PaaS provider goes out of business?).

The final part of this blog series will conclude with Internet hosting service considerations as well as key success factors (KSFs) for SaaS providers. In the meantime, your comments and feedback with regard to the opinions and assertions expressed thus far are welcome.

If you are applications users, how important are the abovementioned considerations in your software selections? For both users and vendors, what are your SaaS experiences (in both using and delivering a solution)?