Привет, коллега! Каждый из нас изобрел свой велосипед. И не один. Это нормально! Мы же программисты! И я горжусь тем, что умею изобретать велосипеды. Полезный опыт, в целом. И горжусь моими друзьями, которые тоже умеют. Мы - изобретательный народ)) Главное, чувство меры в этом деле. В прочем, как и в любом. Но это лирическое отступление.
Под делу. Я в комментарии https://habr.com/ru/company/bcs_company/blog/651765/#comment_24212403 частично ответил на этот вопрос. Этот раздел вообще самая дискуссионная часть шаблона, про которую мы спорили (и спорим) дольше всего. Сложно отделить абстракцию компонентов от реальной инфраструктуры и ее физических параметров. В реальности не часто приходится делать такие схемы. Большая часть задач живет в привычных сегментах, кластере микросервисов и т.п. Поэтому, это всегда какая-то уникальная работа, формат схемы. Сложно поддается формализации.
Я в описании к разделу писал, что сетевая схема предприятия - это секретная информация. Мы стараемся такие схемы делать отдельно от АР. И хранить отдельно. А лучше, вообще не делать)) Потому как, по таким схемам можно искать точки входа для атаки.
Тут надо понимать, что половина, а то и больше, разработок - это не фронт, а что-то в бэках, какая-то интеграция, где пользователя и нет как такового. Поэтому user story для архитектора полезная штука, но привычно отсутствующая. Там, где есть CGM, в основном команды сами делают АР. Я слежу лишь за качеством документа и не противоречивостью разработки с групповой точки зрения. Т.е. согласую АР не погружаясь в детали пользовательского опыта. Поэтому настоящая user story остается за рамками АР. Но бизнес процесс описан должен быть обязательно. Хотя бы словами.
Табличные представления руками заполняем. Самая муторная часть работы. Но, зачастую, схема + описание в таблице - это все, что нужно командам для начала разработки.
Точно разные! Деплой - это про куда: какие сервера, подсети, IP. Т.е. самый близкий к железу уровень. Системная архитектура - это про компоненты: на какие части бьются ваши функциональные блоки; как организована отказоустойчивость с точки зрения деления функц. блоков на шарды, кластеры и т.п.; какие брокеры и как используются для передачи сообщений; другие промежуточные компоненты, которые не интересны на схеме инфопотоков. Иными словами, схема инфопотоков - как организована разработка с точки зрения передачи информации, деления на функциональные блоки; схема компонентов - как реализована функциональная схема физически, на уровне ИТ-систем, служб, компонентов; деплой схема - как мы раскладываем блоки системы по физической сети конкретного предприятия.
Этот раздел - для свободного творчества. Мы его не формализуем. Если автор чувствует в себе силы дать читателю немного больше информации, чем сухие требования, он может описать ситуацию вокруг проекта/задачи.
Тут надо признаться, что не во всех организациях заказчики в состоянии сформулировать требования к доступности и надежности на входе. Поэтому их формулирует архитектор уже как результат своей работы. И это самая с-трудом-заполняемая часть шаблона, если АР делает команда разработки. Поэтому в конце. К слову, нагрузка на интеграцию приводится в описании схемы инфопотоков в последней колонке.
Если взять архитектуру, которую нам выдают команды разработки своими силами (до обучения), то это одна схема. Что-то среднее между инфопотоками, компонентной и системной. Черезполосица такая, местами инфопотоки, местами вызовы АПИ, местами компоненты. И это для людей достаточно, чтобы у себя в команде начать что-то делать. Это я к чему? К тому, что сильно раздувать АР пагубно. У нас их делают не только архитекторы. Заставить разработчиков сделать полноценный документ, это та еще история. Поэтому мы разрешаем ограничиться одной -двумя схемами и описанием к ним. Сценарии делают аналитики, когда они есть в проекте. В бизнес-требованиях или потом в спецификациях на разработку.
Чем заменить? Компонентная?
Привет, коллега! Каждый из нас изобрел свой велосипед. И не один. Это нормально! Мы же программисты! И я горжусь тем, что умею изобретать велосипеды. Полезный опыт, в целом. И горжусь моими друзьями, которые тоже умеют. Мы - изобретательный народ)) Главное, чувство меры в этом деле. В прочем, как и в любом. Но это лирическое отступление.
Под делу. Я в комментарии https://habr.com/ru/company/bcs_company/blog/651765/#comment_24212403 частично ответил на этот вопрос. Этот раздел вообще самая дискуссионная часть шаблона, про которую мы спорили (и спорим) дольше всего. Сложно отделить абстракцию компонентов от реальной инфраструктуры и ее физических параметров. В реальности не часто приходится делать такие схемы. Большая часть задач живет в привычных сегментах, кластере микросервисов и т.п. Поэтому, это всегда какая-то уникальная работа, формат схемы. Сложно поддается формализации.
Я в описании к разделу писал, что сетевая схема предприятия - это секретная информация. Мы стараемся такие схемы делать отдельно от АР. И хранить отдельно. А лучше, вообще не делать)) Потому как, по таким схемам можно искать точки входа для атаки.
Тут надо понимать, что половина, а то и больше, разработок - это не фронт, а что-то в бэках, какая-то интеграция, где пользователя и нет как такового. Поэтому user story для архитектора полезная штука, но привычно отсутствующая. Там, где есть CGM, в основном команды сами делают АР. Я слежу лишь за качеством документа и не противоречивостью разработки с групповой точки зрения. Т.е. согласую АР не погружаясь в детали пользовательского опыта. Поэтому настоящая user story остается за рамками АР. Но бизнес процесс описан должен быть обязательно. Хотя бы словами.
Табличные представления руками заполняем. Самая муторная часть работы. Но, зачастую, схема + описание в таблице - это все, что нужно командам для начала разработки.
Точно разные! Деплой - это про куда: какие сервера, подсети, IP. Т.е. самый близкий к железу уровень. Системная архитектура - это про компоненты: на какие части бьются ваши функциональные блоки; как организована отказоустойчивость с точки зрения деления функц. блоков на шарды, кластеры и т.п.; какие брокеры и как используются для передачи сообщений; другие промежуточные компоненты, которые не интересны на схеме инфопотоков. Иными словами, схема инфопотоков - как организована разработка с точки зрения передачи информации, деления на функциональные блоки; схема компонентов - как реализована функциональная схема физически, на уровне ИТ-систем, служб, компонентов; деплой схема - как мы раскладываем блоки системы по физической сети конкретного предприятия.
Спасибо за совет! Мы с требованиями по нагрузке сейчас экспериментируем. Это сложный момент, который у нас еще не имеет устоявшейся культуры.
Этот раздел - для свободного творчества. Мы его не формализуем. Если автор чувствует в себе силы дать читателю немного больше информации, чем сухие требования, он может описать ситуацию вокруг проекта/задачи.
Тут надо признаться, что не во всех организациях заказчики в состоянии сформулировать требования к доступности и надежности на входе. Поэтому их формулирует архитектор уже как результат своей работы. И это самая с-трудом-заполняемая часть шаблона, если АР делает команда разработки. Поэтому в конце. К слову, нагрузка на интеграцию приводится в описании схемы инфопотоков в последней колонке.
Если взять архитектуру, которую нам выдают команды разработки своими силами (до обучения), то это одна схема. Что-то среднее между инфопотоками, компонентной и системной. Черезполосица такая, местами инфопотоки, местами вызовы АПИ, местами компоненты. И это для людей достаточно, чтобы у себя в команде начать что-то делать. Это я к чему? К тому, что сильно раздувать АР пагубно. У нас их делают не только архитекторы. Заставить разработчиков сделать полноценный документ, это та еще история. Поэтому мы разрешаем ограничиться одной -двумя схемами и описанием к ним. Сценарии делают аналитики, когда они есть в проекте. В бизнес-требованиях или потом в спецификациях на разработку.
В среднем две недели на вариант для окончательного согласования. Т.е. уже обсужденный с разработчиками, смежниками и т.д.
Реализация сильно зависит от размера. От спринта и до бесконечности.
Ну, это просто)) Выключить все источники поступления "новых глав", не смотреть ленты бестселлеров. Пользоваться только поиском.