Комментарии 4
Сбор бизнес-требований всегда идёт первым этапом, или за последние 50 лет что-то поменялось?
Вы представляете им детальный план работ, со сроками и рисками и тут то вам и говорят:
Ой, нам нужна отказоустойчивость, но на второй дата центр денег не дадим.
Ой, у нас перносальные данные, поэтому обмазываемся бюрократией.
Ой, мы хотим латенси 100 мс, но нам надо поставить всякие waf и прочее, поэтому 5 секунд нормально.
Ой, ставим только посгрес про, потому что купили.
И все такое прочее.
Классная статья, которая должна была заставить задуматься, что system design это утопия, которая существует только в голове у инженера и дальше, чем бахвальство на собеседовании не уходит, потому что дальше начинается бизнес. Но походу это пока все еще не получилось.
Вам озвучивают сроки в которые нужно уложиться и вы наполненные энтузиазмом и решительностью, приступаете как и положено с выявления требований к этой системе.
По моему опыту описанные в статье "бизнес ограничения" выявляются на этапе сбора требований. И сами по себе эти "ограничения" больше похожи на "требования". Если конечно не подходить к этапу сбора требований с излишнем формализмом. Не уточнить сроки, бюджет, технологические ограничения и технические компетенции команды - это, на мой взгляд, как минимум странно. Любой практикующий архитектор делает это на уровне безусловных рефлексов.
System Design: Как бизнес влияет на финальный вид ИТ-Системы и выбор технологий