Изнанка архитектуры, или Менять нельзя оставить

Около десяти лет назад мы в CUSTIS реализовали систему распределения товара для «Спортмастера». Со времени ее запуска изменилось многое: корректировались цели заказчика, менялись возможности и потребности рынка, появились новые способы автоматизации. Но на протяжении всех этих лет система дорабатывалась, поддерживалась и настраивалась нами, чтобы оставаться максимально удобной и эффективной для заказчика.

В этой статье мы расскажем о себе, заказчике, системе и требуемых доработках. И о том, почему мы выбрали именно тот подход к проектированию архитектуры, который применили. И почему наше решение было оптимальным.

В какой-то момент в компании «Спортмастер» возникла потребность на доработку одной из частей системы, но объем этой доработки был уже чуть больше среднего и с некоторым переосмыслением базовых понятий.

Перед нами возникла дилемма: как выполнить доработку «красиво»? Сделать быстро и дешево на существующем технологическом стеке, на котором реализовали систему десять лет назад? Или на более современном, внедрение которого будет идти долго и дорого?

Нужно было понять, оценить, обосновать плюсы и минусы обоих подходов. Нам не хотелось отталкиваться от сиюминутной выгоды и сворачивать на проторенную дорожку. Важно было учесть перспективу разных архитектурных решений на последующем жизненном цикле системы, дальнейший путь ее развития и модернизации.

При этом конкретика бизнес-задач в данном случае была менее важна, чем общие характеристики системы. Такие, как длительность эксплуатации, стоимость владения, количество доработок, заложенных в модель развития, скорость устаревания технологического стека, последствия этого устаревания и т. п.

Нам хочется поговорить о том, почему в общем-то стандартная задача по выбору архитектуры и технологического стека для модернизации успешно работающей долгое время системы является достаточно яркой и интересной. И почему это противоречие между «старым» и «новым» в нашем случае так критично и напряженно.

Действующие лица

Мы — это разработчики ПО из ИТ-компании CUSTIS. Работаем над созданием и сопровождением систем автоматизации бизнеса для его ведения и развития.

Бизнес-заказчик описываемых ниже проектов — компания «Спортмастер», крупный ритейлер, который управляет сетью магазинов спортивных товаров.

Фасилитатор нашей коммуникации с бизнес-заказчиком — ИТ-департамент «Спортмастера» Sportmaster Lab.

Контекст

В текущей концепции в «Спортмастере» товародвижением управляют одновременно несколько систем, для каждой отдельной области бизнеса — своя. Есть специализированная система, которая с необходимой степенью подробности реализует управление товарным запасом, учитывая основные бизнес-процессы. Управленческий товарный учет конвертируется в бухгалтерский при помощи сторонней системы «АИСТ».

Ниже схематично показали, как ведется более подробный товарный учет для бизнес-потребностей конкретных департаментов «Спортмастера». Это отдельные специализированные системы (на рисунке — красная граница), а также отображение товарного запаса в проекции на бухгалтерский учет. Товарный запас внутри красной и черной границ эквивалентен.

Внутри красной границы системы не имеют общих остатков, товар «перетекает» из системы в систему. Мы прозвали такую схему «гамбургером», она была спроектирована совместно архитекторами «Спортмастера» и CUSTIS.

Рассматриваемая сегодня система называется «Модуль распределения товаров» (МРТ). Роль МРТ в этом «гамбургере» особая: модуль может управлять всем товаром «Спортмастера». Поэтому в нем отражается учет товара из специализированных систем, а также ведется учет и управление тем товаром, для которого еще не определен владелец — новым, общим. А в случае, когда нет специализированной системы, способной управлять таким товаром наиболее подходящим бизнесу способом, МРТ распределяет и их.

Процедуры работы в «Спортмастере» с товаром на внешней и внутренней цепях поставок существенно различаются. Доставка товара от поставщиков до распределительных центров ведется по-крупному: контейнерами, вагонами и пр. Дальнейшее движение товара по внутренней цепи — намного более подробно: коробками и штуками.

Основные, но не единственные, процессы в МРТ — заранее распланировать ожидаемый к приходу с внешней цепи от поставщика товар, «поймать» его при поступлении. А дальше, сверившись с планами, распределить этот товар тому владельцу во внутренней цепи поставок, который его ожидает. Конечно, распределение носит виртуальный характер, существует только в системе: физически товар едет в контейнерах или лежит на складе, коробка к коробке.

МРТ — далеко не единственная система, разработкой и сопровождением которой мы занимаемся в «Спортмастере». Таких систем много, а необходимость в их развитии, модернизации и доработке есть всегда. Почему же для демонстрации ситуации и подхода к ее разрешению взяли именно пример по модернизации МРТ?

Ответ кроется в сроке эксплуатации системы и в тех архитектурных решениях, которые были
заложены при ее разработке. Они позволяют рассматривать ситуацию с системой
МРТ по ее модернизации как ярко выраженную, «черно-белую», почти без оттенков. Новый
стек против старого, Инь и Ян.

«Идеальная» архитектура

Архитектуру системы МРТ можно во многом назвать «идеальной». Говоря так, мы в первую очередь имеем в виду функциональную архитектуру с точки зрения ее использования на долгом жизненном цикле системы. При этом учитываются постоянные модернизации и доработки в рамках ее целевого предназначения.

Так получилось потому, что архитектурная модель сразу разрабатывалась в предположении, что система должна будет «вбирать» в себя новые возникающие разделы товарного учета — территориальный, номенклатурный, логистический и процессный. Например, появление и вывод торговых марок и брендов с их спецификой дистрибуции.

На основе нашего опыта эксплуатации систем-предшественников мы придумали и реализовали специализированные, но достаточно общие понятия и механизмы, которые в рамках описанного скоупа позволили выполнить настраиваемую декларативную модель работы с предметной областью.

Это помогло решить две задачи на длинном жизненном цикле:

снизить стоимость владения;
снизить (а зачастую свести просто к настройкам) стоимость модернизации и доработок.

Архитектурные модели

Основные составляющие архитектурной модели МРТ:

МРТ состоит из нескольких настраиваемых слоев:

Документы как интерфейс пользователя к операционному слою и как единица работы (создания, редактирования, удаления) пользователя. Их можно назвать «простыми», так как они построены на технологии zero-code.
Операционный слой — история действий над документами, сбор необходимых атрибутов товарных запасов и приведение их «плоский» вид для отражения проводками в учете. Переход документов по состояниям порождают операции. На диаграмме плана счетов (в нашем жаргоне — «Ромашка») тип операции соответствует стрелке перемещения товарных запасов с одного учетного регистра на другой:

• О нотации и методике, используемых для описания решения учетных задач, рассказывали несколько раз, например <a href="http://lib.custis.ru/Диаграммы_планов_счетов_(Максим_Цепков,_ЛАФ-2010)">в этом докладе</a>.</p>" data-abbr="План счетов МРТ">План счетов МРТ («Ромашка») — модель иерархии товарных запасов и их отражения в учете;
• «Карточка ИНФО» — основной инструмент для пользователя, чтобы получить общую информацию по операциям, проводкам и товарным остаткам. Это позволяет визуализировать и проверить причины изменения данных, объяснить остаток на учетных регистрах.
Учетная Машина — слой учета:

• Автоматическое отражение проводок в собственный и другие внешние учеты (сводный товарный учет, бухгалтерский). То есть отображение факта изменения учетного регистра.

«Простой» документ сразу работает консистентно по всей вертикали слоев архитектуры МРТ и даже отражается во внешнем корпоративном учете. Всё за счет настроек, ни единой строки кода — zero-code в действии.

В результате мы получаем настраиваемость, обслуживаемость, малую стоимость владения, небольшую стоимость доработок.

«Неидеальные» технологии

За 10 лет эксплуатации МРТ в мире произошло многое, а в ИТ-индустрии — еще больше. Появились новые технологии, новые средства разработки и новые подходы к разработке.

Не секрет, что даже самые замечательные, архитектурно продуманные системы со временем требуют реинжиниринга просто потому, что использованный технологический стек, на котором они разрабатывались и эксплуатируются, критически устарел.

Критическое устаревание происходит тогда, когда технологический стек перестает поддерживаться производителем ПО. И даже не остается возможности мигрировать на новые версии ПО из технологического стека — попросту потому, что ПО перестает развиваться и поддерживаться совсем.

Деградация технологического стека купируется переводом системы на новейшие версии ПО лишь частично. После достаточно длительного периода такой деградации конец всегда один: моральное и технологическое устаревание инструментов достигает такой степени, что систему становится невозможно, либо крайне дорого поддерживать, не говоря уже ее развитии и доработках.

Еще один фактор устаревания — исчезновение на рынке труда специалистов, которые видят свое профессиональное развитие в работе с этими устаревшими инструментами разработки.

Решающим фактором для нас стало устаревание собственного инфраструктурного фреймворка. Мы разработали его пятнадцать лет назад, когда в отрасли было мало подобных развитых инструментов. Он был необходим, но даже тогда требовал отдельной команды для поддержки и развития. В период бурного развития продуктов, построенных на нем, это было оправданно.

Однако со временем развитие фреймворка прекратилось, и поддержку передали в команды разработки продуктов. Произошло это и потому, что рыночные инструменты обогнали наш: новые продукты использовали более популярные на рынке технологии, которые доросли до промышленного использования.

Поэтому возможность расширить используемый технологический стек, осуществлять развитие и доработки в рамках более нового, безусловно важны для долгоживущих систем, которые не устаревают морально и не нуждаются в полном реинжиниринге из-за их функциональной пригодности для бизнеса.

Визуально это отражает график жизненного цикла технологии:

В момент выбора технологии реализации — это уже растущая или устоявшаяся новая технология, популярность и область применения которой увеличиваются. Поэтому со временем стоимость и риски использования падают. Но появляются другие технологии, более новые, которые вытесняю выбранную, и потому риски со стоимостью начинают возрастать, достигая критической величины. Это заставляет выбирать новые технологии исполнения, в том числе и для доработок систем, реализованных в старых технологиях.

Развитие

Новые потребности

Исторически механизм распределения товара по получателям использовался в разных системах. Основной («в крупном») был в МРТ, в других системах действовали свои локальные механизмы «дораспределения» в специфичных для системы терминах, то есть более детальных аналитических разрезах. Это было нормально, пока не оказалось, что поток товара на внешних цепях должен учитываться при всех распределениях.

Хорошей идеей стала централизация распределения товаров, выделение в терминах ArchiMate 3, application service. Сервис позволяет вести распределение в достаточно детальных аналитиках, разрезах или измерениях для каждого из потребителей, ведь каждый имеет собственную специфику и терминологию. Маппинг обобщенных терминов сервиса и частных специфичных терминов потребителя остается за потребителем.

Так и решили. Но остался другой вопрос: должен ли общий механизм распределения быть частью МРТ, предоставляемый внешнему миру как сервис? Или же это отдельная система с самостоятельным жизненным циклом? Если отдельная система — делать ли ее на старом технологическом стеке, либо выбрать новый?

Архитектурные драйверы

Изменение модели объектов логики распределения, чтобы быть достаточно универсальной, пригодной для различных потребителей сервиса
Производительность распределения
Высокая готовность
Возможность исправления ошибок, изменения поведения системы силами инженера по сопровождению
Реализация в сжатые сроки (два месяца)

Дилемма

Что ж, какие вводные, последствия того или иного выбора здесь имелись? Очевидно, мы находились на архитектурной развилке: избрав тот или иной путь, мы переходим к системе, которая сказывается на других архитектурных решениях.

В контексте разговора о нашей проблеме вспомним определения архитектуры, предложенные еще 20 лет назад. Это дискуссия Мартина Фаулера с Ральфом Джонсоном, которые рассматривали такие формулировки архитектуры, как «проектные решения, которые вы хотели бы принять как можно раньше», «всё важное», «то, что сложно изменить».

В 2014-м наш коллега Игорь Беспальчук описывал концепцию дерева архитектурных решений. Она заключалась в том, что одни архитектурные решения зависят от других (и даже существуют только в контексте «родительских», более ранних решений), и такие зависимости можно изобразить в виде дерева.

Два этих суждения породили прототип нашего замысла. Он строится на трех вопросах, которые и задают ствол дерева архитектурных решений:

*Основные вопросы для дерева архитектурных решений*

Конечно, можно было быстро накидать аргументов «за» и «против» по каждому из трех вопросов. Главная опасность «быстрого» подхода — что-нибудь забыть. Да и одного только ощущения, что наш стек находится в своем жизненном цикле на спаде, недостаточно.

Поэтому мы поступили иначе: каждый вопрос рассматривался с позиций влияния на атрибуты качества архитектуры. Перебирая список общепринятых атрибутов качества (или хотя бы крупных категорий атрибутов), мы задавались вопросом, как это повлияет на наше решение. Ведь чеклист для стандартной, но сложной, многошаговой процедуры еще никому не помешал. (Только посмотрите на историю в больнице имени Джона Хопкинса из книги Герда Гигеренцера.)

В рамках статьи ответим только на первые два вопроса.

Ниже приведены атрибуты качества по ISO/IEC 25010 (ГОСТ Р ИСО/МЭК 25010-2015), в самом стандарте они называются характеристиками:

Вопросы о функционале (В1: внутри МРТ или нет?) и базовых технологиях (В2: те же или новые?) влияют на потенциальные архитектурные решения. Мы собрали наши рассуждения о влиянии на атрибуты качества, записали все плюсы-минусы, риски и последствия. Ответы на В1 и В2 позже помогли нам решить, каким же станет будущее решение.

Некоторые наименования атрибутов качества (характеристик) мы перевели по-другому. Там, где нет аргументов о влиянии ответов В1, В2 на качество, стоит прочерк.

Функциональная пригодность → Полнота, корректность, целесообразность

Уровень производительности → Временные характеристики, использование ресурсов, потенциальные возможности

Совместимость → Сосуществование, интероперабельность

Удобство использования → Пригодность, изучаемость, управляемость, защищенность от ошибки, эстетика, доступность с ограниченными возможностями

Надежность → Зрелость, готовность, отказоустойчивость, восстанавливаемость

Защищенность → Конфиденциальность, целостность, неподдельность, отслеживаемость, подлинность

Сопровождаемость → Модульность

Сопровождаемость → Переиспользование

Сопровождаемость → Анализируемость

Сопровождаемость → Модифицируемость

Сопровождаемость → Тестируемость

Переносимость → Адаптируемость, устанавливаемость, взаимозаменяемость

Документ бизнес-требований (BRD) является отправной точкой для любого программного проекта или бизнес-решения. Благодаря такому документу члены команды приходят к единому мнению о том, что нужно созда...

OSINT & Hacking — как работает фишинг для нельзяграма

Взлом Instagram*‑аккаунта — популярный запрос в поисковиках. Поэтому есть смысл рассказать о том, как это обычно работает. Просто для того, чтобы вы знали, откуда может пойти атака...

Почему нельзя найти универсальный сеттинг, который понравится всем

Сеттинг — один из важнейших факторов успеха игры. Узнали у Владимира Семыкина, автора направления «Геймдизайн» в Нетологии, почему важно выбрать правильный сеттинг, чем о...

Если программист не хочет ничего менять — оставьте его в покое! Для чего разработчику нужен ментор

В Европе и США менторство и коучинг давно стали частью жизни. В российском IT наставничество только набирает обороты. Обсудили с Георгием Могелашвили glamcod...

Ирландия: как IT-эмигранту поменять работу

Принимая решения о переезде в ту или иную страну или город, приходится делать выбор. Чаще всего это конечно выбор “ехать” или “не ехать”, но более удачливым приходится выбирать и из...