Критические факторы успеха реализации микросервисной архитектуры в проекте информационной системы

Аннотация

Микросервисная архитектура (MSA) обещает улучшения в информационных системах, включая повышение производительности, масштабируемости, доступности и удобства сопровождения. Однако проблемы на этапах проектирования, разработки и эксплуатации могут препятствовать успешному развертыванию. В данном исследовании представлено тематическое исследование одной из ведущих телекоммуникационных компаний Индонезии, которая столкнулась с трехмесячной задержкой при внедрении микросервисной архитектуры (MSA). Исследование направлено на предоставление практических рекомендаций для компании по улучшению развертывания MSA и вклад в академические знания путем предложения структурированного подхода к оценке критических факторов успеха (CSF) в аналогичных контекстах.

Посредством обзора литературы был идентифицирован двадцать один фактор и классифицирован в четыре группы: (1) Организация, (2) Процесс, (3) Системы и инструменты и (4) Знания, навыки и поведение. Для оценки приоритета каждого фактора на основе данных опроса исполнителей проектов и практиков разработки программного обеспечения использовался метод анализа иерархий (AHP). Результаты показывают, что категория "Организация" является наиболее важной, при этом (1) Поддержка высшего руководства, (2) Четкое видение и (3) Достаточные ресурсы являются тремя главными CSF для реализации MSA.

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

I. Введение

Микросервисная архитектура (MSA) стала преобладающей тенденцией в разработке программного обеспечения в последние годы [1]. Появление микросервисной архитектуры набрало обороты в начале 2010-х годов, послужив контрмерой сложностям, возникающим при разработке, развертывании и масштабировании монолитных приложений [2]. Команды разработчиков программного обеспечения и организации в различных секторах приняли микросервисную архитектуру для создания и управления своими приложениями [3]. Внедрение MSA охватывает множество отраслей, от технологий до электронной коммерции и банковского дела, и в различных средах разработки, от облачных вычислений до локальных решений [4].

MSA разделяет монолитное приложение на набор более мелких, изолированных и взаимосвязанных сервисов [5]. Каждая из этих служб несет определенные обязанности и работает независимо от других, тем самым позволяя командам разработчиков работать изолированно и снижать общую сложность системы [6]. Популярность MSA обусловлена ее большей гибкостью в разработке, возможностью независимого масштабирования и обновления компонентов, а также содействием системному управлению и безопасности [7].

Несмотря на улучшения и преимущества, предлагаемые внедрением MSA, O'Reilly опубликовал исследование [8], в котором были определены потенциальные проблемы, возникающие на различных этапах внедрения MSA (проектирование, разработка и эксплуатация), такие как преодоление существующего мышления, декомпозиция функциональности и интеграция с унаследованной системой в качестве трех основных проблем. Были выявлены межфазные проблемы в проектировании, разработке и эксплуатации, включая архитектуру, управление, мониторинг, тестирование и другие [9]. Несколько исследователей также изучили выгоды и проблемы развертывания MSA [9],[10].

В качестве тематического исследования одна из ведущих телекоммуникационных компаний Индонезии совершенствует свою систему управления персоналом для повышения доступности, масштабируемости и ремонтопригодности. Одной из предпринимаемых инициатив был переход от монолитной архитектуры к архитектуре на основе микросервисов. Однако в процессе разработки возникли проблемы, в результате чего поставка проекта была отложена на три месяца по сравнению с первоначальным целевым сроком. На основе интервью с одним из технических менеджеров, сложность текущей монолитной системы и недостаток опыта работы с микросервисами на организационном уровне привели к тому, что продолжительность важных аспектов, таких как разработка и тестирование, заняла больше времени, чем ожидалось. Данная проблема согласуется с исследовательскими и практическими данными, которые предполагают, что MSA не является панацеей, поскольку представляет несколько проблем на этапах ее реализации [11]. Около 9% респондентов испытали полный провал (совсем не успешно), и 37% сообщили об ограниченном успехе (некоторый успех) в своих усилиях по внедрению MSA [8].

Предыдущие исследования изучали проблемы и преимущества, которые можно рассматривать как кандидатов в факторы, влияющие на внедрение MSA. Во-первых [6], предлагает содержательную историческую перспективу эволюции микросервисов, выделяя ключевые переходы, которые сформировали современные практики разработки программного обеспечения. Во-вторых [10], предоставляет ценные эмпирические данные из отрасли о практических проблемах внедрения микросервисов, непосредственно поддерживая мой анализ различий в развертывании между общедоступным облаком и локальными системами. В-третьих [11], углубляется в текущие препятствия и будущие направления для микросервисов, обогащая обсуждение текущих проблем и возникающих тенденций.

Значительные преимущества, предлагаемые внедрением MSA, в сочетании с проблемами, с которыми сталкиваются во время его выполнения, формируют основу данного исследования. Предыдущие исследователи заложили прочную основу знаний о преимуществах, проблемах и задачах внедрения MSA, однако не было структурированного сбора критических факторов успеха (CSF) в рамках конкретных тематических исследований, особенно в Индонезии. Следовательно, данное исследование направлено на определение и решение исследовательского вопроса:

RQ: Каковы критические факторы успеха реализации микросервисной архитектуры в проекте информационных систем?

Автор также утверждает, что успех инициативы или программы неразрывно связан с внутренними возможностями организации. Эти возможности состоят из четырех компонентов: (1) Организация, (2) Процессы, (3) Системы и инструменты и (4) Знания, навыки и поведение [12]. Эти компоненты формируют основу для категоризации критических факторов, выявленных в данном исследовании.

II. Методы исследования

Данное исследование организовано в три этапа, как показано на Рис. 1. Этап 1 включает идентификацию Критических факторов успеха (CSF) посредством систематического обзора литературы (SLR) и категоризацию этих факторов на основе категорий возможностей. Этап 2 включает разработку и проведение опроса, предназначенного для сбора количественных данных, служащих основой для процесса расстановки приоритетов. Этап 3 включает оценку уровней приоритета с использованием метода анализа иерархий (AHP), методологии, которая облегчает многокритериальное принятие решений.

Рис. 1. Метод исследования.

III. Определение факторов успеха

A. Изучение литературы

На начальном этапе данного исследования исследователи провели изучение литературы для выявления Критических факторов успеха (CSF) при реализации Микросервисной архитектуры (MSA). Таблица I показывает, что изучение литературы началось с ручного поиска в электронном источнике данных (EDS) Google Scholar, в результате чего было найдено десять релевантных исследований.

ТАБЛИЦА I. ВЫБОР ИССЛЕДОВАНИЙ

Для дальнейшего исследования были выбраны два дополнительных EDS, а именно ScienceDirect и IEEE Xplore, для систематического обзора литературы (SLR) с использованием трехэтапного метода.

• Выполнение строки поиска: Выполнение строк поиска было выполнено в соответствии со спецификациями, изложенными в Таблице II. Эти два источника данных были нацелены на SLR и успешно собрали 413 научных статей из журналов и конференций.
• Извлечение исследований: 413 научных статей прошли дальнейший процесс фильтрации на основе заголовков и ключевых слов для определения их релевантности для углубленного чтения. В результате было отобрано 68 статей, основной целью которых было избежать исследований, сфокусированных на технических реализациях в виде прикладных решений, которые не входили в поиск факторов.
• Скрининг и отбор исследований: Всего 29 исследований, состоящих из 19 исследований SLR (11 из ScienceDirect и восемь из IEEE Xplore) плюс десять исследований, идентифицированных вручную, были продвинуты для более тщательного изучения. Это включало быстрое чтение аннотаций, результатов исследований, обсуждений и выводов, чтобы определить, содержат ли они факторы, релевантные внедрению MSA.

ТАБЛИЦА II. СПЕЦИФИКАЦИЯ ИССЛЕДОВАНИЯ SLR

B. Определение факторов успеха

В этом разделе исследователи разъясняют Критические факторы успеха (CSF), выявленные в результате изучения литературы. Всего было обнаружено 21 критический фактор успеха для реализации Микросервисной архитектуры (MSA), описанные ниже.

1. Поддержка высшего руководства: Поддержка, проявляемая высшими руководителями организации в отношении конкретной инициативы или проекта, включает признание, распределение ресурсов и активное участие высшего руководства в руководстве, поощрении и поддержке успеха инициативы. Исследователи сходятся во мнении, что успех внедрения информационной системы неотделим от всесторонней поддержки со стороны высшего руководства в учреждении или компании [33]-[34].
2. Четкое видение: Исследование [35] добавляет четкое видение как критический фактор успеха внедрения информационной системы в свою структуру. Четкое видение включает цели, которые должны быть достигнуты, доступные ресурсы, сроки, системы, которые должны быть внедрены, поставщиков и возможные методы, необходимые для достижения этих целей.
3. Организационная культура: Внедрение MSA может стимулировать изменение организационной культуры через разделение команд на более мелкие единицы, уменьшая зависимости и коммуникацию между командами. Это также может снизить затраты в процессе управления [10]. Проведенный опрос [30] упоминает, что MSA приводит к лучшей разработке и развертыванию с масштабируемостью по сравнению с монолитной архитектурой; однако есть проблемы, когда организационная культура становится основным фактором во внедрении MSA. Организационная культура также значительно влияет на производительность и эффективность компании, моральный дух и продуктивность сотрудников, а также на ее способность привлекать, мотивировать и удерживать талантливых людей [36].
4. Достаточные ресурсы: Менеджеры проектов и архитекторы программного обеспечения являются основным фокусом высоких затрат на разработку при внедрении MSA из-за отсутствия у разработчиков опыта внедрения MSA [22]. Необходимость проектирования хорошей архитектуры MSA для оптимизации производительности приложений на основе MSA требует адекватных ресурсов программной архитектуры [29]. В контексте данного исследования адекватные ресурсы включают технические, финансовые и человеческие ресурсы, выделенные для процесса внедрения.
5. Управление проектами: Эффективное управление проектами является критической потребностью для каждой инициативы проекта информационной системы [31]. Управление проектами охватывает процессы планирования, организации, направления и контроля используемых ресурсов для достижения целей проекта в установленные сроки, бюджет и ограничения по объему. Задачи инженерии требований (RE) и не-RE, такие как контроль перехода требований в код, координация или управление проектами, рассматриваются как необходимые навыки в эпоху MSA [43]. Синхронизация между командами также является проблемой при разработке микросервисной архитектуры из-за сложных зависимостей и коммуникации сервисов [47].
6. Управление изменениями: Управление сопротивлением в процессе внедрения новой инициативы является важным фактором; организации должны иметь хорошее планирование для эффективного выполнения проектов [31]. Процесс управления изменениями в организации включает понимание, подготовку, выполнение и мониторинг изменений для достижения желаемых результатов и минимизации потенциальных негативных impacts.
7. Обучение и образование: Основная цель обучения - повысить навыки, знания и уровень компетенции всех пользователей в организации. Обучение должно предоставляться и рассматриваться как часть процесса внедрения, потому что оно влияет на коллективные убеждения о преимуществах внедряемой системы [31]. Практикам микросервисов следует иметь компетенции по крайней мере в одной, в идеале нескольких, из основных ролей MSA (веб-разработчик, DevOps-инженер или инженер данных). Три основные группы компетенций указывают на основные технические навыки, которыми должны обладать практики, желающие работать с микросервисами [45].
8. Выбор поставщика: Процесс выбора поставщиков, которые будут сотрудничать с организацией для предоставления конкретных продуктов, услуг или решений. Это включает оценку и отбор поставщиков, которые наилучшим образом соответствуют потребностям и требованиям организации. Тщательный выбор поставщиков, продуктов и услуг необходим, поскольку неудачный выбор может быть очень дорогостоящим, как показано несколькими сообщенными случаями неудач [25].
9. Гибкая методология: Разработка распределенных систем на основе микросервисов может adopt гибкий подход как метод разработки систем; следовательно, коммуникация имеет решающее значение для передачи знаний между командами [24]. Процесс разработки программного обеспечения по гибкой методологии фокусируется на адаптивном сотрудничестве команд, responsiveness к изменениям и поставке высокоценных продуктов. Организации считают гибкую разработку совместимой с архитектурами на основе микросервисов. Общее мнение заключалось в том, что ограниченный контекст каждого микросервиса хорошо работает в гибкой разработке [47].
10. Системное моделирование: Процесс создания моделей, которые визуально или концептуально представляют систему. Цель состоит в том, чтобы понять, проанализировать, спроектировать и построить системы систематическим и структурированным manner, например, с использованием UML. Моделирующие диаграммы используются для описания различных аспектов систем на основе MSA. Результаты показывают, что диаграммы Архитектуры и Функционального потока обычно используются для изображения высокоуровневого представления MSA [28]. Исследование показало, что отсутствие формального представления доменных моделей является проблемой для моделирования программного обеспечения и подчеркивает, что даже простые и неформальные диаграммы, такие как UML, могут использоваться для представления доменных моделей, пока они помогают передавать идеи проектирования [42].
11. Управление API и стандартизация: Управление API включает управление жизненным циклом API, включая планирование, разработку, тестирование, развертывание и сопровождение API (API Contract, API Versioning, Open API Standard и т.д.). Дальнейшее исследование, которое стоит провести, касается проблем, ощущаемых из-за использования API для обеспечения коммуникации сервисов микросервисов [9]. Процесс эволюции API микросервисов страдает от слабой связи между сервисами и приводит к накладным расходам на коммуникацию и необходимости обратной совместимости [46].
12. Сервисная коммуникация: Коммуникация между различными микросервисами within системы (Обнаружение сервисов, Реплицированные экземпляры сервисов, Балансировка нагрузки, Репликация данных, Удаленные вызовы, Отношения между таблицами, REST, Событийно-ориентированная). Есть факты, что межкоммуникация между системами на основе API также создает реальные проблемы [9]. В системе на основе микросервисов, чтобы преодолеть проблему сложной коммуникации и динамичности во время выполнения при обнаружении сбоев, используются данные распределенной трассировки [44].
13. Автоматизация инфраструктуры: Когда применяется технология автоматизации инфраструктуры, развертывание микросервисов становится таким же простым, как и монолитных систем [10]. Мероприятия, охватывающие процессы автоматизации инфраструктуры, включают CI/CD, инструменты (контроль версий, сборка, тестирование, развертывание) и тактики тестирования (модульное, API, интеграционное и контрактное тестирование).
14. Мониторинг и логирование: Применение инструментов для мониторинга, сбора информации и анализа данных для обеспечения оптимальной производительности, обнаружения проблем и поддержки точного принятия решений. Основной проблемой внедрения микросервисов является внутренняя сложность мониторинга приложений, состоящих из большого, динамично развивающегося и гетерогенного числа компонентов [9]. Также существуют проблемы с обнаружением сбоев в системах на основе микросервисов due to присущим характеристикам таких систем, включая сложные коммуникации, частые обновления, динамичность во время выполнения и сложное управление журналами [44]. Мониторинг имеет paramount важность для непрерывного управления разработкой и тестированием, начиная с обратной связи, собранной с поля [48].
15. Внедрение облачных вычислений: Хранение данных, обработка и управление ресурсами через интернет с использованием инфраструктуры, предоставляемой поставщиками облачных услуг, таких как IaaS, PaaS и SaaS. Собственные облачные решения SaaS на основе микросервисов предлагают клиентам возможности гибкой инфраструктуры, одновременно используя экономию масштаба, предоставляемую облачными провайдерами, и архитектуру мультитенантности [27].
16. Проектирование системной архитектуры: Опыт в планировании общей структуры и компонентов системы. Это involves идентификацию потребностей системы, выбор appropriate технологий, моделирование компонентов и организация взаимодействий между этими компонентами. В процессе рассмотрения проектирования архитектуры на основе микросервисов идентификация частей (partitions) приложений в ограниченных контекстах является непростой задачей; микросервисы приносят benefits от реализации этого ограниченного контекста [9].
17. Архитектура и проектирование базы данных: Определение appropriate модели базы данных, проектирование схемы, определение таблиц и их атрибутов и построение отношений между ними. Создание баз данных, которые могут эффективно хранить и извлекать данные, обеспечивать целостность данных и соответствовать требованиям системы. Проектирование шаблона "база данных на сервис" позволяет обеспечить независимость между сервисами MSA путем оснащения каждого сервиса своим хранилищем (при необходимости) [9].
18. Безопасность системы: Знания, связанные с практиками защиты компьютерных систем, сетей или программных приложений от несанкционированного доступа, утечек данных и киберугроз. Безопасность системы aims обеспечить конфиденциальность, целостность и доступность ресурсов системы и данных. Безопасность также создает проблемы во время проектирования, особенно из-за управления доступом (ACL) и proliferation конечных точек [9].

ТАБЛИЦА III. КРИТИЧЕСКИЕ ФАКТОРЫ УСПЕХА НА ОСНОВЕ ИЗУЧЕНИЯ ЛИТЕРАТУРЫ

19. Культура DevOps: Интеграция практик разработки программного обеспечения (Dev) с ИТ-операциями (Ops) для создания эффективного, устойчивого рабочего процесса, ориентированного на быструю поставку бизнес-ценности. Комбинация MSA и DevOps приносит several другие benefits, включая увеличение частоты выпуска программного обеспечения, надежность и масштабируемость системы, устойчивость в случае сбоев и децентрализованное управление командами для контроля разработки приложений [28]. В технологическом аспекте контейнеризация также позволяет DevOps достичь более быстрой реализации развертывания по сравнению с ВМ, поскольку неэффективно запускать каждый микросервис на отдельной ВМ из-за ее длительного времени запуска и увеличенного использования ресурсов [41].
20. Опыт работы с микросервисами: Знания и опыт в проектировании, разработке и управлении архитектурами приложений с использованием микросервисного подхода. Исследование [22] выделяет более высокие затраты на разработку, возможно, из-за того, что разработчики впервые undertake разработку микросервисов.
21. Шаблоны проектирования систем и программного обеспечения: Были идентифицированы several шаблоны проектирования MSA. Наиболее повторяющимися шаблонами проектирования во время процесса реализации MSA в DevOps являются Circuit Breaker и шаблоны миграции, за которыми следуют Observer, Load Balancer, Scalability и Deployment [28].

Согласно Strategy&, подразделению PwC, ориентированному на консалтинг в области бизнес-стратегии, возможности состоят из четырех компонентов, как показано на Рис. 2. Организация, Процесс, Инструменты и система, и Знания, навыки и поведение [12]. Каждый компонент описан следующим образом:

Рис. 2. Четыре части возможностей согласно Strategy& и PWC.

a) Организация: Вся структура и дизайн компании, включая управление, менеджмент и ее операционную модель. Организации с сильными возможностями могут идентифицировать, развивать и использовать конкурентные преимущества на конкурентном рынке. Они могут преобразовывать знания, навыки и поведение individuals или групп в устойчивые организационные возможности, которые создают ценность для всех заинтересованных сторон.

b) Процесс: Шаги или activities, используемые компанией для создания ценности для клиентов. В контексте организации процессы aim достичь эффективности, результативности и желаемых outcomes. Это crucial для проектирования, управления и непрерывного улучшения процессов, чтобы enable организация работать лучше, повышать удовлетворенность клиентов и достигать конкурентного превосходства.

c) Инструменты и система: Правильная комбинация relevant систем и инструментов может укрепить возможности организации или individual, облегчая координацию, эффективность и мониторинг, необходимые для достижения желаемых целей. Важно соответствовать системам и инструментам конкретным потребностям организации или individual и ensure они соответствуют установленным стратегиям и целям.

d) Знания, навыки и поведение: Во многих ситуациях успех individual или группы зависит не только от знаний, которыми они обладают, но также от навыков, применяемых на практике, и поведения, которое поддерживает хорошую производительность. Эти взаимосвязанные знания, навыки и поведение часто становятся фокусом в развитии individuals и стратегиях управления человеческими ресурсами для эффективного достижения организационных целей.

C. Моделирование решений с использованием AHP

Метод анализа иерархий (AHP) - это широко признанный метод решения сложных проблем принятия решений, разработанный Саати [13]. Он разбивает любую сложную проблему на множество подпроблем с использованием AHP в терминах уровней иерархии, где каждый уровень представляет набор критериев или атрибутов относительно каждой подпроблемы.

Рис. 3. Структура методологии AHP как основа для сложных проблем принятия решений.

Например, в модели AHP Рис. 3 иллюстрировал бы верхний уровень (уровень 0) иерархии, представляющий цель проблемы, за которым следует средний уровень (уровень 1), представляющий стратегические и операционные факторы, и последний уровень (уровень 2), обычно представляющий альтернативные actions или подфакторы, которые должны быть рассмотрены для достижения цели. AHP организует чувства, интуицию и логику в структурированный подход к принятию решений, который оказался beneficial в средах, largely состоящих из нематериальных атрибутов.

AHP позволяет individual организовать систему и ее среду во взаимодействующие элементы, а затем синтезировать их путем измерения и ранжирования impact этих элементов на систему в целом [13],[14]. AHP состоит из четырех фаз.

• Фаза 1: Структурирование проблемы и проектирование иерархической структуры факторов и подфакторов.
• Фаза 2: Сбор данных на основе попарных сравнений через экспертные опросы. В процессе сбора данных интервью должны проводиться с экспертами, активно участвующими в решении проблемы [16]. Впоследствии формируется матрица попарных сравнений \( A \) следующим образом: \[A = (a_{ij}), \quad (i,j = 1 \ldots n)\]
• Фаза 3: Определение весов приоритета каждого фактора и выполнение проверки согласованности. В третьей фазе focus на идентификации значений относительной важности самих факторов within конкретной категории, а не на их сравнении с факторами или категориями в других местах [17]. Этого можно достичь, вычислив их локальные веса с использованием (3) [16]. \[W_{A_i}=\frac{\left(\prod_{j=1}^{n} a_{ij}\right)^{1/n}}{\sum_{i=1}^{n} \left(\prod_{j=1}^{n} a_{ij}\right)^{1/n}}\] Впоследствии глобальные веса, которые указывают на относительную важность факторов среди всех факторов, вычисляются следующим образом: глобальный вес категории CSF (Критический фактор успеха) равен ее локальному весу. Для CSF глобальный вес является произведением локального веса CSF и локального веса связанной категории. Этот этап завершается проверкой согласованности через расчет Коэффициента Согласованности (CR) следующим образом: расчет наибольшего собственного значения. Рассчитайте наибольшее собственное значение, используя (4). \[A\omega= \lambda_{max}\omega\] Рассчитайте значение CR, используя (5). \[CR=\frac{CI}{RI}\]
• Фаза 4: Анализ весов приоритета и определение решений для проблемы. В четвертой фазе веса приоритета, рассчитанные из попарных сравнений, анализируются для получения лучших решений проблемы. Эти веса представляют относительную важность каждого критерия или альтернативы, помогая расставить приоритеты options на основе предпочтений лица, принимающего решения.

IV. Результаты и обсуждение

A. Результаты

После идентификации критических факторов успеха (CSF), влияющих на внедрение MSA, была построена иерархическая структура, и были установлены верхние категории этих факторов. Категории: Организация, Процесс, Инструменты и система, и Знания, навыки и поведение, которые специально исследуются в данном исследовании. Четыре категории и их соответствующие факторы проиллюстрированы на Рис. 4.

Рис. 4. Иерархическая структура факторов успеха внедрения микросервисной архитектуры.

После установления иерархии/категоризации была использована сравнительная оценка для определения относительной значимости этих факторов. Затем была разработана матрица попарных сравнений для приоритизации сравнительных оценок в измерениях по шкале отношений. В данном исследовании применялась девятибалльная шкала для сравнения значимости каждой пары факторов, как подробно описано в Таблице IV. Оценка состоит из пяти значений: 1, 3, 5, 7 и 9, представляющих равную важность, небольшую важность по сравнению с другим, существенную или сильную важность, продемонстрированную важность и абсолютную/экстремальную важность соответственно. Промежуточные оценки выражались через использование четных чисел 2, 4, 6 и 8.

ТАБЛИЦА IV. ИЗМЕРЕНИЕ ШКАЛЫ

Экспертов попросили выполнить попарные сравнения факторов. Эти сравнения затем использовались для создания матрицы попарных сравнений. Пример такого сравнения: поддержка руководства versus четкое видение, задавая вопрос: "Насколько значима поддержка высшего руководства по сравнению с четким видением?" Если эксперты отвечали "продемонстрированная важность", в матрицу присваивалось значение 7. И наоборот, если эксперты указывали, что четкое видение имеет большую важность, чем поддержка высшего руководства, в матрицу добавлялось значение 1/7. Участие экспертов в этой приоритизации было задокументировано в опросе попарных сравнений.

После завершения матрицы сравнения исследователи приступили к расчету весов приоритета, индекса согласованности, случайного индекса согласованности и коэффициента согласованности среди факторов с использованием матрицы попарных сравнений. Таблица V отображает случайный индекс согласованности, предоставленный [18]. Важно отметить, что при расчете коэффициента согласованности порог не должен быть превышен. Чтобы обеспечить желаемые outcomes, рекомендуется, чтобы коэффициент согласованности находился в диапазоне от 0 до 0,1, особенно для матриц, превышающих размерность 4x4, как рекомендовано Саати [18]. Если рассчитанный коэффициент согласованности равен или меньше приемлемого значения, это указывает на то, что сравнительные оценки, представленные в матрице, имеют consistent уровень согласованности.

ТАБЛИЦА V. СЛУЧАЙНЫЙ ИНДЕКС СОГЛАСОВАННОСТИ

В данном исследовании процесс расчета приоритетов был разделен на четыре части в соответствии с количеством категорий, и результаты проверки индекса согласованности были следующими: Организация (Кат 1) 0.0931, Процесс (Кат 2) 0.0924, Система и инструменты (Кат 3) 0.0972 и Знания, навыки и поведение (Кат 4) 0.0822. Эти результаты указывают на то, что общий процесс расчета приоритетов является согласованным.

Таблица VI отображает результаты весов приоритета и рейтингов для каждой категории и связанных с ними факторов. Столбец Категория содержит значения веса, представляющие уровень важности каждой категории. Четыре категории, полученные из поддерживающих частей возможностей, требуемых любой компанией или учреждением, в контексте данного исследования относятся к возможностям во внедрении MSA. Анализ показал, что категория Организация является наиболее важной, с весом 0,4844 во внедрении MSA. Категория Знания, навыки и поведение занимает второе место с весом 0,2240, за ней closely следуют категории Процесс и Инструменты и система с весами 0,1615 и 0,1302 соответственно.

В столбце Фактор есть два значения веса: локальный вес как приоритет within области категории фактора и глобальный вес как основа для столбца Приоритет как рейтинг фактора по сравнению со всеми изученными факторами. В категории Организация фактор Поддержка высшего руководства считается наиболее важным, с локальным весом 0,5011. Для категории Процесс фактор Управление проектами является основным приоритетом с локальным весом 0,3046. В категории Инструменты и система наивысший локальный вес 0,3938 у фактора Управление API и стандартизация, и в последней категории, Знания, навыки и поведение, фактор Опыт работы с микросервисами считается наиболее важным с локальным весом 0,2300. Глобально, три главных критических фактора успеха - это Поддержка высшего руководства, Четкое видение и Достаточные ресурсы.

ТАБЛИЦА VI. СВОДКА ВЕСОВ И УРОВНЯ ПРИОРИТЕТА ФАКТОРОВ

B. Обсуждение

Данное исследование фокусируется на процессе идентификации, определения и оценки критических факторов успеха (CSF) для внедрения Микросервисной архитектуры (MSA) в одной из ведущих телекоммуникационных компаний Индонезии. Каждый фактор будет отображен в категории на основе возможностей учреждения или компании по внедрению MSA. Этот процесс отображения crucial как высокоуровневый обзор для руководства компании, чтобы понять, какие внутренние возможности необходимо усилить для того, чтобы similar инициативы могли быть выполнены эффективно и результативно в будущем. Изучение литературы было проведено путем комбинации ручного поиска исследований, считающихся relevant к обсуждаемой теме, дополненного применением систематического обзора литературы (SLR) для обогащения determinants успешного внедрения MSA.

Таблица VII отображает демографию экспертов, которые помогали в процессе приоритизации критических факторов успеха (CSF) в данном исследовании. Нас поддержали четыре эксперта, состоящие из двух типов: те, кто был вовлечен, и те, кто не был непосредственно вовлечен в реализацию проекта. Присутствие этих двух типов экспертов expected для достижения баланса, который поддерживает лучшую объективность в процессе приоритизации, проводимого через опросы. Эксперты были выбраны с several критериями отбора, такими как более пяти лет опыта в области программного обеспечения, наличие опыта в разработке систем на основе MSA и наличие сертификатов в области архитектуры программного обеспечения или управления ИТ-услугами.

ТАБЛИЦА VII. ДЕМОГРАФИЯ ЭКСПЕРТОВ

Метод анализа иерархий (AHP) был employed для получения локальных и глобальных весов как benchmarks для определения уровней приоритета каждой категории и критических факторов успеха (CSF) для внедрения Микросервисной архитектуры (MSA). Данное исследование produced таксономию критических факторов успеха (CSF), принимая во внимание как глобальные, так и локальные веса. Идентифицированные факторы успеха были категоризированы в четыре различных раздела; каждый раздел предлагает several insights для улучшения процесса внедрения MSA в компании.

Рис. 5 представляет outcome процесса глобального взвешивания для всех определяющих факторов успеха с использованием AHP как метода для сложного принятия решений. Можно заключить, что фактор Поддержка высшего руководства значительно превосходит другие факторы. Следующими по порядку идут факторы Четкое видение и Достаточные ресурсы соответственно. Интересное finding заключается в том, что эти три фактора попадают в ту же категорию Организация. Это оправдывает, что категория Организация, отображенная на Рис. 6, также занимает первое место с точки зрения возможностей и значительно превосходит другие категории, такие как Знания, навыки и поведение на втором месте. Результаты данного исследования address исследовательский вопрос.

Рис. 5. Список всех факторов успеха внедрения, упорядоченный по глобальному весу.

Рис. 6. Список категорий на основе возможностей, упорядоченный по весу.

Для будущих исследований мы признаем several ограничения данного исследования, particularly в определении критических факторов успеха (CSF), хотя обзор литературы использовал метод Систематического обзора литературы (SLR). Результаты этих факторов не прошли эмпирическое тестирование для более objective выбора факторов. Подходы, такие как частотный подход, найденный в [19],[20], могли бы быть employed. Более того, реализация комитета экспертных оценок для оценки факторов могла бы быть проведена для ensure, что каждый фактор четко определен [21].

V. Заключение и будущая работа

В данном исследовании 21 критический фактор успеха (CSF) был успешно идентифицирован из процесса обзора литературы и категоризирован в четыре категории: (1) Организация, (2) Процесс, (3) Инструменты и система и (4) Знания, навыки и поведение. Для выполнения процесса оценки уровня приоритета каждого фактора и категории был выбран метод анализа иерархий (AHP) как методология принятия решений на основе данных опроса, проведенного среди участников проекта и практиков.

Выводы из результатов данного исследования, как изображено в Таблице VI, указывают, что с категориальной точки зрения Организация занимает первое место как наиболее важная. Три главных подфактора критического успеха для внедрения Микросервисной архитектуры (MSA): (1) Поддержка высшего руководства, (2) Четкое видение и (3) Достаточные ресурсы. При рассмотрении приоритета каждой категории, на основе локальных весов, очевидно, что в категории Организация основным приоритетным фактором является Поддержка высшего руководства (F1.1). Для второй категории, Процесс, основным приоритетом является фактор Управление проектами (F2.1). В категории Инструменты и система (F3.1) фактор Управление API и стандартизация является приоритетом, и для последней категории, Знания, навыки и поведение, Опыт работы с микросервисами (F4.5) занимает первое место как главный фактор.

Чтобы обеспечить успешное внедрение Микросервисной архитектуры (MSA) в организации, крайне важно повысить вовлеченность руководства, стратегическую ясность и распределение ресурсов. Усиление поддержки высшего руководства имеет жизненно важное значение, поскольку их активное участие и надзор необходимы для сохранения импульса и эффективного решения проблем. Кроме того, формулирование четкого видения и разработка robust стратегии коммуникации ensure, что команды согласованы и работают towards общих целей, thereby минимизируя несоответствие и неэффективность.

Кроме того, компания должна расставить приоритеты в распределении sufficient ресурсов, как финансовых, так и человеческих, для поддержки инициативы MSA. Это включает инвестиции в набор и повышение квалификации персонала для развития необходимого опыта в микросервисах, а также ensure доступ к essential инструментам и системам. Решая эти критические области, компания может leverage идентифицированные критические факторы успеха для смягчения потенциальных рисков, оптимизации выполнения проекта и полной реализации benefits MSA, включая улучшенную масштабируемость, гибкость и операционную эффективность.

Для будущей работы рекомендуется провести дальнейшие исследования для изучения долгосрочных impacts идентифицированных критических факторов успеха (CSF) на устойчивость и масштабируемость реализаций Микросервисной архитектуры (MSA). Кроме того, проведение сравнительных исследований across различных отраслей и размеров организаций было бы valuable для определения, являются ли CSF, идентифицированные в данном исследовании, универсально применимыми или они варьируются в зависимости от контекста.

Литература

1. Smith, D., Jones, M., Williams, R., & Johnson, L. (2020). Embracing Microservices: A Comprehensive Overview of Microservice Architecture and Its Impact on Software Development. Journal of Software Engineering and Applications, 13(4), 123-139.
2. Gupta, S. (2016). Microservices. Procedia Computer Science, 78, 278-283.
3. Johnson, R., & Ho, A. (2019). Adopting microservices at Netflix: Lessons for architectural design. IEEE Software, 36(1), 39-45.
4. Lewis, J., & Fowler, M. (2014). Microservices. online: https://martinfowler.com/articles/microservices.html (Accessed 20 May 2023)
5. Newman, S. (2015). Building Microservices: Designing Fine-Grained Systems. O'Reilly Media, Inc, 551.
6. Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, M., Montesi, F., Mustafin, R., & Safina, L. (2017). Microservices: yesterday, today, and tomorrow. Present and Ulterior Software Engineering, 195-216.
7. Balaiale, A., Heydarnoori, A., & Jamshidi, P. (2016). Microservices architecture enables devops: Migration to a cloud-native architecture. IEEE Software, 33(3), 42-52.
8. Loukides, Mike. & Swoyer, Steve. (2020). Microservices Adoption in 2020. online: https://www.oreilly.com/radar/microservices-adoption-in-2020/ (Accessed 20 May 2023)
9. Jacopo Soldani, Damian Andrew Tamburri, Willem-Jan Van Den Heuvel. (2018). The pains and gains of microservices: A Systematic grey literature review. The Journal of Systems and Software 146 (2018) 215-232.
10. Xin Zhou, Shanshan Li, Lingli Cao, He Zhang, Zijia Jia, Chenxing Zhong, Zhihao Shan, Muhammad Ali Babar. (2023). Revisiting the practices and pains of microservice architecture in reality: An industrial inquiry. The Journal of Systems & Software 195 (2023) 111521
11. Jamshidi, P., Pahl, C., Mendonca, N.C., Lewis, J., Tilkov, S., 2018. Microservices: the journey so far and challenges ahead. IEEE Softw. 35 (3), 24-35. doi:10.1109/MS.2018.2141039.
12. Strategy& (2014). What is a capability?. online: https://www.strategyand.pwc.com/gx/en/about/media/videos/2015-and-older/what-is-a-capability.html (Accessed 20 May 2023)
13. Saaty TL. What is the analytic hierarchy process? In: Mathematical Models for Decision Support. Berlin, Heidelberg: Springer; 1988:109-121.
14. Saaty TL. The analytic hierarchy process. New York: McGraw Hill; 1980.
15. Saaty TL. Decision making for leaders. Pittsburgh: RWS Publications; 1990.
16. Cheng, E.W. and Li, H. (2001). "Analytic hierarchy process: an approach to determine measures for business performance," Measuring Business Excellence, Vol. 5 No. 3, pp. 30-37.
17. Shi, H., Peng, S.Z., Liu, Y. and Zhong, P. (2008), "Barriers to the implementation of cleaner production in chinese SMEs: government, industry and expert stakeholders perspectives," Journal of Cleaner Production, Vol. 16 No. 7, pp. 842-852.
18. Saaty, T.L., 1986. Axiomatic foundation of the analytic hierarchy process. Manage. Sci. 32 (7), 841-855.
19. Khan, A. A., & Shameem, M. (2020). Multicriteria decision-making taxonomy for DevOps challenging factors using analytical hierarchy process. Journal of Software Evolution and Process, 32(10). online: https://doi.org/10.1002/smr.2263
20. Akbar, M. A., Naveed, W., Mahmood, S., Alsanad, A. A., Alsanad, A., Gunnaei, A., & Mateen, A. (2020). Prioritization Based Taxonomy of DevOps Challenges Using Fuzzy AHP Analysis. IEEE Access, 8, 202487-202507. online: https://doi.org/10.1109/ACCESS.2020.3035880
21. Sambasivan, M., & Fei, N. Y. (2008). Evaluation of critical success factors of implementation of ISO 14001 using analytic hierarchy process (AHP): a case study from Malaysia. Journal of Cleaner Production, 16(13), 1424-1433. online: https://doi.org/10.1016/j.jclepro.2007.08.003
22. Lenarduzzi, V., Lomio, F., Saarimäki, N., & Taibi, D. (2020). Does migrating a monolithic system to microservices decrease the technical debt? In Journal of Systems and Software (Vol. 169). Elsevier Inc. online: https://doi.org/10.1016/j.jss.2020.110710
23. Auer, F., Lenarduzzi, V., Felderer, M., & Taibi, D. (2021). From monolithic systems to Microservices: An assessment framework. Information and Software Technology, 137. online: https://doi.org/10.1016/j.infsoft.2021.106600
24. Taibi, D., Lenarduzzi, V., Pahl, C., & Janes, A. (2017). Microservices in agile software development: A workshop-based study into issues, advantages, and disadvantages. ACM International Conference Proceeding Series, Part F129907. online: https://doi.org/10.1145/3120459.3120483
25. Stefanou, C. J. (n.d.). The Selection Process of Enterprise Resource Planning (ERP) Systems. online: https://aisel.aisnet.org/amcis2000/418
26. Karabey Aksakalli, I., Çelik, T., Can, A. B., & Tekinerdoğan, B. (2021). Deployment and communication patterns in microservice architectures: A systematic literature review. Journal of Systems and Software, 180. online: https://doi.org/10.1016/j.jss.2021.111014
27. Nordli, E. T., Haugeland, S. G., Nguyen, P. H., Song, H., & Chauvel, F. (2023). Migrating monoliths to cloud-native microservices for customizable SaaS. Information and Software Technology, 160. online: https://doi.org/10.1016/j.infsoft.2023.107230
28. Waseem, M., Liang, P., & Shahin, M. (2020). A Systematic Mapping Study on Microservices Architecture in DevOps. Journal of Systems and Software, 170. online: https://doi.org/10.1016/j.jss.2020.110798
29. Hasan, M. H., Osman, M. H., Admodisastro, N. I., & Muhammad, M. S. (2023). Legacy systems to cloud migration: A review from the architectural perspective. Journal of Systems and Software, 202. online: https://doi.org/10.1016/j.jss.2023.111702
30. Waseem, M., Liang, P., Shahin, M., di Salle, A., & Márquez, G. (2021). Design, monitoring, and testing of microservices systems: The practitioners' perspective. Journal of Systems and Software, 182. online: https://doi.org/10.1016/j.jss.2021.111061
31. Merhi, M. I. (2021). Evaluating the critical success factors of data intelligence implementation in the public sector using analytical hierarchy process. Technological Forecasting and Social Change, 173. online: https://doi.org/10.1016/j.techfore.2021.121180
32. Merhi, M. I., & Leighton, J. (2015). A process model leading to successful implementation of electronic health record systems. In Int. J. Electronic Healthcare (Vol. 8).
33. Young, R., & Jordan, E. (2008). Top management support: Mantra or necessity? International Journal of Project Management, 26(7), 713-725. online: https://doi.org/10.1016/j.ijproman.2008.06.001
34. Gaardboe, R., Nyvang, T., & Sandalgaard, N. (2017). Business Intelligence Success applied to Healthcare Information Systems. Procedia Computer Science, 121, 483-490. online: https://doi.org/10.1016/j.procs.2017.11.065
35. Warrick, D. D. (2017). What leaders need to know about organizational culture. Business Horizons, 60(3), 395-404. online: https://doi.org/10.1016/j.bushor.2017.01.011
36. Waseem, M., Liang, P., Ahmad, A., Shahin, M., Khan, A. A., & Márquez, G. (2022). Decision models for selecting patterns and strategies in microservices systems and their evaluation by practitioners. 135-144. online: https://doi.org/10.1145/3510457.3513079
37. Poniszewska-Maranda, A., MacIoch, J., Borowska, B., & Maranda, W. (2021). Mechanisms for Transition from Monolithic to Distributed Architecture in Software Development Process. Proceedings - IEEE Computer Society's Annual International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunications Systems, MASCOTS. online: https://doi.org/10.1109/MASCOTS53633.2021.9614287
38. Nino-Martinez, V. M., Octavio Ocharan-Hernandez, J., Limon, X., & Perez-Arriaga, J. C. (2021). Microservices Deployment: A Systematic Mapping Study. Proceedings - 2021 9th International Conference in Software Engineering Research and Innovation, CONISOFT 2021, 24-33. online: https://doi.org/10.1109/CONISOFT52520.2021.00016
39. Waseem, M., Liang, P., Marquez, G., & Salle, A. di. (2020). Testing microservices architecture-based applications: A systematic mapping study. Proceedings - Asia-Pacific Software Engineering Conference, APSEC, 2020-December, 119-128. online: https://doi.org/10.1109/APSEC51365.2020.00020
40. Premarathna, D., & Pathirana, A. (2021). Theoretical frameworks to address the challenges in Microservice Architecture. Proceedings - International Research Conference on Smart Computing and Systems Engineering, SCSE 2021, 195-202. online: https://doi.org/10.1109/SCSE53661.2021.9568346
41. Sultan, S., Ahmad, I., & Dimitriou, T. (2019). Container security: Issues, challenges, and the road ahead. IEEE Access, 7, 52976-52996. online: https://doi.org/10.1109/ACCESS.2019.2911732
42. Zhong, C., Li, S., Huang, H., Liu, X., Chen, Z., Zhang, Y., & Zhang, H. (2024). Domain-Driven Design for Microservices: An Evidence-Based Investigation. IEEE Transactions on Software Engineering, 50(6), 1425-1449. online: https://doi.org/10.1109/TSE.2024.3385835
43. Ayas, H. M., Hebig, R., & Leitner, P. (2024). The Roles, Responsibilities, and Skills of Engineers in the Era of Microservices-Based Architectures. 2024 IEEE/ACM 17th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE), 13-23.
44. Purifallah Mazznemolla, Z., & Rasoolzadegan, A. (2024). An effective failure detection method for microservice-based systems using distributed tracing data. Engineering Applications of Artificial Intelligence, 133(PF), 108558. online: https://doi.org/10.1016/j.engappai.2024.108558
45. Michael Ayas, H., Hebig, R., & Leitner, P. (2024). An empirical investigation on the competences and roles of practitioners in Microservices-based Architectures. Journal of Systems and Software, 213(March), 112055. online: https://doi.org/10.1016/j.jss.2024.112055
46. Lercher, A., Glock, J., Macho, C., & Pinzger, M. (2024). Microservice API Evolution in Practice: A Study on Strategies and Challenges. Journal of Systems and Software, 215(May), 112110. online: https://doi.org/10.1016/j.jss.2024.112110
47. Ünlü, H., Kennouche, D. E., Soylu, G. K., & Demirors, O. (2024). Microservice-based projects in agile world: A structured interview. Information and Software Technology, 165(September 2023). online: https://doi.org/10.1016/j.infsof.2023.107334
48. Giamattei, L., Guerriero, A., Pietrantuono, R., Russo, S., Malavolta, I., Islam, T., Dhiga, M., Koziolek, A., Singh, S., Armbruster, M., Gutierrez-Martinez, J. M., Caro-Álvaro, S., Rodriguez, D., Weber, S., Henss, J., Vögelin, E. F., & Panojo, F. S. (2024). Monitoring tools for DevOps and microservices: A systematic grey literature review. Journal of Systems and Software, 208(November 2023), 111906. online: https://doi.org/10.1016/j.jss.2023.111906