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