Make smart and accurate
software selection decisions
Podcasts, Webinars, and Videos
Interactive Case Studies
ERGO Decision Support System
Private Label Partnerships
TEC Case Studies
Software Evaluation Reports
Meet TEC's Experts
News and Press Releases
Working at TEC
Partner with TEC
To SaaS or Not, Is That a Question? - SaaSy Discussions (Part IIb)
To SaaS or Not, Is That a Question? - SaaSy Discussions (Part IIb)
The first part (Part II) of this blog series
described the opportunities for
software as a service (SaaS
applications, especially in the current difficult economic milieu.
then analyzed the
top five SaaS assumptions (misconceptions) recently outlined by
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
design approach for SaaS is the best in terms of highest
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
approach enables single-tenant solutions via tenant management (virtualization) tools from
Wrapped Apps Corporation
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
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
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
and routing), availability, performance, and configuration-driven customization (both to accommodate personalized
and special functionality). Other architectural factors are
), 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 (
) 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
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
, system usage and performance (
) 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.
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
For example, commercial SaaS billing applications options would be
OpSource Billing CLM (Customer Lifecycle Management
, whereas SaaS customer management applications would be
OpSource Billing CLM
has become the standard for online payment processing, uptime
service level agreement (SLA
) monitoring can be done via
, and the
. Last but not least, SaaS
enterprise applications integration (EAI
, including links to
applications as well) is offered by
Cast Iron Systems
provides analytics, management, and
application programming interfaces (APIs
PaaS The Hosting, Please!
This brings us to the discussion about choosing the
(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
Some examples of available PaaS offerings would be the following:
Google App Engine
, pieces of
’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
is for ISVs that already have an application of their own and are focused on marketing it. The
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
presentation-layer development environment
or other toolkits such as
(Salesforce.com has an
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,
, which can be used to create highly customized applications via the
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
), 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
Two Force.com Endorsements by ERP Veterans
, 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.
have described the event in their respective blog posts.
What really caught my eye there was seeing the two longstanding
enterprise resource planning (ERP
(now part of
Unit 4 Agresso
, 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
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
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.,
) to a new, relatively untested platform. According to Jeremy Roche, CODA’s CEO, the attraction came in the following four distinct forms:
Access to a pre-built infrastructure that includes a security model, workflow, reporting, and multi-tenancy.
The ability to gain immediate access to Salesforce.com’s customer and partner ecosystem.
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.
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,
had initially ported a cut-down on-demand version of its
. The vendor named its
erstwhile SaaS product
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
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
Ruby on Rails (RoR)
On the commercial software side, there is always Microsoft’s stack, which consists of
Internet Information Services (IIS
Oracle SaaS Platform
SaaS programs from
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
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)?
comments powered by Disqus.
comments powered by
Interested in a better way to make software decisions?
Give us a call now: 1-800-496-1303 ext:404
Software Requirements Sets and Comparison Reports
Click here to leverage the experience of our 360 industry perspective