Оригинал: 11 dark secrets of application modernization
Автор: Боб Льюис (Bob Lewis)
Центральное место в сегодняшних стратегиях цифровизации занимает модернизация унаследованных бизнес-приложений. Задача эта оказывается более сложной, затратной и менее благодарной, чем может показаться на первый взгляд.
По оценкам TwoBitHistory.org, более 95 процентов компаний из списка Fortune 1000 все еще используют древнюю иерархическую СУБД IMS от IBM. При этом, как показывают мои наблюдения, процент талантливых разработчиков ПО, которые желали бы работать с таким ПО, стремится к нулю.
Талантливых программистов привлекают современные платформы. Это не единственная причина для обновления приложений, но одна из важнейших. Другие аргументы — снижение лицензионных отчислений и затрат на техническую поддержку, повышение гибкости и адаптируемости информационных систем.
В остальном же плюсы модернизации ПО не столь очевидны. При принятии решения ИТ-директору стоит обратить внимание на подводные камни этого процесса.
1. Модернизация ПО — комплексная задача
Понятие «модернизация ПО» включает широкий спектр решений для широкого спектра проблемам.
В зависимости от характера ПО и от того, с кем вы разговариваете, под модернизацией приложений может пониматься обновление версии, смена платформы, переписывание приложения на современном языке программирования, рефакторинг исходников или замена коробочного софта. Это все очень разные подходы, и у каждого свои подводные камни, некоторые из которых общеизвестны, а другие — нет.
Наличие множества подходов к модернизации заметно усложняет дело: принимаясь за очередное приложение, мы должны решить не только стоит ли его модернизировать, но и какой путь выбрать, если ответ положительный.
А теперь умножьте это на количество имеющихся приложений.
2. Обновление версий — своего рода возврат долга
Некоторые ИТ-директора считают себя настолько прожженными бизнесменами, что «не приобретают технологию ради технологии», а в вопросах обновления приложений и технологического стека руководствуются принципом «не сломано — не чини».
Идет ли речь о серверной ОС, СУБД, системе управления контентом, ОС на персональных компьютерах, браузере и так далее — у таких руководителей подход один: обновляться только если новая функциональность обеспечит возврат инвестиций.
К несчастью, правило «плати сейчас или заплатишь потом» никто не отменял, причем платить потом значительно накладнее и травматичнее, чем вовремя.
3. Замена технологического стека решает только одну из проблем
Перенос унаследованных приложений в стек свободного ПО — популярный способ модернизации с очевидными выигрышами. Примером может служить переход с мейнфрейма и связки z/OS + COBOL + CICS + DB2 на платформу x86 и Linux + COBOL + CICS + DB2. Применительно к облакам такую миграцию называют «lift-and-shift».
Таким образом достигается экономия на лицензионных платежах и техподдержке. Подводный камень? На этом выгоды и заканчиваются.
4. Смена платформы обходится дороже, чем казалось
Под сменой платформы понимается замена одного слоя технологического стека, когда старая платформа теряет популярность. Например, можно перенести приложение с СУБД Sybase на SQL Server.
Выигрыш при этом заключается в уменьшении рисков неполадок и уязвимостей, а также в возможности найти способных разработчиков. Чего не стоит ожидать, так это сокращения затрат и дополнительной функциональности. Затраты в реальности даже возрастут, поскольку вам придется приобрести новые лицензии.
5. Попытка переписать приложения на современном языке программирования может сделать ситуацию еще хуже
Рекламные проспекты уверяют нас, что автоматизированные инструменты извлекут бизнес-логику из унаследованного приложения на COBOL и конвертируют ее в код на современном языке программирования. При этом зачастую все сводится к тому, что из 100 тыс. строк кода на COBOL получается такое же число строк на Java.
Подводный камень здесь в том, что язык программирования не сводится к синтаксису — каждый базируется на собственной философии разработки ПО.
Второй важный момент: как правило, вместе с языком разработчик получает библиотеки готовых функций. Когда разработчики пишут приложение с нуля, они их используют в полной мере. Конвертеры же кода, за редким исключением, этого не умеют, а значит поддерживать сгенерированный код станет еще тяжелее.
6. Рефакторинг — модернизация полноценная, но дорогая и трудоемкая
Рефакторинг — метод модернизации, при котором архитектура унаследованного приложения перерабатывается в соответствии с современными практиками. Например, данные нормализуются, а монолитный код разбивается на микросервисы.
Некоторые инструменты позволяют в значительной степени автоматизировать этот процесс, но сначала опробуйте и протестируйте их в пилотных проектах, чтобы проверить рекламные обещания.
Имейте в виду, что некоторые средства автоматического рефакторинга воспроизводят поведение приложений один-в-один. Такой подход минимизирует риски нарушения бизнес-операций, но не ждите, что, например, вместо пакетной обработки приложение станет обрабатывать данные в реальном времени. А ведь конкурентные преимущества чаще всего обусловлены именно изменениями в архитектуре.
Рефакторинг дает серьезный бизнес-эффект за счет улучшения адаптивности и гибкости, но за все приходится платить. В случае рефакторинга плата оказывается весьма высокой. Польза от модернизации архитектуры очевидна, но вот сам процесс дорог и трудоемок.
7. Переход с одного коробочного софта на другой не похож на модернизацию, но зачастую является оптимальным выбором
Во многих ситуациях лучший способ модернизировать пакет прикладного ПО — заменить его на более современный эквивалент от другого поставщика. Конечно, это не панацея — каждый, кто участвовал в миграции в облако, знает, насколько это может быть сложно. Но зачастую это самый чистый и наименее рискованный способ заменить приложения, реализованные на безнадежно устаревшей платформе, на перспективные, и тем самым обеспечить бизнесу будущее.
8. Разобраться с тем, что у вас на руках, бывает сложнее, чем осуществить модернизацию
Теперь, когда мы показали нюансы различных подходов к модернизации, пора поговорить о более фундаментальных вещах. Приступая к модернизации, вы должны знать, какое приложение будете модернизировать и какая методика лучше подойдет в конкретном случае.
К сожалению, несмотря на блестящие обещания производителей утилит для автоматического выявления конфигурации, они умеют выявлять только серверы в сети, а не установленное на них ПО.
Причем, если размещение приложений задокументировано настолько плохо, что понадобились средства автоматического выявления конфигурации, то с документацией на среду разработки скорее всего дело обстоит еще хуже. А без этой информации вы не можете выбрать оптимальную стратегию модернизации.
9. Приложение — это мнение разработчика, а интеграция — его аргументация
Бизнес-приложение отражает взгляд разработчика на то, как должна строиться работа определенной части организации. Код приложения отражает логику, а структуры данных — его понятийный аппарат.
Там, где функциональность двух приложений пересекается — например, как в случае данных о контрагентах, которые есть и в бухгалтерском приложении, и в CRM — необходима автоматическая синхронизация данных. Составьте реестр таких пересечений, и вы получите сотни точек интеграции, которые необходимо модифицировать и прогонять через регрессионное тестирование всякий раз, когда разработчики добавляют новое или вносят изменения в существующее приложение.
Технология ESB и ей подобные позволяют избавиться от интеграции «точка-точка» и таким образом сократить число точек интеграции, но этим проблемы не исчерпываются.
Немало хлопот доставляют также семантические нестыковки: модели данных о клиентах в бухгалтерском ПО и в CRM сильно отличаются. Согласование различных взглядов на одну и ту же сущность — основная проблема как в ходе разработки интеграции, так и в последующей поддержке. Проблема эта обусловлена в первую очередь не техническими, а человеческими факторами, поэтому ESB здесь вряд ли спасет.
10. Модернизировать приложения легче, чем отвечающих за них ИТ-специалистов
Предположим, ваши сотрудники хорошо справляются с поддержкой и развитием текущей архитектуры приложений. Кроме того, они — кладезь знаний о том, как бизнес использует существующие приложения.
Но в приложениях и платформах, которые должны прийти на смену существующим согласно плану модернизации, они разбираются уже не так хорошо. А без этого ваш план не сработает.
Помимо этого, они должны уметь находить возможности оптимизации бизнеса, а этого можно ждать только от людей, глубоко разбирающихся в текущих системах и в текущей ситуации.
Подводный камень (благоприятный): выгнать за дверь существующих специалистов и нанять новых — не решение проблемы. Конечно вы вправе их уволить, но найти достойную замену будет непросто и обойдется недешево. Неважно насколько компетентным окажется новый специалист — как показывает практика, замена сотрудника обходится компании в сумму его годового жалования. Это может оказаться запретительно дорого.
Вот почему этот подводный камень модернизации — самый опасный.
11. В хорошо организованных ИТ-подразделениях необходимость модернизации возникает редко
В них реализовано управление жизненным циклом. Они постоянно все поддерживают в актуальном состоянии. Бюджет предсказуем — модернизация происходит в фоновом режиме, а революционные преобразования случаются редко.
Дополнительный бонус — модернизация квалификации ИТ-специалистов идет в параллель с модернизацией приложений и платформ.
Обсудить