ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТ Р исо/мэк

1668О—

2015

Информационные технологии

МОДЕЛЬ ЗАВЕРШЕННОСТИ ИНТЕГРАЦИИ СЕРВИСОВ КОНСОРЦИУМА OPEN GROUP (OSIMM)

(ISO/IEC 16680:2012,

Information technology — The Open Group Service Integration Maturity Model (OSIMM, IDT)

Издание официальное

Москва

Стандартинформ

2016

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО «ИАВЦ) на основе собственного перевода англоязычной версии на русский язык стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. № 463-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 16680:2012 «Информационная технология. Модель завершенности интеграции сервисов консорциума Open Group (OSIMM)» (ИСО/МЭК 16680:2012 «Information technology — The Open Group Service Integration Maturity Model (OSIMM)», IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

ГОСТ Р ИСО/МЭК 16680—2015

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

6.2.2    Уровень 2. Интегрированный (интегрированные элементы)

Внедрены технологии для обмена данными между разрозненными системами, а также для интеграции данных и взаимодействий. Становится возможным построение ИТ-системы, которая интегрируется в рамках всех подразделений организации. Тем не менее интеграция не доходит до уровня создания общих стандартов, данных или бизнес-процессов. Поэтому для объединения двух систем необходимо зачастую довольно сложное преобразование данных, операций и протоколов, используемых этими системами. Для каждого такого преобразования может потребоваться специализированное программное обеспечение и интерфейсы, что приводит к появлению множества новых приложений, сложных в управлении и программировании. В связи с этим разработка и автоматизация новых бизнес-процессов оказывается нелегкой задачей.

6.2.3    Уровень 3. Компонентный

Разрозненные ИТ-системы были проанализированы и разбиты на компоненты; имеющие структуру, позволяющую доработать их до новых конфигураций и систем. Кроме того, в ограниченной степени может присутствовать анализ бизнес-функций в компонентах. Хотя компоненты взаимодействуют между собой через заданные интерфейсы, они не являются слабосвязанными, что ограничивает гибкость и взаимодействие между разными сегментами организации (и даже между организациями в «экосистеме» деловых связей). Это порождает сложности в разработке и развертывании совместно используемых бизнес-процессов. Бизнес-компоненты и компоненты инфраструктуры являются разрозненными и могут повторно использоваться при помощи программирования и методик EAI (интеграция приложений предприятия). При этом зачастую они дублируют друг друга и порождают избыточность.

6.2.4    Уровень 4. Сервисы

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

Их менеджмент зачастую осуществлен путем назначения обязанностей по управлению SLA (соглашениями об уровне обслуживания) сегментам организации. Бизнес-функциональность детально проанализирована и разбита на сервисы, располагающиеся в пределах бизнес-архитектуры, которая обеспечивает взаимодействие сервисов на бизнес-уровне. Кроме того, сервисы можно определять при помощи языка спецификаций (например, WSDL или архитектуры сервисных компонентов SCA), который позволяет непротиворечивым образом определить операции, выполняемые сервисом, что дает возможность построить каталог сервисов. Сочетание ИТ-архитектуры с архитектурой сервисов позволяет на базе этих сервисов создавать системы, которые работают в рамках разных организаций в пределах экологической системы. Тем не менее на этом уровне интеграции состав сервисов и поток управления в составном сложном приложении задаются не декларативным языком определения потока, а разработчиками, которые создают специализированный код. Это ограничивает гибкость разработки новых бизнес-процессов в качестве сервисов.

6.2.5    Уровень 5. Композитные сервисы

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

6.2.6    Уровень 6. Виртуальные сервисы

Бизнес- и ИТ-сервисы предоставляются через фасад-уровень косвенного обращения. Потребитель сервиса вызывает нужный ему сервис не напрямую, а через вызов «виртуального сервиса». Инфраструктура выполняет все нужные задачи по преобразованию виртуального вызова в физический вызов самого сервиса. В рамках этого преобразования она может менять адрес, сеть, протокол, данные

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

6.2.7 Уровень 7. Динамически реконфигурируемые сервисы

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

6.3 Направления

Уровень завершенности SOA в организации можно оценивать по следующей совокупности направлений, которые являются важными индикаторами эффективного внедрения SOA.

6.3.1    Бизнес

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

6.3.2    Руководство и организация

Направление «Руководство и организация» определяет структуру и проектирование самой организации, и необходимые направления организационной эффективности в контексте SOAn управления SOA. Аспект «Организация» сфокусирован на организационной структуре, взаимоотношениях, ролях и разрешениях, которые необходимы для внедрения сервис-ориентированной стратегии, в которую включены типы и уровни квалификации, обучения и образования, доступные в организации. Аспект «Руководство» связан с формальными процессами менеджмента, направленными на то, чтобы ИТ-операции, возможности сервисов и решения SOA были постоянно согласованы с потребностями бизнеса. Руководство регулирует множество аспектов других направлений завершенности, в том числе способы структурирования менеджмента и распределения затрат.

6.3.3    Методы

Направление «Методы» определяет методы и процессы, которые организация применяет для своей ИТ- и бизнес-трансформации, а также завершенность организации с точки зрения жизненного цикла разработки ПО. К таким методам и процессам относят: менеджмент требований, методики оценки; менеджмент процессов; процессы обеспечения качества; методологии и методики проектирования, а также инструментальные средства при проектировании решений.

6.3.4    Приложения

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

6.3.5    Архитектура

Направление «Архитектура» определяет структуру архитектуры, куда входят топология, методики интеграции, корпоративные решения, стандарты и политики для архитектуры, уровень внедрения вебсервисов, опыт в реализации SOA, критерии соответствия требованиям SOA, а также типовые производимые артефакты.

ГОСТ Р ИСО/МЭК 16680—2015

6.3.6    Информация

Направление «Информация» определяет то, как структурирована информация, как она смоделирована, метод доступа к корпоративным данным, абстракцию доступа к данным с точки зрения функциональных аспектов, характеристики данных, возможности преобразования данных, определения сервисов и процессов, обработку идентификаторов, учетные данные для использования в системе безопасности, управление знаниями, информационную модель и менеджмент контента.

6.3.7    Инфраструктура и менеджмент

Направление «Инфраструктура и менеджмент» определяет возможности инфраструктуры в организации, менеджмент сервисов, ИТ-операции, ИТ-менеджмент и ИТ-администрирование, то, как выполнены SLA и осуществлен мониторинг, а также какие типы платформ интеграции были предоставлены.

6.4    Базовые уровни сервисов

Первые три уровня модели завершенности OSIMM — разрозненный, интегрированный и компонентный — называются базовыми уровнями сервисов. Достичь интеграции сервисов и ориентированности на сервисы гораздо проще, когда бизнес-функции и инфраструктурные функции разрабатывают в качестве выделенных из состава дискретных компонентов, не зависящих от места использования и слабо связаны с основной средой выполнения. Базовые уровни сервисов можно рассматривать как рекомендуемые предпосылки для сервисов, работающих в условиях унаследованной среды (или даже объединения существующих сервисов). Хотя сервисы можно предоставлять и в слабо структурированных средах, это тем не менее может поставить под угрозу успех решения SOA. Исключением могут быть приложения SOA, создаваемые с нуля. Для достижения ориентированности на сервисы в таком случае не нужны те же шаги, которые необходимы при повторном использовании устаревших бизнес-функций. Сервисы, разрабатываемые с использованием веб-сервисов и других технологий обеспечения работы сервисов, также должны соответствовать характеристикам завершенности, которые определены базовыми уровнями сервисов.

6.5    Вопросы для оценки и индикаторы завершенности по направлениям

Индикаторы завершенности оценивают по совокупности вопросов, которые позволяют получить сведения об имеющихся в организации сервисах, связанных с бизнесом и архитектурой, а также о практиках, связанных с SOA. В базовую модель OSIMM входит набор вопросов для оценки и индикаторы завершенности, которые можно использовать в готовом виде или расширить, для того чтобы определить завершенность интеграции сервисов в организации.

6.5.1    Вопросы для оценки завершенности сервисов

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

-    отдел ИТ-операций;

-    группа разработки и развертывания сервисов;

-    персонал бизнес-подразделений, поддерживающий работу сервиса или бизнес-сферы;

-    корпоративный архитектор;

-    организация СЮ.

6.5.2    Соответствие вопросов оценки индикаторам завершенности

Вопросы для оценки коррелируют с атрибутами завершенности для каждого индикатора завершенности по направлениям. Это помогает организатору оценки определить, какие вопросы оценки предназначены для сбора той информации, которая может быть использована для определения корреляции между конкретными атрибутами завершенности и определенным индикатором завершенности, чтобы тем самым определить уровень завершенности сервиса. На рисунке 2 показано, что вопросы 2 и 3 позволяют сделать вывод об атрибутах завершенности, которые указывают на то, что направление «Бизнес» находится на уровне 1 «Разрозненный» (бизнес-процессы не имеют формального определения и документации).

9

Индикаторы завершенности по направлению «Бизнес» Уровень завершенности Индикатор завершенности Атрибуты завершенности Значимость завершенности Соответ ствие вопросов оценки Разрозненный (уровень 1) Изолированные бизнес-подразделения, линейное управление Формальное определение и документация бизнес-факторов и бизнес-процессов в организации Низкий уровень или отсутствует Бизнес-процессы не имеют формального определения^ и документгщкы*^^ Ограничиваются ^^ррзбуемым поведением определенных приложений; специфические для ИТ 10 (---"\2'3 Вопросы для оценки по направлению «Бизнес» 2    Какова концепция бизнеса и бизнес-цели и как они связаны с текущими задачами ИТ? 3    Определена ли официально, документирована ли и управляется ли текущая архитектура бизнес-процессов?

Рисунок 2 — Соответствие вопросов оценки для уровня завершенности 1 направления «Бизнес»

6.6 Расширение базовой модели OSIMM

Стандартный набор вопросов для оценки и индикаторы завершенности определены в 6.3, 6.3.1 (см. 6) в качестве базовой модели OSIMM. Базовая модель OSIMM может быть расширена путем добавления дополнительных индикаторов завершенности, вопросов для оценки и соответствующих атрибутов для того, чтобы включить в нее индикаторы завершенности, характерные для отрасли или предприятия. Отраслевые расширения могут быть стандартизированы, чтобы обеспечить единую базу для измерения завершенности интеграции сервисов сточки зрения внедрения сервисных структур для конкретной отрасли (в частности, структуры для отраслей розничной торговли и финансовых услуг).

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

Значимости индикаторов завершенности в базовой модели OSIMM следуют с шагом 10 баллов соответственно возрастанию уровня завершенности. Максимальное значение оценки завершенности не может превышать значимости. Для получения единой оценки все значимости суммируются. Дополнительным индикаторам завершенности могут назначаться значимости исходя из того, какую часть они составят от возможной общей оценки завершенности для направления. Оценивание и значимости определяются организатором оценки и согласуются с целевой организацией. Значимость уровня завершенности в базовой модели OSIMM основана на шкале с шагом 10 баллов. Общий количественный показатель оценки завершенности может быть установлен путем сложения значимостей, полученных в ходе оценки. Например, если общий количественный показатель равен 210, это будет означать, что в ходе оценки уровень завершенности SOA соответствует уровню «Компонентный». Тем не менее необходимо понимать, что организации следует сосредоточиться на оценке завершенности SOA по каждому направлению и на той коммерческой выгоде, которую можно получить, увеличив уровень завершенности SOA по определенному направлению. Количественные показатели по областям и отдельные количественные показатели можно сравнивать с целевыми количественными показателями завершенности

10

5    как в менеджменте бизнес-процессов (ВРМ) измеряют показатели окупаемости инвестиций?

6    насколько гибкими являются текущие бизнес-процессы?

7    какие текущие методы финансирования использованы?

8    какая текущая стоимостная модель использована?

9    кто является владельцем портфеля процессов, приложений и сервисов?

10    имеется ли стоимостная модель для начисления потребителям платы за использование сервиса?

11    каким образом определена совокупная стоимость владения (включая программное и аппаратное обеспечение, а также будущее обслуживание) на данный момент?

12    какой уровень партнерства налажен между заинтересованными лицами в бизнесе и заинтересованными лицами в ИТ?

13    каким образом в настоящее время измеряют уровни бизнес-сервисов?

14    какие текущие практики использованы по преобразованию Sl-Адля бизнеса в Sl-Адля ИТ?

15    имеется ли формальная корпоративная архитектура?

16    применено формальное управление корпоративной архитектурой?

17    имеется несколько бизнес-подразделений и есть у них потребность в собственных бизнес-процессах?

18    имеют ли бизнес-подразделения общую информационную модель? Применяется ли совместное использование или репликация данных?

19    работают ли бизнес-подразделения с одними и теми же клиентами, поставщиками и партнерами?

7.3 Направление «Бизнес»: соответствие индикаторов завершенности атрибутам

завершенности

Далее приведен базовый набор индикаторов завершенности по направлению «Бизнес» в модели OSIMM. Каждый индикатор завершенности связан с набором атрибутов завершенности. Атрибуты завершенности — это выявленные характеристики индикатора завершенности для каждого уровня завершенности. Вопросы оценки необходимы для проведения опроса по направлению «Бизнес» в организации. Полученные ответы на вопросы для оценки направления «Бизнес» используют для определения уровня завершенности посредством оценивания результата и выбора тех атрибутов завершенности, которые наилучшим образом соответствуют полученным результатам. Показатели значимостей уровня завершенности применяют для определения средних количественных показателей завершенности по нескольким индикаторам завершенности. Модель может быть расширена путем добавления дополнительных индикаторов завершенности и присвоения значимостям индикаторов уровня завершенности значений, определенных проводящей оценку организацией для индикаторов завершенности.

Таблица 1 — Индикаторы завершенности по направлению «бизнес»

Уровень завершенности Индикатор завершенности Атрибуты завершенности Значимость завершен ности Соответствие вопросов оценки Разрозненный (уровень 1) Изолированные бизнес-подразделения, линейное управление Формальное определение и документация бизнес-факторов и бизнес-процессов организации Низкий уровень или отсутствуют Корпоративная архитектура не является элементом корпоративной или ИТ-стратегии Бизнес-процессы не имеют формального определения и документации 10 2, 15 3 Ограничиваются требуемым поведением определенных приложений; специфические для ИТ 1, 9, 17, 18

Продолжение таблицы 1

Уровень завершенности Индикатор завершенности Атрибуты завершенности Значимость завершен ности Соответствие вопросов оценки Интегрированный (уровень 2) Интеграция бизнес-процессов Формальное определение и документация бизнес-факторов и бизнес-процессов организации Ограниченный Нет формальной корпоративной архитектуры Ограничены целями бизнес-специализации и потребностью в информации от других организаций 20 15 1, 2, 3, 4, 6, 9, 17, 18, 19 Компонентный (уровень 3) Компонентный бизнес Формальное определение и документация бизнес-факторов и бизнес-процессов организации Между организациями Существуют отдельные формальные компоненты корпоративной архитектуры Бизнес-факторы организации документированы как бизнес-цели между организациями 30 15, 16 1, 2, 9, 17, 18, 19 Сервисы (уровень 4) Компонентный бизнес предоставляет и использует сервисы Формальное определение и документация бизнес-факторов и бизнес-процессов организации В масштабах всего предприятия Официальное применение корпоративной архитектуры Бизнес-факторы организации документированы как элементы стратегии предприятия и бизнес-архитектуры 40 3, 15, 16 I,    2, 3, 8, 9, 10, II,    17, 18, 19 Композитные сервисы (уровень 5) Процессы предоставляются и используются посредством композитных бизнес-сервисов Формальное определение и документация бизнес-факторов и бизнес-процессов организации Интегрированы в масштабах всего предприятия Официальное применение корпоративной архитектуры и менеджмента бизнес-процессов (ВРМ) 50 3, 4, 5, 6, 10, 11, 15, 16 Бизнес-факторы организации документированы как элементы стратегии предприятия и бизнес-архитектуры I,    2, 3, 8, 9, 10, II,    17, 18, 19 Виртуальные сервисы (уровень 6) Аутсорсинг сервисов, ВРМ и ВАМ Формальное определение и документация бизнес-факторов и бизнес-процессов организации Интеграция по всему предприятию, а также с внешними бизнес-партнерами Четко определенная корпоративная архитектура, где подробно прописаны как последовательности внутренних процессов, так и аутсорсинговые процессы со службами бизнес-партнеров и между ними. Активное использование мониторинга бизнес-операций (ВАМ) 60 4, 5 ,6, 7, 9, 11, 12, 13, 14, 15, 19

13

ГОСТ Р ИСО/МЭК 16680—2015

- оценку завершенности интеграции сервисов по направлению «Руководство и организация» в модели OSIMM можно проводить путем выявления формального использования управления сервисами и SOA в масштабах всей организации для разработки, развертывания и менеджмента бизнес- и ИТ-сервисов (решений SOA).

8.2    Направление «Руководство и организация»: вопросы для оценки

Обработав ответы на следующие вопросы, эксперт по оценке может поставить в соответствие индикатору завершенности соответствующие атрибуты завершенности, тем самым определив уровень завершенности по направлению «Руководство и организация»:

1    какая квалификация наиболее распространена среди ИТ-персонала?

2    как ИТ-управление относится к SOA?

3    каким образом ИТ-управление соотносится или приведено в соответствие с SOA, корпоративной архитектурой, а также управлением в организации?

4    существуют ли процессы управления SOA, документированы ли они, и если да, то используются ли они для сервисов во время проектирования и во время выполнения?

5    определено ли взаимодействие между организациями, участвующими в SOA, с четко прописанными ролями и обязанностями?

6    какие функции и обязанности определены в рамках управления?

7    как можно описать стоимостную модель ИТ?

8    какое обучение по SOA доступно в ИТ-организации?

9    какие взаимоотношения существуют между командой разработчиков и командой управления инфраструктурой в организации?

10    какие существуют полномочия по SOA и управлению?

11    распространены ли решения SOA организации за ее границы? Внутри организации? За ее пределами между бизнес-партнерами?

8.3    Направление «Руководство и организация»: соответствие индикаторов завершенности

атрибутам завершенности

Далее приведен базовый набор индикаторов завершенности по направлению «Руководство и организация» в модели OSIMM. Каждый индикатор завершенности связан с набором атрибутов завершенности. Атрибуты завершенности — это выявленные характеристики индикатора завершенности для каждого уровня завершенности. Вопросы оценки необходимы для проведения опроса по направлению «Руководство и организация» в организации. Полученные ответы на вопросы для оценки направления «Руководство и организация» используют для определения уровня завершенности посредством оценивания результата и выбора тех атрибутов завершенности, которые наилучшим образом соответствуют полученным результатам. Показатели значимостей уровня завершенности используют для определения средних количественных показателей завершенности по нескольким индикаторам завершенности. Модель может быть расширена путем добавления дополнительных индикаторов завершенности и присвоения значимостям индикаторов уровня завершенности значений, определенных проводящей оценку организацией для индикаторов завершенности.

Таблица 2 — Индикаторы завершенности по направлению «Руководство и организация»

Уровень завершенности Индикатор завершенности Атрибуты завершенности Значи мость завершен ности Соответст вие вопросов оценки Разрозненный (уровень 1) Стратегия и управление специализированным ИТ Официальное применение управления сервисами и SOA в масштабах всей организации для разработки, развертывания и менеджмента бизнес-и ИТ-сервисов (решений SOA) Низкий уровень или отсутствует Отсутствует концепция или стратегия внедрения SOA. Отсутствует признание ценности управления сервисами или процессами ИТ-бизнеса Не существует координации сервисов (SOA) между организациями с той же специализацией (LOB) Минимум обучения по SOA 10 2, 3, 4, 5 11 1, 8

ГОСТ Р ИСО/МЭК 16680—2015

Содержание

1    Область применения....................................................................................................................................1

2    Общие положения........................................................................................................................................1

3    Соответствие.................................................................................................................................................2

4    Термины и определения...............................................................................................................................2

5    Дальнейшее развитие..................................................................................................................................5

6    Модель...........................................................................................................................................................5

6.1    Общие положения.................................................................................................................................5

6.2    Уровни завершенности..........................................................................................................................6

6.3    Направления..........................................................................................................................................8

6.4    Базовые уровни сервисов.....................................................................................................................9

6.5    Вопросы для оценки и индикаторы завершенности по направлениям.............................................9

6.6    Расширение базовой модели OSIMM................................................................................................10

7    Направление «Бизнес»: базовая модель..................................................................................................11

7.1    Направление «Бизнес»: базовая модель. Индикатор завершенности............................................11

7.2    Направление «Бизнес»: вопросы для оценки...................................................................................11

7.3    Направление «Бизнес»: соответствие индикаторов завершенности

атрибутам завершенности..................................................................................................................12

8    Направление «Руководство и организация»: базовая модель...............................................................14

8.1    Направление «Руководство и организация»: базовая модель. Индикатор завершенности..........14

8.2    Направление «Руководство и организация»: вопросы для оценки.................................................15

8.3    Направление «Руководство и организация»: соответствие индикаторов

завершенности атрибутам завершенности.......................................................................................15

9    Направление «Методы»: базовая модель................................................................................................17

9.1    Направление «Методы»: базовая модель. Индикатор завершенности..........................................17

9.2    Направление «Методы»: вопросы для оценки..................................................................................18

9.3    Направление «Методы»: соответствие индикаторов завершенности

атрибутам завершенности..................................................................................................................18

10    Направление «Приложения»: базовая модель......................................................................................20

10.1    Направление «Приложения»: базовая модель. Индикатор завершенности...............................20

10.2    Направление «Приложения»: вопросы для оценки.......................................................................21

10.3    Направление «Приложения»: соответствие индикаторов завершенности

атрибутам завершенности...............................................................................................................21

11    Направление «Архитектура»: базовая модель.......................................................................................23

11.1    Направление «Архитектура»: базовая модель. Индикатор завершенности................................24

11.2    Направление «Архитектура»: вопросы для оценки.......................................................................24

11.3    Направление «Архитектура»: соответствие индикаторов завершенности

атрибутам завершенности...............................................................................................................24

12    Направление «Информация»: базовая модель.....................................................................................26

12.1    Направление «Информация»: базовая модель. Индикатор завершенности..............................26

12.2    Направление «Информация»: вопросы для оценки......................................................................27

12.3    Направление «Информация»: соответствие индикаторов завершенности

атрибутам завершенности...............................................................................................................27

13    Направление «Инфраструктура и менеджмент»: базовая модель......................................................30

13.1    Направление «Инфраструктура и менеджмент»: базовая модель.

Индикатор завершенности...............................................................................................................30

13.2    Направление «Инфраструктура и менеджмент»: вопросы для оценки.......................................30

13.3    Направление «Инфраструктура и менеджмент»: соответствие индикаторов

завершенности атрибутам завершенности....................................................................................31

14    Метод оценки OSIMM...............................................................................................................................33

14.1    Общие положения............................................................................................................................33

14.2    Шаги оценки OSIMM.........................................................................................................................33

Продолжение таблицы 2

Уровень завершенности Индикатор завершенности Атрибуты завершенности Значи мость завершен ности Соответст вие вопросов оценки Интегрированный (уровень 2) ИТ-трансформация Официальное применение управления сервисами и SOA в масштабах всей организации для разработки, развертывания и менеджмента бизнес- и ИТ-сервисов (решений SOA) Ограниченный Совершенствуется формальная стратегия SOA. Имеется некоторая координация между организациями Значение управления сервисами и SOA было признано, но оно не было принято организацией должным образом 20 2, 3, 4, 5, 11 6, 9, 10 Компонентный (уровень 3) Общие процессы управления SOA Официальное применение управления сервисами и SOA в масштабах всей организации для разработки, развертывания и менеджмента бизнес-и ИТ-сервисов (решений SOA) Между организациями Имеется формализованная стратегия SOA совместно с одной или несколькими организациями Значение управления сервисами и SOA было признано, но оно не было принято организацией должным образом Управление SOA было введено, но оно не было принято организацией должным образом Проводится обучение по SOA и имеются квалификации в этой области, однако только среди ИТ-специалистов Совместно используемые сервисы и управление ими могут использоваться одним или несколькими видами бизнесами 30 5, 9 2, 3, 4, 6 2, 3, 4, 6 1, 8 7, 11 Сервисы (уровень 4) Появление управления SOA Официальное применение управления сервисами и SOA в масштабах всей организации для разработки, развертывания и менеджмента бизнес-и ИТ-сервисов (решений SOA) В масштабах всего предприятия Формальная общекорпоративная концепция и стратегия SOA была определена, опубликована и согласована с бизнес-подразделениями в масштабах всей организаций Формальный процесс и структура управления SOA были документированы и функционируют в большинстве подразделений Программы обучения были адаптированы под потребности ИТ и бизнес-подразделений 40 2, 3, 5, 10 4, 6 1, 6, 8 Композитные сервисы (уровень 5) Согласованное управление SOA и ИТ Официальное применение управления сервисами и SOA в масштабах всей организации для разработки, развертывания и менеджмента бизнес- и ИТ-сервисов (решений SOA) Интегрированные в масштабах предприятия Применение SOA и совместно используемые сервисы являются признанным элементом стратегии, бизнес- и ИТ-моделей Управление SOA принято по всему предприятию большинством организаций и наделено полномочиями менеджмента сервисов и решений SOA 50 2, 3, 5, 11 4, 6, 9, 10

ГОСТ Р ИСО/МЭК 16680—2015

Приложение А (справочное) Пример оценки...............................................................................................36

Приложение В (справочное) Преимущества перехода на более высокие уровни завершенности........40

Приложение С (справочное) Взаимосвязь с другими стандартами SOA..................................................42

Приложение D (справочное) Взаимосвязь с другими международными стандартами............................44

Приложение ДА (справочное) Сведения о соответствии ссылочных международных

стандартов ссылочным национальным стандартам Российской Федерации..............48

IV

ГОСТ Р ИСО/МЭК 16680—2015

Введение

Консорциум Open Group — это независимый от поставщиков и не связанный ни с одной технологией консорциум, чья концепция информационного потока без границ (Boundaryless Information Flow™) обеспечивает доступ к интегрированной информации в пределах организаций и между разными предприятиями на основе открытых стандартов, глобальной совместимости и взаимодействия. Open Group работает с клиентами, поставщиками, консорциумами и другими органами стандартизации. Роль этой организации состоит в том, чтобы: фиксировать, анализировать и удовлетворять текущие и вновь возникающие требования, устанавливать политики и распространять передовые практики; способствовать взаимодействию, вырабатывать консенсус, развивать и интегрировать спецификации и технологии сообщества открытого программного обеспечения; предлагать комплексный набор услуг для повышения операционной эффективности консорциумов, а также поддерживать работу наиболее уважаемых в отрасли сервисов сертификации, включая сертификацию UNIX®. Дополнительная информация о консорциуме Open Group доступна по адресу: www.opengroup.org.

Консорциум Open Group уже более 15 лет занимается разработкой и поддержкой программ сертификации. Его специалисты располагают обширным опытом в создании и продвижении тестовых комплексов, предназначенных для проверки соответствия открытым стандартам и спецификациям.

Дополнительная информация доступна по адресу: www.opengroup.org/certification.

Консорциум публикует широкий спектр технической документации, основная часть которой посвящена разработке стандартов и руководств по технологиям и продуктам. Кроме того, на регулярной основе издают официальные документы, технические исследования, документацию по брендам и тестированию, а также бизнес-публикации. Подробные сведения и каталог изданий доступны по адресу: www.opengroup.org/bookstore.

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

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

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

Следует обратить внимание на то, что обновления (в форме списка исправлений) могут прилагаться к любой публикации. Эта информация публикуется по адресу: www.opengroup.org/corrigenda.

Настоящий стандарт является техническим стандартом для модели завершенности интеграции сервисов консорциума Open Group (OSIMM) версии 2. Он был разработан и утвержден консорциумом Open Group.

В модели завершенности интеграции сервис-ориентированной архитектуры (SOA) консорциума Open Group (OSIMM) содержатся средства для оценки уровня завершенности сервис-ориентированной архитектуры в организации, предназначенные для консультантов и ИТ-специалистов, занимающихся практической работой. В ней определен процесс создания плана пошагового внедрения SOA, что позволяет максимально увеличить преимущества каждого этапа на этом пути. Данная модель состоит из семи уровней завершенности и семи направлений, которые необходимо изучить и которые отражают важные параметры бизнес- и ИТ-возможностей, где применение принципов SOA играет важную роль для развертывания услуг. Стандарт OSIMM выступает в качестве количественной модели, которая помогает оценить текущее и необходимое состояние завершенности SOA.

v

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

МОДЕЛЬ ЗАВЕРШЕННОСТИ ИНТЕГРАЦИИ СЕРВИСОВ КОНСОРЦИУМА OPEN GROUP (OSIMM)

Information technologies. The Open Group Service Integration Maturity Model (OSIMM)

Дата введения — 2016—06—01

1    Область применения

Настоящий стандарт представляет модель завершенности интеграции сервисов консорциума Орел Group (OSIMM). В нем определены:

-    модель, относительно которой можно оценивать степень завершенности интеграции сервисов в организации;

-    процесс оценки текущей и необходимой степени завершенности интеграции сервисов в организации при помощи этой модели.

2    Общие положения

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

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

Стандарт OSIMM предлагается в качестве стандартизированной модели, которая способна помочь организациям в развитии SOA. Стандартная модель завершенности позволяет организациям проводить эталонное тестирование уровней SOA и составлять графики трансформации, которые помогут им в планировании. Поставщики могут использовать ее для позиционирования своих услуг и программного обеспечения относительно этих эталонных тестов. Кроме того, стандарт OSIMM может служить программой трансформации, которая способна адаптироваться под конкретные потребности организаций и задачи оценки. Этот процесс состоит из следующих этапов:

-    подготовка программы оценки OSIMM;

-    определение исходного уровня завершенности;

-    определение целевого уровня завершенности;

-    определение пути трансформации, необходимого организации для достижения определенного уровня завершенности.

Издание официальное

Стандарт OSIMM структурирует оценку текущего состояния организации сточки зрения интеграции и гибкости сервисов (включая ориентированность на сервисы), а также ее будущего состояния для различных бизнес-подразделений или предприятий, с учетом проблемных вопросов гибкости и интеграции, требующих решения. Он предоставляет модель, которая поможет организациям в определении своей архитектурной стратегии при внедрении ориентированности на сервисы, включая создание архитектурного плана инициатив по трансформации устаревших систем, интеграции с одним или несколькими пакетами приложений, обновлению и разработке приложений, а также интеграции систем. Этот план помогает определить объем работ, основные сферы изменений и необходимые шаги для различных частей организации с целью их трансформации в направлении более высоких уровней ориентированности на сервисы и интеграции сервисов, с обоснованием сточки зрения ожидаемых преимуществ для бизнеса. Стандарт OSIMM предоставляет структуру для совершенствования результатов анализа и выявления ИТ-улучшений сточки зрения разработки компонентов, интеграции сервисов, ЭОАи ИТ-управления.

Стандарт OSIMM направлен на увеличение уровней гибкости в семи аспектах организации или предприятия, таких как: бизнес, руководство и организация, методы и процессы, портфель приложений, архитектура, информация, инфраструктура и операционный менеджмент. Направленность на эти аспекты помогает во внедрении более гибкого бизнеса посредством заблаговременного планирования интеграции и построения бизнес-моделей, процессов, приложений и инфраструктуры с ориентацией на гибкость.

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

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

3    Соответствие

В настоящем стандарте определены модель завершенности OSIMM SOA и соответствующий процесс оценки завершенности SOA, а также описаны характеристики архитектур, необходимые для достижения конкретного уровня завершенности SOA. Для того чтобы модели завершенности и их оценки соответствовали настоящей спецификации, в них должны, как минимум, использовать терминологию, матрицу, направления, уровни и атрибуты, описываемые в настоящем стандарте. Соответствие конкретным индикаторам модели завершенности не является обязательными. Пример процесса оценки, который соответствует настоящему стандарту, приведен в главе «Метод оценки OSIMM» (см. раздел 14), однако его соблюдение не является обязательным.

4    Термины и определения

В настоящем стандарте приведены определения терминов, которые имеют особое значение в стандарте OSIMM или могут быть неправильно интерпретированы. Таким образом, в целях настоящего стандарта применены следующие термины с соответствующими определениями:

4.1 внедрение (adoption): Детальные шаги, необходимые для осуществления трансформации. К этим шагам могут относить внедрение новых технологий, методик, процессов и техник интеграции, организация корпоративных инициатив, разработка ИТ-директив и технических стандартов, а также создание исполнительных советов, архитектурных комитетов и управления.

ГОСТ Р ИСО/МЭК 16680—2015

4.2    архитектурный стиль (architectural style): Сочетание отличительных особенностей, в которых осуществлена или выражена архитектура. Архитектурный стиль SOA имеет следующие отличительные особенности:

-основан на проектировании сервисов, отражающих бизнес-операции реального мира, и охватывает основные корпоративные (или межкорпоративные) бизнес-процессы;

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

-устанавливает уникальные требования к инфраструктуре — в реализациях рекомендуется использовать открытые стандарты для обеспечения совместимости, а также прозрачности места использования;

-    реализации специфичны для конкретной среды — они ограничены условиями применения или возможны благодаря им и должны быть определены в пределах этих условий применения;

-    требует жесткого управления представлением и реализацией сервиса;

-требует проведения проверки на предмет определения качества сервиса.

4.3    оценка (assessment): Процесс оценки или экспертизы для определения завершенности.

4.4    стандарт языка исполнения бизнес-процессов (BPEL): Стандарт языка исполнения бизнес-процессов.

4.5    бизнес-сервис (business service): Самостоятельная часть бизнес-функциональности, которая может быть вызвана через строго определенные стандартный интерфейс и протокол, независимо от платформы реализации, и управляется в соответствии с договором, в котором определены уровни доступности и качество обслуживания.

4.6    может (сап): Определяет допустимое необязательное отличительное свойство или поведение, которые может иметь оценка.

4.7    направление, представление (dimension, view): Основная ось, вдоль которой можно измерять уровень завершенности SOA.

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

4.8    область (domain): Составная часть направления, представляющая его более конкретный аспект, по которому возможна оценка организации сточки зрения уровня завершенности ее SOA. Кроме того, этот термин может обозначать аспект, на который могут оказывать воздействие принципы SOA. В любой из областей имеется один или несколько индикаторов завершенности на каждом уровне завершенности. Совокупность индикаторов определяет путь развития от менее зрелой SOAk более зрелой. Общий уровень завершенности направления определяется исходя из совокупности уровней по областям.

4.9    динамическая конфигурация (dynamic configuration): Способность системы обнаруживать новые сервисы исходя из сопоставления требуемой спецификации, а также конфигурировать себя для вызова этих новых сервисов без разработки нового программного кода.

4.10    структура (framework): Фундаментальная структура или набор структур, которые могут быть использованы для разработки самых разных архитектурных продуктов. Архитектурная структура должна включать в себя методы разработки информационной системы с точки зрения набора сервисов и демонстрации того, как сервисы сочетаются друг с другом. Кроме того, она должна включать в себя набор инструментов и определять общий словарь.

4.11    основная модель данных (master data model): Сервис виртуальной, интегрированной модели данных с основным представлением.

4.12    завершенность (maturity): Достижение в организации характеристик и поведения, которые обеспечивают более эффективное функционирование в соответствии с бизнес-ролями в результате трансформации и адаптации.

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

3

Концепции трансформации, внедрения и завершенности SOA являются взаимозависимыми: из состава трансформации можно выделить внедрения, в процессе которых создаются новые характеристики — признак завершенности.

4.13    индикатор завершенности, характеристика (maturity indicator, characteristic): Характеристика бизнеса или ИТ, которая может быть измерена и оценена с помощью ответов на определенные вопросы. Каждый индикатор завершенности связан с определенной областью (и, соответственно, с направлением) и уровнем завершенности; если индикатор оценивают как «истинный», это свидетельствует о том, что данная область относится к соответствующему уровню завершенности.

4.14    атрибут уровня завершенности (maturity level attribute): Наблюдаемые характеристики индикатора завершенности в пределах направления для каждого уровня завершенности.

4.15    модель завершенности (maturity model): Средство и шкала оценки текущего состояния завершенности.

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

4.16    должен (must): Определяет свойство или поведение, которое является обязательным для оценки. Для соответствия данной спецификации оценка должна включать это свойство или поведение.

4.17    модель завершенности интеграции сервисов консорциума Open Group; OSIMM (Орел Group Service Integration Maturity Model, OSIMM): Модель, позволяющая оценивать степень соответствия организации или предприятия в рамках их ИТ или бизнеса принципам SOA. Модель определяет семь уровней завершенности: уровень 1 означает наименьшую, а уровень 7 — наибольшую степень соответствия. Следствием более высокой степени завершенности с большой вероятностью является более высокий уровень гибкости в бизнесе. Однако высокий уровень не обязательно «лучше», поскольку у каждой организации может быть свой идеальный уровень завершенности в зависимости от ее бизнес-требований и контекста бизнеса и ИТ.

4.18    организация (organization): Субъект, заинтересованный во внедрении SOA в целях развертывания бизнес-процессов на базе сервисов, включая правительственные организации, коммерческие организации, бизнес-подразделения, проекты, предприятия, экологическую систему оказания услуг или отрасли.

4.19    сервис (servis): Логическое представление воспроизводимой бизнес-операции, которое:

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

-является самостоятельным;

-    может состоять из других сервисов;

-    является «черным ящиком» для потребителей сервиса.

4.20    завершенность интеграции сервисов (service integration maturity): Степень интеграции сервисов, необходимая для реализации ориентированности на сервисы и определяемая семью уровнями завершенности сервисов.

4.21    соглашение об уровне обслуживания; SLA (Service-Level Agreement, SLA): Договор, заключаемый в основном между поставщиками услуг и их пользователями, в котором установлены соглашения о доступности, объеме услуг и времени реагирования.

4.22    управление сервисами (service management): Практики и методики, необходимые для управления сервисами в решениях SOA.

4.23    ориентированность на сервисы (service orientation): Способ мышления в терминах сервисов, разработки на базе сервисов, а также результатов сервисов.

Примечание - Объяснение терминов взято из определения SOA, которое было подготовлено Рабочей группой Open Group SOA; см. www.opengroup.org/projects/soa.

4.24    следует (Should): В отношении оценки, соответствующей этой спецификации, определяет свойство или поведение, которое является рекомендованным, но не обязательным.

4.25    SOA: Архитектурный стиль, поддерживающий ориентированность на сервисы.

4.26    экосистема [SOA] ([SOA] Eco-System): Группа из одной или нескольких организаций, зависящих друг от друга в области достижения бизнес-целей путем использования сервисов, в которых могут быть использованы бизнес-процессы другой компании.

4

ГОСТ Р ИСО/МЭК 16680—2015

4.27    метод SOA(SOA Method): Передовые практики, эталонные архитектуры, шаблоны и руководства по разработке решений SOA.

4.28    трансформация (Transformation): Высокоуровневое изменение с переходом из одного организационного состояния в другое с целью реализации бизнес-требований и целей. Трансформации могут представлять собой бизнес-трансформации (например, уменьшение количества обращений клиентов) или ИТ-трансформации (например, организация поддержки рынков в разных географических регионах). Для того чтобы бизнес-операции были согласованы с ИТ-операциями, бизнес-трансформации и ИТ-трансформации могут потребовать параллельного осуществления.

4.29    виртуальный сервис (Virtualized Service): Скрытый сервис, вызываемый пользователем не напрямую, а через прокси-сервер, который перехватывает вызов и перенаправляет его к реальному сервису, исходя из таких соображений, как нагрузка и доступность.

5    Дальнейшее развитие

Разработка репозитория индикаторов завершенности OSIMM.

Разработка репозитория примеров использования OSIMM.

6    Модель

6.1 Общие положения

Модель завершенности интеграции сервисов консорциума Open Group (OSIMM) определяет, каким образом измеряют уровни интеграции сервисов организации, ее ИТ-системы и бизнес-приложений. Кроме того, она содержит руководство по достижению определенных уровней завершенности сервисов, необходимых для реализации соответствующих бизнес-преимуществ.

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

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

-    бизнес;

-    руководство и организация;

-    методы;

-    приложения;

-    архитектура;

-    информация;

-    инфраструктура и менеджмент.

Существует семь уровней завершенности SOA:

-    разрозненный;

-    интегрированный;

-    компонентный;

-    сервисы;

-    композитные сервисы;

-    виртуальные сервисы;

-динамически реконфигурируемые сервисы.

Уровень завершенности по каждому направлению оценивают путем сопоставления индикаторов завершенности с атрибутами уровня завершенности. Общая оценка индикаторов завершенности по всем направлениям позволяет получить полное представление об уровне завершенности интеграции сервисов в организации.

На рисунке 1 представлены все направления и уровни завершенности.

5