Бұл жазба автоматты түрде аударылған. Бастапқы тіл: Орысша
Ақшаны үнемдеу мақсатында кәсіпкерлер нақты міндеттер, масштаб және мақсаттар туралы арнайы үндемей, шағын IT жүйесін жасау керектігін жиі айтады. Бұл мақала бизнес мақсаттары мен міндеттерін нақты анықтау болашақ it жүйесінің архитектурасына қалай әсер ететінін түсінуге көмектеседі.
Жоспарлау кезеңдерінде ашық болу неліктен маңызды екенін, қандай архитектуралық тәсілдер бар екенін, олардың бизнес мақсаттарына қалай сәйкес келетінін білесіз. Ең бастысы, қатенің бағасы қандай?
Сәлем, Мен Sailet-тен Максиммін. Біз тапсырыс бойынша әзірлеуге маманданамыз, 2017 жылдан бастап жұмыс істейміз, көптеген қызықты жобаларды орындадық, автоматтандыру туралы айтып береміз және ЭҚЖ дамытамыз.
Мен бұған дейін мемлекеттік сектордағы қателіктер туралы және олардан қалай аулақ болу керектігі туралы жазған болатынмын. Енді бизнеске оралыңыз және әлі де басталған мәселелерді талдауды жалғастырыңыз. Ең жиі кездесетіндердің бірі-айтылмау.
ИЯ, мұндай проблема бар. Кәсіпкерлер бастапқы шығындарды азайтуға тырысып, жобалардың нақты ауқымы мен міндеттері туралы жиі үндемейді. Бұл талаптарды жеткіліксіз бағалауға және дұрыс емес архитектураны таңдауға әкеледі, бұл болашақта айтарлықтай қосымша шығындарды талап етеді.
Нақты жағдай:
- Біз бейіндік CRM сияқты өтінімдерді қабылдау жүйесін әзірлеуіміз керек.
- Пайдаланушылар қанша болады? Мерзімдері қандай? және басқа 100500 сұрақ.
- 100-ге жуық қолданушы болады, мүмкін одан да көп, бірақ көп емес. Әзірлеуге 3 ай.
2 айдан кейін:
- Айтыңызшы, біз платформада 15к пайдаланушысы бар 800 компанияны іске қоса аламыз ба?
- Ағымдағы ресурспен, жоқ.
- Неге? Біз сізден сервер мен платформаның сипаттамаларын сұрадық.
- Біз қормен 500 адамға деректер бердік.
- Бірақ, бізге 15,000 керек.
Нақты деректер:
- Standish Group зерттеуіне сәйкес, IT жобаларының 31% - ы аяқталғанға дейін жойылады, ал 52% - ы бюджеттен асып түседі.
- McKinsey есебі ірі IT жобалардың 45% - ы бюджеттің 50% немесе одан да көп артық шығындарын бастан кешіретінін көрсетеді.
Салдары:
- Бұл масштабтауға немесе болашақ талаптарға бейімделуге қабілетсіз архитектураны таңдауға әкеледі. Жүйені жыл сайын жаңартуға немесе оны мүлдем аяқтамауға дайындалыңыз.
- Өзгерістер мен оңтайландырулар қажеттілігіне байланысты, пайдалану процесінде даму шығындары артып келеді.
- Сәйкес емес архитектура жүктемені көбейте алмауы мүмкін. "Бізде бір нәрсе ұзақ уақыт жұмыс істей ме?”.
Мердігер бизнестің нақты мақсаттары мен міндеттерін нақты түсінуі керек, кем дегенде тиімді болатын it жүйесінің дұрыс архитектурасын таңдау керек.
Барлық пайдалану жағдайлары мен болашақ жоспарларын басынан бастап талқылау маңызды. Сіз мердігерге тәжірибе мен шешімдер жасау үшін төлейсіз. Сондықтан шешімдер дұрыс болуы үшін нақты ақпарат беріңіз. Бұл қарапайым нәрсе сізге көп ақша үнемдейді.
Біз негіздерді бөлшектедік, техникалық сәттерге келейік. Қысқа ликбез.
It жүйесінің архитектурасы оның компоненттерін, олардың өзара әрекеттесуін және жұмыс принциптерін анықтайтын негіз болып табылады. Дұрыс жобаланған архитектура жүйенің тұрақтылығын, өнімділігін және масштабталуын қамтамасыз етеді.
Дұрыс емес қамтамасыз етеді ауырсыну много көп ауырсыну очень өте көп ауырсыну Конечно Әрине, мен уақыт пен ақша туралы бірінші кезекте, нервтерді, стрессті, жоғалған пайданы және өте көп ауырсынуды есептемегенде Надеюсь бұл ауырсынудың қаншалықты көп болатынын жеткізе алдым деп үміттенемін.
Жобалардың бірінде ол Тапсырыс берушіге бастапқы жоспардан X6 және 70% орындалған жүйені толық қайта құруды талап етті.
Монолитті сәулет
Бүкіл жүйе барлық компоненттер бір-бірімен тығыз байланысты болатын бірлік ретінде дамиды.
- Артықшылықтары: әзірлеудің және орналастырудың қарапайымдылығы.
- Кемшіліктері: масштабтау және жаңарту қиындықтары.
Көбінесе MVP, шағын платформалар, ішкі порталдар және т.б. әдетте 10к пайдаланушыларға дейін қолданылады.
Микросервистік сәулет
Жүйе тәуелсіз қызметтерге бөлінеді, олардың әрқайсысы функционалдылықтың өз бөлігіне жауап береді. Бір-бірімен өзара әрекеттесетін жеке қосымшалар жиынтығын елестетіп көріңіз.
- Артықшылықтары: масштабтау мен жаңартудың қарапайымдылығы. Егер бір қызметке өзгеріс қажет болса, бұл қалғандарына әсер етпейді.
- Кемшіліктері: қызметтер арасындағы өзара әрекеттесуді басқару мен конфигурациялаудың күрделілігі.
Стартта дәл артық, бірақ масштабта мінсіз. Егер пайдаланушылар бірден 5к-ден болса, онда ол міндетті болып табылады.
Қызметке бағытталған сәулет (SOA)
Жүйе жалпы интерфейстері бар қызметтерден құрылады. Бұл сіздің жүйеңіздің әртүрлі бөліктері стандартталған хаттамалар арқылы бір-бірімен "сөйлесе" алатын сияқты.
- Артықшылықтары: интеграцияның икемділігі. Жаңа қызметтерді қосу оңай.
- Кемшіліктері: жүйенің барлық бөліктері үйлесімді жұмыс істеуі үшін мұқият жоспарлау мен басқаруды қажет етеді.
Көбінесе экожүйелер мен суперапаларда, мысалы, ЕГОВ, Каспи және т.б. өте үлкен.
Енді жүйені жобалау кезінде келесі параметрлер ескерілетінін есте сақтайық:
- Жүктеме: пайдаланушылар саны және деректер көлемі.
- Жылдамдық пен сенімділік: жауап беру Уақыты және ақауларға төзімділік.
- Масштабтау: өнімділікті жоғалтпай кеңейту мүмкіндігі.
Бұл үшін біз үшін мақсаттар мен іскерлік міндеттерді түсіну маңызды. Бұл IT жүйесіне қандай жоспар бар? Кім үшін? Қанша пайдаланушы бар? Оған не болады? Қандай негізгі міндеттерді шешу керек? Біз қайда өсеміз? Және т. б.
Біз бәріне көмектесе аламыз. Ол үшін өтінімді сілтеме бойынша қалдыру керек. Біз бәрін жасай бермейміз, тек біліктіліктен кейін, өйткені бұл тегін.
Егер сіз ауырсынудан, стресстен және жоғалтудан аулақ болғыңыз келсе, басынан бастап ашық болыңыз. Мақсаттарыңыз бен міндеттеріңіз туралы адал болыңыз. 3 негізгі ережені бекітіңіз:
- Нақты жоспарлар мен болжамдарды мердігермен бөлісіңіз. Бұл дұрыс архитектураны таңдауға және артық шығындардан аулақ болуға көмектеседі.
- Бірнеше қадам алға ойлаңыз. Масштабтауды жоспарлаңыз және мүмкін болатын өзгерістерді ескеріңіз.
- Сіздің жобаңыз үшін оңтайлы шешімдерді ұсына алатын мамандарға хабарласыңыз. Онсыз қалай)
Пы.сы. Түсініктемелерде сізді мазалайтын автоматтандыру/әзірлеу/бағдарламалау/цифрландыру тақырыптарын жазыңыз, біз олар туралы міндетті түрде айтып береміз.
В попытке сэкономить, предприниматели часто рассказывают, что нужно разработать небольшую 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 основных правила:
- Поделитесь реальными планами и прогнозами с подрядчиком. Это поможет выбрать правильную архитектуру и избежать перерасходов.
- Думайте на несколько шагов вперед. Планируйте масштабирование и учитывайте возможные изменения.
- Обращайтесь к профессионалам, которые могут предложить оптимальные решения для вашего проекта. Ну как без этого)
Пы.сы. Пишите в комментариях темы об автоматизации/разработке/программировании/цифровизации, которые вас беспокоят и мы обязательно про них расскажем.
Бөлісу
