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.
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.
I have been playing around with LINQ the last couple of weeks. Really nice stuff to work with, it changes the way you work with sets of data and the process of transforming them into other sets of data. But I don’t want to focus on the utility of LINQ here, but on the underlying paradigm shift that we might encounter and that I have been thinking about lately: drawing the analogy between application tiers and a supply chain, and giving the power back to the interface tier.