Представьте, вам поступает задача спроектировать абсолютно новую ИТ-Систему, которую ранее не видел свет. Вам озвучивают сроки в которые нужно уложиться и вы наполненные энтузиазмом и решительностью, приступаете как и положено с выявления требований к этой системе. Далее происходит этап отрисовки верхнеуровнего дизайна, где вы намечаете основные компоненты системы и способы их взаимодействия. Далее после получения одобрения от своих коллег, технического сектора, вы переходите на этап детальной проработки архитектуры, разбиваете ее на модули. Далее вы с умом подходите к оптимизации вашей системы (Кэширование, ограничение нагрузки, балансировка, репликация БД и тд.). И вот потратив много времени и сил у вас в руках результаты ваших трудов. Вы довольный, ни о чем не подозревая идете защищать свое отказоустойчивое, масштабируемой, надежное решение c мгновенным откликом перед руководителями и бизнесом. Вы представляете им детальный план работ, со сроками и рисками и тут то вам и говорят, что система не соответствует бизнес ограничениям! В этот момент обычно руки сами опускаются. Вы делали все по науке и современным стандартам, а вам говорят, что в таком виде система не может быть представлена пользователям, так как какие-то бизнес ограничения не соблюдены.

Эта ситуация по настоящему пугающая, так как драгоценное время, потраченное на проработку системы казалось бы по всем правилам System Design, ушло. Скоро релиз и получается нужно в короткие сроки все переделывать. Команда разработки будет простаивать, так как согласованный финальный вид архитектуры является приреквизитом для старта разработки. Дальше в дело вступает ваш героизм и желание все исправить в короткие сроки, чтобы все таки реализация новой системы не отставала от графика.

Ясно, что для того, чтобы избежать нежелательных последствий в будущем, нам необходимо заранее все предусмотреть.

Сегодня мы обсудим, что такое Бизнес-ограничения, какие они бывают и что сделать чтобы избежать переделок вашей системы на поздних этапах и почему «идеального дизайна» не существует, ведь System Design — это не только про технологии, но и про компромиссы. 

Бизнес ограничения

Бизнес-ограничения — это внешние или внутренние условия, которые накладывают рамки на проектирование и разработку IT-Системы. Они не связаны напрямую с технической реализацией, но критично влияют на архитектуру и выбор технологий.

Давайте поговорим о том, какие типы бизнес-ограничений встречаются:

1. Бюджетные ограничения

Сколько денег можно потратить на инфраструктуру, разработку и поддержку.

Примеры:
1. Облачный бюджет — не более $5к/мес. Выбираем более дешевые инстансы AWS.
2. Нет денег на коммерческие СУБД. Используем PostgreSQL вместо Oracle.

2. Временные ограничения

Сроки выхода продукта или отдельных фич.

Примеры:
1. MVP должен быть готов за 3 месяца. Выбираем монолит вместо микросервисов.
2. Фича “Онлайн-оплата” нужна к Чёрной пятнице. Приоритезируем её над другими задачами.

3. Объем работ

Что должно быть выполнено обязательно.

Примеры:
1. При создание сервиса "Интернет магазин", обязательно должен быть умный поиск товаров с фильтрами и сортировкой. Их то мы и учитываем в нашей системе.
2. В MVP сервиса Бронирования отелей можно ограничиться только поиском отелей в ленте, бронированием и предоплатой. Может воспользоваться внешними системами для реализации оплаты.

4. Юридические и compliance-ограничения

Требования закона или отраслевых стандартов.

Примеры:
1. Система должна соответствовать закону о персональных данных. Добавляем механизм удаления персональных данных.
2. Платежи должны проходить сертификацию PCI DSS. Запрещаем хранение CVC-кодов.

5. Рыночные ограничения

Ожидания пользователей или особенности рынка.

Примеры:
1. В Китае заблокирован Google Cloud. Разворачиваем систему на Alibaba Cloud.
2. Пользователи Африки часто используют 2G. Оптимизируем трафик и размер страниц.

Еще примеры того, как бизнес-ограничения влияют на System Design:

Пример 1: Бюджетное ограничение
Ограничение: Бюджет на сервера — $1к/мес.
Решение: Выбираем технологию, которая позволит уложиться в бюджет

Пример 2: Юридическое ограничение
Ограничение: Данные россиян должны храниться в РФ» (ФЗ-152).
Решение: Размещаем сервера только в дата-центрах Москвы. Не используем облачные хранилища расположенные за пределами страны.

Пример 3: Временное ограничение
Ограничение: Запуск через 2 месяца.
Решение: Выбираем low-code платформу вместо кастомной разработки или закупаем разработку у вендора (компания или организация, которая производит, разрабатывает и/или поставляет товары или услуги под собственной торговой маркой), который подготовит минимально жизнеспособный продукт, способный удовлетворить базовые потребности.

Разговор с бизнесом на одном языке

Давайте остановимся подробнее на 3х составляющих: Стоимость, Скорость, Объем работ и их влияние на наше конечное решение. В System Design эти три фактора образуют "Железный треугольник" (или "Тройное ограничение"), где изменение одного параметра влияет на остальные. Формула: "Хорошо, быстро, дёшево — выберите два":

1. Стоимость (Бюджет). Влияет на выбор технологий (облако vs свои серверы, open-source vs коммерческие решения), масштабируемость (дешёвое решение может не выдержать нагрузку), команду (опытные разработчики стоят дороже, поэтому выбирая технологию необходимо понимать, готовы ли к ней члены команды).

2. Скорость (Время потраченное на проработку решения). Влияет на архитектурные решения (микросервисы требуют больше времени, чем монолит), технологический стек (знакомые технологии ускоряют разработку), тестирование и деплой (CI/CD ускоряет выпуск фич, но требует настройки).

3. Объем работ (Что именно должно быть сделано в рамках проекта). Влияет на сложность системы (10 эндпоинтов vs 1000), количество интеграций (платёжные системы, аналитика, CRM), нефункциональные требования (нагрузка, безопасность, отказоустойчивость).

 Как Стоимость (бюджет) влияет на остальное?

• ↑ Бюджет → ↑ Скорость (можно нанять больше сильных разработчиков, способных справиться с задачей любой сложности, купить готовые решение у вендора).

• ↑ Бюджет → ↑ Качество (можно получить лицензию на качественное ПО или закупить больше необходимого оборудования - это все на прямую будет валяться на конечный вид системы) 

• ↓ Бюджет → ↑ Время или ↓ Качество (придётся делать всё самим и дольше, необходимо ужиматься, жертвуя компетентными разработчиками и качественным ПО).

Как Скорость влияют на остальное?

• ↑ Скорость → ↑ Стоимость или ↓ Качество (нанимаем больше людей или режем фичи, упрощая нашу финальную архитектуру).

• ↓ Скорость → ↓ Стоимость (но бизнес может упустить рынок, поэтому следует продумать архитектуру так, чтобы минимизировать время разработки при ограниченных ресурсах).

Как объём работ влияет на остальное?

• ↑ Объём → ↑ Стоимость или ↑ Время (больше кода, больше система → больше разработчиков чтобы уложиться в срок или оставляем все как есть и принимаем риск не успеть).

• ↓ Объём → можно сделать быстрее и дешевле (Упрощаем финальный вид системы, но рискуем не покрыть все сценарии, что в конечном счете может быть негативно воспринято пользователями).

Схематично обычно эти компромиссы представленный в виде треугольника, в который вписан круг - Качество, то есть то что мы получаем на выходе, после определения 3х величин.

Качество проекта не является независимой величиной. Оно определяется соотношением времени, стоимости и объема работ. Например, если заказчик хочет получить продукт быстро и дешево, то, скорее всего, придется пойти на компромисс в качестве. И наоборот, если заказчик хочет высокое качество и готов ждать, можно оптимизировать сроки и бюджет, чтобы достичь желаемого уровня. 

Для успешного согласования своего технического решения необходимо четко определить, что понимается под качеством в данной конкретной задаче или проекте. Это может быть соответствие определенным стандартам, удовлетворенность клиентов, надежность и т.д. Менеджер проекта должен понимать, как соотносятся между собой время, стоимость, объем и качество, чтобы принимать обоснованные решения и управлять рисками. А технический социалист реализует оптимальное решение которое будет согласовываться с бизнес-ограничениями.

Как балансировать между стоимостью, скоростью и объёмом?

Для того, чтобы грамотно балансировать между бизнес ограничениями и потенциальной архитектурой вашего решения необходимо:

1. Определите Бизнес ограничения:

   • Если главное — скорость (стартап), жертвуем идеальным дизайном.

   • Если главное — надёжность (банк), увеличиваем бюджет и сроки, что позволяем более творчески и смелей подойти к проектированию системы.

2. Считайте нагрузку и стоимость вашего решения. В таком случае вы сами будете в состоянии оценить, вписываетесь вы в бюджет, сроки и объем работ или нет. Тут важно обратить внимание на потенциальный пользовательский и сетевой трафик.

3. Используйте MVP-подход: Сначала — самое важное, потом масштабируем. То есть первая версия системы может быть далека от идеала, но должен быть задел на будущее. Отсюда вытекает следующий пункт.

4. Закладывайте гибкость: Например, монолит → микросервисы, когда будет нужно.

Вывод

Нет «идеального» дизайна — есть оптимальный для конкретного бизнеса. Прежде чем предлагать решение, до старта проектирования, задайте бизнесу следующие вопросы:

1. Какой бюджет?

2. Какие сроки?

3. Что умеет команда?

4. Есть ли регуляторные ограничения?

5. Как система будет зарабатывать?

Только после этого можно выбирать технологии.

PS

Также предлагаю вам ознакомится со статьей: System Design: Чек-лист по сбору и фиксации требований на все случае жизни.

И еще,

если вы желаете познать все тонкости System Design, не только работу с Бизнес-ограничениями, но и хотите научиться по всем правилам проектировать надежные и масштабируемые системы как Google, Netflix, Яндекс, Amazon или вы готовитесь к собеседованию по System Design - смело записывайтесь на мой курс на Stepik: C нуля до проектирования систем уровня senior-инженера.. Специально для Хабра действует промокод 20% HABR20