Сергей Баранов: архитектура и ИТ-стратегия dan repost
Я обещал написать, начал писать и уже получилось пять страниц, так что это будет уже статья, но кое что я все же напишу здесь.
В прошлом году я выступил с темой «Экономические последствия архитектурных решений». В ней было о том, как архитектура влияет на экономику. После этого было несколько проектов, в которых мы реализовали оценку архитектурных решений в деньгах. Это оказалось проще, чем кажется на первый взгляд, но требует некоторых усилий в изменении процессов, модели принятия архитектурных решений и подходам к работе с инициативами. Однако встал очередной вопрос, который именно сейчас стал болезненным.
Заключается он в том, что аналогия технического долга, и архитектурного в частности, завязана на деньги. Прошлым летом у меня было выступление на тему архитектурного долга, но суть в том, что мы всегда считали объем архитектурного долга в терминах технических метрик. И это большая проблема – архитектурные изменения дорогие, дорогие в терминах денег, а обоснование в большинстве источников через связанность, зависимости, избыточную сложность. Основная цель коммерческой организации – зарабатывать деньги, иначе с чего платить зарплату. И расходы тут играют не последнюю роль, как, конечно и доходы, но когда мы строим IT-стратегию или пытаемся обосновать выделение сервиса или что-то подобное, стоит это обычно сколько-то денег, например, месяц работы команды, а что это даст? В деньгах что даст. Вот мы решили апнуть версию базы, неделя команды, а выгода в деньгах какая? Может мы платим процентов по такому долгу 1000 рублей в год, тогда апгрейд версии базы не окупится условно никогда. Конечно, есть еще риски и иные факторы, но все же.
Прямой способ, который описывается во всех источниках - учет времени на выплату процентов по долгу с переводом в деньги по ставке членов команды. Я подсознательно, и на своем опыте, и по опыту работы с различными компаниями, понимаю, что это красивая сказка, так не работает, – тут и отторжение и избыточная нагрузка… Но мы же инженеры и я решил проверить как обстоит дело и запустил опрос. Вот вижу, что кто-то все же честные трудозатраты считает, вопрос к корректности остается открытым, но все же это 20% от всех ответивших. По индустрии будет и того меньше, я думаю, что подводит нас к тому, что этот подход массово не рабочий.
У меня есть несколько других подходов, которые я уже обкатал, которые по косвенным признакам позволяют все же перевести архитектурный долг в деньги, это и мой опыт и опыт коллег, с кем мы в тесном контакте. В скором времени выпущу статью и небольшое решение, которое позволит посчитать его. Важно - мой акцент на долге _над кодом_, потому что долг уровня кода сейчас отдается за минуты, почти бесплатно.
Так как я с самыми мощными моделями и в доверенных источниках не нашел прагматичных методов, думаю, что это будет хорошее решение, а цель достаточно простая – объективно оценить, что отдавать, а что не надо, потому что в условиях бюджетных огранчений выбирать нужно очень аккуратно, ориентируясь на реальные финансовые показатели, а не только на технические параметры и метрики системы.
В прошлом году я выступил с темой «Экономические последствия архитектурных решений». В ней было о том, как архитектура влияет на экономику. После этого было несколько проектов, в которых мы реализовали оценку архитектурных решений в деньгах. Это оказалось проще, чем кажется на первый взгляд, но требует некоторых усилий в изменении процессов, модели принятия архитектурных решений и подходам к работе с инициативами. Однако встал очередной вопрос, который именно сейчас стал болезненным.
Заключается он в том, что аналогия технического долга, и архитектурного в частности, завязана на деньги. Прошлым летом у меня было выступление на тему архитектурного долга, но суть в том, что мы всегда считали объем архитектурного долга в терминах технических метрик. И это большая проблема – архитектурные изменения дорогие, дорогие в терминах денег, а обоснование в большинстве источников через связанность, зависимости, избыточную сложность. Основная цель коммерческой организации – зарабатывать деньги, иначе с чего платить зарплату. И расходы тут играют не последнюю роль, как, конечно и доходы, но когда мы строим IT-стратегию или пытаемся обосновать выделение сервиса или что-то подобное, стоит это обычно сколько-то денег, например, месяц работы команды, а что это даст? В деньгах что даст. Вот мы решили апнуть версию базы, неделя команды, а выгода в деньгах какая? Может мы платим процентов по такому долгу 1000 рублей в год, тогда апгрейд версии базы не окупится условно никогда. Конечно, есть еще риски и иные факторы, но все же.
Прямой способ, который описывается во всех источниках - учет времени на выплату процентов по долгу с переводом в деньги по ставке членов команды. Я подсознательно, и на своем опыте, и по опыту работы с различными компаниями, понимаю, что это красивая сказка, так не работает, – тут и отторжение и избыточная нагрузка… Но мы же инженеры и я решил проверить как обстоит дело и запустил опрос. Вот вижу, что кто-то все же честные трудозатраты считает, вопрос к корректности остается открытым, но все же это 20% от всех ответивших. По индустрии будет и того меньше, я думаю, что подводит нас к тому, что этот подход массово не рабочий.
У меня есть несколько других подходов, которые я уже обкатал, которые по косвенным признакам позволяют все же перевести архитектурный долг в деньги, это и мой опыт и опыт коллег, с кем мы в тесном контакте. В скором времени выпущу статью и небольшое решение, которое позволит посчитать его. Важно - мой акцент на долге _над кодом_, потому что долг уровня кода сейчас отдается за минуты, почти бесплатно.
Так как я с самыми мощными моделями и в доверенных источниках не нашел прагматичных методов, думаю, что это будет хорошее решение, а цель достаточно простая – объективно оценить, что отдавать, а что не надо, потому что в условиях бюджетных огранчений выбирать нужно очень аккуратно, ориентируясь на реальные финансовые показатели, а не только на технические параметры и метрики системы.