Привет, я Максим из Sailet. Мы специализируемся на заказной разработке, работаем с 2017 года, выполнили множество интересных проектов, рассказываем про автоматизацию и развиваем свой СЭД.
Ранее я писал про ошибки в госсекторе и как их избежать. Теперь вернемся к бизнесу и продолжим разбирать проблемы, которые есть еще на старте. Одна из самых частых — недосказанность.
Да, такая проблема действительно существует. Предприниматели часто умалчивают о реальных масштабах и задачах проектов, стремясь снизить первоначальные затраты. Это приводит к недостаточной оценке требований и выбору неподходящей архитектуры, что влечет за собой значительные дополнительные расходы в будущем.
Реальный кейс:
- Нам необходимо разработать систему приема заявок, что-то вроде профильной CRM.
- Сколько будет пользователей? Какие сроки? и другие 100500 вопросов.
- Будет около 100 пользователей, возможно больше, но не сильно. 3 месяца на разработку.
Спустя 2 месяца:
- Скажите, мы же можем завести на платформу 800 компаний с 15к пользователями?
- С текущим ресурсом, нет.
- Почему? Мы же просили у вас характеристики сервера и платформы.
- Мы дали данные под 500 человек с запасом.
- Но, нам нужно 15,000.
Реальные данные:
Следствие:
Подрядчик должен четко понимать РЕАЛЬНЫЕ цели и задачи бизнеса, чтобы как минимум выбрать правильную архитектуру IT системы, которая будет максимально эффективной.
ВАЖНО с самого начала обсудить все сценарии использования и планы на будущее. Вы платите подрядчику за опыт и генерацию решений. Так предоставьте реальную информацию, чтобы решения были правильными. Эта простая вещь сэкономит вам кучу денег.
Основы разобрали, давайте к техническим моментам. Краткий ликбез.
Архитектура IT системы — это фундамент, который определяет её компоненты, их взаимодействие и принципы работы. Правильно спроектированная архитектура обеспечивает стабильность, производительность и масштабируемость системы.
Неправильная обеспечивает боль… много боли… очень много боли… Конечно же, я про время и деньги в первую очередь, не считая нервы, стресс, упущенную выгоду и очень много боли… Надеюсь, удалось передать насколько этой боли будет много.
В одном из проектов она стоила заказчику х6 от первоначального плана и полную переделку системы, которая была выполнена на 70%.
Монолитная архитектура
Вся система разрабатывается как единое целое, где все компоненты тесно связаны друг с другом.
Часто используется под MVP, небольшие платформы, внутренние порталы и т.д. Обычно до 10к пользователей.
Микросервисная архитектура
Система разделяется на независимые сервисы, каждый из которых отвечает за свою часть функционала. Представьте себе набор отдельных приложений, которые взаимодействуют друг с другом.
Точно избыточна на старте, но точно идеальная на масштабе. Если пользователей сразу от 5к, то обязательно ее.
Сервис-ориентированная архитектура (SOA)
Система строится из сервисов с общими интерфейсами. Это как если бы разные части вашей системы могли "разговаривать" друг с другом через стандартизированные протоколы.
Часто в экосистемах и суперапах, вроде ЕГОВ, Каспи и т.д. Совсем большие.
Теперь, давайте запомним, что при проектировании системы учитываются следующие параметры:
И вот для этого нам важно понимать цели и бизнес-задачи. Какой план на эту IT-систему? Для кого? Сколько пользователей? Что с ней будет дальше? Какие ключевые задачи должна решить? Куда растем? И т.д.
Мы точно можем с этим всем помочь. Для этого нужно оставить заявку по ссылке. Делаем не всем, только после квалификации, потому что это бесплатно.
Если вы хотите избежать боли, стресса и потерь, будьте откровенны с самого начала. Говорите честно о своих целях и задачах. Зафиксируйте 3 основных правила:
Пы.сы. Пишите в комментариях темы об автоматизации/разработке/программировании/цифровизации, которые вас беспокоят и мы обязательно про них расскажем.