5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Огранизатор круглого стола Максим Смирнов ведет блог про архитектуру и канал на Facebook.
Я очень рада, что такие события проводятся. Стать классным архитектором было и остается моей мечтой. Мне очень долго было не понятно, как вообще попадают в архитекторы, как нужно развиваться и какие направления выбирать, чтобы они привели к архитектуре, и я думаю, что такие вопросы возникают не только у меня. Замечательно, что есть сообщество, куда можно прийти и задать вопросы архитекторам.
На круглом столе было представлено 4 доклада по 15-20 минут и затем были вопросы из аудитории и обсуждение.
Доклады были краткими и по сути, а обсуждение было очень живое и развернутое.
Далее мои заметки по ходу докладов.
Геннадий Круглов
Certified SOA Architect, ктн, работа с ЦБ
Этапы процесса архитектуры: Вовлечение бизнес -> Вовлечение инженеров -> Прототипирование -> Выбор архитектурного стиля и технологического стека (микросервисы, монолит, SOA) -> Разработка драфта архитектуры -> Демонстрация заказчику -> Проектирование решение -> Документирование арх решения -> Архитектурный надзор
Нужно собрать бизнес требования и желательно сделать прототип — привлечь разработчиков.
На этапе выбора арх стиля — желательно вовлечь безопасность.
В разработке драфта архитектуры нужно показать все срезы архитектуры: бизнес, безопасность, технологии. Можно привлекать специалистов по каждой из области и они будут прорабатывать подробно. Затем архитектор это все консолидирует и обсуждает с заинтересованными лицами. После этого демонстрируем прототип заказчику. Принимается решение о старте проекта.
Если проект стартует, то выполняется детальное проектирование, детализируется уже архитектура. делается документация архитектуры. Далее запускается разработка и, так как в разработке какие-то моменты меняются и эволюционируют, нужно обновлять документацию и проверять, что делают в соответствии с архитектурой.
Навыки, которые нужны архитектору:
Дмитрий Романов, ИТСК (Газпром нефть)
Проектирование ИТ решений, архитектурное сопровождение проектов, около 80 проектов в год, 50 архитекторов.
Зачем нужен ИТ архитектор?
Как принимается решение о правильности концепции?
Работа Архитектора ИТ проекта
Компания ИТСК также выстраивает процесс Architecture as a Service, архитектурное сопровождение.
Доклад 3
Иван Лукьянов
Департамент Информационных технологий г. Москвы
Гос. услуги и МФЦ
Пусть Ивана в профессии: разработчик в Диасофт, аналитик, потом руководитель направления в Альфабанке, потом руководитель архитектуры в ДИТ.
Сначала строим архитектурный ландшафт и описываем существующую архитектуру.
Архитектор должен знать бизнес, в котором он работает и знать современные технологии.
На основе знаний и опыта, требований строим целевую архитектуру. И на основе разницы между существующей и целевой архитектурой описываем как достичь целевую архитектуру.
Важно:
Проектирование
Все решения проектируются с учетом целевой архитектуры. Архитектор утверждает решение в части архитектуры. Общий процесс реализации включает в себя все описанные выше пункты.
Методологическая поддержка общего процесса
Должна быть разработана методология, включая шаблоны используемых документов.
У нас разработан документ по общим принципам по TOGAF и Gartner, описанна методология проектирования, бизнес, проектирование и deployment.
Утвердили архитектурные принципы.Архитектурно-технологическое решение, где описаны бизнес требования и реализация. В этой парадигме делаются все наши проекты.
Черты архитектора:
Архитектура — это некое живое представление, чего мы хотим достичь с точки зрения поддержки бизнеса.
Евгений Асламов Aslamov
ГК Ланит
Путь в архитектуру Евгения: разработчик, аналитик, руководитель проектов.
Заказчики — боссы, комитеты, ИБ, те кто за идею.
Когда архитектор возникает в заказной разработке?
В лучшем случае, когда компания решает идти на какой-то конкурс и архитектор подготавливает заявку. Участвует в выявлении требований, подготовки документации проекта, утверждение технической реализации и т.д.
У заказчиков и заинтересованных лиц часто есть противоречивые требования, которые влияют на архитектора. Но есть контракт, если он составлялся без участия архитектора, то нужно и систему сделать чтобы работало и в контракт уложиться.
Архитектор создает базовые правила, в которых его команда может жить. Задает неприятные вопросы — коллегам, менеджерам, аналитикам, девопсам. И задает их самому себе.
Рассказывает, как надо, как должно быть, что интересного.
Часто архитектор выступает как консультант.
Архитектор часто отвечает за систему, которую создает перед бизнесом.
В больших проектах есть команда архитекторов (архитектор software, архитектор инфраструктуры, БД и т/д и есть ведущий архитектор)
Архитекторов управляет рисками — что систему можно будет использовать, что она не упадет, что ее можно будет ее развивать.
Как архитектор принимает архитектурные решения:
Сделали метамодель системы. Использовали метод ATAM.
Для того, чтобы поддерживать архитектурный контроль архитекторы собираются раз в 1 — 2 месяца и рассказывают о принятых арх решениях и выслушиваем критику коллег.
Статья Евгения на habr Готовим проект в Sparx Enterprise Architect. Наш рецепт
Далее была секция вопросов и ответов, самые запомнившиеся можно прочесть ниже.
software — ПО, тех стек, компоненты и их взаимодействие
БД — определяют какую БД использовать
Арх инфраструктуры — middleware
Арх системы — аппаратный уровень сети и прочее
Solution архитектор
Бизнес архитектор — главный и ведущий аналитик — знают все про бизнес
Ведущий архитектор — коммуникации
Иногда архитектор ИБ — но чаще экспертные роли
Геннадий:
Software — бывшие тим лиды или тех лиды или ведущие разработчики.
Дмитрий:
Архитекторы берутся из разработчиков из консультантов, с широкой экспертизой.
Разработчик умеет говорить и рисовать презентации — solution архитектор.
Дальше просто даем задачи другого уровня и смотрим как он справляется.
Евгений:
Примеры — опять же из разработки, потом администратором, потом тестировщиком, потом внедренцем и архитектором.
Студента — взяли из МГУ Мехмат, был умным коммуникабельным и не зазнайка. Он постоянно подходил критически к тому, что он делает, он дошел так до уровня прикладного архитектора. Человеку должно быть лень и он должен хотеть сделать мир лучше. Он может стать архитектором углубляя свои знания.
Иван:
Хороший разработчик и дальше можно углубляться в языки программирования. В свое время стало любопытно как рождается техническое задание, кто анализирует, кто принимает решение надо это или не надо делать. Это вопрос аналитический, можно попробовать эту роль. Следующий уровень — как решение рождается в целом, на уровне бизнеса. Как можно показать руководителю организации, что ему это нужно. Общаясь с руководителями, можно спуститься на уровень бизнес анализа и на уровень разработчика, которые хотят программировать. Это своеобразная роль коммивояжёра —
Грегори Хопп (Gregor Hohpe) — метафора лифта. Архитектор — это тот, кто поднимается из машинного зала на лифте — разработчики — менеджер — CIO — руководитель компании. На каждом этаже его ожидают какие-то риски и на каждом этаже он должен справляться с разными рисками — технологическими, политическими, коммуникационными.
Понравилось как об этом говорит Г. Греф, что нужны люди, которые умеют придумывать куда развиваться бизнесу и это основная роль архитектора.
Архитектор умеет собирать нужную информацию и донести до каждого уровня.
Вести встречу, быть медиатором.
Какой-то хороший спец назвался архитектором и если его за 1-2 года не съели, то ладно пусть остается.
Был некий эксперт, который назвался архитектором.
Есть исполнители, которые работают над архитектурным ландшафтом. Архитектура системы все-таки должна быть целостной и выполнять свои бизнес задачи. С точки зрения бизнеса архитектор — это человек, которые приводит систему в гармонию, которой можно управлять.
Основные показатели проекта:
Документ используют на этапе выбора технического решения, описали процесс, как собирать требования.
Репозиторий архитектурных моделей, к которому есть небольшая инструкция.
Общие документы — стратегии тех архитектуры.
Методики разработки.
Методики интеграции.
Методика моделирования.
На этапе сдачи в эксплуатацию есть различные чек листы.
Про решения — есть архитектурные стили. Например, микросервисы — разные технологии и эволюция решения. При проектировании нужно стараться не вводить большое число неизвестных компаний технологии одновременно. Наращивать сначала фундамент из технологий.
При этом важно мнение разработчиков и поддержки.
Например, если проект делается, а заказчик справшивает — а технологии модные? А блокчейн там есть? А Data Science?
Готовим набор слайдов, про то, что те технологии, которые выбраны они для этого проекта лучше и почему.
Полномочия между архитектором и PM должен быть баланс между полномочиями архитектор по технической, а PM по организационной.
В случае, если баланс смещен в сторону PM — можно получить проект в срок, но не работающий или не масштабируемый. А если в сторону архитектора, то можно получить прекрасный проект, когда уже он никому не нужен. Это как ответить на вопросы «Кого ты больше любишь маму или папу?».
Делаем документ внутренний, который отвечает на вопрос, как конкретно мы это делаем. Он разработан самими архитекторами, и там есть и бизнес часть и реализация (как конкретно реализуется решение, какие компоненты участвуют). В нем нет детального деплоймента.
Иван:
В больших организациях более 2000 человек сделать одну корпоративную архитектуру и ей следовать практически невозможно. Было сделано разделение на продукты (сервисы) и у каждого продукта есть свой стек технологий, и своя архитектура. Корпоративная архитектура нужна больше акционерам, чтобы они понимали, что куда движутся.
Chief IT architect — общий ландшафт корпоративной архитектуры.
Важно общение. Нужно выстраивать коммуникации и просто общаться.
Проектному архитектору может быть не нужно знание корпоративной архитектуры, но важно знать с кем будет интеграция и на что будет влияние.
Важно делать архитектурные комитеты, возможно знать туда не только корпоративных архитекторов, но и проектных.
Можно посмотреть на это с точки зрения value — кто приносит больше value. Если решения работают, то там и value.
Enterprise architecture сама по себе ценность не приносит, а приносит она ценность через solution архитекторов, которые уже реализуют конкретные задачи.
Никому не нужны generalist — все меньше нужны люди, которые знают ничего обо всем.
Сейчас все изменилось и полсотни технологий для архитектора хорошо знать в общих чертах, а лучше уметь на конкретные вопросы, например, достаточно ли тут RabbitMQ или нужна Kafka.
Есть ли какие-то комплексные модели, которые можно обсчитать, проверить и т.д.
Евгений: есть архитектурный репозиторий, но нет автоматизации. Вводили метрики, которые позволяют посмотреть в модели на системы, и как правило это анализ влияния. На этой основе делали оценку стоимости изменений.
Дмитрий: есть инструмент. Изначально использовали архитектурное хранилище, постепенно пришли к моделированию. В развитии пришли к выводу, что нужен репозиторий архитектурных моделей. Есть система ведения НСИ.
Очень здорово, что можно прийти и послушать архитекторов, познакомиться с сообществом. Такие встречи для меня всегда возможность понять, куда нужно копать, чтобы найти необходимые знания. Кроме того, можно обсудить рабочие кейсы и получить рекомендацию.
Спасибо Максиму Смирнову и ВШЭ за организацию круглого стола архитекторов!
P.S. Заметки писались по ходу докладов и могут содержать неточности, если увидели — пишите, я исправлю.
На фото замок Шамбор во Франции, говорят каждый владелец пристраивал по своей башенке. Иногда, архитектура проекта выглядит именно так. На мой взгляд, архитектор нужен для того, чтобы было все красиво и по-возможности просто, чтобы даже с кучей башенок в разном стиле, все равно получился бы красивый замок.
Я очень рада, что такие события проводятся. Стать классным архитектором было и остается моей мечтой. Мне очень долго было не понятно, как вообще попадают в архитекторы, как нужно развиваться и какие направления выбирать, чтобы они привели к архитектуре, и я думаю, что такие вопросы возникают не только у меня. Замечательно, что есть сообщество, куда можно прийти и задать вопросы архитекторам.
На круглом столе было представлено 4 доклада по 15-20 минут и затем были вопросы из аудитории и обсуждение.
Доклады были краткими и по сути, а обсуждение было очень живое и развернутое.
Далее мои заметки по ходу докладов.
Доклад 1
Геннадий Круглов
Certified SOA Architect, ктн, работа с ЦБ
Этапы процесса архитектуры: Вовлечение бизнес -> Вовлечение инженеров -> Прототипирование -> Выбор архитектурного стиля и технологического стека (микросервисы, монолит, SOA) -> Разработка драфта архитектуры -> Демонстрация заказчику -> Проектирование решение -> Документирование арх решения -> Архитектурный надзор
Нужно собрать бизнес требования и желательно сделать прототип — привлечь разработчиков.
На этапе выбора арх стиля — желательно вовлечь безопасность.
В разработке драфта архитектуры нужно показать все срезы архитектуры: бизнес, безопасность, технологии. Можно привлекать специалистов по каждой из области и они будут прорабатывать подробно. Затем архитектор это все консолидирует и обсуждает с заинтересованными лицами. После этого демонстрируем прототип заказчику. Принимается решение о старте проекта.
Если проект стартует, то выполняется детальное проектирование, детализируется уже архитектура. делается документация архитектуры. Далее запускается разработка и, так как в разработке какие-то моменты меняются и эволюционируют, нужно обновлять документацию и проверять, что делают в соответствии с архитектурой.
Навыки, которые нужны архитектору:
- Навыки коммуникации (убеждение, ведение переговоров)
- Презентации
- Произведения мозговых штурмов и воркшопов
- Знание архитектурных стилей
- Широкий кругозор современных технологий (стек) (понимать сильные и слабые стороны)
- Навыки проектирования решений и приложений
- Навыки разработки с использованием разных фреймворков, продуктов и языков программирования
- Знание фреймворков документирования решений
- Понимания разных типов SDLC
- Широкая сеть профессиональных связей
- Навыки в управлении командами разработки
Доклад 2 Архитектурное сопровождение ИТ проектов
Дмитрий Романов, ИТСК (Газпром нефть)
Проектирование ИТ решений, архитектурное сопровождение проектов, около 80 проектов в год, 50 архитекторов.
Зачем нужен ИТ архитектор?
Как принимается решение о правильности концепции?
- Техническая политика в области ИТ
- Опыт — создание аналогичных систем
- Коллеги — кто то в рамках компании или в других компаниях
- Вендор — консультации с разработчиками
- Тематические форумы
- Технопарк — апробации или пилот на базе Технопарка КИТ
Работа Архитектора ИТ проекта
- Выбор технического решения, чтобы уменьшить риски по срокам и по деньгам. Архитектор нужен, чтобы не было ситуации, когда 1 год делали проект, потом полгода поработали и поняли, что нет масштабирования, а потом 2 года переделывали. Убеждаемся, что все что мы говорим, действительно работает.
- В agile архитектор входит в команду проекта, в waterfall архитектор — участник проектной группы.
- Руководитель проекта просит архитектора в команду. Есть главный инженер проекта, который руководит технически проектом. Может сделать ТЗ и часть проектирования решения, разбирается в сложных тех вопросах. Если система упала в 2 часа ночи, то главный архитектор встает и устраняет проблему.
Компания ИТСК также выстраивает процесс Architecture as a Service, архитектурное сопровождение.
Доклад 3
Архитектура в ИТ проектах организации
Основные архцентры
Иван Лукьянов
Департамент Информационных технологий г. Москвы
Гос. услуги и МФЦ
Пусть Ивана в профессии: разработчик в Диасофт, аналитик, потом руководитель направления в Альфабанке, потом руководитель архитектуры в ДИТ.
Сначала строим архитектурный ландшафт и описываем существующую архитектуру.
Архитектор должен знать бизнес, в котором он работает и знать современные технологии.
На основе знаний и опыта, требований строим целевую архитектуру. И на основе разницы между существующей и целевой архитектурой описываем как достичь целевую архитектуру.
Важно:
- Видение пути
- Построение целевой архитектуры
- Постановка бизнес задач
- Хорошо описанная бизнес задача
Проектирование
Все решения проектируются с учетом целевой архитектуры. Архитектор утверждает решение в части архитектуры. Общий процесс реализации включает в себя все описанные выше пункты.
Методологическая поддержка общего процесса
Должна быть разработана методология, включая шаблоны используемых документов.
У нас разработан документ по общим принципам по TOGAF и Gartner, описанна методология проектирования, бизнес, проектирование и deployment.
Утвердили архитектурные принципы.Архитектурно-технологическое решение, где описаны бизнес требования и реализация. В этой парадигме делаются все наши проекты.
Черты архитектора:
- Коммуникации с руководством, с исполнителями, с поддержкой, с менеджерами и тестировщиками.
- Архитектор должен играть роль переводчика — переводить с языка бизнеса на технический язык и обратно.
- Уважение к коллегам.
- Постоянное развитие.
Архитектура — это некое живое представление, чего мы хотим достичь с точки зрения поддержки бизнеса.
Доклад 4
Евгений Асламов Aslamov
ГК Ланит
Путь в архитектуру Евгения: разработчик, аналитик, руководитель проектов.
Заказчики — боссы, комитеты, ИБ, те кто за идею.
Когда архитектор возникает в заказной разработке?
В лучшем случае, когда компания решает идти на какой-то конкурс и архитектор подготавливает заявку. Участвует в выявлении требований, подготовки документации проекта, утверждение технической реализации и т.д.
У заказчиков и заинтересованных лиц часто есть противоречивые требования, которые влияют на архитектора. Но есть контракт, если он составлялся без участия архитектора, то нужно и систему сделать чтобы работало и в контракт уложиться.
Архитектор создает базовые правила, в которых его команда может жить. Задает неприятные вопросы — коллегам, менеджерам, аналитикам, девопсам. И задает их самому себе.
Рассказывает, как надо, как должно быть, что интересного.
Часто архитектор выступает как консультант.
Архитектор часто отвечает за систему, которую создает перед бизнесом.
В больших проектах есть команда архитекторов (архитектор software, архитектор инфраструктуры, БД и т/д и есть ведущий архитектор)
Архитекторов управляет рисками — что систему можно будет использовать, что она не упадет, что ее можно будет ее развивать.
Как архитектор принимает архитектурные решения:
- формулирование неприятных вопросов — вопросник, по которому архитектор проходит
- создание модели системы — то как она устроена. Может быть верхнеуровневое, из 4х квадратиков и стрелочек, а может быть детальным.
Сделали метамодель системы. Использовали метод ATAM.
Для того, чтобы поддерживать архитектурный контроль архитекторы собираются раз в 1 — 2 месяца и рассказывают о принятых арх решениях и выслушиваем критику коллег.
Статья Евгения на habr Готовим проект в Sparx Enterprise Architect. Наш рецепт
Вопросы и ответы
Далее была секция вопросов и ответов, самые запомнившиеся можно прочесть ниже.
Какие архитекторы бывают?
software — ПО, тех стек, компоненты и их взаимодействие
БД — определяют какую БД использовать
Арх инфраструктуры — middleware
Арх системы — аппаратный уровень сети и прочее
Solution архитектор
Бизнес архитектор — главный и ведущий аналитик — знают все про бизнес
Ведущий архитектор — коммуникации
Иногда архитектор ИБ — но чаще экспертные роли
Откуда берутся архитекторы?
Геннадий:
Software — бывшие тим лиды или тех лиды или ведущие разработчики.
Дмитрий:
Архитекторы берутся из разработчиков из консультантов, с широкой экспертизой.
Разработчик умеет говорить и рисовать презентации — solution архитектор.
Дальше просто даем задачи другого уровня и смотрим как он справляется.
Евгений:
Примеры — опять же из разработки, потом администратором, потом тестировщиком, потом внедренцем и архитектором.
Студента — взяли из МГУ Мехмат, был умным коммуникабельным и не зазнайка. Он постоянно подходил критически к тому, что он делает, он дошел так до уровня прикладного архитектора. Человеку должно быть лень и он должен хотеть сделать мир лучше. Он может стать архитектором углубляя свои знания.
Иван:
Хороший разработчик и дальше можно углубляться в языки программирования. В свое время стало любопытно как рождается техническое задание, кто анализирует, кто принимает решение надо это или не надо делать. Это вопрос аналитический, можно попробовать эту роль. Следующий уровень — как решение рождается в целом, на уровне бизнеса. Как можно показать руководителю организации, что ему это нужно. Общаясь с руководителями, можно спуститься на уровень бизнес анализа и на уровень разработчика, которые хотят программировать. Это своеобразная роль коммивояжёра —
Грегори Хопп (Gregor Hohpe) — метафора лифта. Архитектор — это тот, кто поднимается из машинного зала на лифте — разработчики — менеджер — CIO — руководитель компании. На каждом этаже его ожидают какие-то риски и на каждом этаже он должен справляться с разными рисками — технологическими, политическими, коммуникационными.
Понравилось как об этом говорит Г. Греф, что нужны люди, которые умеют придумывать куда развиваться бизнесу и это основная роль архитектора.
Архитектор умеет собирать нужную информацию и донести до каждого уровня.
Вести встречу, быть медиатором.
Какой-то хороший спец назвался архитектором и если его за 1-2 года не съели, то ладно пусть остается.
Был некий эксперт, который назвался архитектором.
Есть исполнители, которые работают над архитектурным ландшафтом. Архитектура системы все-таки должна быть целостной и выполнять свои бизнес задачи. С точки зрения бизнеса архитектор — это человек, которые приводит систему в гармонию, которой можно управлять.
Как выстроить техническую политику?
Основные показатели проекта:
- Как нужно проектировать стратегию технической архитектуры
- Как нужно к ней идти
- Правила контроля архитектурного ландшафта
- Что нужно актуализировать документацию и отмечать новые технологии прочие веяния.
Документ используют на этапе выбора технического решения, описали процесс, как собирать требования.
Репозиторий архитектурных моделей, к которому есть небольшая инструкция.
Общие документы — стратегии тех архитектуры.
Методики разработки.
Методики интеграции.
Методика моделирования.
На этапе сдачи в эксплуатацию есть различные чек листы.
Как минимизируются риски в связи с архитектурой?
Про решения — есть архитектурные стили. Например, микросервисы — разные технологии и эволюция решения. При проектировании нужно стараться не вводить большое число неизвестных компаний технологии одновременно. Наращивать сначала фундамент из технологий.
При этом важно мнение разработчиков и поддержки.
Как готовится к ответам про новые технологии?
Например, если проект делается, а заказчик справшивает — а технологии модные? А блокчейн там есть? А Data Science?
Готовим набор слайдов, про то, что те технологии, которые выбраны они для этого проекта лучше и почему.
Как должны делится полномочия между руководителем проекта и архитектором?
Полномочия между архитектором и PM должен быть баланс между полномочиями архитектор по технической, а PM по организационной.
В случае, если баланс смещен в сторону PM — можно получить проект в срок, но не работающий или не масштабируемый. А если в сторону архитектора, то можно получить прекрасный проект, когда уже он никому не нужен. Это как ответить на вопросы «Кого ты больше любишь маму или папу?».
Делаем документ внутренний, который отвечает на вопрос, как конкретно мы это делаем. Он разработан самими архитекторами, и там есть и бизнес часть и реализация (как конкретно реализуется решение, какие компоненты участвуют). В нем нет детального деплоймента.
Как быть корпоративным архитекторам, у которых большой поток разных проектов?
Иван:
В больших организациях более 2000 человек сделать одну корпоративную архитектуру и ей следовать практически невозможно. Было сделано разделение на продукты (сервисы) и у каждого продукта есть свой стек технологий, и своя архитектура. Корпоративная архитектура нужна больше акционерам, чтобы они понимали, что куда движутся.
Chief IT architect — общий ландшафт корпоративной архитектуры.
Как строится взаимодействие между проектным архитектором и корпоративным архитектором?
Важно общение. Нужно выстраивать коммуникации и просто общаться.
Проектному архитектору может быть не нужно знание корпоративной архитектуры, но важно знать с кем будет интеграция и на что будет влияние.
Важно делать архитектурные комитеты, возможно знать туда не только корпоративных архитекторов, но и проектных.
Можно посмотреть на это с точки зрения value — кто приносит больше value. Если решения работают, то там и value.
Enterprise architecture сама по себе ценность не приносит, а приносит она ценность через solution архитекторов, которые уже реализуют конкретные задачи.
Никому не нужны generalist — все меньше нужны люди, которые знают ничего обо всем.
Сейчас все изменилось и полсотни технологий для архитектора хорошо знать в общих чертах, а лучше уметь на конкретные вопросы, например, достаточно ли тут RabbitMQ или нужна Kafka.
Как организованы архитектурные репозитории предприятия?
Есть ли какие-то комплексные модели, которые можно обсчитать, проверить и т.д.
Евгений: есть архитектурный репозиторий, но нет автоматизации. Вводили метрики, которые позволяют посмотреть в модели на системы, и как правило это анализ влияния. На этой основе делали оценку стоимости изменений.
Дмитрий: есть инструмент. Изначально использовали архитектурное хранилище, постепенно пришли к моделированию. В развитии пришли к выводу, что нужен репозиторий архитектурных моделей. Есть система ведения НСИ.
Послесловие
Очень здорово, что можно прийти и послушать архитекторов, познакомиться с сообществом. Такие встречи для меня всегда возможность понять, куда нужно копать, чтобы найти необходимые знания. Кроме того, можно обсудить рабочие кейсы и получить рекомендацию.
Спасибо Максиму Смирнову и ВШЭ за организацию круглого стола архитекторов!
P.S. Заметки писались по ходу докладов и могут содержать неточности, если увидели — пишите, я исправлю.
На фото замок Шамбор во Франции, говорят каждый владелец пристраивал по своей башенке. Иногда, архитектура проекта выглядит именно так. На мой взгляд, архитектор нужен для того, чтобы было все красиво и по-возможности просто, чтобы даже с кучей башенок в разном стиле, все равно получился бы красивый замок.