A key distinction between SaaS and non-SaaS is the housing of multiple-tenants in a single instance. This required mass-customization techniques. Most of the customization, or variability, has to be defined at runtime; (re)deploying of the instance should be kept to a minimum! As an effect, the software system engineer has to design the application with support for runtime variability. For more advanced customization scenarios such as business logic and workflows, you will need a (turing-complete) programming language to support this. Statically typed languages are in a serious disadvantage compared to dynamic (scripting) languages as the former requires compilation, building and linking which is not near as easy a simple interpreting engine.

My guess is that statically typed languages will continue to be used for the instance itself, the core application. Building on top of that, all user customizations, or user applications, will mostly be developed using dynamic languages such as javascript or python as they are much easier to work with at runtime compared to the current generation of statically typed languages such as Java and C#.

One of the big architectural decisions you have to make in multi-tenant software is how you store and partition your data. In many cases you will choose for a RDMBS such as Sql Server, MySQL or Oracle. The choice for an RDMBS is well founded; you get powerful querying, transactions, recovery, backups, indexing and management capabilities. Sure, a RDMBS might not easily scale-out but by scaling up you can come a long way.

Once you go the RDBMS route you have to figure out a database schema that will suit your application. Of course it has to support multi-tenancy. And since you have only a single instance of your application your application must take care of dealing with querying the correct data. In your database design you basically have three options:

- A single database for each tenant

- A shared database, multiple-schema for each tenant

- A shared database, shared schema

This all has been well explained in this MSDN document, and that is not where I want to focus at. Instead, I want to share some design struggles I had with this.

I recently have been quite busy figuring out which path to take. The difficult notion here is how to deal with tenant-specific customizations. For example, different tenants might have the same business entity extended with different attributes. This does not align with a relation server, which only supports a fixed database schema. So you either have to design a very generic and flexible schema, in which case all variability is handled by your application layer. But this tends to lead to awkward and inflexible querying and an unclear schema with names like attribute1, attribute2, attribute3, and a lot of meta-data. The second option is to modify the schema at runtime, which is obviously only possible if each tenant has its own schema or database, a shared schema is not possible. The runtime modification of database schemas seemed like a sensible approach. Just use DDL for schema modifications and introspection and some application layer doing the translation work. But this quickly turns out quite complex and error-prone. For example, what to do with schema updates in your application? And how to upgrade existing tenant data to a revised schema?

Dealing with these problems I figured that the real problem might be that I am locked in this ‘ it has to fit in SQL’ mindset. When I came to think of it, a lot of these customer extensions just end up in some forms or reports. They do not interfere with the core functionality of your application. Why, then, should you store this data in a very structured way which causes all the associated hassle? Why not use, let’s say, the semi-structured XML data column in SQL server to store all this tenant-specific, and possibly ambiguous, data? The world-wide web is pretty much semi-structured and ambiguous, but it works pretty well in the end, doesn’t it? And if it works for the web, why should it not work for me?

My current approach therefore is to have an explicit distinction between the structured and semi-structured data I deal with in my application. As it turned out, the structured data is very fixed among the different tenants. This allows me to adopt a shared database, shared schema approach. This might, or might not be the best way to go security-wise (tenants should never ever be able to see each others data), but at least I do have the option. This distinction also leads to a much more elegant and robust design with less complexity.

So, the next time you are struggling with a db schema, rethink it over; does it really need to be structured? Should it really be indexable and queryable? Or does it allow for a semi-structured data approach? The choice for less rigidity and more flexibility might save you a lot of troubles down the road.

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.

(een hersenkronkel in de trein terug naar huis.. ok hoog geek-gehalte, mag het?)

A small wave has hit the developer community this weekend about a clash between two lead developers: Chris Wilson of Microsoft's IE team and and Brendan Eich of the Mozilla foundation. The dispute is about the acceptance of ECMAScript 4; the proposed successor of Javascript. Wilson wrote public doubts about this standard, which let Eich to write a public letter in which Microsoft is being blamed for being reluctant and passive in the development of ECMA4. The debate is interesting, but we have to keep in mind that these are two individuals fighting over this dispute; there are no official positions here. However, I want to leave this aside (I know too little about the dispute as well to make sound arguments), and focus on how I perceive the future of client-side scripting.

As a programmer, I have always been a little bit relucant in learning Javascript. I get the same feeling when I work with Visual Basic. There is something... uneasy about it. The last couple of years I have mainly been programming in modern OO languages such as C++, Java and C#. A procedural language such as Javascript forces me to make such a leap in my approach and thinking that I feel being held back by the language. But I have the same with C. So, clearly it is not the fault of Javascript. In fact, I think Javascript is a good language in that it is easy to read because of a nice syntax, it has good scripting properties such as dynamic typing and it offers a lot of expression.

The question raises.. why is there the need for a 'new' javascript? The main force behind it, is to make the language more 'professional'. Make it more object-oriented, advanced exception handling, templates, etc. Indeed, these are things that are very important for any application of reasonable size. But is it important for Javascript? I have never used Javascript outside the webbrowser. In fact, I think most of the Javascript I use is either developed by a 3rd party or generated on-the-fly. Ajax? I use convenient libraries that abstract me away from the low-level javascript.

An article bij Joel Spolsky on the newSDK made me think about the role of Javascript nowadays. It is a great thing that almost all browsers support Javascript. Could you imagine all browsers supporting a language like, say, C++? Most C++ compilers don't even support the langague the full 100%. I am sure that the software engineers at Mozilla do not want to spend their time supporting a huge and complex language like that. The reason Javascript is so widely supported and popular is for the same reason the C language is still widespread today. It is the biggest denominator across languages, OS-es and browsers. If you write something in Javascript, there is a very good change it will be supported by the platform a client uses. The same is true for the C language, it is extremely powerfull because of the universal support. Even if the C language in itself can be considered obsolete by modern standards.

I believe that we should keep an easy, intuitive, flexible and powerfull language that can be executed for all browsers on all platforms, including new technologies such as PDA's and small mobile browsers. If you want higher-level constructs, you can use high-lever languages and 'compile' them down to javascript. For example, I could specify application logic in C#, which would then be outputted as Javascript in the final output. We can see the same in many smaller domain specific languages which transform a higher-level program into a c-program, which can then be compiled almost everywhere.

I do not believe that adding higher-level constructs into a language such as Javascript will make developers leave their current language and switch to Javascript. Surely, it would be more convenient if you were actually creating client-side javascript by hand. But in my experience, that doesn't happen a lot. But it would make it much harder for current browsers and future browsers to provide a (correct) implementation. You do not want a browser to implement a virtual machine just to be able to run an advanced javascript.