I have been experimenting with the D programming language over the past couple of weeks. D is a native language and was conceived by Walter Bright. Although the language itself has been in development for many years already, it seems that it has been getting more traction over the last couple of years. The name D hints already at it’s reason d’etre: to be a better C++. Because of endless backwards compatibility and decades of evolution the C++ language has grown.
Development
We as programmers like to think otherwise, but we are by no means perfect. We do make mistakes all the time. One of the most important traits of a good programmer is to recognize this and, more importantly, to act upon it. If one takes on a development endeavor there is one obvious path that also happens to be the most error-prone. It is this path: you have an idea, you code, you startup your app, click through it once and you’re finished.
At the vari-arch workshop at the European Conference on Software Architecture (ECSA 2010), I presented my work on Active Components. Active Components are the building blocks in a software product line infrastructure that I have designed. In it’s design I have chosen flexibility over rigidity (i.e. a strong compositional way of specifying your software product, rather than driven by a central architecture). This gives better means to widen the scope of a software product line, something that was specifically the case at the ISV where I did my research.
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.
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.
