В большой и детальной статье под катом — опыт последних двух десятилетий по перестройке устаревших систем в крупных компаниях: что работает, а что ведёт к неудачам, и какие шаблоны можно и нужно использовать. В статье много теории, но появятся шаблоны и примеры — пользуйтесь.
Почему так получается?
Опишем ряд подходов, которые могут помочь. Они помогают разбить проблему на более мелкие части, чтобы удовлетворить новые требования параллельно с совершенствованием технологий. Подходы условно делятся на четыре категории:
Оптимизация затрат
Ключевой момент для решения о переходе с устаревших технологий — деньги. Изменения в бизнесе могут обойтись намного дороже, чем любые ожидаемые плюсы: либо из-за упущенной выгоды, либо из-за стоимости внедрения. Один из первых звоночков — необходимость потратить время и деньги, чтобы внести изменения, которые лишь чуть-чуть повысят эффективность бизнеса.
На этом этапе часто уже невозможно обосновать изменения, не обеспечивающие большой отдачи от инвестиций. Другими словами, состояние технологий диктует масштабы изменений, которые потянет бизнес. Для многих организаций это означает разницу между внесением изменений в привычный ход вещей или необходимостью инициировать более крупный проект. Эти более крупные проекты затем становятся основой для небольших изменений, которые ранее не были учтены, что увеличивает их объём, стоимость и риски.
Совершенствование бизнес-процессов
Любые процессы оказываются тесно связаны с работой системы в условиях ограничений, и часто обходные пути за её пределами формируют бизнес-процессы.
Один из наглядных примеров — система регистрации на рейс в одной из авиакомпаний, в которой использовались терминалы с «зелёным экраном». Из-за ограничений, связанных с устаревшей системой, весь процесс выполняли по чёткому регламенту. Исправления или ошибки приводили к повторному запуску процесса регистрации. Также изначально авиакомпания не предлагала стыковочные рейсы, но затем добавила опцию и дополнительный рабочий процесс в устаревшей системе. Следовательно, если при регистрации пассажир не указывал, что у него стыковка, система сначала выдавала неправильный процесс с печатью неправильных багажных бирок и только после этого переключалась на нормальный процесс. Рабочие места персонала стойки регистрации и обслуживание пассажиров можно было улучшить, внеся изменения в процессы. Но это было невозможно из-за устаревшей версии системы.
Здесь стоит отметить, что требования к заменяющей системе для поддержки импорта и экспорта данных часто могут исходить из подобного обходного пути.
Вывод старой системы
Необходимость вывода старой системы из эксплуатации — распространённая причина модернизации. Это часто вызвано проблемами с поддержкой устаревшего оборудования или программного обеспечения: рост затрат, истечение контрактов на поддержку как для оборудования, так и для программного обеспечения.
Удивительно, что как много крупных организаций работают на уже не поддерживаемом оборудовании и программном обеспечении. Покупка комплектующих на eBay — на редкость распространённая история. Если вы эксплуатируете устаревшие технологии, стоит провести ревизию и создать календарь, обозначив в нём сроки окончания поддержки.
Неминуемый сбой
Для некоторых организаций переломный момент обусловлен внешними факторами: изменением нормативных требований, появлением нового «начинающего» конкурента или ростом уже существующих. В таком случае обновление требует больших временных и финансовых затрат.
Новые технологии
Сами по себе нововведения редко является ключевой целью организации. Они должны отвечать текущим и будущим потребностям бизнеса. Проблема в том, что технологии меняются всё быстрее, а «полезный» срок их службы сокращается. Фактическое определение «полезного» зависит от компании, но в целом при внедрении любых новшеств необходимо учитывать ряд параметров:
Оптимальный подход — переходить на технологии с постепенным внедрением за 2-3 года. Трудно обосновать выбор огромной платформы со сроком окупаемости 5–10 лет, если мы признаём ускоряющиеся темпы изменений.
К счастью, есть ряд полезных инструментов. К ним относятся event storming, карты Уордли (Wardley mapping). Стоит обратить внимание на то, как бизнес-концепции отображаются в архитектуре системы, и понять, как эта архитектура поддерживает создание того или иного продукта.
Зачастую специалисты не изучают возможности за пределами существующих систем и никак не двигаются за их рамки. Также часто упускают из виду такой ценный источник информации, как сами пользователи систем.
Непрерывная доставка
Необходимость быстрых изменений и возможности независимо друг от друга менять элементы бизнеса приводит к появлению гибких подходов с архитектурой на основе микросервисов. Непрерывная доставка становится обязательной. Для неё существует несколько работающих стратегий, в том числе параллельный запуск, разветвление на входе и распределение потоков.
Изменения внутри компании
Если осмотреться и взглянуть на весь процесс выполнения новых бизнес-требований, станет видно, что это лишь отчасти технологическая проблема. Нужно еще согласовывать требования и менять организационную структуру, и, согласно закону Конвея, для этой задачи нужна архитектура для технологий. Если команды и их коммуникации строятся на базе существующего решения и процессов, потребуется их реорганизация с помощью обратного закона Конвея, чтобы они соответствовали новым решениям и их архитектуре.
Legasy-системы могут постоянно ограничивать внедрение современных инженерных практик, особенно связанных с экстремальным программированием и непрерывной доставкой. При замене систем важно убедиться в изменении методов работы, чтобы не возвращаться к системе, которую сложно и дорого менять.
Существующие в компании технологии — результат корпоративной культуры и управления, и без масштабных изменений можно ожидать тех же результатов, что и раньше. Устаревшие попытки модернизации терпят неудачу из-за «корпоративных антител», которые нарочно отклоняют новые методы работы.
Понимание результатов
Задача, с которой столкнулась команда, заключалась в том, чтобы заменить промежуточное программное обеспечение интеграции на новое гибкое решение, не нарушая и не подвергая риску существующие процессы. Прежнее ПО не поддерживалось, дорого стоило, его было трудно изменить. Промежуточное ПО использовалось для интеграции между серверной системой и витриной магазина. Вместе эти системы отвечали за ежедневную продажу уникальных продуктов стоимостью в десятки миллионов фунтов стерлингов.
Работа была приоритетной составляющей более крупной программы. Произошла полная замена серверных систем, поддерживающих бизнес, и витрину магазина также нужно было обновить. Исходя из этого определили KPI:
Устранение проблемы: первый шов и рефакторинг
На начальном этапе команда провела семинар с сотрудниками, глубоко знакомыми с унаследованной системой, чтобы визуализировать архитектуру ПО. В процессе специалисты обнаружили технический шов, который можно было использовать в качестве интеграции в системе обмена сообщениями между устаревшим серверным интерфейсом и промежуточным программным обеспечением интеграции. Имеющийся бэкэнд — устаревшее приложение J2EE — помещал сообщения о публикации продукта в очередь, предоставляемую устаревшей версией SwiftMQ. Команда сделала вывод, что в таком случае будет полезен шаблон перехвата событий, и если он будет реализован как маршрутизатор на основе контента, он позволит управлять маршрутизацией сообщений от устаревшего внутреннего интерфейса и создать параметр, позволяющий внедрить сообщения в новые системы.
Промежуточное интеграционное ПО также обрабатывало сообщения, поступающие из интерфейса магазина, используя JDBC для непосредственного обновления состояния в основной базе данных за устаревшим серверным модулем. Асинхронный обмен сообщениями через SwiftMQ в сочетании с обновлениями базы данных JDBC сформировали интерфейс между Legacy Backend и Integration Middleware.
Команда смогла использовать шаблон Branch by Abstraction в масштабе подсистемы в качестве стратегии, позволяющей заменить устаревшее промежуточное ПО. Абстракция шла на уровне очередей и JDBC. Убедившись, что новая реализация придерживается этого уровня абстракции, специалисты заменили старое решение «несовершенного поставщика», не влияя на бизнес-операции.
Первым делом команда реализовала перехват событий, добавив маршрутизацию событий с помощью рефакторинга. Это удалось. Сыграла роль высокоуровневая обработка системы. Здесь уместно употребить термин «рефакторинг», поскольку структура системы изменилась без каких-либо заметных отклонений в поведении. Теперь при публикации продукта пользователем устаревшая серверная система по-прежнему помещает сообщение публикации в очередь SwiftMQ. Вместо того чтобы использовать промежуточное программное обеспечение интеграции, маршрутизатор событий принимал сообщение из этой очереди и ставит его в исходном виде в альтернативную очередь SwiftMQ. Промежуточное ПО интеграции потребляет сообщение из этой альтернативной очереди.
Также было необходимо создать возможность — исключать сообщения из одной очереди SwiftMQ и помещать их в другую очередь SwiftMQ. Несложное изменение конфигурации позволило промежуточному ПО получать сообщения из новой очереди. В целом рефакторинг оставил наблюдаемое поведение системы неизменным, но маршрутизатор событий теперь стал частью переходной архитектуры, вставленной в конвейер обработки сообщений.
Концепция маршрутизации событий заключалась в том, чтобы разрешить путём конфигурации маршрутизацию сообщений в альтернативный пункт назначения. Новая версия программы могла обрабатывать публикуемые сообщения. Для перехвата событий маршрутизатор обеспечил мост от старой технологии SwiftMQ к новой технологии ActiveMQ, выбранной для целевой архитектуры.
Реализация маршрутизатора событий была непростой. Интеграция со SwiftMQ затруднялась из-за отсутствия доступных драйверов и библиотек, и этот подход несколько раз ставили под сомнение. Но специалисты оценили открывающиеся возможности, завершили работу и запустили в производство. Команда наблюдала за новым компонентом в рабочих условиях и была настроена постепенно совершенствовать его с помощью новых конвейеров непрерывной доставки.
Новое внедрение
Следующей задачей команды стала работа над новым Store Front Manager. Сборка включала основной адаптер базы данных, реализующий шаблон Legacy Mimic. Это был элемент абстракции для обновления основной базы данных информацией о продажах, полученной от Store Front. Для преобразования сообщений в новый формат разработали адаптер устаревших событий, который не изменял старые события, но работал по принципам новой архитектуры. Legacy Storefront Adapter создали в качестве связующего звена между новым Store Front Manager и Legacy Store Front для защиты от изменений при замене онлайн-витрины магазина.
Новый API представили в Legacy Store Front, который использовал новый Store Front Manager. Также добавили функцию, которая отправляла обратные вызовы для продуктов, опубликованных в новом API, в новый адаптер Store Front Manager. Старую и новую версию можно было запускать параллельно.
Компания протестировала новое решение, осталось лишь развернуть его в режиме реального времени с учётом рисков. Для этого использовали другой шов — на этот раз шаблон «Сегментировать по продукту». Маршрутизатор событий усовершенствовали для добавления сортировки по типу продукта, а также по уникальным идентификаторам продукта. Специалисты могли протестировать публикацию, управление и продажу отдельных продуктов по идентификатору, а затем со временем настроить маршрутизатор на всё большее число типов продуктов. По мере обработки продуктов устаревшее ПО промежуточного слоя интеграции сняли с эксплуатации. В итоге сэкономили на лицензиях, поддержке и стоимости хостинга ЦОД.
На данном этапе основным методом оставалась высокоуровневая системная обработка. Для продуктов, направленных через новую систему, обработка теперь выглядела следующим образом. Сообщение публикации помещалось в очередь SwiftMQ. Маршрутизатор событий проверял содержание сообщения и производителя продукта и затем помещал это сообщение без изменений в очередь ActiveMQ. Адаптер устаревших событий преобразовал сообщение в бизнес-событие, соответствующее принципам целевой архитектуры. Приложение New Storefront Manager использовали для хранения собственного образа продукта и пересылки командного сообщения через очередь для его публикации. Устаревший адаптер витрины интернет-магазина использовал эту команду с дальнейшим вызовом нового API в старой версии витрины.
Пользователи теперь могли управлять тем, как продукты представлены на витрине.
При продаже продукта, сведения о котором были опубликованы через API v2, Legacy Store Front стал обращаться к API, предоставляемому Legacy Storefront Adapter с дальнейшим преобразованием вызова в бизнес-событие и размещением его в очередь ActiveMQ. События использовались в новом диспетчере витрины и главном адаптере базы данных. Новый менеджер витрины обновлял внутренний статус состояния продукта, а адаптер основной базы данных обновлял устаревшую основную базу данных с информацией о продажах.
Изменения внутри организации
Команды специалистов уже взаимодействовали с клиентами в другом подразделении той же организации, где успешно заменили другую устаревшую систему.
На инженерном уровне непрерывная доставка и методы поддержки качества стали нормой, а микросервисная архитектура позволила регулярно и независимо развёртывать контейнеры на облачной платформе.
Команды, ответственные за новую программу, продвигали другую часть бизнеса по тому же пути «Agile и CD», потому что им доверяли после успешных предыдущих релизов. Новые методы проектирования и обеспечения качества, в том числе CD, привели к снижению рисков, связанных с бюрократизацией. Редкие релизы с широким охватом заменили на мелкие, частые и надёжные развёртывания.
Наблюдения и результаты
Конечно, история вышла упрощённой. Пример археологии возник вскоре после тестирования в производственной среде. Некоторые важные отчёты об управленческой деятельности не соответствовали друг другу — продукты «терялись».
После долгих поисков команда обнаружила, что база данных, которую использовало промежуточное интеграционное ПО (для хранения состояния длительных бизнес-транзакций), была скопирована в хранилище данных организации. Благодаря ряду пакетных заданий, хранимых процедур и представлений эти данные получилось использовать в отчётах.
Требовались дополнительные имитации, чтобы эти отчёты не нарушались. Специалисты использовали прослушивание сообщений о продажах, поступающих из Store Front, и с помощью JDBC внедряли данные в соответствующие таблицы в хранилище. Эти дополнительные имитаторы также стали частью переходной архитектуры — их можно было удалить.
habr.com
Смена технологий: шаг за шагом
Многие организации пытаются заменить устаревшие системы, иногда в течение 3-5 лет. Каждый раз всё начинается с определения технологического подхода, над которым потом работают в рамках большой многолетней программы модернизации. Потом эта программа заходит в тупик, потому что потребности бизнеса опережают технологическую стратегию и, следовательно, приходится начать всё сначала. Использование постепенного, «водопадного» подхода к программе больших преобразований означает, что часть работы идёт насмарку. Иногда используют и другой подход: в существующую архитектуру привносят часть новых технологий. В обоих сценариях не получается ни списать полностью устаревшие версии, ни удовлетворить ключевые бизнес-цели по экономии затрат и снижению рисков.Почему так получается?
- Во-первых, неудовлетворительные результаты — это следствие недостатков в работе самой организации. Руководители компаний часто ошибочно думают, что если на старую систему наложить новые технологии, то компания получит новый результат. А это не так.
- Во-вторых, для любой модернизации нужна большая программа изменений с серией отдельных проектов и команд. Эти проекты напрямую противоречат концепции BAU (Business As-Usual, обычного хода деятельности). Обычный ход вещей предполагает выполнение бизнес-требований с существующими системами, в то время как новым проектным группам в начале работы задают новый набор требований. Разрыв между тем, что на самом деле нужно бизнесу, и тем, что было согласовано в начале программы, увеличивается. Хотя существуют системы контроля изменений, на работу с ними уходит много времени, а из-за уже подписанных контрактов с поставщиками — ещё и много денег.
- Третья причина неудач — стремление обеспечить функциональное равновесие с уже имеющимся набором систем и бизнес-процессов. Всё начинается с обещания дать бизнесу именно то, что у него есть сегодня, параллельно с некоторым неопределённым «улучшением» технологий. Но даже определить и согласовать текущую функциональность «как есть» — невероятно трудоёмкая и долговременная работа, а новые системы приходится внедрять по модели «большого взрыва».
Выход из замкнутого круга
Организациям нужно удовлетворять потребности бизнеса, одновременно заменяя устаревшие технологии, и всё это на фоне ускоряющихся технологических изменений и более жёсткой конкурентной среды.Опишем ряд подходов, которые могут помочь. Они помогают разбить проблему на более мелкие части, чтобы удовлетворить новые требования параллельно с совершенствованием технологий. Подходы условно делятся на четыре категории:
- понимание результатов, которых вы хотите достичь;
- деление проблемы на составные части (этапы);
- внедрение каждого этапа;
- изменения внутри организации, чтобы внедрить всё на постоянной основе.
Понимание результатов
Для организации жизненно важно согласовать результаты, которых нужно достичь после преобразований. Звучит очевидно, но слишком часто у подразделений компании бывают совершенно разные взгляды на желаемые результаты. Большинство инициатив по модернизации включают несколько составляющих (мы перечислим их ниже), поэтому важно определить, какие из них являются приоритетными.Оптимизация затрат
Ключевой момент для решения о переходе с устаревших технологий — деньги. Изменения в бизнесе могут обойтись намного дороже, чем любые ожидаемые плюсы: либо из-за упущенной выгоды, либо из-за стоимости внедрения. Один из первых звоночков — необходимость потратить время и деньги, чтобы внести изменения, которые лишь чуть-чуть повысят эффективность бизнеса.
На этом этапе часто уже невозможно обосновать изменения, не обеспечивающие большой отдачи от инвестиций. Другими словами, состояние технологий диктует масштабы изменений, которые потянет бизнес. Для многих организаций это означает разницу между внесением изменений в привычный ход вещей или необходимостью инициировать более крупный проект. Эти более крупные проекты затем становятся основой для небольших изменений, которые ранее не были учтены, что увеличивает их объём, стоимость и риски.
Совершенствование бизнес-процессов
Любые процессы оказываются тесно связаны с работой системы в условиях ограничений, и часто обходные пути за её пределами формируют бизнес-процессы.
Один из наглядных примеров — система регистрации на рейс в одной из авиакомпаний, в которой использовались терминалы с «зелёным экраном». Из-за ограничений, связанных с устаревшей системой, весь процесс выполняли по чёткому регламенту. Исправления или ошибки приводили к повторному запуску процесса регистрации. Также изначально авиакомпания не предлагала стыковочные рейсы, но затем добавила опцию и дополнительный рабочий процесс в устаревшей системе. Следовательно, если при регистрации пассажир не указывал, что у него стыковка, система сначала выдавала неправильный процесс с печатью неправильных багажных бирок и только после этого переключалась на нормальный процесс. Рабочие места персонала стойки регистрации и обслуживание пассажиров можно было улучшить, внеся изменения в процессы. Но это было невозможно из-за устаревшей версии системы.
К примеру, в одной организации весь процесс заказа товаров фактически выполнялся в базе данных Microsoft Access, работающей на компьютерах руководителей подразделений. Устаревшая система не могла поддерживать новые технологии работы поставщиков. Импорт и экспорт данных выполнялся несколько раз в неделю. Большая часть организации видела лишь устаревшие цифры, и никто не понимал, что происходит.
Здесь стоит отметить, что требования к заменяющей системе для поддержки импорта и экспорта данных часто могут исходить из подобного обходного пути.
Вывод старой системы
Необходимость вывода старой системы из эксплуатации — распространённая причина модернизации. Это часто вызвано проблемами с поддержкой устаревшего оборудования или программного обеспечения: рост затрат, истечение контрактов на поддержку как для оборудования, так и для программного обеспечения.
Некоторые организации строят чёткие планы по выведению из эксплуатации старых технологий, но большинство игнорирует этот вопрос, пока он не достигнет критической точки. В свою очередь, критические ситуации побуждают компании выбирать варианты модернизации с минимальным прерыванием работы или быстрым выигрышем. Обычно это антипаттерны.
Удивительно, что как много крупных организаций работают на уже не поддерживаемом оборудовании и программном обеспечении. Покупка комплектующих на eBay — на редкость распространённая история. Если вы эксплуатируете устаревшие технологии, стоит провести ревизию и создать календарь, обозначив в нём сроки окончания поддержки.
Неминуемый сбой
Для некоторых организаций переломный момент обусловлен внешними факторами: изменением нормативных требований, появлением нового «начинающего» конкурента или ростом уже существующих. В таком случае обновление требует больших временных и финансовых затрат.
Новые технологии
Сами по себе нововведения редко является ключевой целью организации. Они должны отвечать текущим и будущим потребностям бизнеса. Проблема в том, что технологии меняются всё быстрее, а «полезный» срок их службы сокращается. Фактическое определение «полезного» зависит от компании, но в целом при внедрении любых новшеств необходимо учитывать ряд параметров:
- конкурентные преимущества;
- соответствие предложениям конкурентов или рынка;
- скорость изменений;
- сокращение затрат на изменения;
- низкая стоимость эксплуатации.
Оптимальный подход — переходить на технологии с постепенным внедрением за 2-3 года. Трудно обосновать выбор огромной платформы со сроком окупаемости 5–10 лет, если мы признаём ускоряющиеся темпы изменений.
Решаем, как разбить проблему на более мелкие этапы
Эта работа включает в себя поиск правильных «швов» в существующей архитектуре технологических и бизнес-процессов. Вы обязательно должны учитывать, как элементы текущего решения соотносятся с различными возможностями бизнеса. Для уже имеющихся систем это обычно выглядит так: одно крупное техническое решение отвечает множеству бизнес-потребностей, и необходимо выяснить, можно ли выделить проблемы и справляться с ними изолированно. В идеале задачи должны решаться с минимальной зависимостью друг от друга.Люди не видят, что ждёт их впереди, следовательно, не представляют, в каком направлении двигаться. Поэтому первый шаг — хорошенько осмотреться, как можно быстрее и как можно более глубокого понять состояние имеющихся систем и архитектуры. Часто это очень сложно сделать, так как легко увязнуть в деталях.
К счастью, есть ряд полезных инструментов. К ним относятся event storming, карты Уордли (Wardley mapping). Стоит обратить внимание на то, как бизнес-концепции отображаются в архитектуре системы, и понять, как эта архитектура поддерживает создание того или иного продукта.
Зачастую специалисты не изучают возможности за пределами существующих систем и никак не двигаются за их рамки. Также часто упускают из виду такой ценный источник информации, как сами пользователи систем.
Кроме того, пользователи могут показать обратную сторону IT-экосистемы, которая обычно строится вокруг старых систем, то есть базы данных Access и таблицы Excel с поддержкой версий для ведения бизнеса. Составление дорожной карты клиента, создание схемы обслуживания и карт потока создания ценности — вот инструменты, которые выявляют такие детали.
Непрерывная доставка
Необходимость быстрых изменений и возможности независимо друг от друга менять элементы бизнеса приводит к появлению гибких подходов с архитектурой на основе микросервисов. Непрерывная доставка становится обязательной. Для неё существует несколько работающих стратегий, в том числе параллельный запуск, разветвление на входе и распределение потоков.
Изменения внутри компании
Если осмотреться и взглянуть на весь процесс выполнения новых бизнес-требований, станет видно, что это лишь отчасти технологическая проблема. Нужно еще согласовывать требования и менять организационную структуру, и, согласно закону Конвея, для этой задачи нужна архитектура для технологий. Если команды и их коммуникации строятся на базе существующего решения и процессов, потребуется их реорганизация с помощью обратного закона Конвея, чтобы они соответствовали новым решениям и их архитектуре.
Legasy-системы могут постоянно ограничивать внедрение современных инженерных практик, особенно связанных с экстремальным программированием и непрерывной доставкой. При замене систем важно убедиться в изменении методов работы, чтобы не возвращаться к системе, которую сложно и дорого менять.
Существующие в компании технологии — результат корпоративной культуры и управления, и без масштабных изменений можно ожидать тех же результатов, что и раньше. Устаревшие попытки модернизации терпят неудачу из-за «корпоративных антител», которые нарочно отклоняют новые методы работы.
Лишь немногие организации могут позволить себе отложить модернизацию устаревших систем, пока они дорабатывают организационную структуру и бизнес-процессы. Но если вы просто измените технологии и не сделаете ничего другого, скорее всего, через пару лет снова придётся делать то же самое.
А теперь пример: шаблон организационных изменений
Одна из команд использовала ряд устаревших шаблонов модернизации для замены интеграционного промежуточного программного обеспечения, критически важного для работы бизнеса клиентов, в рамках крупной программы модернизации. Они объединили шаблоны и рефакторинг для успешного управления рисками для бизнеса и облегчения этого сложного этапа.Понимание результатов
Задача, с которой столкнулась команда, заключалась в том, чтобы заменить промежуточное программное обеспечение интеграции на новое гибкое решение, не нарушая и не подвергая риску существующие процессы. Прежнее ПО не поддерживалось, дорого стоило, его было трудно изменить. Промежуточное ПО использовалось для интеграции между серверной системой и витриной магазина. Вместе эти системы отвечали за ежедневную продажу уникальных продуктов стоимостью в десятки миллионов фунтов стерлингов.
Работа была приоритетной составляющей более крупной программы. Произошла полная замена серверных систем, поддерживающих бизнес, и витрину магазина также нужно было обновить. Исходя из этого определили KPI:
- Улучшение бизнес-процессов. Промежуточное ПО во многом было основано на логике. В неё входили правила, лежащие в основе бизнеса: по какому каналу продавать продукт, как и когда представить его на витрине. Существующую систему было очень трудно изменить, чтобы что-то поменять в бизнесе, а ошибки в логике приводили к проблемам наподобие перебоев с поставками продуктов.
- Оперативное удаление старой системы. Прежнюю систему необходимо было удалить, чтобы сократить затраты на лицензию и поддержку. Кроме того, это снижало риски для бизнеса, связанного с работой критически важных функций на устаревшем промежуточном ПО и базах данных.
Устранение проблемы: первый шов и рефакторинг
На начальном этапе команда провела семинар с сотрудниками, глубоко знакомыми с унаследованной системой, чтобы визуализировать архитектуру ПО. В процессе специалисты обнаружили технический шов, который можно было использовать в качестве интеграции в системе обмена сообщениями между устаревшим серверным интерфейсом и промежуточным программным обеспечением интеграции. Имеющийся бэкэнд — устаревшее приложение J2EE — помещал сообщения о публикации продукта в очередь, предоставляемую устаревшей версией SwiftMQ. Команда сделала вывод, что в таком случае будет полезен шаблон перехвата событий, и если он будет реализован как маршрутизатор на основе контента, он позволит управлять маршрутизацией сообщений от устаревшего внутреннего интерфейса и создать параметр, позволяющий внедрить сообщения в новые системы.
Промежуточное интеграционное ПО также обрабатывало сообщения, поступающие из интерфейса магазина, используя JDBC для непосредственного обновления состояния в основной базе данных за устаревшим серверным модулем. Асинхронный обмен сообщениями через SwiftMQ в сочетании с обновлениями базы данных JDBC сформировали интерфейс между Legacy Backend и Integration Middleware.
Команда смогла использовать шаблон Branch by Abstraction в масштабе подсистемы в качестве стратегии, позволяющей заменить устаревшее промежуточное ПО. Абстракция шла на уровне очередей и JDBC. Убедившись, что новая реализация придерживается этого уровня абстракции, специалисты заменили старое решение «несовершенного поставщика», не влияя на бизнес-операции.
Первым делом команда реализовала перехват событий, добавив маршрутизацию событий с помощью рефакторинга. Это удалось. Сыграла роль высокоуровневая обработка системы. Здесь уместно употребить термин «рефакторинг», поскольку структура системы изменилась без каких-либо заметных отклонений в поведении. Теперь при публикации продукта пользователем устаревшая серверная система по-прежнему помещает сообщение публикации в очередь SwiftMQ. Вместо того чтобы использовать промежуточное программное обеспечение интеграции, маршрутизатор событий принимал сообщение из этой очереди и ставит его в исходном виде в альтернативную очередь SwiftMQ. Промежуточное ПО интеграции потребляет сообщение из этой альтернативной очереди.
Также было необходимо создать возможность — исключать сообщения из одной очереди SwiftMQ и помещать их в другую очередь SwiftMQ. Несложное изменение конфигурации позволило промежуточному ПО получать сообщения из новой очереди. В целом рефакторинг оставил наблюдаемое поведение системы неизменным, но маршрутизатор событий теперь стал частью переходной архитектуры, вставленной в конвейер обработки сообщений.
Концепция маршрутизации событий заключалась в том, чтобы разрешить путём конфигурации маршрутизацию сообщений в альтернативный пункт назначения. Новая версия программы могла обрабатывать публикуемые сообщения. Для перехвата событий маршрутизатор обеспечил мост от старой технологии SwiftMQ к новой технологии ActiveMQ, выбранной для целевой архитектуры.
Реализация маршрутизатора событий была непростой. Интеграция со SwiftMQ затруднялась из-за отсутствия доступных драйверов и библиотек, и этот подход несколько раз ставили под сомнение. Но специалисты оценили открывающиеся возможности, завершили работу и запустили в производство. Команда наблюдала за новым компонентом в рабочих условиях и была настроена постепенно совершенствовать его с помощью новых конвейеров непрерывной доставки.
Новое внедрение
Следующей задачей команды стала работа над новым Store Front Manager. Сборка включала основной адаптер базы данных, реализующий шаблон Legacy Mimic. Это был элемент абстракции для обновления основной базы данных информацией о продажах, полученной от Store Front. Для преобразования сообщений в новый формат разработали адаптер устаревших событий, который не изменял старые события, но работал по принципам новой архитектуры. Legacy Storefront Adapter создали в качестве связующего звена между новым Store Front Manager и Legacy Store Front для защиты от изменений при замене онлайн-витрины магазина.
Новый API представили в Legacy Store Front, который использовал новый Store Front Manager. Также добавили функцию, которая отправляла обратные вызовы для продуктов, опубликованных в новом API, в новый адаптер Store Front Manager. Старую и новую версию можно было запускать параллельно.
Компания протестировала новое решение, осталось лишь развернуть его в режиме реального времени с учётом рисков. Для этого использовали другой шов — на этот раз шаблон «Сегментировать по продукту». Маршрутизатор событий усовершенствовали для добавления сортировки по типу продукта, а также по уникальным идентификаторам продукта. Специалисты могли протестировать публикацию, управление и продажу отдельных продуктов по идентификатору, а затем со временем настроить маршрутизатор на всё большее число типов продуктов. По мере обработки продуктов устаревшее ПО промежуточного слоя интеграции сняли с эксплуатации. В итоге сэкономили на лицензиях, поддержке и стоимости хостинга ЦОД.
На данном этапе основным методом оставалась высокоуровневая системная обработка. Для продуктов, направленных через новую систему, обработка теперь выглядела следующим образом. Сообщение публикации помещалось в очередь SwiftMQ. Маршрутизатор событий проверял содержание сообщения и производителя продукта и затем помещал это сообщение без изменений в очередь ActiveMQ. Адаптер устаревших событий преобразовал сообщение в бизнес-событие, соответствующее принципам целевой архитектуры. Приложение New Storefront Manager использовали для хранения собственного образа продукта и пересылки командного сообщения через очередь для его публикации. Устаревший адаптер витрины интернет-магазина использовал эту команду с дальнейшим вызовом нового API в старой версии витрины.
Пользователи теперь могли управлять тем, как продукты представлены на витрине.
При продаже продукта, сведения о котором были опубликованы через API v2, Legacy Store Front стал обращаться к API, предоставляемому Legacy Storefront Adapter с дальнейшим преобразованием вызова в бизнес-событие и размещением его в очередь ActiveMQ. События использовались в новом диспетчере витрины и главном адаптере базы данных. Новый менеджер витрины обновлял внутренний статус состояния продукта, а адаптер основной базы данных обновлял устаревшую основную базу данных с информацией о продажах.
Изменения внутри организации
Команды специалистов уже взаимодействовали с клиентами в другом подразделении той же организации, где успешно заменили другую устаревшую систему.
На инженерном уровне непрерывная доставка и методы поддержки качества стали нормой, а микросервисная архитектура позволила регулярно и независимо развёртывать контейнеры на облачной платформе.
Команды, ответственные за новую программу, продвигали другую часть бизнеса по тому же пути «Agile и CD», потому что им доверяли после успешных предыдущих релизов. Новые методы проектирования и обеспечения качества, в том числе CD, привели к снижению рисков, связанных с бюрократизацией. Редкие релизы с широким охватом заменили на мелкие, частые и надёжные развёртывания.
Наблюдения и результаты
Конечно, история вышла упрощённой. Пример археологии возник вскоре после тестирования в производственной среде. Некоторые важные отчёты об управленческой деятельности не соответствовали друг другу — продукты «терялись».
После долгих поисков команда обнаружила, что база данных, которую использовало промежуточное интеграционное ПО (для хранения состояния длительных бизнес-транзакций), была скопирована в хранилище данных организации. Благодаря ряду пакетных заданий, хранимых процедур и представлений эти данные получилось использовать в отчётах.
Требовались дополнительные имитации, чтобы эти отчёты не нарушались. Специалисты использовали прослушивание сообщений о продажах, поступающих из Store Front, и с помощью JDBC внедряли данные в соответствующие таблицы в хранилище. Эти дополнительные имитаторы также стали частью переходной архитектуры — их можно было удалить.
- Подход «ветвление за счёт абстракции» и использование шаблонов и практик помогли снизить риски.
- Использование перехвата событий (что можно трактовать как технический шов), устаревшей имитации и переходной архитектуры позволило клиенту устранить проблему.
- Сегментирование по продуктам (бизнес-шов) позволило точнее контролировать более широкое распространение и дальнейшее управление рисками.
- Общий подход позволил бизнесу продолжить замену системы в удобном для них темпе.
Меняем старый софт на новый: как не зайти в тупик?
В большой и детальной статье под катом — опыт последних двух десятилетий по перестройке устаревших систем в крупных компаниях: что работает, а что ведёт к неудачам, и какие шаблоны можно и нужно...
habr.com