Википедия говорит, что технический долг (technical debt), или долг кодинга, возникает в коде или архитектуре решения при, обобщая формулировку, умышленном снижении уровня качества решения.

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

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

Кому это нужно?

Сначала о том, для кого эта статья и почему областью ее приложения являются именно банки. Такая область применения выбрана умышленно: банковские организации в России являются чрезвычайно зрелыми, если проводить анализ зрелости (maturity) по шкале СММ, то сам банк будет иметь оценку 4.5+, ведь его деятельность является предсказуемой и оптимизируемой. При этом, архитектурный процесс в банке, как вид обеспечивающей деятельности, зачастую по уровню зрелости едва достигает 2-2.5. То есть, это процесс уже управляемый (managed), но при этом еще недостаточно устояшийся (established). Столь существенное расхождение в уровнях зрелости демонстрирует и очень важную проблематику: архитектура не может эффективно поддерживать бизнес, более того, зачастую, бизнес вообще не может понять зачем она нужна, так как ее процессы и подходы к принятию решений не транспарентны, а результаты деятельности — сомнительны для всех участников.

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

Итак,

Что же такое — техдолг?

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

Мысль, по моему мнению, феноменально предвосхитившая своё время, но сейчас уже заметно сдавшая позиции, тем не менее, сразу вводит нас в понятную проблематику: Каннингем приводит нас именно к долгу кодинга.

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

При этом, рассматривая архитектурный процесс с точки зрения управления качеством становится очевидным, что добавление в архпроцесс механизмов управления техническим долгом превращает его в классический цикл Деминга-Шухарта или цикл P-D-C-A — механизм непрерывного улучшения, реализуемого на ИТ-ландшафте банка, где:

• PLAN —проектирование (от целевого ландшафта до конкретных реализаций);

• DO — разработка;

• CHECK — архнадзор;

• ACT — управление техдолгом.

Являясь инструментом менеджмента качества, использование цикла P-D-C-A в составе архитектурного процесса, делает его стабильным и управляемым, позволяя проводить оптимизацию. Таким образом, при надлежащем усердии, управление техническим долгом становится драйвером повышения зрелости архитектурного процесса, позволяя его выровнять с уровнем зрелости остальных процессов банка.

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

1. корпоративная архитектура (enterprise architecture);

2. архитектура решений (solution architecture);

3. cистемная архитектура/аналитика (system analytics).

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

Рассмотрим проявления техдолга на всех уровнях архитектуры банка:

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

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

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

Теперь, имея три понятия техдолга от разных уровней банковской архитектуры и логически их сложив, определим общее понятие:

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

Таким образом, расхождения, формирующие техдолг, при его возврате требуют изменений:

• на уровне корпархитектуры это стратегические изменения;

• на уровне решений — это функциональные и интеграционные изменения;

• а на уровне системной архитектуры — изменения в коде реализации.

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

Зачем и как управлять техническим долгом?

Что такое управление? В нашем случае — измерение и изменение в желаемую сторону (→0). Неуправляемый техдолг (а то, что за ним никто не приглядывает, не значит, что его нет), гарантированно приводит к неуправляемости ИТ-ландшафта на различных уровнях:

• для корпархитектуры это несоответствие ландшафта потребностям бизнеса умножается на раздутую стоимость сопровождения и изменения;

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

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

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

Учет техдолга

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

• Ответственный бизнес, где указывается наименование того бизнес-подразделения банка, финансирующего проект, результатом которого станет техдолг.

• Описание решения, формирующего техдолг и причины того, почему такое решение классифицировано как техдолг. Сюда же обосновывающие документы: компонентную диаграмму и процессную модель. Как показывает опыт, описывать техдолг нужно достаточно тщательно, отчуждаемо.

• Описание решения — возврата техдолга. Описание целевого решения с приложением целевой архитектуры.

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

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

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

• Дополнительные признаки, включая тегирование, для аналитики.

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

Аналогично, но в нисходящем русле производится декомпозиция долга при переходе с более высокого уровня архитектуры на более низкий.

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

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

Практика по регистрации техдолга или техдолг для всех

К примеру, давно понятно, что какой-то компонент ИТ- ландшафта банка устарел и не соответствует как нефункциональным требованиям, так и к функциональным, что приводит к пониманию необходимости его замены с выводом из эксплуатации. Предположим, что в результате проведённых R&D, был выбран продукт и вендор, появилась дата ввода в эксплуатацию. Для возможности описать частную функциональность, выберем тип такой системы, к примеру ECM/DMS (управление документооборотом и корпоративным контентом).

Такой долг регистрируется корпархитектурой как:

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

Утверждение техдолга

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

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

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

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

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

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

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

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

Есть ли жизнь после утверждения техдолга?

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

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

Классификация технического долга

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

Таким образом,

• корпоративные архитекторы регистрируют стратегические долги, порождаемые расхождением текущего ландшафта и целевого;

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

• системные архитекторы регистрируют долги, связанные с нецелевой реализацией функциональности отдельного компонента, модуля, сервиса, системы.

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

Чем автоматизировать управление техдолгом?

Как профессиональный автоматизатор всего и вся, попробую сформулировать основные процессы, которые такая система должна реализовывать:

1. Регистрация техдолга с уведомлением всех, к кому он относится: архитекторы, бизнес.

2. Поддержка жизненного цикла долга с подготовкой отчетов по разным срезам: бизнес, архитекторы, роадмепы и т.д.

3. Мониторинг показателей технического долга на всех уровнях архитектуры с предоставлением данных главному архитектору и иным заинтересованным лицам.

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

К примеру, интересным является использование для управление техдолгом механизмов service desk, под который легко адаптируются требования по управлению. Также, достаточно простым подходом в реализации является использование любого табличного процессора, к примеру MS Exсel или Google Sheets. Главное, чтобы он поддерживал обмен данными между таблицами, SQL-запросы и реляционную БД с желательной возможностью регистрации техдолга через упрощенную форму. Также простым в реализации вариантом является использование систем управления знаниями, таких как Сonfluence или Notion. Интересным и простым в реализации подходом является возможность работы с техдолгом по аналогии с беклогом проекта.

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

О недостатках подхода

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

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

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

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

Выводы

???? Техдолг — расхождение предлагаемого решения с целевым

Да, технический долг в банке — это важно, так как без работы с ним ландшафт превращается в так называемый зоопарк, который бывает проще сжечь, чем перестроить. Особенно, это относится к изобилию легаси-решений, которые накапливаются, постоянно снижая управляемость продуктовой линейкой бизнеса и затрудняя ее развитие, как в части изменения имеющихся продуктов, так и вывода на рынок новых. Кроме того, отсутствие процедур управления техническим долгом или их недостаточная интеграция как в архитектурный процесс, так и в процесс реализации ИТ-инициатив (как бы это ни называлось), четко и сразу показывает отсутствие реальной ИТ-стратегии у банка и ее прямого следствия — целевого ландшафта, что как бы намекает, что у бизнеса есть планы на будущее, а у ИТ-нет. В общем, неконтролируемый рост энтропии в ландшафте — к переменам. Собственно говоря, оценка этой энтропии, также является одним из показателей текущего качества ландшафта.

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

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

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