Архитектурный монстр Франкенштейна, без которого работа архитектора невозможна

Введение

Меня зовут Руслан Махмудов, я — архитектор решений в Альфа-банке. Хочу рассказать, как мы в Альфа-Банке решали наши архитектурные проблемы, в результате чего создали своего монстра Франкенштейна (в хорошем смысле) — систему RSM, без которой в настоящий момент работа всего архитектурного подразделения фактически невозможна.

Как мы работаем

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

Сначала абстракция

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

После того, как архитектор решений нарисует свою схему, её отсматривают несколько человек. Один из них — корпоративный (enterprise) архитектор: следит, чтобы всё было нарисовано по паттернам и в соответствии со стратегиями развития.

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

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

• Для бизнес-задачи это целевая система ?

• Правильно ли отрисована интеграция?

• Понятен ли бизнес-процесс, в рамках которого используется их система?

• Будут ли у их системы проблемы из-за новых интеграций (например, повысится нагрузка, а система не вывезет)?

• Может, мне вообще нужно сходить в другое место, потому что нарисованная архитектором схема — ерунда несусветная?

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

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

Потом реализация

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

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

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

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

Что? Где? Зачем?

Во время эпохи «до внедрения RSM» в банке было порядка тысячи различных систем (сейчас больше), но не было единого реестра, где мы могли бы узнать:

• Какая система за что отвечает?

• Как она устроена внутри?

• Какая у неё фаза жизненного цикла (в разработке, в эксплуатации, под вывод и прочее)?

• Где она уже используется, в каких процессах банка и какие с ней уже есть интеграции?

• Как с ней интегрироваться?

• Где она физически развёрнута?

• Кто вообще отвечает за систему как владелец? А кто со стороны поддержки и развития?

• С кем в итоге договариваться?

Конечно же, что-то было в нашем бездонном Confluence, что-то можно было узнать у старожилов, что-то лежало в нашей внутренней системе документооборота. В принципе, если в достаточном количестве потратить своё и чужое время, то можно было многое разузнать.

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

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

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

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

Однако, больше у нас не было ничего. 

И ещё важный вопрос: а что же было у архитекторов решений в качестве инструментов для разработки архитектурных решений? Вы, возможно, удивитесь, но из инструментов были только офисные продукты: все архитектурные решения рисовались в Visio, документировались в Word, сопровождались таблицами в Excel, а потом всё это загружалось в портал электронного документооборота на SharePoint. 

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

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

И вот представьте: в те недавние времена в Альфа-Банке было порядка 20 архитекторов решений, которые владели своей частью информации о том, как всё устроено. А ты новичок, и когда приходишь в банк, тебе говорят: «Держи бизнес-требования, нарисуй решение». От такого впадаешь в ступор, ведь даже возможности подсмотреть что-то у кого-то нет, просто потому, что не знаешь, где и что искать. 

В итоге ты ходишь и постоянно теребишь своих коллег: «А как сделать-то? К кому сходить? Куда глянуть?» По цепочке находишь нужных людей, а нужные люди, может быть, скидывают ссылки на Confluence или на многоэтажную документацию: сиди, изучай, разбирайся. А иногда рассказывают что-то лично, в режиме «Поставь, пожалуйста, встречу на полчаса на общий свободный слот в календаре у меня [и ещё пары коллег] на следующей неделе».

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

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

И теперь, наконец-то, я перейду к тому, как мы начали всё перестраивать.

Облегчаем себе жизнь

Рисовалка

На первом шаге мы облегчили работу себе: внедрили Enterprise Architects Sparx — специализированное решение для рисования всяких разноцветных прямоугольников. Но кроме отличной рисовалки разных схем, Sparx заодно может работать как репозиторий архитектурных артефактов.

То есть мы одним внедрением получили возможность:

• хранить и подробно описывать наши прямоугольники;

• видеть их использование на существующих архитектурных схемах и переиспользовать на своих (в том числе через банальный механизм copy-paste, реально экономящий время);

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

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

Метамодель архитектуры банка 

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

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

В итоге мы сделали первые важные шаги по наведению порядка:

1. Разработали метамодель.

2. Настроили Sparx в соответствии с нашей метамоделью.

3. Начали в Sparx переносить всё, что у нас было накоплено и разнесено по десяткам тысяч документов: основные системы, второстепенные системы, существующие архитектурные решения.

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

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

Но этим мы облегчили работу только себе.

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

Для продолжения оптимизации нашего процесса необходимо было внедрять что-то ещё. Но, как быстро выяснилось, подходящего готового решения не существует. Пришлось разработать свой продукт, которым и стал тот самый RSM — Реестр Систем и Модулей, если расшифровать название буквально.

RSM: начало

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

Основные цели, которые мы поставили перед RSM:

1. Быть мастер-системой для нашего репозитория архитектурных артефактов.

2. Быть главным инструментом для разработки, согласования и сопровождения архитектурных решений. 

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

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

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

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

Особый вид издевательства над архитекторами — обзор бета-версий RSM, регулярно проводимый командой разработки. Сначала ты видишь рождение некоего инструмента, который пока вообще никак нельзя использовать. Затем как-то можно, но он почти ничего не умеет. Через какое-то время он начинает что-то уметь делать, но непривычным способом и с ошибками. Чуть позже он перестаёт делать ошибки и даже способен на что-то осмысленное, но всё равно это бета-версия, а наши официальные процессы до сих пор идут по другому пути, зачем тратить время на то, что всё равно никто не использует?

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

RSM: настоящее

Выше я упомянул про цели RSM. Вот чего мы в итоге добились на сегодняшний день:

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

2. RSM теперь является главным инструментом для разработки архитектурных решений. Строго говоря, RSM до сих пор пока на 100% не стал рисовалкой схем. Для архитекторов решений базовый инструмент, в котором рисуются схемы, всё ещё Sparx. Отказ от Sparx есть в планах, но это вопрос не ближайших месяцев и даже не 2026 года. Однако, например, для системных аналитиков это основной и единственный инструмент. 

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

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

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

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

Как это всё выглядит сейчас

Процесс

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

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

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

Очень сильно, по сравнению с тем, что было, упрощён сам процесс согласования:

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

Работа системных аналитиков с помощью новых инструментов в RSM местами упростилась даже больше, чем у архитекторов решений:

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

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

А на этом скриншоте видно детальное описание параметров безопасности для интеграции между двумя разными системами банка (тоже с комментарием безопасника): 

И, разумеется, многие проверки безопасности RSM умеет выполнять автоматически, сразу предупреждая автора о том, что он недоработал какие-то важные моменты.

Результат

Я показал лишь малую часть возможностей нашей самописной системы RSM, но эта система изменила нашу жизнь. Выше я писал, что в старой парадигме мы бы не раскатали наши процессы на 80 человек. Сейчас нас — архитекторов решений — примерно такое количество, и новые процессы, в которых RSM нынче играет роль незаменимого и важнейшего инструмента, позволит масштабировать процессы хоть ещё на 80, хоть на 180 архитекторов (и это я не считаю аналитиков, которые тоже работают в RSM, а их в разы больше).

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

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

Это всё, несомненно, хорошо звучит. Но, конечно же, есть сложности.

Но есть нюансы…

Нюанс приоритетов

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

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

Нюанс интеграций

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

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

Нюанс изменения процессов

Цифровизация и автоматизация нашего процесса по разработке архитектурных решений открыла нам возможность для его оптимизации. Я упоминал это чуть выше как преимущество RSM, но оно же является и недостатком: в процессе задействовано очень много людей, и просто так взять и быстро что-то поменять — это делается не так просто. Иногда нужно долго и упорно, с эскалацией, договариваться со многими коллегами: «Ребята, давайте теперь работать по-другому, пожалуйста». А затем вставать в очередь в бэклог разработки RSM, чтобы нужный процесс был оптимизирован…в следующем году, например.

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

Нюанс усложнения

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

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

RSM: будущее

Закончить хочется на позитивной ноте: вкратце рассказать о перспективах, которые RSM для нас открыл.

Архитектурный ландшафт

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

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

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

ИИ-архитектор

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

Это не выглядит фантастикой. У нас в Альфа-Банке уже давно есть работа с искусственным интеллектом. Есть, например, свой натренированный Альфа-Ген, с которым можно вести осмысленные диалоги. Есть команда, которая прикручивает искусственный интеллект к нашему RSM и пытается обучить его генерировать решения автоматически. 

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

Почему бы и нет? Весь архитектурный ландшафт банка есть в RSM. Все архитектурные решения есть в RSM. Добавляем туда описания паттернов, ADR, прочих правил — и можно тренировать на этом всём любой ИИ, а он потом будет работать за нас.

Это то, к чему мы идем. Эксперименты, повторюсь, уже ведутся. Рано или поздно они превратятся в какую-то RSM доработку. Её пока, конечно, в бэклоге нет, но очень надеюсь, что при моей жизни она все-таки появится. 

Может, это звучит как нереальная мечта, но кто знает — вдруг я и в самом деле доживу до того дня, когда утром буду загружать в RSM бизнес-требования от заказчиков, нажимать волшебную кнопку «сгенерировать», выбирать/валидировать/немного править результат, и отправлять на согласование в тот же RSM. И это только до обеда. А после обеда уже всё будет согласовано, дайте мне следующую задачу, пожалуйста. Lead time сократится до нескольких часов, а нашей скорости разработки и внедрения архитектурных решений все будут завидовать.

Это и была позитивная нота. Спасибо за внимание.

Подписывайтесь на Телеграм-канал Alfa Digital — кроме выжимок интересных статей, там постим новости, опросы, видео с митапов, анонсы.

Читайте также: