SaaS: naming, paradigm shift, value
June 17th, 2006
This week I had a discussion in the aspadvice.com private lists around the “Software as a Service” wording. We agreed with Santos Ray Victorero that SaaS is not the most representative name for what it means.
Here is one of my responses:
I do not like it either, but, hey, is not the first time we disagree with naming big things…
Anyway, better than analyze naming, I would go through the key areas involved in Software as a Service.
What SaaS enables?
- leverage massive economy of scale by sharing the infrastructure among tenants
- catch the long tail of the market
How?
My father runs a shop. Buying a full blown server with SQL
2005 and Windows 2003 to run his software is not what he wants. Not
only for the money, but he don’t want problems mantaining both
infrastructure and software. However, he needs software that just
works. So this is the value proposition of SaaS. Application
development costs are shared, the
“enterprise grade” application can be offered to very small businesses
as well.
So, if we are talking about the next big
programming language, SaaS is not that guy. However, this is a social
paradigm shift in terms of software delivery. As more people realize
about the value around this model, more applications will be developed
to fulfill their needs. That means that more tooling, guidance,
abstractions, etc. software companies like Microsoft will deliver. And
we as architect/developers will start writing this kind of applications
sooner or later.
Salesforce.com
is the emblema of SaaS nowadays. They are on the CRM arena. Microsoft
with their * Live stuff is heading that way as Ozzie points out in his
memo “Services Disruption“.
It’s late now to change this name because it’s in CIO’s minds. But let’s make the effort to explain this concept clearly!
SaaS: Workflow in multitenant environment
June 7th, 2006
As part of writing my thesis about Software
as a Service, I started to collaborate with Gianpaolo Carraro and Fred Chong from the Architecture
Strategy team. The interaction with them has been great
so far and some of the topics we’ve been discussing included how to enable
workflow in a multitenant environment.
When designing an application that will be
delivered as SaaS you might want to provide tooling to your tenants to allow
them extending the data model, the business process, the UI, etc. to fit their
unique needs. While thinking about how to customize business processes I came up
with a maturity model that I found descriptive.
First, I asked myself this question: How
a workflow can change?
- Behavioral
(decisions/rules) - Structural
(activities)
Behavioral changes
The behavioral changes are related
to decisions that are modeled in the workflow. Like “If the PO is greater than
X then…â€. So for TenantA that value might be $3,000, but for TenantB it could
be $1,000,000.
Let’s focus on behavioral changes for a
moment. These are the maturity levels I recognize regarding this kind of
changes:
- Level 1:
every workflow decision lives inside the workflow - Level 2:
same as level 1 but the decisions could be dynamically updated on runtime - Level 3:
externalize decisions on policy and rulesets providing change management
Level 3 is very interesting because:
- Rules can be versioned
- Rules can be stored outside the workflow
- Rules support forward chaining
- Rules expose business language
Structural changes
Structural changes, on the other side, are changes to the workflow structure itself.
Like “After the approval of the PO call a webservice on url Xâ€.
Here I also identified a maturity model for
the adoption
- Level 1:
design a basic set of workflow flavors and let the tenant decides - Level 2:
design a base workflow and let the tenant perform fixed customizations - Level 3:
design a base workflow and let the tenant perform modifications using a
workflow designer which exposes business terms
Some images have been taken from the article "The Amazing Race Metaphor", Vignesh Swaminathan, Architect Journal, Issue # 7
In my next post I will write about how can
we achieve some of these maturity levels using