Данную заметку можно рассматривать как комментарий к интервью Г.Грефа, в котором рассказывается про такие новые для банкиров вещи как «время», «гибкость», «конкуренция» и много другое. Основная идея Сбербанка теперь заключается в том, что монолитные универсальные ИТ-структуры должны уступить место мобильным изменяемым открытым модулям. Такой подход в перспективе должен сократить сроки вывода новых решений на рынок (time to market) с нынешних месяцев и недель до дней и часов.

Я хочу поделиться своим наблюдением, которое появились за время решения подобной задачи, правда в значительно меньше по размеру банке: любые модули со временем становятся такими же тяжеловесными, как и базовая система. Берем систему из условных миллиона строк кода, делим ее на 10 модулей по 100 тыс.строк. Такая модель действительно быстрее решает задачи, а значит самих задач становится в несколько раз больше. Увеличение количества задач ведет к разрастанию модулей, и спустя пару лет мы имеем уже 10 модулей по 1 млн.строк с повторением всех тех же проблем, что были в базовой системе. Проблемы конечно уже локализованы в своих модулях, но их уже в 10 раз больше...
Спустя время оказывается быстрее решать задачи не в предназначенных для этого модулях, а там где в текущий момент это быстрее (например, потому что команда того модуля занята рефакторингом образовавшейся «свалки кода»). Плюс никто не отменял человеческого фактора, когда разработчики разных модулей пытаются тянуть одеяло не себя (забирать чужие задачи), пытаясь или тупо больше заработать, или предусмотрительно на будущее повысить значимость своего модуля.

Почему такой подход работает в ит-компаниях? Да потому что модулей там не 10, а 210, и каждый из них зачастую полноценный бизнес, который сам себя окупает. Потому что основной бизнес-процесс там — это разработка, а главные сотрудники компании — программисты. Т.е. если в банке процесс выстроен так, что ночью что-то приснилось продажнику, и он говорит «сделайте, я пойду продавать», то в ит-компании обычно это произносит программист: «мне приснилось, я сделал — иди и продавай». И ценность разработки там определяется не критериями «совместимости с единой архитектурой», а способностью повторить результат в те же сроки с тем же качеством. Понятно что продукты типа Виндовс или Айфон, которые исторически являются генераторами прибыли, пытаются удерживать в единообразной структуре (просто чтобы дешево и достаточно быстро клепать ежегодные обновления, что и является причиной наличия огромного количества ошибок), но разве Фейсбук покупая Вотсап первым делом начал переписывать его под структуру самого фейсбука?

Ну и немного про хаос...
Представьте что Сбербанк сейчас по аналогии с ит-гигантами начнет скупать стартапы и уже раскрученные сервисы. Плюс к этому у него свои «модули». Плюс дочерние банки и другие компании. Это самый настоящий хаос. Никто никогда не покупает стартап, оценивая, какая у него СУБД. Разве кому то есть дело, на чем написан Вотсап, если у него 1ккк пользователей? Если какое нить дарование на школьной олимпиаде напишет для Сбербанка алгоритм обучения искусственного интеллекта на Делфи, разве это будет поводом отказаться от его использования, хотя базовым модулем для ИИ принята виртуальная машина Java? Когда Гугл увеличит производительность своего Go в 10 раз, все сразу кинутся переписывать на него, или наоборот введут запрет на его использование (чтобы не ломал выстроенную модульную систему)?
И эти примеры родила только моя скудная фантазия с прицелом на лет 5 вперед... А сколько всего случится и гораздо раньше?

Господа, выход тут только один — учиться управлять хаосом (неизбежно надвигающимся). В отличии от всего остального, это единственно универсальный навык...