Привет, Хабр! Меня зовут Валерий Лобанов, работаю 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 точно не работает? «Если я буду игнорировать это, возможно, оно исчезнет».
Если ваша должность подразумевает опасность легасиобразования, будьте проактивны. Выстраивайте диалог с бизнесом и стратегию борьбы с несвежим кодом. И, разумеется, задавайте вопросы в комментариях.
