Strangler Fig
Во время отпуска в тропических лесах Queensland в 2001 году мы увидели несколько фикусов-душителей (strangler figs). Это лианы, которые прорастают в укромном уголке дерева. По мере роста они вытягивают питательные вещества из дерева-хозяина, пока не достигнут земли, чтобы пустить корни, и кроны, чтобы получить солнечный свет. Затем они становятся самодостаточными, а дерево-хозяин может погибнуть, оставив фикус в качестве напоминания о своей форме. Этот постепенный процесс замены основного дерева показался мне поразительно похожим на то, как мои коллеги модернизируют устаревшие программные системы. Пару лет спустя я опубликовал в блоге небольшую заметку об этой метафоре. Хотя с тех пор я не использовал этот термин в своих публикациях, он всё равно привлёк внимание, и теперь термин «фикус душитель» часто используется для описания постепенного подхода к модернизации устаревших систем.
В наши дни программные системы лежат в основе большей части человеческой деятельности, но часто не очень хорошо справляются с этой задачей. Они создавались десятилетиями, часто с небольшими инвестициями и заботой о поддержании их работоспособности. Поскольку одни потребности пользователей и технологические платформы меняются, это программное обеспечение тоже должно измениться, но эти изменения часто осуществляются путем создания патча за патчем, каждый патч усложняет адаптацию к будущим изменениям. В конце концов люди понимают, что больше не могут чинить то, что есть, и им нужна полная модернизация.
Столкнувшись с таким выбором, легко подумать, что это просто замена. Мы знаем, как работает старая система, поэтому просто создадим новую систему, которая будет делать то же самое, но на основе новой, более совершенной технологии, которая будет лучше поддерживать изменения. Но мы видели, как этот простой на первый взгляд план в большинстве случаев проваливался. Замена серьёзной IT-системы занимает много времени, а пользователи не могут ждать появления новых функций. Замены кажутся простыми в реализации, но зачастую сложно разобраться в деталях существующего поведения. Что ещё хуже, может оказаться, что большая часть этого поведения на самом деле не нужна, так что его реализация будет пустой тратой времени.
Альтернативный вариант, который предпочитаем мы с коллегами, — это постепенная модернизация. Как и в случае с инжиром, она начинается с небольших дополнений, часто в виде новых функций, которые создаются поверх устаревшей кодовой базы, но отдельно от неё. При этом мы переносим фрагменты поведения из устаревшей системы в новую кодовую базу.
Иэн Картрайт, Роб Хорн и Джеймс Льюис определили четыре основных вида деятельности, которые необходимы для такого поэтапного подхода.
- Поймите, каких результатов вы хотите достичь
- Решите, как разбить задачу на более мелкие части
- Успешная поставка частей
- Измените структуру организации, чтобы это можно было делать на постоянной основе
(Указанный здесь порядок не подразумевает последовательность.)
Чтобы приступить к модернизации, нам нужно чётко понимать, каких результатов мы хотим добиться. Слишком часто мы сталкиваемся с тем, что у разных групп разные цели. Нам нужно как можно раньше согласовать ключевые результаты, а затем регулярно пересматривать их, чтобы убедиться в согласованности и понять, нужно ли менять приоритеты.
В идеале программное обеспечение должно состоять из понятных компонентов, которые можно заменять по отдельности. Устаревшие системы редко обладают этим свойством, поэтому приходится изрядно потрудиться, чтобы разбить их на управляемые части. Для этого нужно определить швы, которые мы можем вставить в систему, чтобы разделить ее2. Часто бывает полезно определить, как система удовлетворяет различные потребности бизнеса, и выделить отдельные потребности в новые компоненты.
Как только мы изолируем несколько компонентов, мы сможем приступить к их замене. Поскольку эти компоненты небольшие, внедрение нового программного обеспечения сопряжено с меньшим риском. Как только они заработают, компания сможет извлечь выгоду из этих новых компонентов и быстрее окупить инвестиции. Мы также узнаем больше о том, как заменить устаревшую систему и как это повлияет на бизнес, что поможет нам принимать более взвешенные решения по мере продолжения модернизации.
При этом люди часто возражают против необходимости создания переходной архитектуры, которая позволит сосуществовать новой и устаревшей системам, а также против кода, который будет удалён после завершения модернизации. Хотя это может показаться пустой тратой времени, снижение рисков и более раннее получение выгоды от постепенного подхода перевешивают затраты.
Все это связано с более масштабными организационными изменениями. Устаревшие системы становятся негибкими и хрупкими, потому что их создали с помощью дизайн-мышления и организационных процессов. Если организационная культура и руководство не изменятся, новые системы окажутся в такой же неразберихе. Поэтому нам также необходимо внедрить новые методы разработки, в том числе реорганизовать отдел разработки и его связи с бизнесом в целом с учетом закона Конвея.
Использование подхода «Фикус-душитель» для модернизации устаревших систем не упрощает задачу. Замена программной системы, глубоко интегрированной в бизнес-процессы, никогда не будет простой задачей. Этот подход позволяет постепенно и наглядно осуществлять как инвестиции, так и возврат средств, что даёт организации возможность развивать программное обеспечение и бизнес-процессы для более эффективной поддержки текущей среды и (что, возможно, ещё важнее) для более устойчивого развития в будущем.
Перевод: https://martinfowler.com/bliki/StranglerFigApplication.html
Автор: Мартин Фаулер