Привет, Хабр! Меня зовут Валерий Лобанов, работаю IT бизнес-партнёром по корпоративному бизнесу в Московском кредитном банке (МКБ). Моя задача — видеть проблемы до того, как они возникнут, предлагать решения и их реализовывать.
Legacy — классический пример проблемы, которая подкрадывается незаметно, но видна издалека. В этом хабрапосте вы сможете прочесть:
много плохих определений того, что такое legacy;
почему появление в проекте legacy не ваша вина (хотя иногда всё-таки ваша);
как убедить бизнес, что рефакторинг экономически выгоден, и почему правильный ответ «никак»;
что же всё-таки делать.
Что такое legacy?
Перед тем как начинать этот разговор, неплохо бы определиться с терминами. Здесь сразу же возникает проблема: legacy — термин общеизвестный, и всё же каждый понимает его немного по-своему.
Допустим, для кого-то legacy — это код на старом языке. И действительно, можно вспомнить, например, такой язык, как Cobol. Один из старейших языков программирования в мире (первая версия вышла в 1959 году). Тем не менее до сих пор порядка 240 миллиардов (!) строк этого языка крутятся в продакшене, в основном — в финансовых и административных системах США. Найти программиста на Cobol всё сложнее, однако это по-прежнему проще, чем переписывать такой объём кода.
С другой стороны, язык C всего на десяток лет моложе, а код на нём, как правило, не попадает в категорию legacy. Возможно, дело всё-таки не в языке?
Есть и более общее понимание: legacy — это устаревший стек. Но и тут не всё так просто. Допустим, git появился в 2005 году, а библиотека Knockout для веб-фронтенда — в 2010-м. Однако git вряд ли кто-то назовёт legacy, а вот к Knockout это определение подходит больше. Последний её релиз был сравнительно недавно, в 2019 году, но и тогда код с её использованием многие отнесли бы в категорию legacy.
Наконец, существует радикальное определение legacy с точки зрения амбициозного PM’а: «Legacy — это всё, что было до того, как я пришёл в проект». Насколько оно верно, предоставлю судить читателю.
На самом деле гипотетическая функция isLegacy — это не функция от времени или популярности. Например, в 2022 году в России оказались труднодоступны продукты Oracle, и завязанный на них код в одно мгновение стал проблемой. Я бы сказал, что этот код стал legacy. И потому в определении legacy лучше отталкиваться не от обстоятельств, а от неких функциональных свойств.
Legacy — это боль
Эта фраза сама по себе никого не удивит: все знают, что legacy — боль. Но что если использовать её не как описание, а как определение? Ну, конечно, не в таком радикальном виде. Придётся немного уточнить.
В консалтинговой компании Gartner разработали модель, известную как Run-Grow-Transform (RGT). Эта модель помогает анализировать потребности бизнеса и то, насколько их удовлетворяет IT-инфраструктура. Run — это обеспечение функционирования, выполнение текущих операций. Grow — рост количественный и качественный, масштабирование и наращивание функционала. Transform — изменение, адаптация к новым условиям и новым рынкам.
Что такое legacy с точки зрения модели RGT? Боль. А именно:
Run — повышается стоимость владения (TCO). У legacy выше стоимость поддержки: в случае hardware- legacy сложно достать комплектующие на замену, а для software- legacy тяжело найти специалиста поддержки. Вследствие тех же факторов увеличиваются операционные риски, уменьшается ожидаемый аптайм. Это плохо для любого бизнеса, но в банковской сфере, где операционные риски регулируются Базельской конвенцией, это смерти подобно.
Grow — любые доработки стоят дороже и делаются медленнее. Или ввиду кадрового голода (поищите-ка программиста на Cobol), или из-за того, что технологии категории legacy хуже подходят для быстрой и гибкой разработки.
Transform — здесь опять же фактором является человеческий ресурс. Изменения, связанные с legacy, всегда дороже и медленнее. Кроме того, legacy обычно усложняет IT-ландшафт: требуются дополнительные танцы с бубном, чтобы подружить legacy-технологию со state-of-the-art-частью стека.
Итак, с моей точки зрения, legacy — это всё, что вызывает у бизнеса характерную боль, описанную в предыдущем абзаце.
Как обнаружить legacy и почему от этого никто не застрахован
Не так уж давно в одной очень близкой галактике жил да был в нашем IT-ландшафте депозитный модуль. Он обслуживал депозиты юридических лиц, делал это исправно и не вызывал нареканий. Но однажды ко мне пришли коллеги и сказали: твой модуль — г… в смысле legacy. Я возмутился — это почему вдруг? Мне говорят: ну, он написан на старых технологиях. Я отвечаю — ничего подобного. Модуль написан на .Net, это стильно, модно, молодёжно.
Но в душу закрался-таки червь сомнения. Решил я этот модуль пощупать — и ужаснулся. Дотнет дотнетом, а клиентское приложение написано на Windows Forms, только под виндовый десктоп, и разработчиков для него, кроме как пенсионного возраста, не сыщешь. И понял я, что правы были мои коллеги.
Legacy возникает внезапно. Невозможно заранее предсказать, какая технология будет развиваться, а какая окажется неконкурентоспособной и станет дрейфовать в забытьи. Когда выбираешь стек для проекта, всегда есть шанс поставить не на ту лошадь. Конечно, здесь есть некая доля личной ответственности разработчика. По некоторым лошадям сразу видно, что их лучшие дни позади. Но если выбирать из тех, что выглядят бодро, — дальше на всё воля случая. Главное — вовремя слезть с лошади, обнаружив, что она сдохла.
Legacy может быть тяжело обнаружить с позиций менеджмента. Формальные характеристики (как то - используемый язык программирования) могут быть неинформативны. Вместо того чтобы разглядывать красивые диаграммы, нарисованные для начальства, иногда лучше просто взять и потрогать продукт руками. А заодно неплохо бы спросить самих разработчиков. Казалось бы, очевидная идея, но это только на бумаге. На деле в общении между IT и бизнесом часто возникают трудности. Собственно, для того чтобы их устранять, существует специальный человек под названием…
IT бизнес-партнёр
Наверное, у этой статьи немало читателей, которым изложенные мной тезисы показались вполне очевидными, а вот название моей должности вызвало вопросы. У нас в блоге есть отдельная статья о том, что такое IT-бизнес-партнёр, зачем он нужен и почему это хорошая идея. Не буду пересказывать её полностью, ограничусь основными тезисами.
IT бизнес-партнёр — медиатор между IT и бизнесом. Выражаясь метафорически, их «семейный психолог», который помогает выстроить доверительные партнёрские отношения. Да, именно партнёрские: в парадигме IT бизнес-партнёрства неприемлемы отношения «заказчик — исполнитель». Конечно, бизнес играет ведущую роль, но, если IT-отдел будет пассивным исполнителем, хуже будет всем, в том числе в итоге и бизнесу. IT должно уметь высказывать свои предложения и пожелания, а бизнес должен уметь их слышать. IT бизнес-партнёр организует эту связь.
Как это относится к legacy? Как правило, разработчики (по крайней мере, «лиды» и «сеньоры») первыми видят проблему. Но не всегда они могут донести своё видение до бизнеса. Разговор о legacy — неприятный для бизнеса разговор. Он означает, что нужно потратить время и деньги на нечто, что не даст непосредственного, измеримого эффекта. Что придётся, как в «Алисе в Зазеркалье», очень быстро бежать, чтобы остаться на месте. И при этом не вполне очевидно, что это действительно необходимо. Вдруг разработчикам просто захотелось поиграть с новыми хайповыми технологиями на деньги компании? Сейчас-то всё работает, а как известно — «работает — не трогай».
В подобных переговорах IT бизнес-партнёр играет важнейшую роль. На своём опыте могу сказать, что существуют три основных стратегии убеждения бизнеса в необходимости избавления от legacy.
Три способа убедить бизнес
Первый способ — подсчёт экономической эффективности. Просто взять, обложиться бумагой и таблицами, прикинуть потенциальные убытки от legacy и потенциальные выгоды от новых технологий. Бизнес умеет считать деньги. Если принести ему такие выкладки — с выделением ресурсов не будет никаких проблем. Конечно, если выкладки достаточно убедительны.
Однако такие выкладки всегда неубедительны. В них по определению слишком много потенциального и гипотетического, и бизнес в них никогда не поверит. Напротив, он закономерно придёт к выводу, что IT-отдел пытается его надурить. Поэтому первый способ не работает.
Второй способ убеждения — это катастрофа. Legacy наносит вред своим существованием. Однажды этот вред становится критичным. Например, жизненно важный сервис отправляется в Валгаллу, и бизнес хочет, чтобы он вернулся в строй в течение минут, а по факту проходят часы или даже дни. Катастрофы очень убедительны. После того как это случится, бизнес почти наверняка выделит необходимые средства на усовершенствование IT-ландшафта. Проблема в том, что к этому моменту вред уже нанесён и цена может быть слишком высока. Хотелось бы добиться того же результата малой кровью.
Третий и самый лучший способ — это доверие. IT бизнес-партнёр должен выстроить доверительные отношения между бизнесом и IT. Отношения, где обе стороны готовы слушать и могут быть услышаны. Также IT бизнес-партнёр служит арбитром, гарантом этого доверия. Он не на стороне бизнеса, он не на стороне IT — он на стороне общей выгоды. И там, где бизнес не доверился бы IT-отделу, он доверится IT бизнес-партнёру.
Не аврал, а рутина
Даже если отношения между IT и бизнесом такие же радужные, как у главных героев мелодрамы в последние минуты экранного времени, договариваться об изничтожении того или иного legacy всё равно утомительно. Приходится заново проговаривать одни и те же аргументы, заново пробовать на прочность доверие.
Бизнесу следует понимать, что «legacy-образование» — это как тромбообразование; оно, к сожалению, происходит незаметно, но постоянно. Это не несчастный случай и не результат чьей-то ошибки. Хорошие, рабочие системы превращаются в legacy не вполне предсказуемо, но статистически неизбежно. Поэтому борьба с legacy должна быть не экстренным мероприятием, а стратегией.
У нас в МКБ эта стратегия расписана на ближайшие несколько лет. Выделены компоненты, которые уже устарели или постепенно устаревают — такие как использование dblink’ов, шина от IBM и прочая. Описано, к каким выгодам ведёт их устранение с точки зрения модели RGT. Созданы проекты, назначены ответственные. В общем, всё очень рутинно и совершенно не героически. И это хорошо. Героизм нужен только, если что-то пошло не так.
В заключение
Знаете, какая стратегия борьбы с legacy точно не работает? «Если я буду игнорировать это, возможно, оно исчезнет».
Если ваша должность подразумевает опасность легасиобразования, будьте проактивны. Выстраивайте диалог с бизнесом и стратегию борьбы с несвежим кодом. И, разумеется, задавайте вопросы в комментариях.
Комментарии (39)
Thomas_Hanniball
20.01.2023 19:27+2«Legacy — это всё, что было до того, как я пришёл в проект». Насколько оно верно, предоставлю судить читателю.
Фраза верна на все 100%. Проект становится legacy, когда старая команда уволилась, а новую некому было обучать и вводить в курс дела, поэтому новая команды вешает на проект ярлык legacy и делает новый проект, чтобы заменить текущий, в котором будет разбираться.
funca
20.01.2023 19:34+2Лучший способ разобраться для новой команды это повторить.
На доскональное изучение существующей реализации или переписывание команда потратит примерно одинаковое время. Но во втором случае давление со стороны бизнеса будет меньше (если получится продать конечно).
"Ребята уже третий месяц чего-то пишут" выглядит лучше, чем "ребята уже третий месяц разбираются".
MockBeard
20.01.2023 20:07В работающем легаси могут быть зашиты сотни бизнес-процессов, останавливать которые никто не позволит. И для переписывания, нужно будет сначала досконально разобраться как все работает, чтобы просто оценить масштабы.
IdeaLog Автор
20.01.2023 21:50Тут немного поможет, если старая система не совсем монолит. Вполне рабочий вариант - переписывать или добавлять отдельные модули на целевом стеке. Например в нашем огромном кредитной процессе так был сделан модуль мониторинга (исполнения кредита).
IdeaLog Автор
20.01.2023 22:05+1В частном бизнесе так не очень работает. За это что-то кто-то платит, а бизнес начинает сильно переживать, когда не понимает, куда уходят деньги. Да и по практике отсутствие прозрачности в ИТ - ведёт потом к масштабным сокращениям. А это уж точно не наш метод )
funca
20.01.2023 22:29Зависит от частного бизнеса. Бывает так, что бюджет планируются на год вперёд. А на следующий год ни кто не хочет признать, что деньги потрачены впустую и выделяется бюджет ещё на год - ну чтобы наверняка все доделали, или хотя бы что-то показали). В общем по-разному бывает.
Thomas_Hanniball
20.01.2023 20:31+3Знаете, какая стратегия борьбы с legacy точно не работает? «Если я буду игнорировать это, возможно, оно исчезнет».
Эта стратегия работает. Причём как у исполнителей, так и у менеджеров.
У исполнителей: Работает — не трогай.
У менеджеров: Я сюда пришёл поработать на 2-3 года, чтобы прокачаться, а потом уйти на другую более высокооплачиваемую работу. Так что эта проблема с legacy будет головной болью того, кто придёт после меня.
А если сюда ещё добавляется обвинительная культура, когда за любую ошибку людей наказывают лишением премии, то желание что либо менять отпадает само собой. Зачем что-то менять в компании с риском стать крайним и сидеть без премии пару кварталов, если можно ничего не менять и стабильно получать свои премии.IdeaLog Автор
20.01.2023 21:57Тут на 100% соглашусь. Как там было ... Culture eats strategy for breakfast. Если в компании культура перекидывания ответственности, то проблема в ней явно не в легаси-системах.
stackjava
20.01.2023 22:04+2Так а в чем все таки работа ИТ Бизнес партнера?
Бизнес отвечает за прибыль.
ИТ отвечает за то чтобы сделать и оно работало на проде.
ИТ бизнес партнер отвечает за... Мир во всем мире и дружбу ?
IdeaLog Автор
20.01.2023 22:49И действительно ... Бизнес даёт требования, команда аналитиков-разработчиков-тестировщиков их реализует. А не разогнать ли мне всех руководителей проектов и скрам-мастеров ...
stackjava
21.01.2023 10:20Вот вы и ответили на то кто должен делать связку: рук проектов.
Но РП это от бизнеса. Так что Бизнес нанял спец чела для того чтобы вести проект РП.
Скрам мастером может быть любой член команды.
Дак что в итоге делает ИТ бизнес партнер?
IdeaLog Автор
21.01.2023 11:28И РП от ИТ нужен, и скрам-мастером может быть далеко не любой.
Бог с ним с БП, я вот за CIO переживаю, вы бы такими темпами и его уволили )))
stackjava
21.01.2023 12:44+2Наверно для этого и нужен ИТ бизнес партнер - уходить от ответов на конкретный вопрос и уводить диалог в сторону...
Дак все таки 3 раз пишу вопрос:
Дак что в итоге делает ИТ бизнес партнер?
markin
20.01.2023 23:26Очень странный вопрос. Ваше видение существует только в идеальном мире маленькой компании в вакууме. Между IT и бизнесом всегда существует некоторый разрыв. Наличие связующего звена, понимающего и коммуницирующего обе стороны, сказывается крайне положительно на совместных процессах.
stackjava
21.01.2023 10:23В мире разработки продукта есть куча людей:
Продакт, бизнес аналитик, системный аналитик, разработчики, тестировщик, скрам мастер либо выделен либо переходящая роль.
Продакт либо сам коммуницирует с командой либо через рук проекта.
IdeaLog Автор
21.01.2023 11:13А ещё есть Директора департаментом, Зам. преды и другие ЛПР. Управление их ожиданиями - одна из составляющих роли.
FulgerX2007
20.01.2023 22:06Если не делать рефакторинг то каждое изменение или добавление функционала в дальнейшем будет просить все больше и больше времени ии рисков.
vagon333
21.01.2023 01:49+1Катастрофа, Аврал, Боль - слова продаж и ярких слоганов.
Многие продукты с красивой архитектурой, поддержка которых проста и требует минимальных вложений, лучше не трогать.
В конце-концов, любой "легаси" был передовым продуктом 10-20 лет назад, и если продукт соответствует текущим требованиям - don't fix it. :)
Refactoring - еще тот капкан.
Если убедили перейти на новый продукт, то переход не предполагает правку/удаление старого, а требует планируемое внедрение/создание параллельного продукта.
По крайней мере, это практика в банковской области разного размера компаний штатов.
Никто в здравом уме не подставится переходом на новый продукт и не даст изменить существующий без возможности отката. Всегда должен существовать PlanB - откат на legacy.IdeaLog Автор
21.01.2023 11:16Странно было бы не соглашаться с необходимостью rollback plan.
Важно только в этом откате не откатиться на эксель, а дальше - на бумагу ;)
panzerfaust
21.01.2023 08:05+1Три способа убедить бизнес
Кстати, есть способ номер ноль. Это озвученное Мартином правило бойскаута: код после тебя должен быть лучше, чем до тебя. Я не прошу у бизнеса время на рефакторинг, а итеративно занимаюсь рефакторингом каждый раз, когда захожу в участок кода по делу. Но очевидно, это неприменимо для высоких уровней архитектуры.
fomiash
21.01.2023 09:51Здесь можно столкнуться с тем, что это "лучше" тоже процесс устаревающий, как и code style, следуя посылу статьи со временем превращается в легаси. В итоге один разработчик зашел в часть кода, сделал "лучше" для части функций, через пару лет второй, потом третий через пять, четвертый просто смотрит на эту мешанину стилей и подходов и матерится. Это все будет легаси, судя по определению, которое дал автор. А раз так, не гуманнее ли по отношению к четвертому разработчику следовать первоначальному стилю кода(окружения) для однообразности логического блока, а рефакторить так уж весь блок скопом?
IdeaLog Автор
21.01.2023 11:24+1Размер блоков и модулей и констстентности внутри них - это очень правильный практический вопрос. Тут можно сравнить с темами про микро- и макроэкономику. Вроде все про экономику, но предпет и подходы несколько отличаются.
vkni
Ну и как вы представляете «довериться друг другу» в обществе «конкуренции»? Это у вас «фентези» получается, с рыцарями, драконами и принцессами.
IdeaLog Автор
Если продолжать эту идею, то вовлечение болтших компаний в опен-сорс никогда бы не происходило. Да и наш кейс еще более скромный: доверяем мы все же не компании-конкуренту, а бизнес - ИТ, а ИТ - бизнесу.
ermouth
Как именно МКБ вовлечён в open source?
IdeaLog Автор
Здесь имею в виду скорее компании типа Яндекса, Гугла и иже с ними, которые свои коммерческие продукты выводят в опен сорс. Вот тут было недавно интересное видео на этот счет про CatBoost. https://youtube.com/watch?v=G7G286S8ntc&si=EnSIkaIECMiOmarE
МКБ вовлечен скорее как потребитель - мы много чего такого используем и дорабатываем. Хотя тему с комитами на гитхаб тоже, проработать можно.
ermouth
Вполне ожидаемо. Я только не понимаю, с чего ИТ-комьюнити должно вам довериться.
Увы, процитированными вами же словами Друкера – культура вашей организации съест это начинание на завтрак. Ребята в галстуках делиться не умеют.
IdeaLog Автор
Тут доверие бизнес-бизнес на критическом пути. С разработчиками в этом плане сильно проще.
Доверие и Долженствование - слова из разных вселенных. Тут я с вами полностью согласен.
По поводу культуры в Банке - буду благодарен за фактуру, на которой вы основываетесь, строя столь неутешительные гипотезы. Это помогло бы понять, с чем ещё надо поработать.
ermouth
Ребята в галстуках делиться не умеют.
vkni
Там дедушка Столлман сначала выкручивал руки GPLкой, пока не выяснилось, что обобществлять инфраструктурные проекты выгодно. А внутри трёхлитровой банки с пауками — нет, обобществлять не выгодно.
murkin-kot
Очень просто. Пример - два вора идут на дело. Они вынуждены доверять друг другу. Иначе дело погорит. И после дела тоже доверяют. Иначе получится ситуация "кто первый сдаст".
Вы, как и многие сторонники искажённой модели социализма, имевшей место в СССР, упускаете из вида массу деталей, в которых порылся дьявол.
Глобально оптимизировать систему с пятью степенями свободы вполне возможно, но когда степеней свободы будет миллион, или даже миллиард, то вы уже сами понимаете своё полное бессилие.
Примитив, к которому сводится общество сторонниками социализма, коммунизма, марксизма и тому подобного, никогда не позволит обеспечить именно глобальную оптимизацию "для всех". Хотя глобальная оптимизация для царствующих паразитов вполне возможна, хотя и она будет далека от потенциально достижимой эффективности.
Сложные задачи требуют сложных решений. Отойдёте от примитива - найдёте решение. Или не найдёте. Потому что в сравнении со сложностью задачи все мы ничтожны. Но если не отходить от примитива - точно решений не найдёте.
vkni
Ну это, блин, сарказм был. Шпилька в сторону поборников «свободной конкуренции».
murkin-kot
Сторонники свободной конкуренции точно так же сильно всё упрощают. А сарказм они не понимают, потому что свободная конкуренция "только для меня" выгоднее, чем все остальные предложения, поскольку они "не только для меня". То есть помимо логически порочного подхода здесь присутствует ещё и мотив выгоды (правда многие довольствуются лишь порочной логикой, даже не задумываясь о выгоде).
vkni
Да, и это я тоже знаю. И более того, могу вообще лекцию провести на тему «человек хорошо описывается моделью homo-economicus, даже если действует слабоосознанно», просто горизонт планирования у разных людей разный + разное окружение.
Но дайте же поприкаловаться — это же весело, когда вы пишете реплику, а оппоненты действуют совершенно предсказуемо. Это же игра такая.
murkin-kot
Интересно. Где можно достать конспект? Ну и кому писать аргументированные возражения?