Технический долг как инструмент управления архитектурой банка

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

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

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

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

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

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

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

Итак,

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

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

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

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

Рис 1. Обобщенная модель архитектурного процесса с выделенным техдолгом и механизмом непрерывного улучшения
Рис 1. Обобщенная модель архитектурного процесса с выделенным техдолгом и механизмом непрерывного улучшения

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

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

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

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

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

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

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

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

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

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

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

Рис 2. Цепочка участников процесса проектирования с артефактами
Рис 2. Цепочка участников процесса проектирования с артефактами

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

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

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

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

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

Источник: https://habr.com/ru/post/591777/


Интересные статьи

Интересные статьи

Всем доброго вторника. Началась неделя распродаж в сфере ритейл и наверное не только. А 'то значит что что уже никакие серьезные изменения в проде не делаются или еще не делались и будут выполнятся по...
Мы уже долгое время занимались регулярной публикацией обзоров лучших инструментов аннотирования на рынке. Радостно видеть, что экосистема всегда динамична, а у платформ аннотирования появляются всё ...
20 ноября 2000 года произошло событие, которого с нетерпением ожидали очень многие: Intel официально представила новые процессоры Pentium — Pentium 4 на ядре «Willamette». Впервые упоми...
Несколько последних лет хотелось заполучить игрушку на пульте управления и обязательно с видео. Но не купить готовую, а сделать самому. И в итоге заказал себе вот такую игрушку, с простенькой с...
В любой среде разработки есть инструмент с названием «Output». Нет нужды описывать что он делает, поскольку абсолютно все разработчики его используют в своей работе ежедневно. Он прост и консерва...