CC BY
61
УДК 021.8+025.1
ВЫБОР ЭФФЕКТИВНОГО ПРОЕКТА РЕАЛИЗАЦИИ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ
И.В. Пырлина
Предложен оптимальный набор критериев выбора наилучшего проекта реализации сервис-ориентированной архитектуры информационной системы и метод агрегирования их оценок по совокупности критериев качества архитектуры. Проанализировано семь проектов архитектуры сервисов и представлен результат ранжирования приоритетности проектов по заданным критериям. Показано, что выбор проекта зависит от оценок по совокупности критериев в основных областях: внутренняя организация информационной системы, организация изменений и политик, готовность процессов и бизнес-сервисов, минимизация операционных рисков.
Ключевые слова: метод порогового аррегирования, сервис-ориентированная архитектура, операционные риски, критерии эффективности, ранжирование.
ВВЕДЕНИЕ
Концепция сервис-ориентированной архитектуры (СОА) предполагает создание архитектуры приложения с хорошо структурированной топологией интерфейсов, предоставляющих возможность доступа к функциональности приложений из других программ при помощи открытых стандартов [1]. Прикладная логика реализуется, как и раньше, в отдельных приложениях и подсистемах, а для доступа к функциям приложений используется специальная «обертка» в виде Web-сервиса, позволяющая вызывать данную функциональность из других приложений и подсистем. Существуют разные определения понятия СОА [1, 2].
Данная концепция позволяет решить проблему интеграции различных систем, работающих в рамках организации, дает возможность многократного их применения для решения различных задач. Впервые СОА была предложена компанией «Gartner Group» в 1996 г. Однако реализация подобной архитектуры требовала развития стандартов и технологий, поддерживающих ее. Проблема выбора наилучшего проекта реализации СОА в рамках линии бизнеса или компании знакома предприятиям в любой отрасли. С момента появления концепции СОА предприятия ищут пути ее успешной реализации посредством информационных технологий. Они получают большое число предложений от
компаний-поставщиков решений, которые, в свою очередь, создали различные платформы на базе СОА. Каждое предлагаемое проектное решение реализации СОА отличается своими достоинствами и недостатками. К приложениям с СОА предъявляются требования по гибкости, времени ожидания обращения к сервисам, вероятности отказа обработки запроса от системы потребителя, минимизации возможных рисков реализации инновационной архитектуры (рисков персонала, рисков информационных систем, технических рисков). Важно, что под эффективностью проекта в данном случае понимается не только экономическая эффективность и прибыльность проектов, но и общее влияние реализации СОА на работу комплекса информационных систем компании. Как же выбрать эффективный проект реализации СОА информационной системы (ИС)?
На практике задачи отбора эффективных проектов реализации СОА решаются путем анализа характеристик проекта с помощью линейной свертки критериев эффективности. Часто для целей принятия решения используются также показатели экономической эффективности проекта. Однако в случае СОА-приложений выгоды от проектов скорее качественные, и лишь косвенно оказывают влияние на ключевые количественные показатели предприятия. А линейную свертку основных характеристик проекта нельзя считать достаточно объ-
ективной, поскольку высокие оценки одних показателей компенсируют низкие оценки по другим.
В настоящей статье сформулированы основные критерии качества СОА и предлагается метод выбора эффективного проекта реализации сервис-ориентированной архитектуры ИС, предполагающий применение метода порогового агрегирования [3, 4] для оценок по совокупности критериев качества архитектуры. На практике предложенный метод применен для анализа семи проектов реализации СОА в различных отраслях и продемонстрирован выбор наиболее эффективного проекта, исходя из сравнения критериев.
Всего было проанализировано 4435 ошибок по семи проектам за период с 2006—2010 гг. (табл. 1). Все ошибки разделены на четыре приоритета по степени ущерба и важности их устранения («очень высокий», «высокий», «средний» и «низкий»).
Предлагается использовать риски как отдельную группу критериев, влияющих на выбор проекта архитектуры. Статистика по рискам с помощью максиминной свертки будет агрегирована для финального ранжирования проектов.
Таблица 1
Статистика возникновения рисков реализации
1. ПОСТАНОВКА ЗАДАЧИ
Различные альтернативы реализации ИС с СОА можно оценить по вектору критериев. Определим альтернативу как проект реализации, который оценивается по нескольким ключевым характеристикам или критериям.
Задача состоит в ранжировании проектов и выборе наиболее эффективного из них. Выбор осуществляется с помощью метода порогового агрегирования четырехградационных ранжировок критериев. В соответствии с данным методом строится преобразование оценок критериев проектов по правилу агрегирования, что позволяет проранжи-ровать проекты и дать более точную оценку их эффективности.
Для отработки предлагаемого метода выбрано несколько предприятий нефтегазовой и банковской отраслей. Такой выбор обоснован тем, что проекты внедрения ИС с СОА сравнимы между собой по архитектуре и перечню решаемых задач. Были подготовлены опросные листы экспертов-архитекторов компании SAP в рамках реализации или анализа проектов, используемые для оценки зрелости ИС. Краткое описание соответствующих проектов (проекты 1—7) приведено в Приложении 1. В рамках каждого проекта также анализировались риски реализации СОА.
2. АНАЛИЗ РИСКОВ
Риски ИС с СОА оценивались на базе статистики ошибок, собранной по анализируемым проектам. Качество ИС напрямую выражается через количество ошибок в различных компонентах системы, соответственно и риски ИС с СОА представляются в виде рисков возникновения ошибок компонентов ИС. Воспользуемся следующей классификацией рисков ИС: риски ввода-вывода результатов, функциональные риски, риски связующего программного обеспечения (ПО), риски обработки данных, системные риски.
Тип риска
Номер проекта Приоритет Риски ввода-вывода результатов Функ-цио-наль-ные риски Риски свя-зую-щего ПО Риски обработки данных Системные риски
1 Очень высокий Высокий Средний Низкий 1 44 140 1 19 463 1251 12 1 25 82 1 4 170 509 6 9 128 283 7
2 Очень высокий Высокий Средний Низкий 0 24 45 3 7 109 151 8 0 24 29 20 1 21 18 1 7 73 192 14
3 Очень высокий Высокий Средний Низкий 0 0 5 1 0 0 11 1 0 0 1 0 0 0 4 0 1 0 3 1
4 Очень высокий Высокий Средний Низкий 0 0 10 0 0 17 59 0 0 1 1 0 1 5 10 0 0 5 18 3
5 Очень высокий Высокий Средний Низкий 0 9 10 0 2 26 49 1 1 2 3 0 0 5 23 2 1 13 10 0
6 Очень высокий Высокий Средний Низкий 0 2 6 0 1 48 74 0 0 0 3 0 1 17 26 0 0 5 5 0
7 Очень высокий Высокий Средний Низкий 0 0 3 0 1 4 4 0 0 1 2 0 0 2 2 0 1 5 4 0
Итого 304 2318 197 828 788
3. ОПИСАНИЕ КРИТЕРИЕВ
Определим качество архитектуры решения как совокупность свойств и признаков, выявляющих соответствие информационной системы концепции СОА. Для определения критериев рассмотрим ИС в аспекте эффективности организации системы, результативности ее работы, рациональности управления сервисами и данными, наличия политик и элементов платформы, а также проведем анализ операционных рисков. Такой подход к оценке качества ИС в большей степени отвечает потребностям совершенствования управления ею и может дать информацию для мониторинга и выработки конкретных мер по модернизации таких систем. Важно, что успешность проекта реализации СОА определяется не только выбранным ПО и архитектурой решения, но и своевременной идентификацией и минимизацией рисков при сервис-ориентированном подходе к созданию ИС.
По существу, предлагаемый подход состоит в оценке качества ИС в следующих основных областях:
— внутренняя организация ИС с сервис-ориентированной архитектурой (качество организации процессов, применение основных принципов СОА при организации данных, инструментов и сервисов);
— организация изменений и политик (упорядоченность выполняемых функций, комплексность политик и мер сопровождения ИС);
— готовность процессов и бизнес-сервисов (уровень стандартизации процессов, проработки новых подходов к формализации бизнес-операций и формированию потребностей ИС, проработка данных);
— операционные риски (потенциальные убытки исправления ошибок ИС).
Каждая область содержит набор критериев сравнения проектов. Рассмотрим их подробнее.
3.1. Внутренняя организация ИС с сервис-ориентированной архитектурой
Степень реализованности сервисной платформы определяется по наличию необходимых и достаточных компонентов платформы, удовлетворяющих концепции СОА. Среди таких компонентов выделяются:
— платформа для обеспечения интерфейса пользователя в целях доступа к сервисам;
— платформа для обеспечения использования разнородных источников и получателей данных в сервисах;
— платформа для обеспечения использования сервисов в бизнес-процессах;
— среда разработки и оркестрации сервисов.
Соответственно ранги по степени реализован-ности сервисной платформы имеют следующий вид: наличие одного из четырех компонентов платформы (1), наличие двух компонентов (2), наличие трех компонентов (3), наличие всех компонентов (4).
Уровень отказоустойчивости (High availability) сервисов, т. е. существуют ли готовые или находящиеся в разработке методы обеспечения отказоустойчивости корпоративных сервисов в смысле бизнес-перспективы и возможности отработки ситуаций, когда сервисы недоступны. По определению, сервисы в рамках ИС с СОА должны предоставлять высокий уровень осведомленности, готовности и достижимости сервисов, т. е. должны обладать обозримостью (visibility) между потребителями и поставщиками. Осведомленность предполагает предоставление методов информирования потребителей поставщиками о наличии сервисов. Готовность сервиса означает уровень участия поставщика сервиса во взаимоотношениях с потребителями сервисов. Достижимость — это связь между сервисными участниками путем обмена информации, наличие и качество соответствующих каналов связи. Оценка критерия различает методы информирования о доступности сервисов, уровень готовности и достижимости: 1 — низкий уровень осведомленности потребителей сервисов, низкая степень готовности сервисов и достижимости; 2 — публикация запросов потребителей сервисов, средняя степень готовности и достижимость сервисов; 3 — рассылка информации о сервисе потребителям, высокая готовность и достижимость сервисов; 4 — публикация в репозитории, очень высокая готовность и достижимость сервисов.
Степень гибкости и масштабирование СОА-плат-форм ориентированы на такие аспекты, как адекватный подбор конфигурации в смысле производительности, возможности поддержки различных уровней доступности сервисов, возможности обеспечения потребностей развития бизнеса при повышении требований по соглашению об уровне сервиса (service level agreement — SLA) и увеличения нагрузки. В рамках данного критерия определим ранги: 1 — низкая гибкость и масштабируемость платформы; 2 — средняя гибкость и масштабируемость платформы; 3 — высокая гибкость и масштабируемость платформы; 4 — очень высокая гибкость и масштабируемость платформы.
Готовность существующих приложений определяет уровень доработки системы или изменения текущей архитектуры, чтобы выделить и реализовать сервисы. Значения рангов: 1 — необходимо дорабатывать все системы ландшафта; 2 — необходимо дорабатывать большую часть систем ландшафта; 3 — в ландшафте имеются системы, предоставляющие сервисы; 4 — нет необходимости дорабатывать системы.
3.2. Организация изменений и политик
Степень повторного использования в архитектуре сервисов предприятия определяется наличием продуманного и целостного описания процедуры преобразования шагов процессов в шаги сервисов для их поставщиков. Ранги определяются по степени повторного использования: 4 — уровень повторного использования функциональности превышает 40 %; 3 — составляет от 20 до 40 %; 2 — от 10 до 20 %; 1 — от 0 до 10 %.
Возможности по проектированию сервисов — критерий определения уровня знаний проектировщика сервисов, необходимых для корректной обработки новых запросов на сервисы или изменения существующих сервисов. Иначе говоря, владеет ли он методами оркестровки или перестроения сервисов и знает ли сильные и слабые стороны каждого из подходов. Ранги: 4 — очень высокий уровень знаний; 3 — высокий уровень; 2 — средний уровень; 1 — низкий уровень.
Возможности по поддержке процесса предоставления сервисов: имеются ли специально подготовленные сотрудники для поддержки деятельности по предоставлению сервисов или «осервествле-нию» текущих информационных систем. Ранги: 4 — очень высокий уровень подготовки; 3 — высокий уровень; 2 — средний уровень; 1 — низкий уровень.
Управление изменениями поставщика сервисов — критерий определения уровня готовности поставщиков сервисов к их предоставлению, включая поддержку бизнес-процессов и сервисов, и их обеспечение. Ранги: 4) — очень высокий уровень гибкости и надежности поставщика сервисов; 3) — высокий уровень; 2) — средний уровень; 1) — низкий уровень.
Уровень сервиса (SLA) — критерий, обозначающий степень проработки соглашения об уровне сервиса, как со стороны бизнеса, так и со стороны информационных технологий. Он должен быть простым и конкретным, насколько это возможно: доступность, производительность, качество, время. Например: «Проверка кредитоспособности через портал: 99,99 % таких запросов, сделанных в рабочее время, должны обрабатываться за 0,8 с с качеством 100 %». Ранги: 4 — наличие SLA с системой контроля, штрафов и поощрений; 3 — наличие SLA с частичным контролем; 2 — не до конца проработанный SLA; 1 — отсутствие SLA.
3.3. Готовность процессов и бизнес-сервисов
Степень управления сервисами — критерий, определяющий уровень управления процессом построения ИС с СОА. Он позволяет определить преимущества стандартизации, уровень разбиения процессов на операции, обеспечивающий возможность повторного использования функциональ-
ности, соответствующие правила проектирования процессов. Важно обеспечить целостность процедуры управления жизненным циклом процессов и сервисов. Ранги определяются по степени управления процессами и сервисами: 4 — управление на уровне портфеля проектов; 3 — управление на уровне советов; 2 — выделенное единое управление сервисами по направлениям бизнеса; 1 — кусочное управление.
Степень согласованности основных данных означает, насколько одни и те же объекты данных имеют единую структуру и описание при работе с разными приложениями и процессами. При реализации ИС с СОА необходимо иметь согласованное представление о бизнес-партнерах, материалах, работниках, финансовой ситуации, организационной структуре и других основных объектах. Ранги: 4 — очень высокий уровень согласованности данных; 3 — высокий уровень согласованности данных; 2 — средний уровень; 1 — низкий уровень.
Степень согласованности данных о транзакциях. В отличие от основных данных, которые могут быть представлены как входные параметры, данные о транзакциях являются больше результатом какого-то бизнес-процесса. Чем больше они одинаковы с виду и по существу, тем меньше логических связей нужно для следующих шагов бизнес-процесса и подготовки параметров. Ранги: 4 — очень высокий уровень согласованности данных; 3 — высокий уровень согласованности данных; 2 — средний уровень; 1 — низкий уровень.
Контроль версионности1 шагов процесса означает степень проработки подхода контроля изменений процессов и управления их версиями. При реализации ИС с СОА должны быть описания, как обеспечить бизнес-процесс (параметрами) и что ожидать от бизнес-процесса (результаты), насколько устойчиво описание входящих данных и предсказуемо описание результата сейчас и в будущем, как часто изменяется процесс. Ранги: 4 — отсутствие изменений процессов и высокая гранулярность сервисов; 3 — редкое изменение процессов и низкая гранулярность сервисов; 2 — частое изменение процессов и низкая гранулярность сервисов; 1 — отсутствие контроля версионности.
3.4. Минимизация операционных рисков
Анализ рисков, связанных с ошибками работы системы с СОА [5], осуществляется на основе классификации и статистики, приведенной в § 2.
Для каждого проекта внедрения (или альтернативы) делалась оценка архитектуры решения и готовности к внедрению приложений с СОА, а также
1 Определим версионность как новые варианты существующих шагов процесса, измененных в связи с внедрением системы или правил ведения бизнеса.
предложение целевого состояния информационного ландшафта после внедрения ИС. Всего рассматривается семь проектов. Каждый проект получает оценки по критериям (см. Приложение 1), приведенным выше. Все критерии предполагают качественную оценку по шкале: 1 — низкий; 2 — средний; 3 — высокий; 4 — очень высокий.
4. КРАТКОЕ ОПИСАНИЕ МЕТОДОВ АГРЕГИРОВАНИЯ
При разработке методики обработки данных одна из главных задач состояла в формировании наиболее адекватного и обоснованного суждения о качестве проекта ИС с СОА. Безусловно, эта задача не может быть решена в полной мере. В настоящей работе для ее решения применены метод порогового агрегирования и максиминный метод.
4.1. Методы порогового агрегирования
Без применения метода агрегирования предложенные критерии оценки ИС не могут дать четкого представления о том, какой проект наиболее выгодный. Для решения подобных задач наиболее часто применяется метод линейной свертки. Однако нередко он оказывается неэффективным в силу «компенсаторного» характера критериев, т. е. при агрегировании низкие оценки по одним критериям компенсируются высокими оценками по другим. В отличие от метода линейной свертки пороговый метод агрегирования [3, 4] основан на построении результирующего ранжирования по совокупности критериев, представленных четырьмя рангами. Агрегирование осуществляется в соответствии с пороговым правилом, которое позволяет построить бинарное отношение, определяющее предпочтения на множестве проектов.
Множество проектов ИС с СОА оценивается по семи критериям. Каждый критерий проекта ранжируется по четырехбалльной шкале.
Агрегирование происходит по «пороговому правилу»:
Wr = {(x, y)i[vx(x) < vx(y)] и [vx(x) = = v1(y) n v2(x) < v2(y)] и [Vj(x) = v1(y) n v2(x) = = v2(y) n v3(x) < v3(y)]},
где x и y — сравниваемые альтернативы проектов, vj(x) и vl(y) — число единиц («1») в записях векторов x и y, v2(x) и v2(y) — соответственно число двоек («2»), а v3(x) и v3(y) — число троек («3»). Таким образом, отношение Wtr представляет собой матрицу — множество пар векторов, для которых либо в первом сравниваемом векторе число единиц меньше, чем во втором, либо при равном числе единиц число двоек в первом векторе меньше, чем во втором. Результат агрегирования — ранжирование векторов.
В случае четырех рангов и трех критериев все множество оценок разбивается на классы:
1) {1, 1, 1} — оценки «низко» по всем векторам;
2) {2, 1, 1}, {1, 2, 1}, {1, 1, 2} — оценки «низко» по всем векторам, кроме одного со значением «2»;
3) {3, 1, 1}, {1, 3, 1}, {1, 1, 3} — оценки «низко» по всем векторам, кроме одного со значением «3»;
4) {4, 1, 1}, {1, 4, 1}, {1, 1, 4} — оценки «низко» по всем векторам, кроме одного со значением «4»;
5) {2, 2, 1}, {2, 1, 2}, {1, 2, 2} — оценки «средне» по всем векторам, кроме одного вектора со значением «1»;
6) {1, 2, 3}, {2, 3, 1}, {1, 3, 2}, {2, 1, 3}, {3, 1, 2}, {3, 2, 1} — оценка по одному вектору «низко», по двум другим «средне» и «высоко»;
7) {1, 2, 4}, {2, 4, 1}, {1, 4, 2}, {2, 1, 4}, {4, 1, 2}, {4, 2, 1} — оценка по одному вектору «низко», по двум другим «средне» и «очень высоко»;
8) {1, 3, 3}, {3, 3, 1}, {3, 1, 3} — оценки «высоко» по всем векторам, кроме одного со значением «1»;
9) {1, 3, 4}, {3, 4, 1}, {1, 4, 3}, {3, 1, 4}, {4, 1, 3}, {4, 3, 1} — оценка по одному вектору «низко», по двум другим «высоко» и «очень высоко»;
10) {1, 4, 4}, {4, 4, 1}, {4, 1, 4} — оценки «очень высоко» по всем векторам, кроме одного со значением «1»;
11) {2, 2, 2} — оценки «средне» по всем векторам;
12) {2, 2, 3}, {2, 3, 2}, {3, 2, 2} — оценки «средне» по всем векторам, кроме одного со значением «3»;
13) {2, 2, 4}, {2, 4, 2}, {4, 2, 2} — оценки «средне» по всем векторам, кроме одного со значением «4»;
14) {2, 3, 3}, {3, 3, 2}, {3, 2, 3} — оценки «высоко» по всем векторам, кроме одного со значением «2»;
15) {2, 3, 4}, {3, 4, 2}, {2, 4, 3}, {3, 2, 4}, {4, 2, 3}, {4, 3, 2} — оценка по одному вектору «средне», по двум другим «высоко» и «очень высоко»;
16) {2, 4, 4}, {4, 4, 2}, {4, 2, 4} — оценки «очень высоко» по всем векторам, кроме одного со значением «2»;
17) {3, 3, 3} — оценки «высоко» по всем векторам;
18) {3, 3, 4}, {3, 4, 3}, {4, 3, 3} — оценки «высоко» по всем векторам, кроме одного со значением «4»;
19) {3, 4, 4}, {4, 4, 3}, {4, 3, 4} — оценки «очень высоко» по всем векторам, кроме одного со значением «3»;
20) {4, 4, 4} — оценки «очень высоко» по всем векторам.
Число классов эквивалентности К = (п + 3) х х (п + 2)(п + 1)/6, где п — число критериев в области. В результате получается порядковая шкала, которую можно отобразить на отрезок [0, 1]. В качестве агрегированного значения области ИС можно воспользоваться числом V = (/ — 1)/К е [0, 1], где / — номер класса эквивалентности.
4.2. Максиминный метод
В случае с ранжированием в области «Риски» предлагается применить максиминный метод
Обследование N Первоначальное \ Повторное ч Результаты
У ранжирование s ранжирование анализа
Схема общего подхода
(максиминную свертку) анализа данных [6]. Ранжирование происходит по правилу: определим
матрицу S+, такую что Vx, y е A, S + = {n(x, y)}, где n(x, x) ^ A — множество проектов, n(x, y) = = {/\Pj(x) > Pl(y)}, P^x) — значение варианта x по
критерию /.
Иными словами, в матрице S+ на пересечении строки x и столбца y стоит число n(x, y), которое равно числу критериев альтернативы x, имеющих более высокие значения, чем альтернатива y с учетом погрешности вычислений. В данной работе альтернативе x и y соответствуют сравниваемые проекты архитектуры, а n(x, y) — число критериев сравнения типов рисков.
Выберем минимальное значение в каждой строке матрицы S +. А затем выберем наибольшее значение из выбранных. Результирующее «максимин-ное» значение (т. е. группа рисков) получает максимальный ранг. Далее повторим процедуру для оставшихся групп рисков. Таким образом, правило выглядит так: x признается лучшим и выбирается тогда и только тогда, когда
n(x, y) = max{min{n(ö, b)}}
a e A b e A
для некоторых x, y е A. В случае максиминного критерия получается гарантированная нижняя оценка для всех n(x, y), что рассматривается как преимущество по сравнению с методом линейной свертки.
5. ПЕРЕХОД ОТ ЧИСЛОВЫХ ОЦЕНОК К РАНГАМ
Ко всем числовым оценкам по четырем группам критериев применяем агрегирование выбранными методами: к первым трем — метод порогового агрегирования [3], а к рискам — максиминный метод. Получившиеся числовые оценки переведем в ранги по четырем группам для каждого проекта. Для перевода в ранги разделим интервал [0, 1] на четыре равных части. Это позволяет сгруппировать результат ранжирования в четыре ранга:
— первый и самый низкий ранг находятся в интервале [0; 0,25];
— средний ранг — в интервале [0,25; 0,5];
— высокий ранг — в интервале [0,5; 0,75];
— очень высокий — в интервале [0,75; 1].
Рассмотрим область «Внутренняя организация
ИС с СОА». В данной области выделены четыре
критерия и собраны оценки по семи проектам. После применения метода порогового агрегирования значения оценок в области приведены в табл. 2.
Для получения итогового ранжирования на уровне проекта необходимо провести процедуру агрегирования повторно на уровне областей анализа. В данном случае полученный результат соответствует только одной области «Внутренняя организация ИС с СОА». Для продолжения анализа переведем полученные оценки агрегирования в ранги. Результат показан в табл. 3.
Предложенный подход перехода от числовых значений к рангам применяется к каждой группе критериев при первом агрегировании, а затем для получения итогового ранга по проектам.
Схема подхода к ранжированию проектов показана на рисунке. Перечислим основные этапы этого подхода.
Этап «Обследование»
Шаг 1. Определение альтернатив.
Шаг 2. Анкетирование архитекторов решений:
— сбор данных по архитектуре решений;
— сбор статистики ошибок текущих систем.
Шаг 3. Оценка альтернатив по вектору критериев
Этап «Первоначальное ранжирование»
Шаг 1. Ранжирование рисков:
— категоризация рисков по пяти группам;
— ранжирование групп рисков максиминным методом.
Таблица 2
Агрегированные значения по группе критериев 1
Критерий Номер проекта
1 2 3 4 5 6 7
Внутренняя 0,06 0,62 0,97 0,97 0,97 0,97 0,97
организация
ИС с СОА
Таблица 3
Итоговое ранжирование по области 1
Критерий Номер проекта
1 2 3 4 5 6 7
Внутренняя организация ИС с СОА 1 3 4 4 4 4 4
Шаг 2. Ранжирование проектов по группам критериев:
— внутренняя организация ИС;
— организация изменений и политик;
— готовность процессов и бизнес-сервисов;
— минимизация операционных рисков.
Этап «Повторное ранжирование»
Шаг 1. Перевод в ранги результатов первоначального ранжирования.
Шаг 2. Повторное ранжирование альтернатив методом порогового агрегирования.
Этап «Результаты анализа» — выбор проекта с наибольшим рангом как наиболее эффективного.
Предложенный подход позволяет, используя существующую статистику ошибок ИС и информацию об архитектуре реализуемого решения, получить объективную оценку работоспособности архитектуры и ее эффективности.
6. ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ
Для апробации метода выбора наиболее подходящего проекта ИС были проанализированы семь проектов архитектуры сервисов. Для каждого проекта оценивались вариант реализации ИС с СОА, его внутренняя организация и риски по предложенным критериям. Описание проанализированных проектов см. в Приложении 1.
Сбор данных по всем группам критериев, кроме рисков, осуществлялся путем опроса экспертов компании SAP, предоставивших свои оценки совместно с представителями соответствующих компаний, чьи проекты анализировались. В опросный лист были включены вопросы по предложенным критериям. Вопросы разделены на три основных раздела. В результате каждый из участвующих в сравнении проектов получил свой ранг по каждой из четырех составляющих качества ИС с СОА.
Ответы на вопросы давались в виде четырехградаци-онных оценок (4 — «очень хорошо», 3 — «хорошо», 2 — «средне», 1 — «плохо»). Интегральное значение на уровне раздела получалось методом порогового агрегирования [3] в случае первых трех групп критериев и макси-минным методом в случае с рисками. Собранные оценки в ходе анализа проектов представлены в табл. 4.
Оценки по рискам были получены не в ходе опроса, а на основе собранной статистики по рискам проектов и применения максиминного метода агрегирования. Для примера рассмотрим риски первого проекта (табл. 5). Минимальные значения в каждом типе рисков выделены жирным шрифтом.
В соответствии с методом перехода от числовых оценок к рангам первый ранг получают функциональные риски для проекта 1. При ранжировании были выбраны самые высокие из минимальных оценок, что говорит о наибольшем количестве ошибок и соответственно свидетельствует о наибольшем риске соответствующего типа. В данном случае первый ранг присваивается наи-
Таблица 4
Результаты анализа архитектуры проектов
Номер проекта
НЛЛТРП 14 1ЛТ/ТТР1Л Т/Т TT
пимср критерии
1 2 3 4 5 6 7
I. Внутренняя организация ИС с СОА
1 Степень реализованности сервисной платформы 3 2 4 4 4 4 4
2 Уровень отказоустойчивости сервисов 1 3 3 3 3 3 3
3 Степень гибкости и масштабирование СОА-платформ 1 2 4 4 4 4 4
4 Готовность существующих приложений 1 2 4 4 4 4 4
II. Организация изменений и политик
1 Степень повторного использования в архитектуре сервисов предприятия 1 2 4 2 2 2 2
2 Возможности по проектированию сервисов 1 3 3 3 3 2 3
3 Возможности по поддержке процесса предоставления сервисов 1 3 3 3 3 3 3
4 Управление изменениями поставщика сервисов 1 4 4 4 4 4 4
5 Уровень сервиса (SLA) 1 3 3 3 3 3 3
III. Готовность процессов и бизнес-сервисов
1 Степень управления сервисами 2 2 2 2 2 2 2
2 Степень согласованности основных данных 3 4 2 4 4 2 2
3 Степень согласованности данных о транзакциях 3 2 4 3 3 4 4
4 Контроль версионности шагов процесса 1 2 2 3 3 2 2
IV. Минимизация операционных рисков
1 Риски ввода-вывода данных 1 1 1 1 1 1 1
2 Функциональные риски 4 4 1 1 4 1 1
3 Риски связующего ПО 1 1 1 1 1 1 1
4 Риски обработки данных 2 1 1 1 1 1 1
5 Системные риски 3 4 1 1 1 1 1
большей оценке риска, так как чем больше риск, тем хуже предлагаемый проект. Поэтому в отличие от предыдущих примеров ранжирования по всем остальным критериям, в случае с рисками применяется противоположный подход ранжирования: ранг 1 присваивается самому высокому риску, ранг 4 — самому низкому. Напомним, что в случае с остальными критериями самый низкий результат агрегирования приобретал ранг 1. Результат ранжирования данных приведен в табл. 5. Остальные оценки по оставшимся шести проектам группы «Минимизация операционных рисков» были получены по тому же принципу.
Следующий шаг — применение метода порогового агрегирования к оценкам, приведенным в табл. 5. В результате получим агрегированное значение по четырем областям или группам критериев для каждого проекта (табл. 6). Затем переведем в ранги получившиеся значения, воспользовавшись предложенным подходом перехода от чисел к рангам (табл. 7).
Полученное ранжирование по группам позволяет провести повторное агрегирование и ранжирование оценок проектов (табл. 8). Итоговое ранжирование осуществляется уже исходя из семи рангов, соответствующих оценкам по семи проектам.
Таблица 5
Риски проекта 1
Таблица 6
Результаты порогового агрегирования по группам
Таблица 7
Результаты ранжирования
Номер Критерий Номер проекта
1 2 3 4 5 6 7
I Внутренняя организа- 1 3 4 4 4 4 4
ция ИС с СОА
II Организация измене- 1 4 4 4 4 4 4
ний и политик
III Готовность процессов 1 3 3 4 4 3 3
и бизнес-сервисов
IV Минимизация опера- 4 3 1 1 2 1 1
ционных рисков
Таблица 8
Итоговое агрегирование и ранжирование
Критерий Номер проекта
1 2 3 4 5 6 7
Агрегированная 0,08 0,91 0,53 0,56 0,82 0,53 0,53
оценка
Итоговый ранг 1 7 4 4 6 4 4
Анализ (см. табл. 8) показал, что проект 2 самый эффективный. Данный проект с учетом взвешенного анализа характеристик системы, внутренней организации и возможных рисков является наиболее выгодным. Кроме того, он больше всех соответствует концепции СОА. На втором месте проект 5, на третьем — проекты 3, 4, 6 и 7, а на последнем — проект 1.
ЗАКЛЮЧЕНИЕ
Предложенный метод позволяет осуществить выбор проекта реализации ИС с сервис-ориентированной архитектурой в зависимости от оценок по совокупности критериев в четырех основных областях: внутренняя организация ИС с сервис-ориентированной архитектурой; организация изменений и политик; готовность процессов и бизнес-сервисов; минимизация операционных рисков. Оценка в последней из перечисленных областей определяется в соответствии со статистикой по проектам. Задача выбора оптимального проекта анализировалась с помощью метода порогового агрегирования. Для этого сформулированы ранговые критерии качества сервис-ориентированной архитектуры. Сначала анализ проводится по критериям в каждой из четырех областей, а затем повторно для получения итоговой взвешенной оценки.
Предложенный метод обладает свойством «не-компенсируемости» для любого критерия с низкой оценкой. Результат ранжирования дает четкую картину приоритетности и эффективности проектов по заданным критериям.
Автор благодарен профессору Ф.Т. Алескерову за постановку задачи.
Номер Критерий Номер проекта
1 2 3 4 5 6 7
I Внутрен- 0,06 0,62 0,97 0,97 0,97 0,97 0,97
няя органи-
зация ИС
с СОА
II Организа- 0 0,84 0,95 0,84 0,84 0,76 0,84
ция изме-
нений и по-
литик
III Готовность 0,38 0,65 0,64 0,79 0,79 0,64 0,64
процессов
и бизнес-
сервисов
IV Минимиза- 0,25 0,16 0 0 0,05 0 0
ция опера-
ционных
рисков
Типы рисков Очень высокий Высокий Средний Низкий Ранг
Риски ввода— 1 44 140 1 4
вывода данных
Функциональ- 19 463 1251 12 1
ные риски
Риски свя- 1 25 82 1 4
зующего ПО
Риски обра- 4 170 509 6 3
ботки данных
Системные 9 128 283 7 2
риски
ЛИТЕРАТУРА
1. Дубова Н. SOA: подходы к реализации. Менеджмент ИТ // Открытые системы. — 2004. — № 6. — URL: http://www. osp.ru/os/2004/06/184450/ (дата обращения 27.06.2012).
2. Черняк Л. Говорим SOA, подразумеваем EA // Открытые системы. — 2005. — № 4. — URL: http://www.osp.ru/os/ 2005/04/185518/_p3.html (дата обращения 27.06.2012).
3. Aleskerov F. T, Chistyakov V. V., Kalyagin V. A. Multiple criteria threshold decision making algorithms: Working paper
WP7/2010/02. - M.: State University - Higher School of Economics, 2010. — 40 p.
4. Алескеров Ф.Т., Якуба В.И. Метод порогового агрегирования трехградационных ранжировок // Доклады академии наук. — 2007. — Т. 413, № 2. — С. 181—183.
5. Пырлина И.В. Классификация операционных рисков при сервисно-ориентированном подходе к созданию информационной системы // Бизнес-Информатика. — 2011. — № 4 (18). — С. 54—61.
6. Aleskerov F., Ersel H., Yolalan R. Multicriterial Ranking Approach for Evaluating Bank Branch Performance // Intern. Journal of Information Technology & Decision Making. — 2004. — Vol. 3, N 2. — P. 321—335.
ПРИЛОЖЕНИЕ
Описание проектов
Проект l. Нефтегазовая компания
Описание проекта Проектирование корпоративных приложений с СОА. Создание четырех композитных приложений с использованием девяти корпоративных сервисов в рамках одного выбранного процесса
Описание архитектуры решения Создание единой системы согласования запросов на приобретение дорогих товаров (с использованием четырех композитных процессов и девяти сервисов). Система использует элементы процессов, существующих в ландшафте предприятия систем mySAP Enterprise Resource Planning (ERP), Supply Relationship Management (SRM). С помощью интеграционной шины данных SAP NetWeaver данные передаются в перечисленные системы. В качестве интерфейса пользователя используется корпоративный портал, для ведения основных данных используется решение SAP NetWeaver Master Data Management (MDM)
Организационное обеспечение Назначение владельцев процессов, создание организационной структуры для поддержания СОА (владельцы процессов, архитектор СОА, бизнес-аналитик, разработчик сервисов, интеграционный эксперт)
Проект 2. Нефтегазовая компания
Описание проекта Внедрение решения «транспорт — менеджер», реализующего композитный процесс подачи заявки на автотранспорт на базе сервисного подхода на интеграционной платформе
Описание архитектуры Создание композитного приложения на базе платформы SAP NetWeaver в целях взаимосвязи производственных и контроллинговых системах текущего ИТ-ландшафта (ИС-АТ, ГИС, SAP-системы), обеспечения создания приложений на основе бизнес-процессов и усовершенствования процессов транспортного управления
Организационное обеспечение Ввод новых ролей в организационной структуре ИТ
Проект З. Банковская компания
Описание проекта Создание фронтального решения, обеспечивающего «единое окно продаж», интеграцию каналов взаимодействия с клиентом, организацию и управление работой единой клиентской базой, а также возможность гибкой перестройки данных функций в зависимости от появления новых бизнес-требований, новых продуктов или каналов продаж
Описание архитектуры Основная задача системы — интегрировать учетные системы, системы SAP R/3 и «не-SAP системы» («Сфера», 1С, «Lotus»), чтобы обеспечить работу в режиме реального времени специалистов. Композитное приложение обеспечивает: — единый интерфейс пользователя, ориентированный на совместную работу (Web-интерфейс); — единое ведение основных данных; — независимость реализуемого процесса от специфики реализации бизнес-сервисов
Организационное обеспечение Нет
Проект 4. Нефтегазовая компания
Описание проекта Создание информационно-технического комплекса, решающего весь спектр задач, связанных с ведением и использованием данных в компании. В решении предусмотрена возможность интеграции различных информационных систем (ERP, учетных, производственных) на уровне данных, реализована функция разграничения прав доступа к информации
Описание архитектуры Создание Единой системы нормативно-справочной информации на платформе SAP MDM с поэтапной организацией информационно-технологического ландшафта и централизованного хранилища данных, включающего в себя все основные справочники и классификаторы корпоративных прикладных систем (ERP-класса, учетных и производственных). Большое значение придается созданию базовой аппаратно-программной интеграционной инфраструктуры на основе SAP NetWeaver
Организационное обеспечение Ввод новых ролей в организационной структуре ИТ и соответствующих бизнес-подразделений
Проект 5. Нефтегазовая компания
Описание проекта Для эффективной работы корпоративных информационных систем, взаимодействия всех справочников и баз данных компании реализуется интеграция используемых локальных информационных систем по средствам единой технологической платформы с помощью сервисного подхода. Создание удобного механизма работы с информацией, независимо от средств существующих локальных систем
Описание архитектуры Обеспечение оптимальной интеграции существующих решений SAP с локальными информационными системами средствами интеграционной платформы SAP NetWeaver. Решение предусматривает организацию работы с критическими стандартами Microsoft.NET и J2EE для интеграции современных бизнес-приложений
Организационное обеспечение Ввод новых ролей в организационной структуре ИТ и соответствующих бизнес подразделений
Проект 6. Нефтегазовая компания
Описание проекта В проекте осуществляется интеграция системы класса ERP и нефтегазовой системы OIS для реализации прозрачных бизнес-процессов с возможностью использования данных из нескольких систем. В частности, реализуемый процесс призван отразить фактические показатели выполнения мероприятия с помощью стандартных документов системы класса ERP на основании акта выполненных работ из подсистемы OIS «Ремонты»
Описание архитектуры Реализуется средство интеграции систем OIS и R/3, которое выполняет следующие функции: — поддерживает существующие протоколы и форматы передачи данных; — обеспечивает подключение новых систем к существующей инфраструктуре без нарушения ее работы; — гарантирует доставку информации от отправителя к получателю, предоставляет инструменты мониторинга и администрирования потоков данных; — эффективно использует имеющиеся каналы связи, при необходимости использовать резервные способы доставки информации
Организационное обеспечение Нет
Проект 7. Банковская компания
Описание проекта Основная задача проекта — решение проблем интеграции учетных систем, системы ERP и другие системы («Сфера», 1С, «Lotus», TIBCO BW) для обеспечения бухгалтерского учета, контроля ресурсов и управления сквозными бизнес-процессами, использующими данные из различных систем
Описание архитектуры Реализуется средство интеграции систем SAP R/3 и «не-SAP систем», которое выполняет следующие функции: — поддерживает существующие протоколы и форматы передачи данных; — обеспечивает подключение новых систем к существующей инфраструктуре без нарушения ее работы; — обеспечивает интеграцию проектов на организационном, информационном и технологическом уровнях; — обеспечивает встраивание новых бизнес-процессов в существующую среду бизнес-процессов корпорации
Организационное обеспечение Нет
Статья представлена к публикации членом редколлегии А.С. Манделем.
Пырлина Ирина Владимировна — эксперт по ИТ-архитектуре, Компания SAP, г. Москва, И [email protected].
