Оценка пригодности корпоративных приложений для миграции в облако

Использование Analytic Hierarchy Process для оценки пригодности приложений для работы в облаке

На простой вопрос - как узнать, подходит ли корпоративное приложение для работы в облаке - нет простого ответа. В данной статье автор демонстрирует пошаговый подход к оценке набора используемых приложений для определения пригодности корпоративных приложений для работы в облаке, основываясь на методике Analytic Hierarchy Process (AHP).

Бриджеш Деб, старший ИТ-архитектор, Infosys

Бриджеш Деб (Brijesh Deb) работает старшим ИТ-архитектором в отделе SETLabs компании Infosys. Деб имеет разнообразный опыт работы в ИТ-отрасли, охватывающий архитектуру корпоративных приложений, консультирование по технологиям, прикладные исследования, управление проектированием; в настоящее время занимается технологиями облачных вычислений, Web 2.0 и JavaEE.



02.03.2012

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри Облачные вычисления: Основы

Облачные вычисления обещают несомненные преимущества для производственных приложений:

  • Они могут уменьшить затраты (например, позволяя развертывать и настраивать испытательную среду для приложений или предоставляя возможность добавлять и удалять вычислительные ресурсы по мере необходимости).
  • Они помогают быстрее обрабатывать большие объемы данных (за счет распределения рабочей нагрузки).
  • Они могут помочь быстрее реагировать на меняющиеся условия (за счет возможности применения бизнес-аналитики к более крупным объемам данных со сложной структурой с меньшим временем выполнения).

Но как узнать, подходит ли корпоративное приложение для работы в облаке?

Существуют различные аспекты (с точки зрения бизнеса, технологии, рисков), которые могут сильно влиять на общий успех перехода к облачным вычислениям на предприятии; это означает, что не существует единого для всех ответа на вопрос, подходит ли приложение для работы в облаке (я называю это "пригодностью"). Каждое предприятие должно оценить свой набор используемых приложений, основываясь на своих собственных бизнес-требованиях, технологической стратегии и готовности рисковать.

Перед принятием решения о переходе к облачным вычислениям необходимо задать себе некоторые вопросы:

  • Какие факторы нужно учесть при подготовке к переносу корпоративных приложений в облако? Как оценить различные конкурирующие приоритеты?
  • Как на основе бизнес-приоритетов и технической возможности идентифицировать приложения и сервисы, которые более всего подходят для миграции в облачную среду?
  • Как расставить приоритеты для корпоративных приложений и сервисов, чтобы постепенно перейти в облако? Как осуществить оценку объективно, а не на основании "внутреннего чутья"?
  • Каковы риски?

Помня об этих вопросах, я разработал подход к оценке набора используемых приложений для определения пригодности ваших корпоративных приложений для работы в облаке. Он основан на процессе Analytic Hierarchy Process (AHP).

AHP – это структурированная методика принятия сложных решений, помогающая пользователю вместо поиска "правильного" решения выделить "лучшее" решение для своей проблемы, ситуации и параметров. Идея этой методики впервые возникла в 1970 году. Процесс устроен просто:

  1. Разложить проблему на ряд простых для понимания подпроблем. Приветствуется любая входная информация (будь то точные таблицы данных или грубые догадки), если она имеет отношение к рассматриваемой ситуации.
  2. Оценить элементы, сравнивая их каждый с каждым попарно. Это можно сделать, используя конкретные факты или суждения, – вам нужно оценить относительную важность каждого элемента.
  3. Назначить числовое значение каждой оценке, что позволит сравнивать элементы друг с другом на протяжении всего жизненного цикла процесса решения проблемы.
  4. Рассчитать для каждого альтернативного решения числовые приоритеты; они представляют относительную способность каждой альтернативы достичь поставленной цели.

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

Оценочный подход

На рисунке 1 продемонстрирован оценочный подход в виде высокоуровневой блок-схемы.

Рисунок 1. Блок-схема оценки готовности набора используемых приложений к работе в облаке
Рисунок 1. Блок-схема оценки готовности набора используемых приложений к работе в облаке

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

  • Бизнес-ценность. Какую бизнес-ценность может получить организация, переместив приложения в облако?
  • Техническая возможность. Реально ли перенести приложения в облако?
  • Степень риска. Каков риск переноса приложений в облако?

Каждое из этих измерений имеет решающее значение для принятия положительного или отрицательного решения относительно переноса приложений в облако. Например, приложение может получить высокие оценки по бизнес-ценности и технической возможности, но оно может не быть хорошим кандидатом на перенос в облако, если уровень риска превышает допустимый для конкретного предприятия.

Оценка приложения в каждом из этих измерений представляет собой многофакторный анализ решений (multi-criteria decision analysis – MCDA); AHP – это один из методов, используемых в MCDA (ссылки на дополнительную информацию по MCDA приведены в разделе Ресурсы). AHP включает в себя разработку различных альтернатив на основе различных критериев, причем некоторые из них могут конфликтовать с другими альтернативами, а некоторые имеют противоположную природу (качественно или количественно) или противоположное влияние (позитивное или негативное) на общую применимость.

Методы, используемые в AHP, определяют относительный приоритет для данного набора критериев по определенной шкале. По сравнению со многими другими MCDA-методами AHP имеет ряд преимуществ:

  • AHP предоставляет комплексную структуру для комбинирования количественных и качественных критериев в процессе принятия решений.
  • AHP предоставляет возможность оценить непротиворечивость в процессе табличного анализа; это способствует устранению аномалий и повышению объективности.

Стоит также отметить, что из процесса оценки с самого начала исключаются те приложения, которые явно не подходят для работы в облаке. Внутренние и внешние приложения разделяются и оцениваются по отдельности, поскольку имеют разную природу и значение. Внутренние приложения – это приложения, доступ к которым осуществляется только внутри предприятия и которые защищены сетевым экраном; к внешним приложениям можно обратиться и в обход сетевого экрана. Аргументом в пользу того, что каждый тип приложений заслуживает отдельного рассмотрения, является тот факт, что вопросы безопасности намного более актуальны для внешних приложений, чем для внутренних.

Давайте применим AHP для оценки пригодности набора приложений для работы в облаке.


Оценка с использованием AHP

Процесс использования AHP для оценки пригодности приложения для работы в облаке состоит из нескольких компонентов (или шагов). К ним относятся:

  • Определение иерархии критериев.
  • Определение приоритета критериев.
  • Оценка приложения по набору критериев.
  • Вычисление общей AHP-оценки.

Определение иерархии критериев

Каждое из представленных мной измерений (бинес-ценность, техническая возможность и степень риска) имеет несколько критериев; они в свою очередь могут иметь несколько уровней модульных подкритериев (рисунок 2).

Рисунок 2. Схематическое представление AHP для оценки технической возможности работы в облаке
Рисунок 2. Схематическое представление AHP для оценки технической возможности работы в облаке

Критерии, принадлежащие различным измерениям, структурированы в иерархию уровней в соответствии с концепцией AHP. На рисунке 2 показана иерархическая структура для оценки технической возможности.

Помните, что критерии и подкритерии могут быть как количественными, так и качественными. Например, "Количество внешних систем" – это количественный критерий, тогда как "Четко определенная точка интеграции" – качественный.

Кластер критериев и их подкритериев называется группой критериев. Например, на рисунке 2 критерий "Дизайн приложения" и два его подкритерия "Слабое связывание" и "Виртуализация" принадлежат одной и той же группе, состоящей из трех элементов.

На рисунке 3 представлен пример списка иерархии критериев оценки для всех трех измерений, своего рода дерево критериев. Хотя критерии и подкритерии общего характера можно использовать повторно, некоторые критерии необходимо настраивать в соответствии с контекстом предприятия.

Рисунок 3. Иерархия критериев для всех трех измерений
Рисунок 3. Иерархия критериев для всех трех измерений

Я расскажу, как использовать технические критерии и подкритерии, чтобы продемонстрировать действия, применяемые при оценке технической возможности для трех примеров приложений.

Определение приоритета критериев

Различным критериям присваиваются относительные приоритеты от 1 до 9 в соответствии с AHP-шкалой (таблица 1).

Таблица 1. AHP-шкала приоритетов критериев (от 1 до 9); шкала для попарного сравнения
ИнтенсивностьОпределениеОбъяснение
1Одинаковая важностьДва элемента одинаково участвуют в достижении цели
3Умеренная важностьОдин элемент немного предпочтительнее другого
5Серьезная важностьОдин элемент предпочтительнее другого
7Очень важенОдин элемент намного предпочтительнее другого
9Чрезвычайная важностьОдин элемент чрезвычайно предпочтительнее другого
2, 4, 6, 8Промежуточные значения

Сначала определяются приоритеты для критериев, а затем для индивидуальных подкритериев каждого критерия. Сумма приоритетов индивидуальных критериев в определенном уровне нормируется на единицу.

Подкритерий имеет как локальный, так и глобальный приоритет. Глобальный приоритет – это произведение его собственного приоритета (локальный приоритет) и приоритета родительского критерия. Таким образом, глобальный приоритет критерия "Количество внешних систем" является произведением его локального приоритета и приоритета критерия "Простота интеграции".

В таблице 2 приведена оценка относительного приоритета для примера технического критерия уровня 1.

Таблица 2. Оценка относительного приоритета; расчет приоритета для критерия
Техническая возможностьПИПМТСДППриоритет
Простота интеграции (ПИ)110.50.20.1075
Простота миграции (ПМ)110.330.20.0989
Технологический стек (ТС)2310.330.2304
Дизайн приложения (ДП)55310.5633
Коэффициент непротиворечивости0.0127

Все диагональные элементы матрицы равны 1 (элементы сравниваются сами с собой). Сравнения выполнены только в верхнем треугольнике матрицы; значения в нижнем треугольнике матрицы эквивалентны значениям в верхнем треугольнике.

Например, важность технологического стека (ТС) в два раза больше простоты использования (ПИ). Согласно методологии AHP рассчитывается список относительных приоритетов и коэффициент непротиворечивости. Коэффициент непротиворечивости помогает оценить непротиворечивость попарного сравнения.

Аналогично, для всех критериев и подкритериев рассчитывается относительный приоритет. Как показано в таблице 3, глобальный приоритет подкритерия представляет собой произведение его локального приоритета и родительского приоритета. Таким образом, для критерия "Количество внешних систем (ВС)" глобальный приоритет равен произведению его локального приоритета (0.109586) и приоритета критерия "Простота интеграции" (0.1075).

Таблица 3. Расчет приоритетов (глобальных и локальных) для подкритериев
Простота интеграцииВСТИУИЛокальный приоритетГлобальный приоритет
Количество внешних систем (ВС)10.3330.20.109590.0117790
Четко определенная точка интеграции (ТИ)310.50.309150.0332293
Количество устройств для интеграции (УИ)5210.581260.0624777
Коэффициент непротиворечивости0.00319

Оценка приложения по критериям

На этом шаге мы рассмотрим оценку корпоративного приложения по количественному и качественному критериям.

Оценка по количественному критерию
При оценке приложения по количественному критерию приложения сравниваются друг с другом с учетом количественного значения критерия:

  • Балл приложения по критерию, имеющему положительный эффект, рассчитывается путем нормирования значений на единицу. Для ряда чисел ri, i=1 ... n нормированное значение rin представляет собой ri, деленное на сумму всех последующих чисел в наборе.
    Нормализация
  • По критерию, имеющему отрицательный эффект, относительный балл приложения рассчитывается путем определения обратных значений и последующей их нормализации. Обратное значение – это мультипликативная инверсия числа; обратное значение числа x равно 1/x.

В таблице 4 продемонстрирована ситуация, когда критерий "Количество внешних систем" оказывает отрицательное воздействие; с увеличением количества внешних систем количественный "балл" критерия "Простота использования" уменьшается. Таким образом, вы можете увидеть относительные баллы трех приложений, которые должны интегрироваться с 5, 3 и 2 внешними системами соответственно.

Таблица 4. Балл для количественного критерия с отрицательным эффектом
Оценка приложенияКоличество системОбратное значение (отрицательный эффект)Балл
Приложение 150.200.194
Приложение 230.330.323
Приложение 320.500.484

Оценка по качественному критерию
Для качественного критерия относительный балл приложения рассчитывается путем попарного сравнения с использованием AHP-шкалы (от 1 до 9). Процесс аналогичен определению приоритетов для критерия.

Вычисление общего AHP-балла

Общий AHP-балл приложения для измерения рассчитывается как сумма произведения его относительного приоритета по каждому критерию и относительного приоритета соответствующего критерия. На рисунке 4 приведена формула.

Рисунок 4. Формула для вычисления общего AHP-балла
Рисунок 4. Формула для вычисления общего AHP-балла

В этой формуле:

  • Sx – AHP-балл для x-го приложения;
  • M – число групп критериев;
  • Ni – число элементов в i-ой группе критериев;
  • Pi – значение приоритета i-ой группы критериев;
  • pij – значение приоритета j-го критерия, принадлежащего i-ой группе критериев;
  • sijx – балл сравнения x-го приложения по j-му критерию в i-ой группе критериев.

Высокоуровневый перечень действий при использовании AHP

Прежде чем завершить данную статью, мне бы хотелось предоставить высокоуровневый перечень действий, которые нужно выполнить при использовании AHP для оценки пригодности набора ваших корпоративных приложений для работы в облачной среде:

  1. Определение иерархии критериев:
    1. Определение иерархии критериев для каждого измерения.
    2. Настройка иерархии на корпоративный контекст.
  2. Определение приоритета критериев:
    1. Определение относительной важности одного критерия по сравнению с другим путем попарного сравнения.
    2. Определение локального приоритета для всех критериев.
    3. Определение глобального приоритета для всех подкритериев.
  3. Определение балла приложения для критериев:
    1. Определение относительной пригодности приложений-кандидатов по каждому критерию путем попарного сравнения.
    2. Определение относительного балла приложений-кандидатов по каждому критерию.
    3. Для критериев с отрицательным эффектом использовать обратное значение для определения балла.
  4. Определение AHP-балла:
    1. Определение общего AHP-балла для приложений-кандидатов при помощи формулы, приведенной на рисунке 4.

Заключение

Мне бы хотелось завершить статью подведением итогов оценки. После выполнения AHP-оценки для всех трех измерений баллы приложений можно сопоставить в матрице решений, пример которой представлен в таблице 5. Группа в верхней части матрицы наиболее подходит для развертывания в облаке; каждая последующая группа менее пригодна для миграции в облако.

Матрица даст целостное представление о результатах переноса в облако различных корпоративных приложений для разных измерений и поможет в принятии обоснованного решения.

Таблица 5. Пример матрицы решений о пригодности
Балл приложения: Бизнес-ценностьБалл приложения: Техническая возможностьБалл приложения: Степень рискаПригодность
ВысокаяВысокаяНизкаяПодходят по всем измерениям. Приложения этой группы больше всего подходят для переноса в облако; их балл положителен по всем измерениям.
ВысокаяНизкаяНизкаяПодходят по двум измерениям. Приложения в этой группе также пригодны для облачных вычислений; их балл положителен по крайней мере в двух измерениях.
НизкаяВысокаяНизкаяПодходят по двум измерениям.
ВысокаяВысокаяНизкаяПодходят по двум измерениям.
НизкаяНизкаяНизкаяПодходят по одному измерению. Приложения в этой группе не являются идеальными кандидатами; их балл положителен только в одном измерении.
ВысокаяНизкаяВысокаяПодходят по одному измерению.
НизкаяВысокаяВысокаяПодходят по одному измерению.
НизкаяНизкаяВысокаяНе подходят ни по одному измерению. Приложения этой группы лучше всего оставить "как есть"; их балл не подходит ни по одному измерению.

Поскольку облачные вычисления привносят определенные проблемы и риски, каждое предприятие, прежде чем отправляться в облака, должно оценить свой набор приложений, основываясь на своих бизнес-требованиях, технологической стратегии и готовности рисковать. Рассмотрев процесс оценки, включающий много конкурирующих критериев с различной природой, эффектами и приоритетами, я продемонстрировал применение многомерного статистического подхода с использованием Analytic Hierarchy Process (AHP) для поиска корпоративных приложений, которые можно перенести в облако.

Ресурсы

Научиться

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=800092
ArticleTitle=Оценка пригодности корпоративных приложений для миграции в облако
publish-date=03022012