Введение
Назначение этой статьи – дать базовое понимание специалистам, далеким от разработки, о том, как опасны устаревшие компьютерные системы и код и чем они могут навредить бизнесу.
Возможно, вы уже слышали слово “легаси” (legacy) от сотрудников технических отделов и, как правило, в негативном ключе. Данным термином обозначают методы, технологии и компьютерные системы или прикладные программы, которые по каким-либо причинам признаны устаревшими. Однако всегда ли такое наследство несет негативный эффект для бизнеса, обязательно ли от него избавляться и как понять, что оно действительно вам мешает?
Как правило, с проблемами легаси чаще сталкиваются программисты, аналитики, тестировщики и специалисты поддержки, о чем свидетельствует разнообразный опыт нашей собственной команды. Для конечных пользователей эти проблемы, как правило, остаются под капотом, а для CEO скрываются за цифрами отчетности, не выделяясь какой-то явной логикой.
По сути, вся ситуация напоминает перманентный тюнинг внешнего вида и салона автомобиля, движок которого дышит уже с трудом, но пассажиры об этом не догадываются. Рано или поздно это чудо автопрома непременно заглохнет где-то на полпути между точкой А и точкой Б, но до этого момента будет производить вполне приятное впечатление, особенно если пассажирский салон более чем комфортен, и подвеска, или будем говорить прямо – первая линия поддержки, позволяет практически незаметно переносить случайные выбоины на пути.
Впрочем, и здесь не стоит сразу бросаться менять старый и проверенный трактор на новомодный смарт. Все зависит от целей и текущего состояния вопроса.
Как понять, что легаси вам мешает?
Вот список тревожных симптомов и проблем, которые вы можете заметить, даже не будучи специалистом:
Отсутствие четкой и ясной документации на поддерживаемые бизнес-процессы
Возможно, сейчас документация кажется вам неважной, ведь каждый из ваших сотрудников -- настоящий профи, и может среди ночи рассказать весь бизнес-процесс от А и до Я, а информационная система, в которой они работают, изучена ими вдоль и поперек. Однако реальный опыт, как правило, показывает, что это далеко не так, более того, очень часто даже терминология, которой пользуются сотрудники разных отделов, существенно отличается. Самый базовый пример: попытка выстроить бизнес-процесс утверждения договоров на поставку. Юристы воспринимают термин “договор” совершенно иначе чем бухгалтерия, и оба отдела акцентируются на совершенно разных этапах утверждения договора.
Сейчас компании более охотно признают ценность прозрачных и хорошо организованных бизнес-процессов, и найти статью о плюсах такого подхода не составит труда. Как пример: Benefits of BPM | 11 Massive Advantages of Business Process Management. Впрочем, данная статья примечательна еще и исследованиями на которых основана, в частности на исследовании от 2020 года о том, что вспышка COVID заставила предприятия больше вкладываться в автоматизацию своих бизнес-процессов и изменила их оценку важности замены устаревших процессов.
Ригидность к улучшениям
По какой-то причине вы не можете легко и быстро интегрироваться с ведущими сервисами, своевременно масштабировать или гибко модифицировать ПО и поэтому вечно опаздываете вскочить на подножку уходящего поезда рыночных возможностей.
Поверьте, это не череда трагических случайностей, а тревожный симптом.
Особенно четко этот симптом наблюдается в государственных учреждениях, где ригидность обусловлена форматом работы, и любые изменения требуют долгосрочного согласования. Например, чрезмерные затраты правительства США на ИТ инфраструктуру в 2019 году (более 70 миллиардов долларов) послужили причиной внутреннего расследования, которое показало, что основной проблемой является именно устаревшее ПО.
Однако и коммерческие компании, чей формат работы предусматривает гибкость и открытость новым технологиям, также страдают от легаси. Авиакомпании, банки, страховые и ретейлеры рано или поздно сталкиваются с тем что они неспособны преодолеть ригидность устаревшего ПО. Как результат, их работа становится нестабильной, они не могут выводить на рынок новые продукты и услуги и даже стабильно поддерживать существующие. К примеру компания Delta Air Lines в августе 2016 году столкнулась с непредвиденным сбоем казалось бы надежных систем бронирования, регистрации на рейс и посадки, что вызвало простой в течение нескольких часов и отмену более 2000 рейсов. Этот и другие кейсы приведены в статье “Legacy systems are problems for boardrooms not computer geeks,” Financial Times, Jan. 31, 2017.
Уныние в ИТ команде и потеря лояльности пользователей
Казалось бы, как легаси может воздействовать на атмосферу в команде?
Секрет тут прост, любая модификация легаси-систем сродни заплатке на атомную бомбу: скорее всего не рванет, но трогать лишний раз не хочется. Специалисты по устаревшим языкам и технологиям обходятся дорого, достаточно вспомнить проблему 2000 года, а новички стремятся поставить на старое окружение заплатку из чего-то современного, и все это со временем превращается в монструозный зоопарк технологий, куда не каждый специалист решится сунуться. В результате пользователи начинают всё чаще жаловаться на проблемы, а развитие продукта затормаживается.
Кроме того, повышается вероятность увольнения сотрудников, которые будут демотивированы и не захотят раскапывать проблемы в старом монструозном коде, на который нет документации, либо она передавалась как устное народное творчество.
Конечно, незаменимых сотрудников нет, но стоит помнить, что поиск и адаптация нового сотрудника имеют свою цену, и чем сложнее и запутаннее проект, в котором надо научиться разбираться, тем дольше новый сотрудник будет входить в курс дела (и получать деньги за то, что разбирается в старом коде!). Тем временем, важные для бизнеса задачи придётся решать всей остальной команде.
А теперь представьте, что резкие изменения рынка (а последнее время они всегда резкие) требуют от вас мгновенного реагирования. Можно не представлять, а прочитать в какие условия поставлены компании сейчас: Коронавирус (COVID-19): влияние на бизнес.
Типичные пути решения
Итак, мы выяснили, что наличие легаси -- это не только проблема ИТ-отдела, но и возможная угроза для стабильности и роста компании. Рассмотрим типичные способы борьбы с такой ситуацией:
игнорировать – данный путь может дорого обойтись, если вы уже видите перечисленные выше проблемы, но иногда является оптимальным. В конечном итоге, если траектория бизнеса неизменна, лучше положиться на старого и надежного боевого товарища, вместе с которым пройдены вода, огонь и медные трубы;
полностью заместить новым ПО – иногда этот путь оказывается единственно возможным, поскольку легаси, как болезнь, может очень быстро “заразить” и все смежное окружение;
постепенно/покомпонентно замещать – это, как правило, путь революции снизу, когда ИТ отдел планомерно проводит рефакторинг домашней системы, однако он требует практически безграничного упорства и последовательности;
реинжиниринг бизнес-процессов и следом за ними ПО – данный путь является, пожалуй, самым радикальным, практичным и эффективным, однако он трудоемок и требует осознанной поддержки руководства.
Заключение
Как видим, легаси может навредить бизнесу, а не только нервам программистов, работать с легаси можно по-разному, и для разных случаев разные способы хороши.
В следующей части статьи мы более подробно рассмотрим, когда и какой путь стоит выбирать, а также расскажем, как выбор технических средств может помочь работать с легаси.
Вам может быть интересно:
Комментарии (20)
matheu042
29.11.2021 19:01+1Спасибо, полезная и актуальная статья. А теперь интересно было бы послушать примеры реального
леченияизбавления от легаси на примере относительно крупной компании. Это был бы супер актуальный и интересный кейс.
BugM
30.11.2021 01:43В любом достаточно крупном проекте от легаси в принципе нельзя избавиться полностью. Пока заканчиваешь переписывать одно, устаревает второе. А еще фичи делать надо когда-то.
Зато можно поддерживать количество и состояние легаси кода приемлимым. Иногда лазить в него, местами рефакторить. Не боятся обновлять или фичи прикручивать. Или модным мониторингом все обвесить. Или вот как сейчас на jdk17 перевести все. Если на это выделять время у вас всегда будут разработчики которые ориентируются во всем легаси кода и поддерживают его в приемлимом состоянии.
Плата за это - некоторое уменьшение скорости разработки новых фич. На длинной дистанции плюсов больше как мне кажется.
SpiderEkb
30.11.2021 11:18Банк Содружества Австралии и Океании в 2012-м году решил полностью избавиться от легаси в своем коде.
Заняло это у них 5 лет (до 2017-го года). Обошлось в $750млн. Количество людских ресурсов неизвестно.
Больше желающих заменить проверенный десятилетиями работающий код в большой mission-critical системе не нашлось.
Известный случай с "падением серверов" службы занятости в США тоже оказался не в пользу замены легаси. Расследование выявило, что сами сервера с их легаси кодом работали как часы. Все проблемы были на middle слоях. Там, где использовались "современные стеки". Именно они оказались неготовыми к резко возросшей нагрузке.
Ну и правильно отмечено - если вы начинаете в большом легаси переходить на современный стек - будьте готовыми к тому, что к тому времени, когда вы разберетесь как оно работает, все перепишете, проведете все необходимые ретесты и внедрите, ваш "современный когда-то стек" уже превратится в то же легаси, от которого вы пытались избавиться.
Проблема на самом деле не в легаси. Проблема в недостаточной документированности процессов. Если все описано и документировано, да еще и архитектура изначально выбрана правильно, то абсолютно неважно когда и на чем оно написано.
А "избавление от легаси" часто объясняется просто - "я не хрена не понимаю как оно работает, дай-ка перепишу все по-своему". Это типичное велосипедостроение и хреносозидательство.
BugM
30.11.2021 11:32Кобол таки пора переписывать. Разработчиков уже нет, а через 10 лет (примерный срок завершения переписывания больших систем если начать завтра) вообще не будет. Нанять и и обучить тоже сложно. Мало кто хочет даже за оплату выше рынка.
Я бы оценил лет в 30 срок когда точно пора переписывать. Лучше через 20 уже начать плотно думать об этом и бюджет выделять. Чтобы через 30 точно закончить.
SpiderEkb
01.12.2021 12:42С кобол разработчиками не все так плохо. Просто это достаточно замкнутый мир. Это не джависты, которые прыгают с проекта на проект. Разработка на кобол требует более глубоких знаний, во-первых, платформы, на которой все это крутится т.к. платформы там достаточно специфические и требования к эффективности тоже достаточно высокие (а если человек хорошо знает платформу, то освоить кобол тело техники) и, во-вторых, более глубокого вникания в предметную область т.к. там сосредоточена вся бизнес-логика в которую так или иначе приходится вникать для достижения требуемой эффективности.
В общем, это отдельный мир где специалистов ищут или прямым хантингом или через знакомых. А отнюдь не публикацией вакансии на каком-нибудь hh. В крайнем случае поиск будет внутри специализированных групп на LinkedIn.
Это как бы "устрицы". С коболом дела не имел, но плотно работаю с его альтернативой - RPG. Ситуация именно такая.
Ну и найти замену коболу достаточно сложно - он разрабатывался специально под максимально эффективную по скорости и ресурсам реализацию коммерческой бизнес-логики. Реальная альтернатива - тот же RPG. Со всеми его специфическими возможностями (числовые типы с фиксированной точкой, работа со строками, прямой доступ к таблицам БД, возможность интеграции SQL непосредственно в код и т.п.)
Ну и объемы... Та же АБС (автоматизированная банковская система) это сотни тысяч, если не миллионы строк кода, 80 и более процентов которого составляют бизнес-логику и вообще не имеют никакого интерфейса (работают исключительно в фоне). Да еще и реализованы в модели близкой к модели акторов. Т.е. охватить разумом всю последовательность действий, которая возбуждается по изменению одного поля в какой-то таблице может оказаться очень и очень сложно.
И весь этот код работает очень давно. И из него вычищено за время работы 99.(9)% дефектов.
Плюс неизбежно возникнут головные боли типа "вот в таблице это поле прописано как timestamp, в коде с ним работают как с char, я пытаюсь сделать так же, но оно у меня даже не компилируется".
Плюс надо очень хорошо знать сам кобол чтобы понимать все тонкости работы кода, который переписываешь.
Т.е. мало все это понять как работает, мало все это переписать, надо еще провести полный ретест (а это компонентное, бизнес, нагрузочное и интеграционное тестирование на предмет неухудшения - оно не должно потреблять больше и не должно работать медленнее оригинала). Пример банка Австралии тому хороший показатель.
В общем, я не знаю так ли оно нужно. Есть ли сейчас действительно новые языки, ориентированные именно на коммерческие расчеты и глубоко интегрированные в платформы, на которых все это работает (т.е. которые дают реально быстрый и эффективный код).
По поводу "легаси" (правда, не языков, а платформ) давно ведутся споры - стоит ли мигрировать. Вот есть статейки на эту тему:
ymishta
29.11.2021 20:24Специалисты по устаревшим языкам и технологиям обходятся дорого
Судя по тому, что на Delphi, например, никто не предлагает рейтов в разы выше тех, что на популярных языках платятся, да и на саппорт-девелоперских вакансиях тоже не наблюдается избытка $$$, это утверждение мимо тазика.
harios
29.11.2021 20:59+3Шел 2021, уже пару месяцев как вышел Delphi c поддержкой Windows 11 и M1, но люди все еще продолжали хоронить его. :)
ITMatika
30.11.2021 08:03С одной стороны, я ещё пользуюсь изредка Delphi и считаю его недооценённой на текущий момент системой. С другой - давайте будем честны с собой - Borland сама похоронила Delphi много лет назад, а сейчас всё никак не может реабилитировать стюардессу в глазах нового поколения.
harios
30.11.2021 08:44С другой - давайте будем честны с собой - Borland сама похоронила Delphi много лет назад
Полностью согласен, такое действительно было, только Borland похоронила не Delphi, а себя саму и это отразилось на Delphi. Благо его успели выкупить Embarcadero.
DMGarikk
30.11.2021 12:14Шел 2021, уже пару месяцев как вышел Delphi c поддержкой Windows 11 и M1, но люди все еще продолжали хоронить его. :)
У кобола тоже компиляторы в 21 году выходят с обновлениями и всякими ф-циями
а люди всё продолжают его хоронить
max_dark
29.11.2021 21:01+1Legacy - То чувство, когда проект над которым работаешь находится на стадии "казнить, нельзя помиловать", но правки всё равно нужно вносить...
shornikov
Надо бы посчитать, что выгодней бизнесу - постоянно держать штат программистов, которые переписывают рабочий код стараясь держать его в тренде, или раз заплатить, и через 20 лет еще раз заплатить...
KongEnGe
Вот возьмем спецов по коболу: этим гадам уже один раз заплатить не получается, они садятся на пожизненную зарплату :)
harios
Есть такая мысль что этим гадам даже пожизненно будет платить дешевле, потому что эти же системы переписанные на современных "великолепных" стеках будут работать медленней, с ошибками, со штатом разработки х10 и железа требовать х3.
KongEnGe
Я к тому, что бизнес со своим тактическим выигрышем на наращивании техдолга с кобольщиками стратегически просчитался. Нашлась проруха и на старуху.