На простой вопрос - как узнать, подходит ли корпоративное приложение для работы в облаке - нет простого ответа. В данной статье автор демонстрирует пошаговый подход к оценке набора используемых приложений для определения пригодности корпоративных приложений для работы в облаке, основываясь на методике Analytic Hierarchy Process (AHP).
Облачные вычисления обещают несомненные преимущества для производственных приложений:
- Они могут уменьшить затраты (например, позволяя развертывать и настраивать испытательную среду для приложений или предоставляя возможность добавлять и удалять вычислительные ресурсы по мере необходимости).
- Они помогают быстрее обрабатывать большие объемы данных (за счет распределения рабочей нагрузки).
- Они могут помочь быстрее реагировать на меняющиеся условия (за счет возможности применения бизнес-аналитики к более крупным объемам данных со сложной структурой с меньшим временем выполнения).
Но как узнать, подходит ли корпоративное приложение для работы в облаке?
Существуют различные аспекты (с точки зрения бизнеса, технологии, рисков), которые могут сильно влиять на общий успех перехода к облачным вычислениям на предприятии; это означает, что не существует единого для всех ответа на вопрос, подходит ли приложение для работы в облаке (я называю это "пригодностью"). Каждое предприятие должно оценить свой набор используемых приложений, основываясь на своих собственных бизнес-требованиях, технологической стратегии и готовности рисковать.
Перед принятием решения о переходе к облачным вычислениям необходимо задать себе некоторые вопросы:
- Какие факторы нужно учесть при подготовке к переносу корпоративных приложений в облако? Как оценить различные конкурирующие приоритеты?
- Как на основе бизнес-приоритетов и технической возможности идентифицировать приложения и сервисы, которые более всего подходят для миграции в облачную среду?
- Как расставить приоритеты для корпоративных приложений и сервисов, чтобы постепенно перейти в облако? Как осуществить оценку объективно, а не на основании "внутреннего чутья"?
- Каковы риски?
Помня об этих вопросах, я разработал подход к оценке набора используемых приложений для определения пригодности ваших корпоративных приложений для работы в облаке. Он основан на процессе Analytic Hierarchy Process (AHP).
AHP - это структурированная методика принятия сложных решений, помогающая пользователю вместо поиска " правильного" решения выделить "лучшее" решение для своей проблемы, ситуации и параметров. Идея этой методики впервые возникла в 1970 году. Процесс устроен просто:
- Разложить проблему на ряд простых для понимания подпроблем. Приветствуется любая входная информация (будь то точные таблицы данных или грубые догадки), если она имеет отношение к рассматриваемой ситуации.
- Оценить элементы, сравнивая их каждый с каждым попарно. Это можно сделать, используя конкретные факты или суждения, - вам нужно оценить относительную важность каждого элемента.
- Назначить числовое значение каждой оценке, что позволит сравнивать элементы друг с другом на протяжении всего жизненного цикла процесса решения проблемы.
- Рассчитать для каждого альтернативного решения числовые приоритеты; они представляют относительную способность каждой альтернативы достичь поставленной цели.
В данной статье я подробно рассмотрю процесс AHP и продемонстрирую, как применить этот подход при принятии решения относительно того, подходит ваше корпоративное приложение для реализации в облаке или нет. Поскольку общие принципы всех облачных систем одинаковы, эта методика должна быть полезной независимо от выбранной вами облачной платформы (или платформ).
На рисунке 1 продемонстрирован оценочный подход в виде высокоуровневой блок-схемы.
Рисунок 1. Блок-схема оценки готовности набора используемых приложений к работе в облаке
Этот подход представляет собой многомерную статистическую оценку; корпоративные приложения оцениваются в трех измерениях:
- Бизнес-ценность. Какую бизнес-ценность может получить организация, переместив приложения в облако?
- Техническая возможность. Реально ли перенести приложения в облако?
- Степень риска. Каков риск переноса приложений в облако?
Каждое из этих измерений имеет решающее значение для принятия положительного или отрицательного решения относительно переноса приложений в облако. Например, приложение может получить высокие оценки по бизнес-ценности и технической возможности, но оно может не быть хорошим кандидатом на перенос в облако, если уровень риска превышает допустимый для конкретного предприятия.
Оценка приложения в каждом из этих измерений представляет собой многофакторный анализ решений (multi-criteria decision analysis - MCDA); AHP - это один из методов, используемых в MCDA. AHP включает в себя разработку различных альтернатив на основе различных критериев, причем некоторые из них могут конфликтовать с другими альтернативами, а некоторые имеют противоположную природу (качественно или количественно) или противоположное влияние (позитивное или негативное) на общую применимость.
Методы, используемые в AHP, определяют относительный приоритет для данного набора критериев по определенной шкале. По сравнению со многими другими MCDA-методами AHP имеет ряд преимуществ:
- AHP предоставляет комплексную структуру для комбинирования количественных и качественных критериев в процессе принятия решений.
- AHP предоставляет возможность оценить непротиворечивость в процессе табличного анализа; это способствует устранению аномалий и повышению объективности.
Стоит также отметить, что из процесса оценки с самого начала исключаются те приложения, которые явно не подходят для работы в облаке. Внутренние и внешние приложения разделяются и оцениваются по отдельности, поскольку имеют разную природу и значение. Внутренние приложения - это приложения, доступ к которым осуществляется только внутри предприятия и которые защищены сетевым экраном; к внешним приложениям можно обратиться и в обход сетевого экрана. Аргументом в пользу того, что каждый тип приложений заслуживает отдельного рассмотрения, является тот факт, что вопросы безопасности намного более актуальны для внешних приложений, чем для внутренних.
Давайте применим AHP для оценки пригодности набора приложений для работы в облаке.
Процесс использования AHP для оценки пригодности приложения для работы в облаке состоит из нескольких компонентов (или шагов). К ним относятся:
- Определение иерархии критериев.
- Определение приоритета критериев.
- Оценка приложения по набору критериев.
- Вычисление общей AHP-оценки.
Определение иерархии критериев
Каждое из представленных мной измерений (бинес-ценность, техническая возможность и степень риска) имеет несколько критериев; они в свою очередь могут иметь несколько уровней модульных подкритериев (рисунок 2).
Рисунок 2. Схематическое представление AHP для оценки технической возможности работы в облаке
Критерии, принадлежащие различным измерениям, структурированы в иерархию уровней в соответствии с концепцией AHP. На рисунке 2 показана иерархическая структура для оценки технической возможности.
Помните, что критерии и подкритерии могут быть как количественными, так и качественными. Например, "Количество внешних систем" - это количественный критерий, тогда как "Четко определенная точка интеграции" - качественный.
Кластер критериев и их подкритериев называется группой критериев. Например, на рисунке 2 критерий "Дизайн приложения" и два его подкритерия "Слабое связывание" и "Виртуализация" принадлежат одной и той же группе, состоящей из трех элементов.
На рисунке 3 представлен пример списка иерархии критериев оценки для всех трех измерений, своего рода дерево критериев. Хотя критерии и подкритерии общего характера можно использовать повторно, некоторые критерии необходимо настраивать в соответствии с контекстом предприятия.
Рисунок 3. Иерархия критериев для всех трех измерений
Я расскажу, как использовать технические критерии и подкритерии, чтобы продемонстрировать действия, применяемые при оценке технической возможности для трех примеров приложений.
Определение приоритета критериев
Различным критериям присваиваются относительные приоритеты от 1 до 9 в соответствии с AHP-шкалой (таблица 1).
Таблица 1. AHP-шкала приоритетов критериев (от 1 до 9); шкала для попарного сравнения
|
Интенсивность |
Определение |
Объяснение |
|---|---|---|
| 1 | Одинаковая важность | Два элемента одинаково участвуют в достижении цели |
| 3 | Умеренная важность | Один элемент немного предпочтительнее другого |
| 5 | Серьезная важность | Один элемент предпочтительнее другого |
| 7 | Очень важен | Один элемент намного предпочтительнее другого |
| 9 | Чрезвычайная важность | Один элемент чрезвычайно предпочтительнее другого |
| 2, 4, 6, 8 | Промежуточные значения |
Сначала определяются приоритеты для критериев, а затем для индивидуальных подкритериев каждого критерия. Сумма приоритетов индивидуальных критериев в определенном уровне нормируется на единицу.
Подкритерий имеет как локальный, так и глобальный приоритет. Глобальный приоритет - это произведение его собственного приоритета (локальный приоритет) и приоритета родительского критерия. Таким образом, глобальный приоритет критерия "Количество внешних систем" является произведением его локального приоритета и приоритета критерия "Простота интеграции".
В таблице 2 приведена оценка относительного приоритета для примера технического критерия уровня 1.
Таблица 2. Оценка относительного приоритета; расчет приоритета для критерия
|
Техническая возможность |
ПИ |
ПМ |
ТС |
ДП |
Приоритет |
|---|---|---|---|---|---|
| Простота интеграции (ПИ) | 1 | 1 | 0.5 | 0.2 | 0.1075 |
| Простота миграции (ПМ) | 1 | 1 | 0.33 | 0.2 | 0.0989 |
| Технологический стек (ТС) | 2 | 3 | 1 | 0.33 | 0.2304 |
| Дизайн приложения (ДП) | 5 | 5 | 3 | 1 | 0.5633 |
| Коэффициент непротиворечивости | 0.0127 |
Все диагональные элементы матрицы равны 1 (элементы сравниваются сами с собой). Сравнения выполнены только в верхнем треугольнике матрицы; значения в нижнем треугольнике матрицы эквивалентны значениям в верхнем треугольнике.
Например, важность технологического стека (ТС) в два раза больше простоты использования (ПИ). Согласно методологии AHP рассчитывается список относительных приоритетов и коэффициент непротиворечивости. Коэффициент непротиворечивости помогает оценить непротиворечивость попарного сравнения.
Аналогично, для всех критериев и подкритериев рассчитывается относительный приоритет. Как показано в таблице 3, глобальный приоритет подкритерия представляет собой произведение его локального приоритета и родительского приоритета. Таким образом, для критерия "Количество внешних систем (ВС)" глобальный приоритет равен произведению его локального приоритета (0.109586) и приоритета критерия "Простота интеграции" (0.1075).
Таблица 3. Расчет приоритетов (глобальных и локальных) для подкритериев
|
Простота интеграции |
ВС |
ТИ |
УИ |
Локальный приоритет |
Глобальный приоритет |
|---|---|---|---|---|---|
| Количество внешних систем (ВС) | 1 | 0.333 | 0.2 | 0.10959 | 0.0117790 |
| Четко определенная точка интеграции (ТИ) | 3 | 1 | 0.5 | 0.30915 | 0.0332293 |
| Количество устройств для интеграции (УИ) | 5 | 2 | 1 | 0.58126 | 0.0624777 |
| Коэффициент непротиворечивости | 0.00319 |
Оценка приложения по критериям
На этом шаге мы рассмотрим оценку корпоративного приложения по количественному и качественному критериям.
Оценка по количественному критерию
При оценке приложения по количественному критерию приложения сравниваются друг с другом с учетом количественного значения критерия:
- Балл приложения по критерию, имеющему положительный эффект, рассчитывается путем нормирования значений на единицу. Для ряда чисел ri , i=1 ... n нормированное значение rin представляет собой ri , деленное на сумму всех последующих чисел в наборе.
- По критерию, имеющему отрицательный эффект, относительный балл приложения рассчитывается путем определения обратных значений и последующей их нормализации. Обратное значение - это мультипликативная инверсия числа; обратное значение числа x равно 1/x .
В таблице 4 продемонстрирована ситуация, когда критерий "Количество внешних систем" оказывает отрицательное воздействие; с увеличением количества внешних систем количественный "балл" критерия "Простота использования" уменьшается. Таким образом, вы можете увидеть относительные баллы трех приложений, которые должны интегрироваться с 5, 3 и 2 внешними системами соответственно.
Таблица 4. Балл для количественного критерия с отрицательным эффектом
|
Оценка приложения |
Количество систем |
Обратное значение (отрицательный эффект) |
Балл |
|---|---|---|---|
| Приложение 1 | 5 | 0.20 | 0.194 |
| Приложение 2 | 3 | 0.33 | 0.323 |
| Приложение 3 | 2 | 0.50 | 0.484 |
Оценка по качественному критерию
Для качественного критерия относительный балл приложения рассчитывается путем попарного сравнения с использованием AHP-шкалы (от 1 до 9). Процесс аналогичен определению приоритетов для критерия.
Общий AHP-балл приложения для измерения рассчитывается как сумма произведения его относительного приоритета по каждому критерию и относительного приоритета соответствующего критерия. На рисунке 4 приведена формула.
Рисунок 4. Формула для вычисления общего AHP-балла
В этой формуле:
- Sx - AHP-балл для x -го приложения;
- M - число групп критериев;
- Ni - число элементов в i -ой группе критериев;
- Pi - значение приоритета i -ой группы критериев;
- pij - значение приоритета j -го критерия, принадлежащего i -ой группе критериев;
- sijx - балл сравнения x -го приложения по j -му критерию в i -ой группе критериев.
Высокоуровневый перечень действий при использовании AHP
Прежде чем завершить данную статью, мне бы хотелось предоставить высокоуровневый перечень действий, которые нужно выполнить при использовании AHP для оценки пригодности набора ваших корпоративных приложений для работы в облачной среде:
- Определение иерархии критериев:
- Определение иерархии критериев для каждого измерения.
- Настройка иерархии на корпоративный контекст.
- Определение приоритета критериев:
- Определение относительной важности одного критерия по сравнению с другим путем попарного сравнения.
- Определение локального приоритета для всех критериев.
- Определение глобального приоритета для всех подкритериев.
- Определение балла приложения для критериев:
- Определение относительной пригодности приложений-кандидатов по каждому критерию путем попарного сравнения.
- Определение относительного балла приложений-кандидатов по каждому критерию.
- Для критериев с отрицательным эффектом использовать обратное значение для определения балла.
- Определение AHP-балла:
- Определение общего AHP-балла для приложений-кандидатов при помощи формулы, приведенной на рисунке 4.
Мне бы хотелось завершить статью подведением итогов оценки. После выполнения AHP-оценки для всех трех измерений баллы приложений можно сопоставить в матрице решений, пример которой представлен в таблице 5. Группа в верхней части матрицы наиболее подходит для развертывания в облаке; каждая последующая группа менее пригодна для миграции в облако.
Матрица даст целостное представление о результатах переноса в облако различных корпоративных приложений для разных измерений и поможет в принятии обоснованного решения.
Таблица 5. Пример матрицы решений о пригодности
|
Балл приложения: Бизнес-ценность |
Балл приложения: Техническая возможность |
Балл приложения: Степень риска |
Пригодность |
|---|---|---|---|
| Высокая | Высокая | Низкая | Подходят по всем измерениям. Приложения этой группы больше всего подходят для переноса в облако; их балл положителен по всем измерениям. |
| Высокая | Низкая | Низкая | Подходят по двум измерениям. Приложения в этой группе также пригодны для облачных вычислений; их балл положителен по крайней мере в двух измерениях. |
| Низкая | Высокая | Низкая | Подходят по двум измерениям. |
| Высокая | Высокая | Низкая | Подходят по двум измерениям. |
| Низкая | Низкая | Низкая | Подходят по одному измерению. Приложения в этой группе не являются идеальными кандидатами; их балл положителен только в одном измерении. |
| Высокая | Низкая | Высокая | Подходят по одному измерению. |
| Низкая | Высокая | Высокая | Подходят по одному измерению. |
| Низкая | Низкая | Высокая | Не подходят ни по одному измерению. Приложения этой группы лучше всего оставить "как есть"; их балл не подходит ни по одному измерению. |
Поскольку облачные вычисления привносят определенные проблемы и риски, каждое предприятие, прежде чем отправляться в облака, должно оценить свой набор приложений, основываясь на своих бизнес-требованиях, технологической стратегии и готовности рисковать. Рассмотрев процесс оценки, включающий много конкурирующих критериев с различной природой, эффектами и приоритетами, я продемонстрировал применение многомерного статистического подхода с использованием Analytic Hierarchy Process (AHP) для поиска корпоративных приложений, которые можно перенести в облако.