Оценка пригодности корпоративных приложений для миграции в облакоИсточник: IBM
На простой вопрос - как узнать, подходит ли корпоративное приложение для работы в облаке - нет простого ответа. В данной статье автор демонстрирует пошаговый подход к оценке набора используемых приложений для определения пригодности корпоративных приложений для работы в облаке, основываясь на методике 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 для оценки пригодности приложения для работы в облаке состоит из нескольких компонентов (или шагов). К ним относятся:
Определение иерархии критериев Каждое из представленных мной измерений (бинес-ценность, техническая возможность и степень риска) имеет несколько критериев; они в свою очередь могут иметь несколько уровней модульных подкритериев (рисунок 2). Рисунок 2. Схематическое представление AHP для оценки технической возможности работы в облаке Критерии, принадлежащие различным измерениям, структурированы в иерархию уровней в соответствии с концепцией AHP. На рисунке 2 показана иерархическая структура для оценки технической возможности. Помните, что критерии и подкритерии могут быть как количественными, так и качественными. Например, "Количество внешних систем" - это количественный критерий, тогда как "Четко определенная точка интеграции" - качественный. Кластер критериев и их подкритериев называется группой критериев. Например, на рисунке 2 критерий "Дизайн приложения" и два его подкритерия "Слабое связывание" и "Виртуализация" принадлежат одной и той же группе, состоящей из трех элементов. На рисунке 3 представлен пример списка иерархии критериев оценки для всех трех измерений, своего рода дерево критериев. Хотя критерии и подкритерии общего характера можно использовать повторно, некоторые критерии необходимо настраивать в соответствии с контекстом предприятия. Рисунок 3. Иерархия критериев для всех трех измерений Я расскажу, как использовать технические критерии и подкритерии, чтобы продемонстрировать действия, применяемые при оценке технической возможности для трех примеров приложений. Определение приоритета критериев Различным критериям присваиваются относительные приоритеты от 1 до 9 в соответствии с AHP-шкалой (таблица 1). Таблица 1. AHP-шкала приоритетов критериев (от 1 до 9); шкала для попарного сравнения
Сначала определяются приоритеты для критериев, а затем для индивидуальных подкритериев каждого критерия. Сумма приоритетов индивидуальных критериев в определенном уровне нормируется на единицу. Подкритерий имеет как локальный, так и глобальный приоритет. Глобальный приоритет - это произведение его собственного приоритета (локальный приоритет) и приоритета родительского критерия. Таким образом, глобальный приоритет критерия "Количество внешних систем" является произведением его локального приоритета и приоритета критерия "Простота интеграции". В таблице 2 приведена оценка относительного приоритета для примера технического критерия уровня 1. Таблица 2. Оценка относительного приоритета; расчет приоритета для критерия
Все диагональные элементы матрицы равны 1 (элементы сравниваются сами с собой). Сравнения выполнены только в верхнем треугольнике матрицы; значения в нижнем треугольнике матрицы эквивалентны значениям в верхнем треугольнике. Например, важность технологического стека (ТС) в два раза больше простоты использования (ПИ). Согласно методологии AHP рассчитывается список относительных приоритетов и коэффициент непротиворечивости. Коэффициент непротиворечивости помогает оценить непротиворечивость попарного сравнения. Аналогично, для всех критериев и подкритериев рассчитывается относительный приоритет. Как показано в таблице 3, глобальный приоритет подкритерия представляет собой произведение его локального приоритета и родительского приоритета. Таким образом, для критерия "Количество внешних систем (ВС)" глобальный приоритет равен произведению его локального приоритета (0.109586) и приоритета критерия "Простота интеграции" (0.1075). Таблица 3. Расчет приоритетов (глобальных и локальных) для подкритериев
Оценка приложения по критериям На этом шаге мы рассмотрим оценку корпоративного приложения по количественному и качественному критериям. Оценка по количественному критерию
В таблице 4 продемонстрирована ситуация, когда критерий "Количество внешних систем" оказывает отрицательное воздействие; с увеличением количества внешних систем количественный "балл" критерия "Простота использования" уменьшается. Таким образом, вы можете увидеть относительные баллы трех приложений, которые должны интегрироваться с 5, 3 и 2 внешними системами соответственно. Таблица 4. Балл для количественного критерия с отрицательным эффектом
Оценка по качественному критерию Общий AHP-балл приложения для измерения рассчитывается как сумма произведения его относительного приоритета по каждому критерию и относительного приоритета соответствующего критерия. На рисунке 4 приведена формула. Рисунок 4. Формула для вычисления общего AHP-балла В этой формуле:
Высокоуровневый перечень действий при использовании AHP Прежде чем завершить данную статью, мне бы хотелось предоставить высокоуровневый перечень действий, которые нужно выполнить при использовании AHP для оценки пригодности набора ваших корпоративных приложений для работы в облачной среде:
Мне бы хотелось завершить статью подведением итогов оценки. После выполнения AHP-оценки для всех трех измерений баллы приложений можно сопоставить в матрице решений, пример которой представлен в таблице 5. Группа в верхней части матрицы наиболее подходит для развертывания в облаке; каждая последующая группа менее пригодна для миграции в облако. Матрица даст целостное представление о результатах переноса в облако различных корпоративных приложений для разных измерений и поможет в принятии обоснованного решения. Таблица 5. Пример матрицы решений о пригодности
Поскольку облачные вычисления привносят определенные проблемы и риски, каждое предприятие, прежде чем отправляться в облака, должно оценить свой набор приложений, основываясь на своих бизнес-требованиях, технологической стратегии и готовности рисковать. Рассмотрев процесс оценки, включающий много конкурирующих критериев с различной природой, эффектами и приоритетами, я продемонстрировал применение многомерного статистического подхода с использованием Analytic Hierarchy Process (AHP) для поиска корпоративных приложений, которые можно перенести в облако. |