Так сколько у вас пользователей? 60? 600?
Давайте к более жизненным вещам. 150 килобайт - это не размер приложения. Это сегодня даже Hello world не сделает. Приложение - это все библиотеки, которые нужно установить для его полноценной работы. Вот стоит голая ОСь, вот накатываем приложение. Если вы накатите свои 150 килобайт, работать не будет ничего. Так что объем будет от 20-50 мегабайт до 2-3 гигов. А вот теперь мы внедряем новую версию. Поменяли ваше так называемое функциональное приложение и пяток библиотек. Естественно, ковыряться в потрохах и выцеплять, какая конкретно библиотека поменялась, вы не будете. Меняете все скопом. Тормоза. И не надо рассказывать про чудесные криптоконтейнеры.
Я не о том спрашиваю. Мне не интересно, как передать строку коннекта прикладному приложению. Как реализуется следующий сценарий: На всех рабочих местах стоит ваш запускатор, который коннектится к некой БД. Положение этой БД меняется. Какие действия надо предпринять, чтобы с завтрашнего утра ваш запускатор смотрел на другую БД и дергал пользователей, права и параметры запуска уже с новой БД?

Теоретика вижу я.
Декомпозиция не панадол. Очень многое меняется при изменении количества пользователей.

Меняются требования к ИС, к документированию. Грубо говоря - чем больше пользователей, тем дубовее должен быть интерфейс и тупее инструкция. Больше бумаг, больше инстанций согласования. Меньше возможностей сделать операцию тремя разными способами, но зато три подобных операции должны выполняться сходным путем и иметь минимальные, но явно видимые отличия.

Изменяются требования к сопровождению и к разработке - задач становится слишком много, чтобы их потянул универсальный солдат "всё в одном". То есть встает проблема сохранения и передачи знаний.

Если один пользователь генерит одно обращение в поддержку раз в неделю - при 60 у вас в максимуме будет 12 обращений в день. Пять минут выслушать, десять минут решить, на прочие задачи осталось пять часов. Сложно, но один человек может и справиться. Если 600 - то обращений в день у вас будет 120 и надо сажать выделенных людей на прием, фиксацию и первичную сортировку сообщений. Пять минут выслушать, пятнадцать (уже не десять - сложность системы возросла) минут решить - прошло 40 часов. Нужна машина времени, чтобы заняться другими задачами.

И это только что касается ИС, а есть еще железо и администрирование...
В общем - классический переход количества в качество.

На каком количестве пользователей заканчивается ваш ряд: 10, 50, 100, 250, 500, 1000, 2000? Дальше не пишу, ибо сам далее не ходил, но ряд не окончился и там будут свои нюансы.

И мне повторить не сложно. Нужно учитывать ПОЛНЫЙ объем всех библиотек, которые могут потребоваться для работы приложения.
Давайте на примере. Имеем АРМ, сформированный из трех делфевых приложений, работающих с оракловой БД. Размеры 200, 250 и 300 килобайт. Можно ли делать вывод о размере? Кто писал делфевые проги - начинают смеяться уже на этом месте. Оказывается, мы экономили и собрали свои проги с использованием рантайм библиотек, общий объем которых - 2,5 метра. Объем 3,25 МБ? Нет. Оказывается, для работы нужен оракловый клиент. А его надо ставить отдельно и он еще 200 метров. Все? Нет, вывод данных производится в Ворд и Эксел. Нужно ставить Майкрософт офис...
Как считать - отдельная и очень интересная тема, не зря сейчас так много движухи на тему веб-приложений.
Ошибки могут возникнуть в любой точке комплекса.

Что нужно сделать при плановом изменении, чтобы пользовательские криптоконтейнеры аутентификации одномоментно были изменены на максимально возможном количестве рабочих станций? Как поступать с теми рабочими станциями, где криптоконтейнер аутентификации не обновлен?

А если не получает? Пусть у нас произошла авария на штатном хранилище и подключено резервное? Через вот это?
Есть механизм гарантированной доставки нескольких криптоконтейнеров аутентификации до каждого пользователя? И механизм поддержания актуальности? Другими словами, есть хранилище конфигураций 1 и хранилище конфигураций 2 (резерв). В момент Х происходит рассогласование - 1 говорит коннектиться к базе А, 2 говорит коннектиться к базе Б. В час Х на 20 минут хранилище 1 становится недоступным, пользователи коннектятся к базе Б через хранилище 2. Через 20 минут хранилище 1 восстанавливается, и оставшиеся пользователи коннектятся к базе А через хранилище 1. Рассогласование данных. Возможно?

Никогда, никогда не публикуйте настоящие логины и пароли, даже на локалхосте. Даже если это sa, postgres и masterkey.

Ну, тогда пожалуй все. Система, которая допускает рассогласование данных в простейшей ситуации, не имеет права на существование.

Виноватый назначен.

Интересно же посмотреть на чистого, незамутненного теоретика, у которого нет разницы между 60 и 600 пользователями. Это типа как выпускник-краснодипломник приходит в разработчицкую контору и начинает рассказывать, как правильно софт писать.

Пожалуйста, дарю идею на условии отсутствия любых претензий с вашей стороны при попытке ее реализации.

Да не отвечает топикстартер на самые интересные вопросы. Ни как 100 приложений получилось, ни сколько пользователей было в сопровождаемых им системах, ни наличие внедрений. Но зато прекрасно создает/переизобретает термины - платформа разработки сетевых КИС (промежуточное приложение по запуску ПО с указанием параметров запуска), функциональные приложения (вместо прикладное ПО), криптоконтейнер (запароленный архив)...