The post has been translated automatically. Original language: Russian
In an attempt to save money, entrepreneurs often say that they need to develop a small IT system, specifically keeping silent about the real tasks, scale and goals. This article will help you understand how a clear definition of business goals and objectives affects the architecture of a future IT system.
You will learn why it is important to be frank at the planning stages, what architectural approaches exist, and how they relate to business goals. And most importantly, what is the price of a mistake?
Hi, I'm Maxim from Sailet. We specialize in custom development, have been working since 2017, have completed many interesting projects, talk about automation and develop our EDMS.
Earlier I wrote about mistakes in the public sector and how to avoid them. Now let's get back to business and continue to sort out the problems that are still at the start. One of the most frequent is understatement.
Yes, such a problem does exist. Entrepreneurs often keep silent about the real scale and objectives of projects, in an effort to reduce initial costs. This leads to an insufficient assessment of requirements and the choice of an unsuitable architecture, which entails significant additional costs in the future.
The real case:
- We need to develop a system for accepting applications, something like a profile CRM.
- How many users will there be? What are the deadlines? and other 100,500 questions.
- There will be about 100 users, maybe more, but not much. 3 months for development.
After 2 months:
- Tell me, can we bring 800 companies with 15k users to the platform?
- With the current resource, no.
- why? We asked you for the server and platform specifications.
- We have given data for 500 people with a margin.
- But we need 15,000.
Real data:
- According to a Standish Group study, 31% of IT projects are cancelled before completion, and 52% exceed the budget.
- The McKinsey report shows that 45% of large IT projects experience budget overruns of 50% or more.
The consequence:
- This leads to the choice of an architecture that is not able to scale or adapt to future requirements. Get ready to update the system every year or not finish it at all.
- Due to the need for changes and optimizations already in operation, development costs increase.
- An unsuitable architecture may not be able to handle the increased load. “Has everything been working for a long time?"
The contractor must clearly understand the REAL goals and objectives of the business in order to at least choose the right architecture of the IT system that will be as effective as possible.
It is IMPORTANT to discuss all use cases and future plans from the very beginning. You pay the contractor for the experience and generation of solutions. So provide real information so that the decisions are correct. This simple thing will save you a lot of money.
We've sorted out the basics, let's get to the technical points. A brief educational program.
The architecture of an IT system is the foundation that defines its components, their interaction and principles of operation. A properly designed architecture ensures the stability, performance and scalability of the system.
The wrong one provides pain... a lot of pain... a lot of pain… Of course, I'm talking about time and money first of all, not counting nerves, stress, lost profits and a lot of pain… I hope I managed to convey how much this pain will be.
In one of the projects, it cost the customer x6 from the original plan and a complete redesign of the system, which was completed by 70%.
Monolithic architecture
The whole system is developed as a single whole, where all components are closely connected to each other.
- Advantages: Ease of development and deployment.
- Cons: Difficulties of scaling and updates.
It is often used for MVP, small platforms, internal portals, etc. Usually up to 10k users.
Microservice architecture
The system is divided into independent services, each of which is responsible for its own part of the functionality. Imagine a set of separate applications that interact with each other.
- Advantages: Ease of scaling and updates. If one service needs to be changed, it does not affect the rest.
- Cons: The complexity of managing and configuring interaction between services.
Definitely redundant at the start, but definitely perfect at scale. If the users are from 5k at once, then it is mandatory.
Service-oriented Architecture (SOA)
The system is built from services with common interfaces. It's as if different parts of your system could "talk" to each other through standardized protocols.
- Advantages: Flexibility of integration. It is easy to add new services.
- Disadvantages: It requires careful planning and management so that all parts of the system work harmoniously.
Often in ecosystems and superpaths, such as EGOV, Kaspi, etc. Very big ones.
Now, let's remember that the following parameters are taken into account when designing the system:
- Load: The number of users and the amount of data.
- Speed and reliability: Response time and fault tolerance.
- Scalability: The ability to expand without loss of performance.
And for this, it is important for us to understand the goals and business objectives. What is the plan for this IT system? For whom? How many users are there? What will happen to her next? What are the key tasks to solve? Where are we growing up? Etc.
We can definitely help everyone with this. To do this, you need to submit a request via the link. We don't do it for everyone, only after qualification, because it's free.
If you want to avoid pain, stress, and loss, be honest from the very beginning. Speak honestly about your goals and objectives. Fix the 3 basic rules:
- Share real plans and forecasts with the contractor. This will help you choose the right architecture and avoid cost overruns.
- Think a few steps ahead. Plan for scaling and consider possible changes.
- Contact professionals who can offer optimal solutions for your project. Well, how about it)
Please write in the comments the topics about automation/development/programming/digitalization that you are concerned about and we will definitely tell you about them.
В попытке сэкономить, предприниматели часто рассказывают, что нужно разработать небольшую 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 системы — это фундамент, который определяет её компоненты, их взаимодействие и принципы работы. Правильно спроектированная архитектура обеспечивает стабильность, производительность и масштабируемость системы.
Неправильная обеспечивает боль… много боли… очень много боли… Конечно же, я про время и деньги в первую очередь, не считая нервы, стресс, упущенную выгоду и очень много боли… Надеюсь, удалось передать насколько этой боли будет много.
В одном из проектов она стоила заказчику х6 от первоначального плана и полную переделку системы, которая была выполнена на 70%.
Монолитная архитектура
Вся система разрабатывается как единое целое, где все компоненты тесно связаны друг с другом.
- Плюсы: Простота разработки и развертывания.
- Минусы: Сложности масштабирования и обновлений.
Часто используется под MVP, небольшие платформы, внутренние порталы и т.д. Обычно до 10к пользователей.
Микросервисная архитектура
Система разделяется на независимые сервисы, каждый из которых отвечает за свою часть функционала. Представьте себе набор отдельных приложений, которые взаимодействуют друг с другом.
- Плюсы: Легкость масштабирования и обновлений. Если один сервис нуждается в изменениях, это не затрагивает остальные.
- Минусы: Сложность управления и настройки взаимодействия между сервисами.
Точно избыточна на старте, но точно идеальная на масштабе. Если пользователей сразу от 5к, то обязательно ее.
Сервис-ориентированная архитектура (SOA)
Система строится из сервисов с общими интерфейсами. Это как если бы разные части вашей системы могли "разговаривать" друг с другом через стандартизированные протоколы.
- Преимущества: Гибкость интеграции. Легко добавлять новые сервисы.
- Недостатки: Требует тщательного планирования и управления, чтобы все части системы работали гармонично.
Часто в экосистемах и суперапах, вроде ЕГОВ, Каспи и т.д. Совсем большие.
Теперь, давайте запомним, что при проектировании системы учитываются следующие параметры:
- Нагрузка: Количество пользователей и объем данных.
- Скорость и надежность: Время отклика и устойчивость к сбоям.
- Масштабируемость: Возможность расширения без потери производительности.
И вот для этого нам важно понимать цели и бизнес-задачи. Какой план на эту IT-систему? Для кого? Сколько пользователей? Что с ней будет дальше? Какие ключевые задачи должна решить? Куда растем? И т.д.
Мы точно можем с этим всем помочь. Для этого нужно оставить заявку по ссылке. Делаем не всем, только после квалификации, потому что это бесплатно.
Если вы хотите избежать боли, стресса и потерь, будьте откровенны с самого начала. Говорите честно о своих целях и задачах. Зафиксируйте 3 основных правила:
- Поделитесь реальными планами и прогнозами с подрядчиком. Это поможет выбрать правильную архитектуру и избежать перерасходов.
- Думайте на несколько шагов вперед. Планируйте масштабирование и учитывайте возможные изменения.
- Обращайтесь к профессионалам, которые могут предложить оптимальные решения для вашего проекта. Ну как без этого)
Пы.сы. Пишите в комментариях темы об автоматизации/разработке/программировании/цифровизации, которые вас беспокоят и мы обязательно про них расскажем.
Share
