A contemporary buzz word in software development circles is without a doubt ‘SaaS’ or Software as a Service. The dust that twirled by the introduction of ‘SOA’ (Service Oriented Architecture) has just settled down a bit and yet here comes another windstorm. What SaaS precisely entails is certainly not definite, and maybe never will before it’s outdated by yet another acronym, but I will leave that aside for a moment. A lot of people consider a pure SaaS as a software system that can be scaled enormously with high efficiency and low costs. Archetypical SaaS software products are GMail and Salesforce.com. The services that GMail offers, managing your e-mail, is a fairly standard one. Everybody more or less uses e-mail the same way. That makes it an ideal domain for a single-instance, scalable SaaS solution. But how can this be done for, let’s say, a typical ERP implementation? Surely, ERP products are often highly customized towards their users. This customization can provide that competitive advantage for businesses. Forcing every organization into a single ERP implementation is a no-go.
The benefits of economies of scale and scope, in this view, can only be achieved by having a single instance of your software that houses all of your ‘tentants’. Depending on the context, tenants are customers, clients or users. This is in contrast with a typical ASP that may have a single instance for each and every client, thereby having to deal with a lot of costly overhead for managing all these instances.
To still reap the benefits of economies of scale and scope in a single-instance, multi-tenant, SaaS application the software itself is required to offer this customization to their tenants. And this is in fact what Salesforce.com or any other more complex SaaS solution offers. They provide the tenant tools and techniques to add extra data fields to entities, provide custom business workflows, etc. The result is that a SaaS solution can no longer be seen as a single software application, but is also a (high-level) business platform on which their users can ‘build’ their businesses.
And that is where model-driven development might play an important role. Let the business user construct their model, and your application is the runtime machine on which these models are executed. This requires a paradigm shift for most software developers that consider their constructed software as an end-of-the-line shrink-wrapped application. Instead, a SaaS developer will construct the runtime-machine on which businesses (tenants) can develop their own solutions. Your software will become just another layer in the stack.
For the typical SaaS programmer this means a shift in focus on not delivering end-products, but rather on creating a more or less generic application platform on which business can build their own applications. Ofcourse, how generic exactly is dependent on the goal of your business. Typically, the more specific your application platform will be, the easier it will be to construct it, but the more constrained the applications will be that can be build on top of your application platform. This is as much a business decision as it is a technical one.
I am currently researching the use of model-driven development and generative programming for a paper. I plan on writing more on these techniques related to the thoughts behind SaaS on my blog as well. As I am at the moment in the middle of re-engineering an existing web-application to be in the spirit of SaaS, I will also be writing about the technical challenges and hurdles that one has to take.
Share this post
Twitter
Google+
Facebook
Reddit
LinkedIn
StumbleUpon
Email