В администрациях многих городов есть главный архитектор. Обычный архитектор отвечает за отдельные жилищные комплексы, парки и тому подобное, а главный делает так, чтобы эти объекты не мешали друг другу, интегрировались с городской инфраструктурой, формировали архитектурный ансамбль — в общем, составляли единое целое.
В ИТ-инфраструктуре крупной компании тоже важна архитектурная целостность. Точно так же, как хаотичная застройка города может привести, например, к дорожным пробкам, несогласованные архитектурные решения в ИТ часто приводят к «пробкам» в разработке, увеличивая Time2Market и в итоге приводя к недополученной прибыли. О том, как создается архитектурный ансамбль МКБ, расскажут Дмитрий Корчев, заместитель председателя архитектурного комитета, и Роман Сайбуллин, руководитель разработки процессов обслуживания юридических лиц корпоративного блока.
A — значит ad hoc
Архитектура есть у любого проекта. Вообще у любого, даже у студенческой лабораторной на 2000 строк в одном файле. Конечно, никто не говорит, что это обязательно будет хорошая архитектура, но по факту она есть.
Хорошая команда разработчиков в итоге обязательно придет к хорошей архитектуре. Эволюционным методом: обучаясь на своих ошибках, пробуя различные решения и отбрасывая их в пользу более удачных. Проблема в том, что бизнесу не нужно «в итоге», ему нужно сейчас, а в идеале — вчера.
Пробы и ошибки — это время и деньги. Не вполне удачное решение, ушедшее в продакшн, постепенно превращается в технический долг. Соответственно, стоит вопрос о том, как минимизировать количество проб и прийти к удачной архитектуре кратчайшим путем. В качестве ответа на этот вопрос и существует архитектурный комитет.
Что может пойти не так
Во всяком инженере живет инстинктивная ненависть к бюрократическим процедурам. Есть даже целый сайт с не вполне цензурным, но весьма проникновенным манифестом на эту тему. Однако существуют институции, полезность которых, хоть и с зубовным скрежетом, приходится признать даже самому упертому инженеру. Поговорим о том, почему без архитектурного комитета может быть (а по факту — будет) плохо.
Допустим, команда разрабатывает продукт, у нее все хорошо, продукт уже вот-вот готов отправиться в прод… И тут внезапно письмо от Security Team. Продукт не отвечает таким-то и таким-то корпоративным требованиям безопасности, нужно срочно привести в соответствие. Разумеется, разработчики все сделают. Но, возможно, для этого придется пересмотреть какие-то решения, прошерстить много кода… Было бы намного проще, если бы все требования безопасности были известны заранее и учитывались изначально.
Или другая ситуация. Команда уже собирается деплоить свое решение, как вдруг (внезапно) выясняется, что ИТ-инфраструктура к этому не готова. Например, банально не хватает серверных мощностей. Запуск откладывается до покупки нового сервера. Можно было приобрести его заранее, но кто ж знал?
А теперь допустим, ничего этого не произошло. Решение успешно запущено и функционирует. А потом выясняется, что его некому поддерживать. В компании нет специалистов по использованной технологии. Можно было заранее нанять их, можно было выбрать другую технологию, но — кто ж знал?
Разработчики — это замечательные люди, которые любят пробовать все новое. Они занесли в нашу организацию технологии, которые непонятно как сопровождать и администрировать.
Роман Сайбуллин
Или команда запускает сервис для обеспечения работы своего решения, а потом выясняется, что другая команда недавно запустила практически аналогичный сервис. Можно было как-то скооперироваться, но… В общем, вы поняли.
Чтобы принять оптимальные решения и минимизировать Time2Market, нужна полнота необходимой информации. Как у продуктовой команды, так и у всех, кому с ее продуктом предстоит взаимодействовать. Недостаток информации приводит к проблемам на ровном месте. Чтобы избежать этих проблем, существует архитектурный комитет.
Как это работает
Слово «комитет» — мрачновато-аппаратное: что-то про цензуру и надзор, про «тащить и не пущать». Так и вышло.
В МКБ с 2019 года существовал Архитектурный комитет 1.0, на который команда выходила со своей задачей, предложением по реализации, вопросами и потребностями, а представители совета – архитекторы, дирекции ИТ, ИБ, дирекции рисков, юристов, бизнес – задавали вопросы по этому решению. Оглядываясь назад, приходится с грустью признать, что это выглядело как экзамен: комитет играл роль приемной комиссии, которая либо пропускала решение, либо отправляла команду на пересдачу.
Дмитрий Корчев
Впрочем, даже в своей первой версии архитектурный комитет был полезен. Он помогал избегать необдуманных решений. Однако намного лучше — помогать принимать обдуманные.
В 2022 году МКБ официально получил второй уровень зрелости CMMI. В России модель CMMI (Capability Maturity Model Integration) малоизвестна, однако используется тысячами компаний за рубежом. Она позволяет улучшить структуру и качество процессов, в том числе процесса разработки. МКБ на практике оценил эффективность методологии, и в 2023 году рассчитывает достичь третьего уровня зрелости. Впрочем, это лирическое отступление.
Архитектурный комитет версии 2.0 следует практикам CMMI в области DAR (Decision Analysis and Resolution). Как это выглядит? Принятие каждого «большого» архитектурного решения включает в себя следующие подготовительные пункты:
Определить список тех, чьи интересы затрагивает решение («интерессантов»). Каждый из них должен участвовать в обсуждении и принятии решения, иначе случится какая‑нибудь ситуация из предыдущего параграфа.
Совместно с интересантами определить критерии, по которым оценивается решение. Например — безопасность, стоимость разработки, стоимость поддержки, время введения в эксплуатацию. Важно определить критерии заранее, до того, как будет выбираться решение.
Составить список вариантов — несколько возможных способов, которыми может быть решена задача.
Произвести оценку вариантов (скоринг). По каждому критерию вариантам решения выставляется балл, который затем умножается на весовой коэффициент (важность критерия). Баллы по всем критериям суммируются, и дается общая оценка.
Выбирается не менее двух вариантов с наивысшим скорингом, которые затем и будут обсуждаться на архитектурном комитете.
«Интересантам» заранее рассылаются материалы по проекту. Это позволяет не тратить время заседания на проговаривание общих мест. На заседании обсуждаются уже детали, высказываются вопросы и пожелания. Если проект всех устраивает — можно приступать к реализации. В противном случае формируются поручения авторам проекта: внести в него те или иные изменения в установленный срок, после чего происходит повторное заседание.
Практики DAR гарантируют комплексное рассмотрение архитектурных решений, в котором все заинтересованные стороны делятся своим взглядом на проблему. Продуктовая команда знает, чего от нее хотят, и дает знать о собственных требованиях. Если вариант решения неудачен по каким-то критериям, это выясняется заранее. Если есть удачные варианты, о которых команда разработки не подумала, — есть шанс, что они всплывут в обсуждении.
Как это на практике
В качестве CRM в МКБ используется Oracle Siebel. Это энтерпрайзное решение, с регулярными обновлениями. Однажды зашла речь о том, чтобы перейти на новую версию. Однако нюанс в том, что Siebel используется в масштабах всего банка, как в корпоративном, так и в розничном сегменте. И тут мнения бизнес-заказчиков разошлись.
Корпоративный бизнес очень хотел новую версию. Мотивация: стабильность и бенефиты, уменьшающие Time2Market. При этом розничному бизнесу переход был очень некстати, а обновиться, не затронув розницу, было нельзя.
Совещания и дискуссии ни к чему не приводили, количество интересантов росло, вопрос застопорился.
На Архитектурный комитет было идти не с чем, поэтому я обратился к архитекторам за помощью. Архитекторы помогли сформировать критерии принятия решений, альтернативные варианты решений и выполнить скоринг. В результате все заинтересованные лица поняли, что лучше разделить инстанс Oracle Siebel CRM на два.
Роман Сайбуллин
На заседании архитектурного комитета обсудили нюансы этого соломонова решения. Безопасников очень интересовало, как на двух инстансах будет реализована ролевая модель. Продуктовая команда изначально полагала, что это вопрос вторичный и им можно будет заняться в процессе внедрения. Однако представитель безопасников убедил команду, что ролевую модель необходимо спроектировать заранее, а также продумать, как она будет взаимодействовать с IDM-системой. Команде было дано поручение доработать проект, после доработки он был принят.
Помимо этого, архитектурный комитет стал площадкой для налаживания взаимопонимания между «заинтересантами». Представители розницы рассказали подробнее про свои разработки, из-за которых они не хотели заниматься переходом на новую версию (например, про «Единое окно»). Корпоративный бизнес обрисовал свои потребности, из-за которых новая версия ему нужна. Таким образом всем стала ясна мотивация решения о разделении инстанса Siebel.
Совет да любовь
Архитектурный комитет полезен для выработки оптимального решения, однако в первую очередь это все-таки контролирующий орган. Прохождение архитектурного комитета обязательно для проектов крупного масштаба, требующих изменений ИТ-ландшафта компании. Однако консультация может быть полезна и отдельно от контроля. В частности, практики CMMI в области DAR, о которых говорилось выше, можно использовать не только для подготовки к заседанию архитектурного комитета, но и в целом для поиска оптимального решения. Поэтому у архитектурного комитета появился «младший брат».
Мы провели опрос по сервисам архитектуры и поняли, что очень много сотрудников недополучают сервис структурированной помощи для формирования решений. В результате родилась идея Архитектурного совета — это рабочая группа, в которой мы помогаем проектировать и выбирать решения, фактически занимаясь чем‑то средним между обучением и консалтингом. Архитектурный совет не обязателен, в отличие от Архитектурного комитета.
Дмитрий Корчев
Несмотря на свою необязательность, Архитектурный совет пользуется популярностью у разработчиков. За прошедший год в него обращались в три раза чаще, чем в Архитектурный комитет.
Вместо постскриптума
За годы работы ИТ-команда МКБ много узнала о проектировании и согласовании архитектуры. Таким опытом хочется делиться. Не так давно в МКБ вышел главный архитектор Дмитрий Клецких. С его приходом описанные процессы получили развитие, а какие именно мы расскажем чуть позже.
Если у вас есть вопросы или замечания, оставляйте их в комментариях. А если вам интереснее перенимать опыт на практике — посмотрите список наших вакансий.
Спасибо за внимание!