Как цели бизнеса формируют архитектуру будущей IT системы: руководство для предпринимателей

В попытке сэкономить, предприниматели часто рассказывают, что нужно разработать небольшую IT-систему, специально умалчивая о реальных задачах, масштабе и целях. Эта статья поможет вам понять, как четкое определение бизнес-целей и задач влияет на архитектуру будущей IT системы. Вы узнаете, почему важно быть откровенным на этапах планирования, какие архитектурные подходы существуют, как они соотносятся с бизнес-целями. А самое важное — какова цена ошибки? Привет, я Максим из Sailet. Мы специализируемся на заказной разработке, работаем с 2017 года, выполнили множество интересных проектов, рассказываем про автоматизацию и развиваем свой СЭД. Ранее я писал про ошибки в госсекторе и как их избежать. Теперь вернемся к бизнесу и продолжим разбирать проблемы, которые есть еще на старте. Одна из самых частых — недосказанность.

Откровенность как основа успешного проекта

Да, такая проблема действительно существует. Предприниматели часто умалчивают о реальных масштабах и задачах проектов, стремясь снизить первоначальные затраты. Это приводит к недостаточной оценке требований и выбору неподходящей архитектуры, что влечет за собой значительные дополнительные расходы в будущем.

Реальный кейс:

— Нам необходимо разработать систему приема заявок, что-то вроде профильной CRM. — Сколько будет пользователей? Какие сроки? и другие 100 500 вопросов. — Будет около 100 пользователей, возможно больше, но не сильно. 3 месяца на разработку. Спустя 2 месяца: — Скажите, мы же можем завести на платформу 800 компаний с 15к пользователями? — С текущим ресурсом, нет. — Почему? Мы же просили у вас характеристики сервера и платформы. — Мы дали данные под 500 человек с запасом. — Но, нам нужно 15,000.

Реальные данные:

1. Согласно исследованию Standish Group, 31% IT проектов отменяются до завершения, а 52% превышают бюджет.
2. Отчет McKinsey показывает, что 45% крупных IT проектов испытывают перерасход бюджета на 50% и более.

Следствие:

• Это ведет к выбору архитектуры, не способной масштабироваться или адаптироваться к будущим требованиям. Готовьтесь обновлять систему каждый год или вообще ее не закончить.
• Из-за необходимости изменений и оптимизаций уже в процессе эксплуатации повышаются затраты на разработку.
• Неподходящая архитектура может не справляться с увеличением нагрузки. «Что-то у нас всё долго работает?».

Подрядчик должен четко понимать РЕАЛЬНЫЕ цели и задачи бизнеса, чтобы как минимум выбрать правильную архитектуру IT системы, которая будет максимально эффективной. ВАЖНО с самого начала обсудить все сценарии использования и планы на будущее. Вы платите подрядчику за опыт и генерацию решений. Так предоставьте реальную информацию, чтобы решения были правильными. Эта простая вещь сэкономит вам кучу денег.

Что такое архитектура IT-системы?

Основы разобрали, давайте к техническим моментам. Краткий ликбез. Архитектура IT системы — это фундамент, который определяет её компоненты, их взаимодействие и принципы работы. Правильно спроектированная архитектура обеспечивает стабильность, производительность и масштабируемость системы. Неправильная обеспечивает боль… много боли… очень много боли… Конечно же, я про время и деньги в первую очередь, не считая нервы, стресс, упущенную выгоду и очень много боли… Надеюсь, удалось передать насколько этой боли будет много. В одном из проектов она стоила заказчику х6 от первоначального плана и полную переделку системы, которая была выполнена на 70%.

Основные виды архитектур

Монолитная архитектура

Вся система разрабатывается как единое целое, где все компоненты тесно связаны друг с другом.

• Плюсы: Простота разработки и развертывания.
• Минусы: Сложности масштабирования и обновлений.

Часто используется под MVP, небольшие платформы, внутренние порталы и т. д. Обычно до 10к пользователей.

Микросервисная архитектура

Система разделяется на независимые сервисы, каждый из которых отвечает за свою часть функционала. Представьте себе набор отдельных приложений, которые взаимодействуют друг с другом. Плюсы: Легкость масштабирования и обновлений. Если один сервис нуждается в изменениях, это не затрагивает остальные. Минусы: Сложность управления и настройки взаимодействия между сервисами. Точно избыточна на старте, но точно идеальная на масштабе. Если пользователей сразу от 5к, то обязательно ее.

Сервис-ориентированная архитектура (SOA)

Система строится из сервисов с общими интерфейсами. Это как если бы разные части вашей системы могли «разговаривать» друг с другом через стандартизированные протоколы.

• Преимущества: Гибкость интеграции. Легко добавлять новые сервисы.
• Недостатки: Требует тщательного планирования и управления, чтобы все части системы работали гармонично.

Часто в экосистемах и суперапах, вроде ЕГОВ, Каспи и т. д. Совсем большие. Теперь, давайте запомним, что при проектировании системы учитываются следующие параметры:

• Нагрузка: Количество пользователей и объем данных.
• Скорость и надежность: Время отклика и устойчивость к сбоям.
• Масштабируемость: Возможность расширения без потери производительности.

И вот для этого нам важно понимать цели и бизнес-задачи. Какой план на эту IT-систему? Для кого? Сколько пользователей? Что с ней будет дальше? Какие ключевые задачи должна решить? Куда растем? И т. д.

Божественная интеграция

Мы точно можем с этим всем помочь. Для этого нужно оставить заявку по ссылке. Делаем не всем, только после квалификации, потому что это бесплатно. Если вы хотите избежать боли, стресса и потерь, будьте откровенны с самого начала. Говорите честно о своих целях и задачах. Зафиксируйте 3 основных правила:

1. Поделитесь реальными планами и прогнозами с подрядчиком. Это поможет выбрать правильную архитектуру и избежать перерасходов.
2. Думайте на несколько шагов вперед. Планируйте масштабирование и учитывайте возможные изменения.
3. Обращайтесь к профессионалам, которые могут предложить оптимальные решения для вашего проекта. Ну как без этого)

Пы.сы. Пишите в комментариях темы об автоматизации/разработке/программировании/цифровизации, которые вас беспокоят и мы обязательно про них расскажем.

Вместо заключения

Если вы хотите избежать боли, стресса и потерь, будьте откровенны с самого начала. Говорите честно о своих целях и задачах. Зафиксируйте 3 основных правила: Поделитесь реальными планами и прогнозами с подрядчиком. Это поможет выбрать правильную архитектуру и избежать перерасходов. Думайте на несколько шагов вперед. Планируйте масштабирование и учитывайте возможные изменения. Обращайтесь к профессионалам, которые могут предложить оптимальные решения для вашего проекта. Ну как без этого) Пы.сы. Пишите в комментариях темы об автоматизации/разработке/программировании/цифровизации, которые вас беспокоят и мы обязательно про них расскажем.