﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Paul Cowan commented on Multi Tenancy - Where do you put variability?</title><description>I don't think it is a matter of the architecture just being extensible.
  
  
I migrated the app. to ASP.NET MVC but that is really just a point of technicality.
  
  
I think the challenging bit and probably the fun bit is to make the app. as configurable for each tenant without having to cater for each tenant individually.
  
  
Tenant in this context is a client.
  
  
Each client has their own web site and their own database instance but when I release a new version, each client gets the same code version and each db is from the same schema.  SQLCompare has been a god send on this front.
  
  
THe key to me is definintg the points of variability and then allowing these points to be configurable or flexible enough for each clients needs without verging significantly for that clients needs.
  
  
I never want to have a plug in or a code piece (apart from a dsl) that is just applicable for that client.
  
  
You have to keep in mind the maintainability of the whole.
  
  
Of course the business are always promising the clients they can have their own functionality.
  
  
Leads to some interesting meetings..........
  
  
  
  
</description><link>http://ayende.com/3509/multi-tenancy-where-do-you-put-variability#comment4</link><guid>http://ayende.com/3509/multi-tenancy-where-do-you-put-variability#comment4</guid><pubDate>Sat, 09 Aug 2008 20:03:49 GMT</pubDate></item><item><title>Tobin Harris commented on Multi Tenancy - Where do you put variability?</title><description>I'm interested in learning the difference between a multi-tenanted application and a framework.
  
  
For example, Ruby on Rails is a bit like a multi-tenanted application for developers. Each application has the same core modules, the same folder structure, and broadly the same architecture.
  
  
Rails also has a set of key extension points. You add your own views, controllers and models. You download the plugins you want to add pre-built slices of functionality. 
  
  
In Rails, they've found useful extension points to where the variability can go.
  
  
Is this completely different to how you might build a multi-tenanted application? Could you build a "framework" that provides the core functionality, with appropriate extension points? And then just use that framework to build a multi-tenanted application at a good pace?
  
  
Might have missed the point here, but just curious!
</description><link>http://ayende.com/3509/multi-tenancy-where-do-you-put-variability#comment3</link><guid>http://ayende.com/3509/multi-tenancy-where-do-you-put-variability#comment3</guid><pubDate>Sat, 09 Aug 2008 19:52:50 GMT</pubDate></item><item><title>Paul Cowan commented on Multi Tenancy - Where do you put variability?</title><description>As a side note.  I started off with the idea of having a seperate SSIS .dtsx package for each tenant.
  
  
My good God, the trouble that brought me.
  
  
SSIS nearly gave me a nervous breakdown.
  
  
Rhino.ETL was the right option and thankfully I had the good sense to bin SSIS.
  
  
Nobody should make the same mistake.
</description><link>http://ayende.com/3509/multi-tenancy-where-do-you-put-variability#comment2</link><guid>http://ayende.com/3509/multi-tenancy-where-do-you-put-variability#comment2</guid><pubDate>Sat, 09 Aug 2008 19:36:56 GMT</pubDate></item><item><title>Paul Cowan commented on Multi Tenancy - Where do you put variability?</title><description>This current raft of posts hits a nerve with me as it is something I have been dealing with for the last year.
  
  
We also have new tenants coming on board soon.
  
  
As usual, there is a lot of great documentation on product lines in the java space.
  
  
My approach is to be either flexible in the structure of my db design or define the points of variabiltiy and have dsls to configure the individual tenants variability.
  
  
For instance every tenant can have their own field structure for contacts in our db without having to add extra columns to the table.
  
  
Each tenant can also have their own ETL script that maps contacts from their datastore to our datastore by having that variability trapped in one .boo file that is handled by Rhino.ETL.
  
  
I am still not were I would like to be with writing my own dsls and eagerly await the book.
  
  
A lot can still be achieved with configuration.  
  
  
if defs although a crude approach are still an option.
</description><link>http://ayende.com/3509/multi-tenancy-where-do-you-put-variability#comment1</link><guid>http://ayende.com/3509/multi-tenancy-where-do-you-put-variability#comment1</guid><pubDate>Sat, 09 Aug 2008 19:31:49 GMT</pubDate></item></channel></rss>