Multi-tenancy. Одно из ключевых понятий в современной сервисно-ориентированной архитектуре, которое не так-то и просто перевести на русский язык: «гибкость в настройках под индивидуального пользователя» - громоздко как-то получается. Поэтому, с вашего позволения, я буду пользоваться английским термином, а его смысл подробно объясню на родном великом и могучем.
Как мы знаем, SaaS-решения физически существуют, как правило, в одном экземпляре, обслуживая при этом множество клиентов-подписчиков (эти-то подписчики и называются словом «tenant» – «арендатор»). Из этого следует, что если мы хотим, чтобы клиентов было действительно много, то наше решение должно быть достаточно гибким, чтобы удовлетворить более чем разнообразные нужды каждого подписчика.
Существует рекомендуемый Microsoft способ достичь такой гибкости – проектировать решение так, чтобы максимумом его функциональности можно было управлять при помощи мета-данных (мета-данные – это данные, описывающие другие данные. Например в SQL Server структура таблиц вашей базы в свою очередь хранится как набор записей в таблицах системной БД).
Отметим, что мета-данные могут описывать не только схему данных приложения для конкретного подписчика, но и внешний вид пользовательского интерфейса, и, что самое интересное – особенности бизнес-логики (примелимую стоимость реализации настраиваемой бизнес-логики с выходом .NET 3.0 обеспечивает Windows Workflow Foundation)!
Посмотрим теперь на Team Foundation Server, который по сути является совершенно равноправным SaaS-решением. Поставив некий «знак равенства» между понятиями «подписчик» и «team project», мы только в одной подсистеме work item tracking обнаружим метаданные на всех трех уровнях:
Схема данных: Возможность иметь уникальный набор полей для каждого типа work item’а в каждом team project’е.
Бизнес-логика: Настройка правил валидации данных, схем переходов work item’а из одного состояния в другое и т.п.
Пользовательский интерфейс: Настройка дизайна формы создания/редактирования work item’ов данного типа.
В других подсистемах TFS возможности настройки могут не распространяться на все 3 уровня, но, тем не менее, они достаточно гибкие, чтобы на одном сервере сосуществовали проекты, использующие формальную методологию MSF for CMMI и agile методологию SCRUM.
Обратной стороной multi-tenacity является увеличенная стоимость provisioning (подключения нового клиента к системе и настройки системы под этого конкретного клиента). Поэтому, я думаю, имеет смысл рассмотреть экономический эффект создания некоего (полу)автоматического конфигуратора – платить за provisioning все равно придется, главное не платить дважды из-за скупости :-)
Возвращаясь к TFS, до появления Process Template Editor накладные расходы на создание и настройку шаблона проекта были весомым аргументом против внедрения – за универсальность, как совершенно правильно отметил в комментариях к одному из моих предыдущих постов Виктор Шатохин, приходится платить. С выходом же этого инструмента я бы грубо оценил сокращение накладных расходов в 2-2.5 раза хотя бы потому, что в большинстве случаев не приходится заниматься ручным написанием нетривиального XML-кода.