Команда Spring АйО подготовила перевод статьи о том, почему архитектурный долг — это гораздо больше, чем кривой код или устаревшие паттерны. Автор показывает, как ошибки на уровнях приложений, бизнеса и стратегии усиливают друг друга и превращаются в системные риски.
Когда я был разработчиком, половина раздражающих моментов была связана с техническим долгом (вторая половина — с оценками, которые принимают за жёсткие дедлайны).
Мы всегда различали долговые обязательства в коде и архитектурный долг: технический долг — это временные хаки, которые ты делаешь, чтобы уложиться в срок, и потом никогда не убираешь; архитектурный — это структурные решения, которые возвращаются и кусают тебя через полгода.
Да, внедрение таких шаблонов, как strangler pattern, или отказ от синглтонов — это определённо про софтверную архитектуру. Но архитектурный долг куда шире того, что можно увидеть в коде.
Комментарий от Евгения Сулейманова – эксперта сообщества Spring АйО
Технический долг мы еще как-то вытягиваем усилиями команды: переписали сервис, добавили тесты, поправили индексы - и локально стало легче. Архитектурный долг так не чинится. Это про лишние системы, дублирующие потоки данных, размытую ответственность и странную орг. структуру. Он размазан по всей системе и превращает любое изменение в маленький корпоративный ад - долго, дорого и с непредсказуемыми побочками.
Как я вижу технический архитектурный долг сегодня
Как корпоративный архитектор я по-прежнему в основном жалуюсь на архитектурный долг и на оценки, которые принимают за дедлайны. Тут ничего не изменилось.
Сейчас я гораздо меньше переживаю о том, как работает само приложение. Это просто невозможно, если в компании сотни приложений¹. Меня куда больше волнует, как эти приложения взаимодействуют с остальным ландшафтом. Как движутся данные, где они хранятся, есть ли узкие места, кто всё это потом будет поддерживать и какую роль конкретное приложение будет играть в будущем.
В корпоративной среде это неизбежно. Приложений очень много, и больше половины из них — сторонние SaaS-решения. Нужно держать под контролем то, что контролировать можешь, и отпускать то, что не можешь.
Слои архитектурного долга
Но архитектурный долг уходит далеко за пределы технических слоёв. Enterprise architecture — это не техническая архитектура².
И да, архитектурный долг может создать организации массу проблем. Но долг на бизнес-и стратегическом уровнях способен нанести ещё больший ущерб.
Комментарий от Евгения Сулейманова – экспе��та сообщества Spring АйО
Самое коварное в архитектурном долге то, что он сначала вообще не выглядит проблемой. "Еще один SaaS", "быстренько прикрутим SFTP", "потом разберемся с процессами" - и вот уже стратегия строится на кривой карте. Если вы не описываете ландшафт (AS-IS / TO-BE, карты capabilities), то вы не управляете архитектурой, вы просто надеетесь, что все как-то "само сложится". В реальном ентерпрайзе это почти всегда заканчивается болезненно.
Разберёмся, какие проблемы возникают на каждом из слоёв.
Слой приложений / инфраструктуры
Как уже говорилось во вступлении, EA не должен фокусироваться на уровне кода. Это задача разработчиков и лидов разработки. Они каждый день работают с кодом — вы нет. Вы можете предложить шаблоны или идеи (например, event sourcing для приложений, которые попадают в такую проблемную зону), но именно они решают, как структурировать и поддерживать код.
Вместо этого я фокусируюсь на таких вещах, как интеграционные паттерны. Мы всё ещё скидываем файлы по sFTP, одновременно используя REST API? Может, стоит перейти целиком на REST, чтобы унифицировать подход.
А что делают наши системы? Если несколько систем дают одни и те же возможности, их можно объединить. Например, хранение файлов — классика. У вас может быть бесплатный SharePoint, который идёт с каждым Microsoft-аккаунтом, но при этом вы арендуете место в AWS. Возможно, их стоит объединить.
И не забывайте про зависимость от вендора. Найти баланс между выгодной скидкой за большой пакет услуг от одного и того же вендора и ситуацией, когда они блокируют вам выход, пряча ваши системы за огромными затратами на миграцию — реальная проблема, с которой сталкиваются многие компании.
На этом слое весь долг напрямую влияет на операционку. Растут затраты, увеличиваются сроки поставки.
Бизнес-слой
Как и на слое приложений/инфраструктуры, мы не копаемся в деталях. Нам неважно, сколько людей работает в каком отделе и какие у них должности.
Нас волнуют такие вещи, как владение и ответственность. Если приложение или процесс падает, если утекают данные — кому вы будете звонить?
Кого нужно собрать в комнате, если вы хотите модернизировать отдел? Да, нужно поговорить с руководителем отдела и его стейкхолдерами. Но каждый отдел работает с другими отделами. Как и приложения, процессы и потоки связаны друг с другом. Вы не хотите модернизировать процессы одного отдела и парализовать ежедневную работу пяти других.
Что насчёт устаревших или «фантомных» процессов? Если вы даёте новичку схему бизнес-процессов, чтобы помочь ему освоиться, а она неверная — неприятно. Гораздо хуже, если это не новичок, а аудитор.
Поэтому на этом уровне главное — документация. Описание того, как работают отделы, кто что делает и что им нужно для работы. Если люди работают, исходя из неверных предположений, они начнут проекты на основе тех же неверных предположений. Они проигрывают ещё до старта.
И снова — это про стоимость и внешние риски. Ошибки здесь усиливают операционные проблемы.
Стратегический слой
Корпоративный архитектор не формирует стратегию. Он помогает тем, кто её формирует.
Но для этого нужно навести порядок. Чем лучше инсайты вы можете дать, тем лучше (потенциально) будет результат.
Главные проблемы долга здесь — неправильные определения и недостроенные фреймворки. Я много говорил о ценности карт бизнес-возможностей (Business-Capability maps)³ именно по этой причине.
Если вы хотите понять, в чём организация сильна или слаба, можно сделать карту зрелости бизнес-возможностей — огромное упражнение, в котором вы проходите по каждой возможности и оцениваете её по выбранным параметрам.
Теперь у каждой возможности есть оценка, и можно понять, на что стоит обратить внимание и что улучшать (если это вписывается в вашу с��ратегию).
Отлично! Но что, если мы неправильно определили сами возможности? Может, карта устарела, или это вовсе не карта возможностей, а просто перечень отделов, собранный по принципу корпоративных силосов. Тогда вы будете строить стратегию на 3–5 лет, опираясь на ложные предпосылки.
Долг на этом уровне может иметь огромные долгосрочные последствия. Он блокирует трансформации и может сделать привлекательной плохую стратегию.
Как бороться с архитектурным долгом
К счастью, есть хорошие новости: в отличие от разработчиков, у корпоративных архитекторов есть время и видимость, чтобы замечать архитектурный долг. У нас есть время и ресурсы на создание дашбордов и сбор доказательств того, что происходит. У нас есть доступ к правильным людям, которым можно изложить свои аргументы.
И именно так и нужно действовать. Намного проще показать CIO или COO несостыковки с помощью PowerPoint или дашборда, чем с помощью God-класса, который вы хотите перелопатить в команд-бас.
Учёт — ключ. В моих архитектурных инструментах чётко перечислено, что я считаю долгом. У меня также есть список в блокноте — что хочу исправить и в каком порядке.
Построение аргументации — это сбор всех данных, создание AS-IS и TO-BE моделей и расчёт бизнес-кейса: какие улучшения получим и какие риски несём, если ничего не делать.
А дальше — выбор битв. Бывают области, где архитектурный долг терпимее. Например, системы инноваций против систем учёта⁴. В инновационных проектах можно мириться с долгом больше, чем в ключевых системах, которые содержат источники истины. Но только если долг будет погашен после завершения фазы инноваций.
И будьте готовы к тому, что очень часто услышите: «Хорошо, иди и исправь это». Убедитесь, что у вас есть ресурсы действительно пойти и исправить. Долг не исчезнет только от того, что вы его обозначили.
Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.