Чего хочет бизнес
Бизнес развивается непрерывно и динамично. Что это значит для архитектуры?
С каждым годом растут требования по оценке точности бюджета проекта. Чтобы правильно спланировать проект и затраты по проекту требуется иметь достаточно точную оценку от ИТ с учетом интересов всех стейкхолдеров, чем раньше, тем лучше.
Растёт сложность и масштаб задач, проекты укрупняются и изменения затрагивают все большее количество систем банка.
Растёт количество задач. Объем задач, которые требуют проработки архитектуры, вырос в 3,5 раза за последние 4 года и продолжает непрерывно расти.
Бизнес не хочет отставать от рынка. Бизнес хочет идти гораздо быстрее рынка. И, при этом, мы все прежде всего думаем о клиентах. А клиенты ценят:
простой и интуитивно понятный интерфейс, то есть, когда все самое нужное всегда под рукой;
приятный и красивый дизайн;
лучший сервис на рынке.
Помимо бизнеса и команды проекта, в его исполнении заинтересовано достаточно большое количество подразделений, которые напрямую в нем не участвуют. Но с точки зрения архитектуры — это стейкхолдеры.
Чего хотят стейкхолдеры
Задачи не существуют сами по себе. У каждой задачи есть заинтересованные стороны — стейкхолдеры, которые хотят, чтобы их интересы были учтены в проекте.
Чего же они хотят? Простых вещей, которые не менее важны для клиента, чем простые и понятные функции. Кратко о них:
Комплаенс. Заботится о требованиях законодательства и Центрального банка к хранению данных клиента, и о том, как клиент представлен в системах банка, чтобы данные клиента были едиными, целостными и непротиворечивыми.
Юристы. Заботятся о том, чтобы решения и функции банка соответствовали законодательству.
Различные финансовые департаменты. Оценивают решения с точки зрения соблюдения норм финансового учета предприятия и требований регулятора.
Бизнес направления. Разные направления бизнеса активно развиваются достаточно большим количеством бизнес-подразделений (бизнес стрим или просто бизнес). Бизнес заботится о клиентах и о том, чтобы функции банка были понятными и удобными и соответствовали требованиям рынка. Бизнес подразделений много, и они активно отстаивают интересы различных сегментов клиентов. При формировании требований к архитектуре бизнес-подразделения фокусируются на достижении целей определенных сегментов клиентов. Но сегменты очень разные и бывает, что интересы одних категорий клиентов противоречат другим. При этом они стремятся найти консенсус и учесть интересы всех сторон.
Что это значит для архитектуры? Каждое изменение нужно посмотреть на соответствие бизнес стратегии развития продукта, технической стратегии развития продукта, стратегии развития ландшафта предприятия в целом. Очень важно, чтобы все бизнес направления развивали ИТ ландшафт предприятия.
Информационная кибербезопасность. Заботится о данных клиента, делает функцию безопасной для применения. Клиент должен быть уверен, что данные, которые он передает в банк под надежной защитой, поэтому подразделение кибербезопасности оберегает данные клиента от всех видов угроз.
Что это значит для архитектуры? Каждое изменение архитектурного ландшафта необходимо оценить, дать экспертное заключение и заложить в бюджет необходимые средства защиты информации или масштабирование существующих.
Подразделения сопровождения. Заботятся о доступности функций банка для клиентов. Приложения должны работать без сбоев 24 часа в сутки 365 дней в году.
Что это значит для архитектуры? Нужно оценить влияние каждого изменения на обеспечение бесперебойности работы всего архитектурного ландшафта. Уже на раннем этапе надо оценить и заложить в бюджет проекта масштабирование оборудование или расширение штатной численности.
Enterprise-архитекторы. Заботятся о будущем клиента.
Что это значит для архитектуры? Функции, которые предоставляются клиенту будут развиваться, а для развития функций жизненно необходимо делать их на современном стеке, а изменения архитектурного ландшафта должны соответствовать долгосрочной стратегии развития.
Поэтому чем раньше и чем точнее мы выявляем все необходимые потребности всех стейкхолдеров или получаем от них одобрение, тем больше вероятность того, что проект уложится в заданные сроки, будет безопасным, масштабируемым, сопровождаться с требуемым уровнем обеспечения сервиса, и будет долго радовать клиента новыми фичами.
Но мы сейчас, скорее, говорим об идеальном мире:) В реальном мире бизнес не мог и не может ждать долго. И раньше и очень часто приходилось начинать разработку до того, как была готова архитектура. В процессе разработки всплывали риски и приходилось их принимать уже по ходу проекта.
Тогда мы решили запустить проект под кодовым названием «Упорядочивание архитектуры». Для него было несколько причин.
Почему надо было что-то менять
Причин инициирования изменений было несколько, и все они не должны приводить к существенному увеличению времени и затрат.
№1. Нужно учесть интересы огромного количества стейкхолдеров заранее.
Почему это важно?
Чтобы учесть интересы большого количества стейкхолдеров нужно время. Но бизнес не хочет и не может ждать, и очень часто приходилось начинать разработку до того, как была готова архитектура решения.
В процессе разработки, как правило, выяснялось, что решение, которое уже начали делать, не удовлетворяет требованиям стейкхолдеров. Например, команды развития все разработали, все сделали, устанавливают решение на стенд нагрузочного тестирования и не проходят тесты. Нужен новый, принципиально иной способ интеграции.
Еще пример, достаточно часто встречавшийся до начала трансформации — при установке решения на интеграционный стенд выясняется, что решение не соответствует требованиям безопасности. Нужно срочно покупать дорогостоящее средство обеспечения безопасности данных. Решение подобных задач на позднем этапе требует гораздо больше затрат, чем если бы учесть эти требования заранее.
Переделывать всегда долго, дорого, сложно и, как правило, очень неинтересно.
Проект превышает запланированный бюджет, нарушаются дедлайны, смещаются графики реализации. В результате нужная функция для клиента не выпускается в нужный срок.
№2. Нужно общее видение информационного ландшафта предприятия.
Почему это важно? Информационные ресурсы полны различной информации. Confluence, системы документооборота, архитектурный портал, документации в Word, Excel, различные Схемы в Visio — все эти инструменты и системы так или иначе хранят информацию о том, как все устроено.
Дефицита информации не было. Но когда информации слишком много, а бизнес слишком быстро развивается — информация теряет свою актуальность при каждом следующем цикле развития.
Постоянно приходилось что то срочно искать, когда бизнес приходит с новой задачей. Информация быстро устаревает и на различных ресурсах она всегда отличается.
Разные подходы к ведению архитектурных документов, разные артефакты, разные уровни детализации, различные схемы формировались в различных инструментах. Все это приводило к тому, что очень долго приходилось сопоставлять данные из разных источников.
№3. Сокращение времени онбординга и обеспечение комфортной работы.
Почему это важно?
Новым аналитикам, новым архитекторам приходилось совершенно не просто.
Запутанный ландшафт, огромное количество информации в разных источниках, огромное количество документации приводило к длительному онбордингу — обычно это 4-6 месяцев.
Сжатые сроки, срывы дедлайнов, эскалации, срывы сроков проекта из-за постоянных переделываний, мягко выражаясь, сильно демотивируют.
Вывод
Стало очевидным что нужно что-то менять.
И перед тем, как начинать проект, а особенно начинать что-то реализовывать, писать код, делать какие-то настройки, нужно:
Заранее спланировать архитектуру решения настолько детально насколько это возможно или двигаться итерациями постепенно повышая степень проработки решения.
Показать решение стейкхолдерам и участникам команд и собрать обратную связь. Учесть замечания.
Стараться делать так как было запланировано изначально до завершения проекта
Все это нужно делать быстро и использовать максимально актуальные и достоверные данные об архитектурном ландшафте предприятия.
А теперь расскажем про то, как мы сделали трансформацию.
Выбираем инструменты
Трансформацию мы начали с выбора инструментов. Вот основные требования, которые к ним предъявлялись:
Простота и понятность большому количеству стейкхолдеров.
Инструменты не должны стоить очень много.
Инструменты должны позволять работать с единой базой, потому что одна из целей была создание единого архитектурного репозитория.
Инструмент должен позволять просто и быстро переиспользовать ранее созданные элементы.
И первый инструмент, который был выбран, инструмент концептуального проектирования. Концепт архитектуры должен быстро появляться, должен быть понятен всем заинтересованным лицам, чтобы на раннем этапе они могли его прочитать, высказать свои замечания и скорректировать архитектурное решение.
Второй инструмент — нотация. Различные нотации, которые применяются на рынке для проектирования архитектуры не всегда понятны тем, кто не занимается архитектурой, они требуют изучения.
Кроме этого в Банке уже была нотация, которая представляет из себя сильно упрощенную нотацию UML. Мы решили её оставить, так как большинство заинтересованных лиц в банке давно ею пользовались, и она всех устраивала. Простая, понятная, привычная нотация позволяла большому количеству стейкхолдеров быстро разобраться в достаточно большом количестве решений разной сложности.
Третий инструмент — единая база элементов решения, или архитектурный репозиторий, в котором хранится любая архитектурная документация, все решения и их элементы.
Четвертый инструмент — процессы ведения архитектурной документации. Мы объединили все процессы так, что каждый следующий проект уточняет и детализирует решение.
В качестве инструмента визуального проектирования был выбран Sparx Enterprise Architect. Он работает с единой базой данных. Любое изменение в архитектурном ландшафте проходит через стадию концептуального проектирования.
Концепт решения загружается в систему RSM (это наша разработка для ведения документооборота архитектурных документов). Дальнейшая документация проекта ведется в RSM, там же согласуется и концепт, и документация проекта.
Теперь каждое изменение архитектурного ландшафта предприятия в обязательном порядке проходит этап согласования концепта.
Большое количество команд развития разрабатывает документацию, детализирует концепт до нужного состояния. Всё согласуется, поддерживается в актуальном состоянии. И если мы видим сильное отклонение от концепта, то быстро согласовываем эти изменения для получения одобрения стейкхолдеров.
Такой подход сближает концепт решения и реализацию, что позволяет искать на ранней стадии оптимальные пути решения с точки зрения бизнеса с учетом сроков в заданных ограничениях.
Систематизируем окружение
В Альфа-Банке архитектурный ландшафт достаточно непростой.
большое количество систем;
некоторые не очень крупные системы детализированы очень сильно, да так, что за деревьями леса не видно;
некоторые крупные системы не так хорошо документированы, и иногда даже не совсем понятно, что делает этот большой монстр;
многие элементы являются частью других систем;
статус систем не всегда очевиден, что сильно замедляет решение (мы должны понимать, какое решение целевое, а какое legacy);
много одних и тех же систем с разными наименованиями: системы живут, развиваются, переименовываются — иногда сложно найти, как система называлась 5 лет назад.
Что мы сделали, чтобы исправить ситуацию?
Внедрили трехуровневую модель. Теперь всё, что мы вносим в единую БД, соответствует метамодели: это либо система, либо модуль, либо компонент.
На концепте решения мы изображаем первые два уровня — это система или модуль. На более поздних этапах отображаем компонент.
Автор решения сам выбирает детализацию, в зависимости от требований бизнеса и сроков. Чем детальнее концепт, тем точнее оценка, но дольше разрабатывать и согласовывать решение. Чем более абстрактный концепт, тем быстрее он реализуется. Но оценка может быть не настолько точной.
Также:
Все системы, модули классифицировали и занесли в реестр.
В процессе работы определили функции всех систем.
Заполнили огромное количество данных по всем системам.
Заполнили вторые, третьи, четвертые наименования: когда она была переименована и какое было старое название.
Таким образом мы посчитали всё: в числах это 903 системы, 1061 модуль и 1993 компонента на момент публикации статьи. Но цифры растут с космической скоростью. Теперь все функции собраны в едином месте, системы классифицированы и эта информация доступна практически всем.
Когда приходит аудит ИТ ландшафта, а в последнее время это случается достаточно часто, мы всегда можем поднять всю историю по системам, найти и предоставить документацию, вне зависимости от того, как много лет назад называлась та или иная система.
Каждый занимается своим делом
Очень часто архитектор не занимается бизнес-задачей. Ему приходится что-то искать, заполнять реестры и списки, и, когда у бизнеса возникает новая идея, он не всегда может найти архитектора.
Что мы сделали?
Мы сфокусировали деятельность всех архитекторов: дали возможность каждому архитектору заниматься своим любимым делом.
Теперь у нас…
Solution-архитектор отвечает:
за интеграции и взаимодействие между системами и модулями;
за реализацию решения на конкретном бизнес-направлении какой-то определенной бизнес-инициативы;
Solution-архитектор поднимается высоко вверх до энтерпрайз уровня, когда общается с Enterprise-архитекторами по поводу развития ландшафта в целом, и погружается в системную архитектуру, если техническое решение сложное.
Системный Архитектор отвечает:
за развитие систем (одной конкретной системы), нагрузку и обеспечение её масштабирования с точки зрения архитектуры;
за выбор системной архитектуры и обеспечение требований к бесперебойной работе, в соответствии с требованиями SLA;
за общие стандарты и общие подходы ведению кода, единиц развертывания так как одну систему могут разрабатывать очень большое количество команд.
Технический Архитектор отвечает за техническую архитектуру (железо, сетевое оборудование предприятия).
Enterprise-архитектор отвечает за стратегию развития архитектурного ландшафта предприятия в целом.
Также мы наладили внутрикорпоративный обмен знаниями и последними новостями: собрали около 800 экспертов во внутрикорпоративное комьюнити архитекторов и аналитиков с уникальной экспертизой.
Все находятся в Едином информационном пространстве, обмениваются знаниями, опытом, последними новостями. Мы приглашаем в это же сообщество и команды развития, и аналитиков, и всех экспертов. Аналитик, попадая в это сообщество, уверен, что ему окажут всестороннюю поддержку.
Итог — каждый занимается своим делом, но все в курсе, что происходит у других.
Непрерывный цикл производства
Искать информацию всегда сложно, и она быстро устаревает. Архитектурный ландшафт развивается стремительно, появляются новые системы и модули. А при проектировании хочется просто сосредоточиться на функционале и на продукте для клиента.
Что мы сделали? Мы взяли наши инструменты, нашу базу данных, окружение, систему модулей и компонентов и всё объединили в непрерывный цикл производства.
Как работает этот цикл?
На ранней стадии у нас есть концепт разной степени детальности.
Уже на стадии концепта появляются некоторые параметры безопасности. Они достаточно верхнеуровневые, но позволяют оценить решение.
Есть одобрение стейкхолдеров — после концептуального проектирования всё согласовывается.
Есть одобрение ответственных за развитие систем — они участвуют в согласовании концепта решения, если их систему планируется дорабатывать.
Производится более точная оценка проекта, стоимости доработок каждой системы и итоговый бюджет проекта более точен. Имея более точные данные, бизнес дает добро — проекту быть.
В ходе исполнения проекта у нас появляется ещё больше деталей, которые вносятся в единую БД и корректируются, если на ранней стадии где-то ошиблись. Здесь мы не создаём новые сущности, лишь уточняем уже существующие данные и в течение всего жизненного цикла проекта вносим их в единую систему.
Система RSM не позволяет сильно отклониться от концепта.
И, что самое главное, каждый следующий проект развивает наш единый репозиторий, обогащает и уточняет.
Назначаем ответственных
Отдельно следует отметить то, что в этот же цикл производства мы включили и процесс назначения ответственных.
Мы выделили достаточно внушительный перечень людей, которые отвечают за систему.
Когда мы проектируем новую систему, то:
сразу же закрепляем её за определенным департаментом;
у неё появляется Solution и Enterprise-архитектор;
система закрепляется за определенным ИТ департаментом в лице ИТ- директора;
По мере развития системы весь перечень ответственных корректируется и уточняется. У системы появляются ответственные за команды развития и команды сопровождения.
Все существующие системы банка теперь закреплены за ответственными — всё занесли в Единый общий реестр.
Итак, что у нас получилось?
Проект очень активно развивается но мы уже получили первые результаты.
Стейкхолдеры получили возможность дать рекомендации еще до того, как бюджет проекта сформирован. Все стейкхолдеры участвуют в согласовании концепта решения. Они видят изменения архитектурного ландшафта предприятия ещё до внесения изменений и могут оценить решение, дать рекомендации. Эти рекомендации учитываются при планировании бюджета.
У нас появился общий взгляд на архитектуру предприятия. Мы всё внесли в архитектурный репозиторий и наладили основные процессы по его актуализации в процессе работы всех команд, всех бизнес направлений и всех проектов. Мы перешли от ручной регистрации изменений и ведения реестров в различных системах к единой автоматизированной системе ведения архитектурного репозитория, которая непрерывно развивается, пополняется и корректируется с каждым новым изменением.
Все системы обрели владельцев и ответственных за развитие, за сопровождение, ответственных системных архитекторов. Всех можно просто и быстро найти.
Все системы промаркированы, классифицированы. Все видят статус системы. Информация доступна всем заинтересованным пользователям.
Архитектура стала прозрачной и доступной всем. Все видят архитектуру не только своей части, но и связи с другими системами, интеграции, и не просто те, которые существуют, но и те, что запланированы к реализации через полгода.
Мы сократили онбординг новых архитекторов практически в два раза. Прозрачная архитектура, инструментарий, поддержка наставников — всё это делает онбординг проще, понятнее и быстрее.
В дальнейшем мы планируем сделать:
Единый репозиторий бизнес-процессов. В рамках репозитория бизнес мог бы видеть, как их изменения влияют на общий ландшафт банка, сколько это стоит и какие риски приносит.
Единое пространство для проектирования еще больших артефактов. Например, артефакты кибербезопасности, системной архитектуры, артефакты, использующиеся при сопровождении систем.
Система автосогласования — система, которая позволит существенно ускорить процесс согласования и облегчит стейкхолдерам принятие решения по согласованию как концепта, так и документации проекта.
Система прогнозирования рекомендаций по архитектурным решениям. У нас уже существует достаточно большой объем данных по типовым интеграциям, по шаблонным архитектурным решением, постепенно собираем базу и статистику того, как согласуются решения. Мы будем использовать эти данные для сокращения времени проектирования.
Потенциал предлагаемого подхода и предлагаемых решений достаточно большой. Дальнейшее развитие будет приносить еще большую ценность для различных подразделений предприятия и для бизнеса.
Недавно мы выступали на митапе Alfa Analyze IT Meetup с темой «Как аналитику проще погрузиться в архитектуру?» Для статьи мы использовали материал из нашего доклада, но дополнили его. Если хотите изучить то, о чем мы говорим в статье немного с другой стороны оставим ссылку на видео.
Полезные ссылки:
Как Git LFS влияет на опыт ведения документации рядом с кодом
Docs as Code: как вести фронтовую документацию рядом с кодом, чтобы репозиторий не раздуло
«В ближайшие 6 лет требования к системным аналитикам вряд ли сильно изменятся». Интервью
Путь веб-мастера в системный анализ: инструменты, кейсы, мысли вслух
Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.
