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.

In your search for achieving excellence in creating software you might have come across one of these statements that 'code is an art' or something in that fashion. Although these statements are very appealing, I believe it not to be true. I will explain why. First let's start with the reasons why a computer programmer (or coder) is considered an artist and it's product (code) art. Writing code is labour intensive and various attempts have been made to automise the coding process through the use of high-level visual languages or application-generator tools. They all fail. Why is this? Because writing code is a complex and, most importantly, creative process. The same reasoning explains why there are still no good pop-song-generating software or fancy automatic movie generating applications. Maybe this will come one day, but this area is still in its very early infancy. Still, the coder can be considered an artist because he or she is creating a product through an undeterministic and creative process where the exact outcome is not clear upfront. Just like musicians or novelists. So, if writing code can be compared to creating music, writing a novel or painting ... then why can the code not be considered an art? Music certainly is art, and so is a well-written novel. The important, but subtle, difference is this:

The value of art is determined by the art itself. Whereas the value of code is not determined by the code itself.

To restate: a painting is perceived beautiful based on the painting itself. Music is valued via the music itself. In contrast, a software product is not valued on the code itself, but on what it does. No user really cares whether you have an elegent recursive call, or a three-tier architecture. Software should work. We should never forget this. Surely, your colleagues may be impressed by the sheer elegance of your code, but your users certainly won't be! The goal of a musician and its audience are aligned: to create beautiful music. The goal of a coder and its audience is not, there is a clear mismatch and that makes it more difficult to create good software. Most programmers out there, if not all, enjoy writing beautiful and elegant code. Which is a good thing because elegant code tends to have other convenient properties such as easy maintenance, reusability, self-documenting, etc. But let's not forget that this is not the primary goal our users have; just create software that works.

One of the most overlooked aspects in any software project is the end-user (e.u.) documentation. Can you recall how many (web)applications you have encountered that had proper e.u. documentation in it? I for one cannot, even though the (web)applications are getting more sophisticated and more complex every day. And to be honest, the software projects I create often lack proper documentation as well. So why is this the case? There are a number of reasons that I can think of:

• Typically developers don't like writing end-user documentation. It is just way cooler to create new functionality than write about functionality you have already written.
• Developers are not the right people to do it anyway, you need a customer-perspective. That is where the role of a technical writer comes in.
• E.u. documentation is often written when a product is already finished. When the development of a software product is already over-time and over-budget it is extra hard to convince the customer or projectmanager to put even more time and money in it to create proper documentation.
• The available tooling is not sufficient or well-known enough

Just some pitfalls here. But most people do agree that end-user documentation is important. For the acceptance of any new system it is a vital part.

How can we adress these problems? On my quest for the right tooling I have not found many good products. There are soms tools that let you generate documentation help files, or even create tutorial videos. But they are by their nature very loosely coupled with the actual software product and development process.

As part of my education I have enrolled into a course where I will be able to explore this problem more in depth, and provide a solution for it. My idea is to create a usable tool that can be pragmatic used in an (agile) development process and establish the link between the developer and technical writer. Furthermore, I want to be able to make e.u. documentation part of the build process and also be able to break a build if the documentation is not correct. In the coming weeks I will think hard about how to create this philosophy into a concrete product. I will keep you updated!

Ah, so finally Microsoft has also taken the road towards the Model-View-Controller pattern. Scott Guthrie talks about it in his weblog. It was a matter of time ofcourse after the self-proclaimed success of Ruby-On-Rails and the popularity of unit testing. One of the most important motivations that Scott mentions in his articles are 'seperation of concerns' and 'designed for testability'. Let's take a look at these two:

Seperation of concerns. The tradition ASP.NET model, using WebForms, had already a form of seperation. Namely between the HTML template (.aspx) and the code-behind (.vb or .cs or which language you have chosen). However, often you still end up inserting a lot of UI logic and business logic in the code-behind. Mainly because it is just so much more convenient to have all your UI logic in one place, instead in both the .aspx and code-behind file. So it boils down to this; no, the .aspx and .cs are not really seperated. In fact, I often just see the .aspx as a more convenient way of declaring controls, instead of programmatically adding them in the code-behind. In the last couple of years I have barely done anything more in the .aspx except for writing the HTML controls. That is right, I never use the designer. It is a huge frustration to me and I feel I have no control, whatsoever. The development time you win by using build-in grid wizards and such is often minimal compared to the time you lose to get the html output correct in the end.

Seperation of concerns is a good thing. Because most importantly, it eases your mind since you only have to focus on one aspect at the time. The code tends to be more cohesive, more readible and better understandable. Besides that, you automatically gets a better reusability of the components you write.

Designed for testability. This is still a big thing not well done in development nowadays. It is just very hard to test the UI. That is exactly where the user comes in and where things get fuzzy. Difficult to automate and therefore difficult and time-extensive to test. The basic idea to improve testability is to make your UI as dumb as possible. Also known as a passive view. The layer that renders your HTML should be thin-sliced over and over again, untill it does nothing more than just rendering some tags around provided text. The idea is that you might have errors in this thin layer, but you minimize the change of this because most of your code will be in another testable layer. UI testing is difficult, but this might just be another step towards software of better quality.

When I read about the MVC framework in ASP.NET I did not see a lot of really cutting-edge features. Actually, I have already built most of these features into ASP.NET right now. I build my .aspx as passive views. I design my controller classes in another library. Which makes use of the object-oriented model, which is generated by an O/R mapper. I have been working with this design for the last year and it has been very satisfactory. I notice that I get less erors in my applications, not only because of the increased testability, but also because of a more seperated approach in the design which provides me a good overview and makes me feel in control.

The only thing thas been bothering me lately is the asp.net WebForms model. It is just a pain in the ass to create a lean and mean performant application with this model. Especially the viewstates put a huge burden on this. I think a lot of asp.net developers experience this, because it just is too easy to drop some controls, enable viewstate and do continuously postbacks. But it just adds too much overhead. That is why I am looking forward to the release of this lightweight framework. Not because it is very revolutionary, or that you can do things with it which are not possible today, but to get rid of all this extra drag you get with the WebForms model. The time has come to take back control!