Как стать автором
Поиск
Написать публикацию
Обновить

System Design: Как бизнес влияет на финальный вид ИТ-Системы и выбор технологий

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров2.2K
Всего голосов 2: ↑1 и ↓10
Комментарии4

Комментарии 4

Сбор бизнес-требований всегда идёт первым этапом, или за последние 50 лет что-то поменялось?

Добрый день.

Бизнес требования - как общие требования к продукту (именно что должно быть сделано? - функциональные требования) и правда дают страт проектированию, но зачастую делается акцент на общий функционал без углубления в ограничения (Сроки, Бюджет, рынок и тд.).

Вы представляете им детальный план работ, со сроками и рисками и тут то вам и говорят:

Ой, нам нужна отказоустойчивость, но на второй дата центр денег не дадим.

Ой, у нас перносальные данные, поэтому обмазываемся бюрократией.

Ой, мы хотим латенси 100 мс, но нам надо поставить всякие waf и прочее, поэтому 5 секунд нормально.

Ой, ставим только посгрес про, потому что купили.

И все такое прочее.

Классная статья, которая должна была заставить задуматься, что system design это утопия, которая существует только в голове у инженера и дальше, чем бахвальство на собеседовании не уходит, потому что дальше начинается бизнес. Но походу это пока все еще не получилось.

Вам озвучивают сроки в которые нужно уложиться и вы наполненные энтузиазмом и решительностью, приступаете как и положено с выявления требований к этой системе.

По моему опыту описанные в статье "бизнес ограничения" выявляются на этапе сбора требований. И сами по себе эти "ограничения" больше похожи на "требования". Если конечно не подходить к этапу сбора требований с излишнем формализмом. Не уточнить сроки, бюджет, технологические ограничения и технические компетенции команды - это, на мой взгляд, как минимум странно. Любой практикующий архитектор делает это на уровне безусловных рефлексов.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации