Post #815

Откуда берутся нефункциональные требования? Сформулировал тут в одной архитектурной дискуссии 4 основных источника: 📊показатели назначения (объемы и скорости: сколько чего у нас есть в бизнесе, и насколько быстро нам нужно осуществлять действия, как долго хранить информацию, что для нас важнее — скорость одной транзакции или пропускная способность — число транзакций в единицу времени. Понятно, откуда эту информацию взять: из изучения бизнеса) 🧨анализ рисков (что будет, если система не будет функционировать X минут/часов, если у нас пропадут данные, если система по ошибке выдаст что-то не то, если не найдем на рынке специалистов по этому языку программирования/технологии, если, если, если... Тут тоже понятно: идентифицируем источники риска, оцениваем вероятность и возможный ущерб, принимаем решение по режиму обработки риска) 🚧внешние и внутренние ограничения (совместимость с внешними системами, их требования по нагрузке, форматам, безопасности и т.д.; регуляторные требования, замечания аудиторов; наличие технических средств; структура, культура и навыки команд; процесс бюджетирования, экономические и политические возможности) 🗺 стратегии развития (насколько всё вышеперечисленное будет меняться, в том числе и функциональные требования — это, пожалуй, единственное место, где они всплывают. Сюда же укладываются все требования внутреннего качества — насколько легко будет систему менять, с учетом возможного развития и известных ограничений). Дискуссия, собственно, была про обычную тему: какие архитекторы уникальные и как они всё это могут интуитивно угадать, обладая высокой насмотренностью, опытом, прагматизмом, пониманием контекста и ответственностью. Конечно, также обязательно, чтобы архитектор вышел из разработчиков. Ну и никакой ИИ это взять на себя не может. Мне это живо напомнило цитату 1979 года про структурный анализ: Большая тайна системного анализа была изложена совершенно открыто. Это не было искусством, во всяком случае не настолько искусством, это был метод, подход, техника. Хотя было бы диким упрощением сказать, что любой мог сделать это, конечно, это определенно не было уделом волшебников или гениев. Вот хочется такую же книгу про тайны архитектуры, без магии и скрытых знаний. "Нужно сделать то-то и то-то, для этого следуйте такому-то алгоритму. Вам понадобится вот такая информация." Работа архитектора ведь, по сути — про принятие решений (со всей полнотой ответственности). А уж эта область, кажется, разработана довольно детально, даже с неплохой математикой. Которой, кстати, учат как раз на институтских курсах "системного анализа". Так что если вы вдруг хотите переходить из роли аналитика в роль архитектора — начинайте с принятия решений, или хотя бы с организации их принятия, помощи в их принятии и их фиксации. В ADR, например. Архитекторы ленятся их вести, ну хотя бы аналитики пусть ведут. Потом можно будет как аргумент использовать при запросе повышения: всего зафиксировано столько-то решений, непосредственно с моей помощью принято из них столько-то.