Comments 29
Немножко концептуальных дополнений.
Кажется, у вас не упомянуто, что каждый слой архитектуры делегирует только вниз. В текущих реалиях это почти всегда заставляет слой «ИБ+мониторинг» рисовать над стандартными biz, data, app and infra/tech слоями, и прикидывать его с самого начала, а не под п.5.
Ещё имхо требования по нагрузке удобнее определять в ограничениях, а не в нефункциональных характеристиках.
Спасибо за совет! Мы с требованиями по нагрузке сейчас экспериментируем. Это сложный момент, который у нас еще не имеет устоявшейся культуры.
Насчёт нагрузки и других аналогичных измеряемых штук есть такой вполне классический подход, что пороговые метрики, по которым будет производиться приёмка, описываются в ТЗ, как и методики проверки этих метрик (и деградации этих метрик для unhealthy системы).
Вот эти цифры, с некоторой расшифровкой, и попадают в ограничения архитектурного проекта.
Их реально легче учитывать не как требования (планка, которую нужно достичь), а как ограничения (плинтус, ниже которого нельзя упасть).
непонятно, где у вас функциональная модель, сценарии применения
быстрый переход к частям и компонентам, но зачем эти компоненты сотрудничают — непонятно
Если взять архитектуру, которую нам выдают команды разработки своими силами (до обучения), то это одна схема. Что-то среднее между инфопотоками, компонентной и системной. Черезполосица такая, местами инфопотоки, местами вызовы АПИ, местами компоненты. И это для людей достаточно, чтобы у себя в команде начать что-то делать. Это я к чему? К тому, что сильно раздувать АР пагубно. У нас их делают не только архитекторы. Заставить разработчиков сделать полноценный документ, это та еще история. Поэтому мы разрешаем ограничиться одной -двумя схемами и описанием к ним. Сценарии делают аналитики, когда они есть в проекте. В бизнес-требованиях или потом в спецификациях на разработку.
Подождите, но эта информация по функционалке где-то должна быть. Аргумент "командам для старта хватит" - ну такое, с ньюансами. В целом команды и без этого наверное могли побежать ) Чтоб бизнес-аналитик - встречал такое, но обычно после формулирования БТ и проработки инф. архитектуры.
Тут надо понимать, что половина, а то и больше, разработок - это не фронт, а что-то в бэках, какая-то интеграция, где пользователя и нет как такового. Поэтому user story для архитектора полезная штука, но привычно отсутствующая. Там, где есть CGM, в основном команды сами делают АР. Я слежу лишь за качеством документа и не противоречивостью разработки с групповой точки зрения. Т.е. согласую АР не погружаясь в детали пользовательского опыта. Поэтому настоящая user story остается за рамками АР. Но бизнес процесс описан должен быть обязательно. Хотя бы словами.
"3.3 Системная архитектура"
вы бы поизучали мировые разработки, например, 42010, а то изобретаете велосипеды, мешаете архитектуру и её представления
"6. Нефункциональные требования и дополнительная информация"
непонятно, почему это в конце, а не в начале, вы же на основании этих требований во многом решение проектируете
требования к доступности?
требования к надёжности?
если всего этого нет, то нет критериев для выбора и тестирования решений, можно брать любую фантазию, хоть FoxPro
Тут надо признаться, что не во всех организациях заказчики в состоянии сформулировать требования к доступности и надежности на входе. Поэтому их формулирует архитектор уже как результат своей работы. И это самая с-трудом-заполняемая часть шаблона, если АР делает команда разработки. Поэтому в конце. К слову, нагрузка на интеграцию приводится в описании схемы инфопотоков в последней колонке.
Архитектор занимается проектированием решения. Требования к качеству должны разрабатываться до проектирования решения — системными аналитиками, инженерами по требования.
Никто и не ожидает, что заказчики, например, холодильного оборудования для ресторана смогут сформулировать требования к надёжности холодильника. Поэтому по всех стандартах пишут, что требования разрабатываться совместно заказчиком и поставщиком.
Схемки с разной детализацией потоков данных полезные, наглядные!
2. Бизнес-архитектура
...
2.2 Требования
какие именно требования в бизнес-архитектуре? бизнес-требования, именно к бизнесу? или требования заинтересованных лиц? или требования к решению?
если требования к решению — то они не являются частью бизнес-архитектуры
2.1 Обзор предметной области
... Может быть описанием предметной области. Или описанием потребностей пользователя ... Стоит описать исторические предпосылки возникновения потребности или проблемы....
Исторические предпосылки важны, но они не являются частью предметной области. Предметная область существует независимо от компании и ситуации в ней, а вам важно знать и то и другое — и как устроено, например, страхование частных лиц в стране в целом и какая именно ситуация с процессами и сервисами страхования в конкретной компании, чью деятельность вы хотите улучшать с помощью новой автоматизации.
Похожие штуки делаем. Сколько у вас уходит времени на такой документ и сколько времени затем его реализуют в рабочем софте?
А разделы 3.3 и 3.4 точно разные? Табличные представления руками заполняете или используете какие-то тулы?
Точно разные! Деплой - это про куда: какие сервера, подсети, IP. Т.е. самый близкий к железу уровень. Системная архитектура - это про компоненты: на какие части бьются ваши функциональные блоки; как организована отказоустойчивость с точки зрения деления функц. блоков на шарды, кластеры и т.п.; какие брокеры и как используются для передачи сообщений; другие промежуточные компоненты, которые не интересны на схеме инфопотоков. Иными словами, схема инфопотоков - как организована разработка с точки зрения передачи информации, деления на функциональные блоки; схема компонентов - как реализована функциональная схема физически, на уровне ИТ-систем, служб, компонентов; деплой схема - как мы раскладываем блоки системы по физической сети конкретного предприятия.
Тут вопрос наверное в том кто потребители этой информации и цели ее формализации в виде артефакта. Вот есть неФТ, надо под некий SLA спроектировать отказо- и катастрофоустойчивое решение. Вы балансировку шардов субд, инстансы приложения покажете на одном вью, а размещение их на условном бэйрбоне и раунд-робин балансир по IP на другом вью? не кажется ли вам что могут возникнуть вопросы с совмещением информации в единую картину на разных уровнях OSI?
Табличные представления руками заполняем. Самая муторная часть работы. Но, зачастую, схема + описание в таблице - это все, что нужно командам для начала разработки.
Привет вам из ВТБ. У нас в целом выглядт похоже, с точностью до формы стрелочек ) Есть небольшой совет про раздел 3.3 "Системная архитектура" - у вас это не совсем сис. арх, а скорее только схема сетевых взаимодействий. Для самой схемы немного не хватает как минимум отрисованных сущностей мест подключений серверов - ведь каждый сервер подключен в какую-то сеть - vlan, vxlan и т.д. и для сетевиков и ИБ это очень важная информация. Может также на границах сегментов стоит добавить фаерволлы, чтоб было видно как идет трафик и где нужно заказывать доступы, плюс всякие приколы типа NAT.
Далее, чтоб раздел стал полноценной сис. архитектурой не хватает таких вещей как всякие инфраструктурные штуки:
- балансировщики нагрузки (SLB/GSLB, NAT/SNAT, пулы балансировки, ограничения по трафику, сессиям)
dns (нужно ли создавать какие-то fqdn для вашей системы)/ad (в каких доменах, какие технические учетки, какие группы нужны)
что-то про СХД (на каких системах лежат данные, как презентованы, сколько места, сколько iops и т.п.)
отдельный раздел про контейнеры (есть ли выделенный egress, ingress; квоты; всякие штуки типа сайд-каров)
Привет, коллега! Каждый из нас изобрел свой велосипед. И не один. Это нормально! Мы же программисты! И я горжусь тем, что умею изобретать велосипеды. Полезный опыт, в целом. И горжусь моими друзьями, которые тоже умеют. Мы - изобретательный народ)) Главное, чувство меры в этом деле. В прочем, как и в любом. Но это лирическое отступление.
Под делу. Я в комментарии https://habr.com/ru/company/bcs_company/blog/651765/#comment_24212403 частично ответил на этот вопрос. Этот раздел вообще самая дискуссионная часть шаблона, про которую мы спорили (и спорим) дольше всего. Сложно отделить абстракцию компонентов от реальной инфраструктуры и ее физических параметров. В реальности не часто приходится делать такие схемы. Большая часть задач живет в привычных сегментах, кластере микросервисов и т.п. Поэтому, это всегда какая-то уникальная работа, формат схемы. Сложно поддается формализации.
слово "системная" неудачная, т.к. каждый под системой понимает свою совокупность слоёв корпоративной архитектуры
...
Рабочий шаблон архитектурного решения