— Все документы — ГОСТы — ГОСТ Р ИСО/МЭК 16680-2015 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МОДЕЛЬ ЗАВЕРШЕННОСТИ ИНТЕГРАЦИИ СЕРВИСОВ КОНСОРЦИУМА OPEN GROUP (OSIMM)
ГОСТ Р ИСО/МЭК 16680-2015 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МОДЕЛЬ ЗАВЕРШЕННОСТИ ИНТЕГРАЦИИ СЕРВИСОВ КОНСОРЦИУМА OPEN GROUP (OSIMM)
Добавил:
Дата: [24.10.2017]
ГОСТ Р ИСО/МЭК 16680-2015 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МОДЕЛЬ ЗАВЕРШЕННОСТИ ИНТЕГРАЦИИ СЕРВИСОВ КОНСОРЦИУМА OPEN GROUP (OSIMM)
Information technologies. The Open Group Service Integration Maturity Model (OSIMM)
Дата введения - 1 июня 2016 г.
Введен впервые
Предисловие
1 Подготовлен Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО "ИАВЦ) на основе собственного перевода англоязычной версии на русский язык стандарта, указанного в пункте 4
2 Внесен Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
3 Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. N 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 Введен впервые
Введение
Консорциум Open Group - это независимый от поставщиков и не связанный ни с одной технологией консорциум, чья концепция информационного потока без границ (Boundaryless Information FlowTM) обеспечивает доступ к интегрированной информации в пределах организаций и между разными предприятиями на основе открытых стандартов, глобальной совместимости и взаимодействия. 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.
1 Область применения
Настоящий стандарт представляет модель завершенности интеграции сервисов консорциума Open Group (OSIMM). В нем определены:
- модель, относительно которой можно оценивать степень завершенности интеграции сервисов в организации;
- процесс оценки текущей и необходимой степени завершенности интеграции сервисов в организации при помощи этой модели.
2 Общие положения
Сервис-ориентированная архитектура (SOA) - это архитектурный стиль, который поддерживает ориентированность на сервисы. Сервис - это бизнес-задача со сформулированным для внешнего применения описанием, которое часто имеет форму договора между поставщиком и потребителем. По мере того как организации внедряют SOA и используют сервисы в качестве фундаментального структурирующего элемента своей архитектуры, они все чаще сталкиваются с необходимостью оценивать свое текущее положение на пути миграции и наилучшие способы реализации ожидаемых преимуществ, получаемых в результате интеграции и инвестиций в более высокие уровни завершенности SOA.
Стандарт OSIMM помогает организации создать план пошаговой трансформации в направлении высоких уровней интеграции сервисов, чтобы достигать все возрастающих преимуществ для бизнеса, связанных с более высокими уровнями завершенности. Стандарт OSIMM используют для того, чтобы определить, какие организационные характеристики являются необходимыми для достижения нового уровня завершенности. Это также помогает определить, возможно ли проблемы, возникающие на текущем уровне завершенности интеграции сервисов, решить путем перехода на более высокий уровень.
Стандарт OSIMM предлагается в качестве стандартизированной модели, которая способна помочь организациям в развитии SOA. Стандартная модель завершенности позволяет организациям проводить эталонное тестирование уровней SOA и составлять графики трансформации, которые помогут им в планировании. Поставщики могут использовать ее для позиционирования своих услуг и программного обеспечения относительно этих эталонных тестов. Кроме того, стандарт OSIMM может служить программой трансформации, которая способна адаптироваться под конкретные потребности организаций и задачи оценки. Этот процесс состоит из следующих этапов:
- подготовка программы оценки OSIMM;
- определение исходного уровня завершенности;
- определение целевого уровня завершенности;
- определение пути трансформации, необходимого организации для достижения определенного уровня завершенности.
Стандарт OSIMM структурирует оценку текущего состояния организации с точки зрения интеграции и гибкости сервисов (включая ориентированность на сервисы), а также ее будущего состояния для различных бизнес-подразделений или предприятий, с учетом проблемных вопросов гибкости и интеграции, требующих решения. Он предоставляет модель, которая поможет организациям в определении своей архитектурной стратегии при внедрении ориентированности на сервисы, включая создание архитектурного плана инициатив по трансформации устаревших систем, интеграции с одним или несколькими пакетами приложений, обновлению и разработке приложений, а также интеграции систем. Этот план помогает определить объем работ, основные сферы изменений и необходимые шаги для различных частей организации с целью их трансформации в направлении более высоких уровней ориентированности на сервисы и интеграции сервисов, с обоснованием с точки зрения ожидаемых преимуществ для бизнеса. Стандарт OSIMM предоставляет структуру для совершенствования результатов анализа и выявления ИТ-улучшений с точки зрения разработки компонентов, интеграции сервисов, SOA и ИТ-управления.
Стандарт OSIMM направлен на увеличение уровней гибкости в семи аспектах организации или предприятия, таких как: бизнес, руководство и организация, методы и процессы, портфель приложений, архитектура, информация, инфраструктура и операционный менеджмент. Направленность на эти аспекты помогает во внедрении более гибкого бизнеса посредством заблаговременного планирования интеграции и построения бизнес-моделей, процессов, приложений и инфраструктуры с ориентацией на гибкость.
Настоящий стандарт определяет базовую модель OSIMM. В базовой модели представлены структура OSIMM и процесс оценки. Базовая модель имеет расширяемую структуру, что позволяет клиентам и консалтинговым организациям добавлять дополнительные индикаторы завершенности. Благодаря расширению модели можно, например, сконцентрировать оценку завершенности на внедрении развивающихся отраслевых структур, новых методик или организационных требований. Авторы стандарта OSIMM уверены в том, что база данных расширений OSIMM будет развиваться, позволяя получать все больше знаний о процессе внедрения SOA.
Стандарт OSIMM можно использовать в целях проведения оценки текущего и необходимого уровней завершенности для предприятия или бизнес-подразделения в организации, а также составления плана действий по трансформации текущего уровня в необходимый. Например, организация может применять OSIMM к определенному набору приложений в своем портфеле. В этом случае принимают решение разделить большое количество приложений на несколько групп, исходя из их привязки к бизнес-функциям. Затем при помощи модели завершенности оценивают текущее состояние каждой группы. Исходя из ключевых проблем, бизнес-факторов и целей, устанавливают целевое состояние для каждого участка. Затем для каждой группы определяется свой шаг трансформации, необходимый для достижения целевого состояния группы.
3 Соответствие
В настоящем стандарте определены модель завершенности OSIMM SOA и соответствующий процесс оценки завершенности SOA, а также описаны характеристики архитектур, необходимые для достижения конкретного уровня завершенности SOA. Для того чтобы модели завершенности и их оценки соответствовали настоящей спецификации, в них должны, как минимум, использовать терминологию, матрицу, направления, уровни и атрибуты, описываемые в настоящем стандарте. Соответствие конкретным индикаторам модели завершенности не является обязательными. Пример процесса оценки, который соответствует настоящему стандарту, приведен в главе "Метод оценки OSIMM" (см. раздел 14), однако его соблюдение не является обязательным.
4 Термины и определения
В настоящем стандарте приведены определения терминов, которые имеют особое значение в стандарте OSIMM или могут быть неправильно интерпретированы. Таким образом, в целях настоящего стандарта применены следующие термины с соответствующими определениями:
4.1 внедрение (adoption): Детальные шаги, необходимые для осуществления трансформации. К этим шагам могут относить внедрение новых технологий, методик, процессов и техник интеграции, организация корпоративных инициатив, разработка ИТ-директив и технических стандартов, а также создание исполнительных советов, архитектурных комитетов и управления.
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. В любой из областей имеется один или несколько индикаторов завершенности на каждом уровне завершенности. Совокупность индикаторов определяет путь развития от менее зрелой SOA к более зрелой. Общий уровень завершенности направления определяется исходя из совокупности уровней по областям.
4.9 динамическая конфигурация (dynamic configuration): Способность системы обнаруживать новые сервисы исходя из сопоставления требуемой спецификации, а также конфигурировать себя для вызова этих новых сервисов без разработки нового программного кода.
4.10 структура (framework): Фундаментальная структура или набор структур, которые могут быть использованы для разработки самых разных архитектурных продуктов. Архитектурная структура должна включать в себя методы разработки информационной системы с точки зрения набора сервисов и демонстрации того, как сервисы сочетаются друг с другом. Кроме того, она должна включать в себя набор инструментов и определять общий словарь.
4.11 основная модель данных (master data model): Сервис виртуальной, интегрированной модели данных с основным представлением.
4.12 завершенность (maturity): Достижение в организации характеристик и поведения, которые обеспечивают более эффективное функционирование в соответствии с бизнес-ролями в результате трансформации и адаптации.
Например, в организации могут быть налажены процессы выявления новых сервисов, которые будут упрощать создание сервисов в будущем. Основные свойства характеристик и поведения, достигнутых в организации, определяют уровень завершенности интеграции сервисов, которые и описаны в модели OSIMM.
Концепции трансформации, внедрения и завершенности SOA являются взаимозависимыми: из состава трансформации можно выделить внедрения, в процессе которых создаются новые характеристики - признак завершенности.
4.13 индикатор завершенности, характеристика (maturity indicator, characteristic): Характеристика бизнеса или ИТ, которая может быть измерена и оценена с помощью ответов на определенные вопросы. Каждый индикатор завершенности связан с определенной областью (и, соответственно, с направлением) и уровнем завершенности; если индикатор оценивают как "истинный", это свидетельствует о том, что данная область относится к соответствующему уровню завершенности.
4.14 атрибут уровня завершенности (maturity level attribute): Наблюдаемые характеристики индикатора завершенности в пределах направления для каждого уровня завершенности.
4.15 модель завершенности (maturity model): Средство и шкала оценки текущего состояния завершенности.
Модель завершенности также предоставляет средства разработки плана трансформации для перехода от текущего состояния завершенности к целевому. Она позволяет количественно оценить относительный рост определенных важных аспектов внутри разных направлений в рамках границ организации, но не ограничивается ими.
4.16 должен (must): Определяет свойство или поведение, которое является обязательным для оценки. Для соответствия данной спецификации оценка должна включать это свойство или поведение.
4.17 модель завершенности интеграции сервисов консорциума Open Group; OSIMM (Open 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.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 представлены все направления и уровни завершенности.
Рисунок 1 - Матрица завершенности OSIMM
Столбцы в этой матрице соответствуют уровням завершенности, а строки - направлениям. Каждая ячейка в матрице определяет уровень завершенности для одного из направлений, представленных в столбцах. Общую завершенность SOA в организации оценивают путем определения уровня завершенности по каждому направлению.
Рассмотрим для примера ячейку "Информация/Разрозненный", уровень в которой определен как "Решение для работы с данными для конкретных приложений". Атрибуты завершенности сопоставлены с индикаторами завершенности модели OSIMM (см. 6.5). Если атрибуты завершенности показывают, что в конкретном приложении или системе на момент оценки присутствуют индикаторы уровня завершенности "Разрозненный", то считается, что направление "Информация" находится на уровне "Разрозненный" (уровень 1), поэтому для оцениваемого приложения или системы характерен уровень "Решение для работы сданными для конкретных приложений".
Подобным образом можно оценивать каждое направление, что в конечном итоге позволит определить уровень завершенности по всем направлениям или бизнес-представлениям. Кроме того, можно оценить общий уровень завершенности для всей организации на основе уровней завершенности для каждого направления.
6.2 Уровни завершенности
В основе модели OSIMM лежат семь уровней завершенности интеграции бизнес- и ИТ-сервисов в организации. Каждый из семи уровней отражает возможное абстрактное состояние организации с точки зрения завершенности интеграции ее сервисов (бизнес- и/или ИТ-сервисов) и решений SOA. Каждый последующий уровень завершенности надстраивается над предшествующими и содержит в себе весь набор атрибутов завершенности из них.
6.2.1 Уровень 1. Разрозненный (изолированные элементы)
Отдельные подразделения организации разрабатывают собственное программное обеспечение независимо друг от друга, без интеграции данных, процессов, стандартов и технологий. Это существенно ограничивает способность организации к реализации бизнес-процессов, которые требуют взаимодействия между подразделениями, и ИТ-системы не могут интегрироваться без значительных усилий персонала (например, без повторного ввода или повторной интерпретации данных).
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 Руководство и организация
Направление "Руководство и организация" определяет структуру и проектирование самой организации, и необходимые направления организационной эффективности в контексте SOA и управления SOA. Аспект "Организация" сфокусирован на организационной структуре, взаимоотношениях, ролях и разрешениях, которые необходимы для внедрения сервис-ориентированной стратегии, в которую включены типы и уровни квалификации, обучения и образования, доступные в организации. Аспект "Руководство" связан с формальными процессами менеджмента, направленными на то, чтобы ИТ-операции, возможности сервисов и решения SОА были постоянно согласованы с потребностями бизнеса. Руководство регулирует множество аспектов других направлений завершенности, в том числе способы структурирования менеджмента и распределения затрат.
6.3.3 Методы
Направление "Методы" определяет методы и процессы, которые организация применяет для своей ИТ- и бизнес-трансформации, а также завершенность организации с точки зрения жизненного цикла разработки ПО. К таким методам и процессам относят: менеджмент требований, методики оценки; менеджмент процессов; процессы обеспечения качества; методологии и методики проектирования, а также инструментальные средства при проектировании решений.
6.3.4 Приложения
Направление "Приложения" определяет стиль, структуру приложений, функциональную декомпозицию, готовность к повторному использованию, гибкость, надежность и расширяемость приложений, понимание и единообразное использование передовых практик и моделей, доступность корпоративных схем и объектных моделей, а также то, было ли для разных бизнес-подразделений создано несколько приложений, выполняющих одну и ту же базовую функцию.
6.3.5 Архитектура
Направление "Архитектура" определяет структуру архитектуры, куда входят топология, методики интеграции, корпоративные решения, стандарты и политики для архитектуры, уровень внедрения веб-сервисов, опыт в реализации SOA, критерии соответствия требованиям SOA, а также типовые производимые артефакты.
6.3.6 Информация
Направление "Информация" определяет то, как структурирована информация, как она смоделирована, метод доступа к корпоративным данным, абстракцию доступа к данным с точки зрения функциональных аспектов, характеристики данных, возможности преобразования данных, определения сервисов и процессов, обработку идентификаторов, учетные данные для использования в системе безопасности, управление знаниями, информационную модель и менеджмент контента.
6.3.7 Инфраструктура и менеджмент
Направление "Инфраструктура и менеджмент" определяет возможности инфраструктуры в организации, менеджмент сервисов, ИТ-операции, ИТ-менеджмент и ИТ-администрирование, то, как выполнены SLA и осуществлен мониторинг, а также какие типы платформ интеграции были предоставлены.
6.4 Базовые уровни сервисов
Первые три уровня модели завершенности OSIMM - разрозненный, интегрированный и компонентный - называются базовыми уровнями сервисов. Достичь интеграции сервисов и ориентированности на сервисы гораздо проще, когда бизнес-функции и инфраструктурные функции разрабатывают в качестве выделенных из состава дискретных компонентов, не зависящих от места использования и слабо связаны с основной средой выполнения. Базовые уровни сервисов можно рассматривать как рекомендуемые предпосылки для сервисов, работающих в условиях унаследованной среды (или даже объединения существующих сервисов). Хотя сервисы можно предоставлять и в слабо структурированных средах, это тем не менее может поставить под угрозу успех решения SOA. Исключением могут быть приложения SOA, создаваемые с нуля. Для достижения ориентированности на сервисы в таком случае не нужны те же шаги, которые необходимы при повторном использовании устаревших бизнес-функций. Сервисы, разрабатываемые с использованием веб-сервисов и других технологий обеспечения работы сервисов, также должны соответствовать характеристикам завершенности, которые определены базовыми уровнями сервисов.
6.5 Вопросы для оценки и индикаторы завершенности по направлениям
Индикаторы завершенности оценивают по совокупности вопросов, которые позволяют получить сведения об имеющихся в организации сервисах, связанных с бизнесом и архитектурой, а также о практиках, связанных с SOA. В базовую модель OSIMM входит набор вопросов для оценки и индикаторы завершенности, которые можно использовать в готовом виде или расширить, для того чтобы определить завершенность интеграции сервисов в организации.
6.5.1 Вопросы для оценки завершенности сервисов
Вопросы для оценки используют сначала для исследования целевой организации и получения сведений об атрибутах завершенности сервисов, которые затем определят конкретные уровни завершенности сервисов. Вопросы для оценки группируют по направлениям завершенности. Используя эти вопросы, организатор внедрения OSIMM опрашивает заинтересованных лиц со стороны ИТ и бизнеса, ответственных за определение и развертывание сервисов. Например, для того чтобы собрать достаточное количество информации и сопоставить индикаторы завершенности с атрибутами завершенности, можно опросить следующие группы на предприятии:
- отдел ИТ-операций;
- группа разработки и развертывания сервисов;
- персонал бизнес-подразделений, поддерживающий работу сервиса или бизнес-сферы;
- корпоративный архитектор;
- организация СIO.
6.5.2 Соответствие вопросов оценки индикаторам завершенности
Вопросы для оценки коррелируют с атрибутами завершенности для каждого индикатора завершенности по направлениям. Это помогает организатору оценки определить, какие вопросы оценки предназначены для сбора той информации, которая может быть использована для определения корреляции между конкретными атрибутами завершенности и определенным индикатором завершенности, чтобы тем самым определить уровень завершенности сервиса. На рисунке 2 показано, что вопросы 2 и 3 позволяют сделать вывод об атрибутах завершенности, которые указывают на то, что направление "Бизнес" находится на уровне 1 "Разрозненный" (бизнес-процессы не имеют формального определения и документации).
Рисунок 2 - Соответствие вопросов оценки для уровня завершенности 1 направления "Бизнес"
6.6 Расширение базовой модели OSIMM
Стандартный набор вопросов для оценки и индикаторы завершенности определены в 6.3, 6.3.1 (см. 6) в качестве базовой модели OSIMM. Базовая модель OSIMM может быть расширена путем добавления дополнительных индикаторов завершенности, вопросов для оценки и соответствующих атрибутов для того, чтобы включить в нее индикаторы завершенности, характерные для отрасли или предприятия. Отраслевые расширения могут быть стандартизированы, чтобы обеспечить единую базу для измерения завершенности интеграции сервисов с точки зрения внедрения сервисных структур для конкретной отрасли (в частности, структуры для отраслей розничной торговли и финансовых услуг).
Значимость индикатора завершенности дает возможность установить вес для индикатора завершенности в рамках одного направления. К примеру, это может потребоваться, если в базовую модель добавлены организационные или отраслевые индикаторы завершенности. Кроме того, организатор внедрения OSIMM перед началом оценки может скорректировать значимости для согласования с ожиданиями и бизнес-требованиями к целевой организации.
Значимости индикаторов завершенности в базовой модели OSIMM следуют с шагом 10 баллов соответственно возрастанию уровня завершенности. Максимальное значение оценки завершенности не может превышать значимости. Для получения единой оценки все значимости суммируются. Дополнительным индикаторам завершенности могут назначаться значимости исходя из того, какую часть они составят от возможной общей оценки завершенности для направления. Оценивание и значимости определяются организатором оценки и согласуются с целевой организацией. Значимость уровня завершенности в базовой модели OSIMM основана на шкале с шагом 10 баллов. Общий количественный показатель оценки завершенности может быть установлен путем сложения значимостей, полученных в ходе оценки. Например, если общий количественный показатель равен 210, это будет означать, что в ходе оценки уровень завершенности SOA соответствует уровню "Компонентный". Тем не менее необходимо понимать, что организации следует сосредоточиться на оценке завершенности SOA по каждому направлению и на той коммерческой выгоде, которую можно получить, увеличив уровень завершенности SOA по определенному направлению. Количественные показатели по областям и отдельные количественные показатели можно сравнивать с целевыми количественными показателями завершенности для организации, что позволит показать текущий прогресс на пути к достижению целей в области завершенности. Однако показатели завершенности не предназначены для сравнения разных организаций, поскольку каждая организация уникальна.
7 Направление "Бизнес": базовая модель
В этом разделе определена базовая модель для направления "Бизнес". В базовой модели содержится набор универсальных индикаторов и атрибутов завершенности, по которым уровень завершенности SOA в организации можно оценивать относительно матрицы завершенности OSIMM. Для расширения базовой модели OSIMM поставщики и пользователи могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты.
Перечисленные далее вопросы для оценки помогут получить сведения о том, каким образом в организации формально определены и документированы ее бизнес-факторы и бизнес-процессы, которые могут находиться в диапазоне от "изолированных, связанных с бизнес-подразделениями" до "предоставляющих бизнес-возможности посредством сервисов, в которых учитывается контекст".
Рисунок 3 - Направление "Бизнес" в модели OSIMM
7.1 Направление "Бизнес": базовая модель. Индикатор завершенности
Базовая модель OSIMM предоставляет один из нескольких возможных индикаторов завершенности для каждого направления. Организации, поставщики и консультанты могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты для выработки дополнительных рекомендаций, необходимых для повышения уровня завершенности SOA в организации.
Базовая спецификация модели OSIMM направления "Бизнес" определяет следующий индикатор завершенности:
- оценку завершенности SOA по направлению "Бизнес" в OSIMM проводится путем выявления наличия формального определения и документации по бизнес-факторам и бизнес-процессам в организации.
7.2 Направление "Бизнес": вопросы для оценки
Следующие далее вопросы для оценки помогут получить сведения о том, как в организации создаются формальные определения и документация по бизнес-факторам и бизнес-процессам. Обработав ответы на следующие вопросы, эксперт по оценке может поставить в соответствие индикатору завершенности соответствующие атрибуты завершенности, тем самым определив уровень завершенности по направлению "Бизнес":
1 какие основные бизнес-факторы в этом направлении представлены?
2 какая концепция бизнеса и бизнес-цели и каким образом они связаны с текущими задачами ИТ?
3 определена ли официально, документирована ли и управляется ли текущая архитектура бизнес-процессов?
4 является ли архитектура бизнес-процессов полной и актуальной?
5 как в менеджменте бизнес-процессов (ВРМ) измеряют показатели окупаемости инвестиций?
6 насколько гибкими являются текущие бизнес-процессы?
7 какие текущие методы финансирования использованы?
8 какая текущая стоимостная модель использована?
9 кто является владельцем портфеля процессов, приложений и сервисов?
10 имеется ли стоимостная модель для начисления потребителям платы за использование сервиса?
11 каким образом определена совокупная стоимость владения (включая программное и аппаратное обеспечение, а также будущее обслуживание) на данный момент?
12 какой уровень партнерства налажен между заинтересованными лицами в бизнесе и заинтересованными лицами в ИТ?
13 каким образом в настоящее время измеряют уровни бизнес-сервисов?
14 какие текущие практики использованы по преобразованию SLА для бизнеса в SLA для ИТ?
15 имеется ли формальная корпоративная архитектура?
16 применено формальное управление корпоративной архитектурой?
17 имеется несколько бизнес-подразделений и есть у них потребность в собственных бизнес-процессах?
18 имеют ли бизнес-подразделения общую информационную модель? Применяется ли совместное использование или репликация данных?
19 работают ли бизнес-подразделения с одними и теми же клиентами, поставщиками и партнерами?
7.3 Направление "Бизнес": соответствие индикаторов завершенности атрибутам завершенности
Далее приведен базовый набор индикаторов завершенности по направлению "Бизнес" в модели OSIMM. Каждый индикатор завершенности связан с набором атрибутов завершенности. Атрибуты завершенности - это выявленные характеристики индикатора завершенности для каждого уровня завершенности. Вопросы оценки необходимы для проведения опроса по направлению "Бизнес" в организации. Полученные ответы на вопросы для оценки направления "Бизнес" используют для определения уровня завершенности посредством оценивания результата и выбора тех атрибутов завершенности, которые наилучшим образом соответствуют полученным результатам. Показатели значимостей уровня завершенности применяют для определения средних количественных показателей завершенности по нескольким индикаторам завершенности. Модель может быть расширена путем добавления дополнительных индикаторов завершенности и присвоения значимостям индикаторов уровня завершенности значений, определенных проводящей оценку организацией для индикаторов завершенности.
Таблица 1 - Индикаторы завершенности по направлению "бизнес"
|
Уровень завершенности |
Индикатор завершенности |
Атрибуты завершенности |
Значимость завершенности |
Соответствие вопросов оценки |
|
Разрозненный (уровень 1) Изолированные бизнес-подразделения, линейное управление |
Формальное определение и документация бизнес-факторов и бизнес-процессов организации |
Низкий уровень или отсутствуют Корпоративная архитектура не является элементом корпоративной или ИТ-стратегии Бизнес-процессы не имеют формального определения и документации Ограничиваются требуемым поведением определенных приложений; специфические для ИТ |
10 |
2, 15 3 1, 9, 17, 18 |
|
Интегрированный (уровень 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 1, 2, 3, 8, 9, 10, 11, 17, 18, 19 |
|
Композитные сервисы (уровень 5) Процессы предоставляются и используются посредством композитных бизнес-сервисов |
Формальное определение и документация бизнес-факторов и бизнес-процессов организации |
Интегрированы в масштабах всего предприятия Официальное применение корпоративной архитектуры и менеджмента бизнес-процессов (ВРМ) Бизнес-факторы организации документированы как элементы стратегии предприятия и бизнес-архитектуры |
50 |
3, 4, 5, 6, 10, 11, 15, 16 1, 2, 3, 8, 9, 10, 11, 17, 18, 19 |
|
Виртуальные сервисы (уровень 6) Аутсорсинг сервисов, ВРМ и ВАМ |
Формальное определение и документация бизнес-факторов и бизнес-процессов организации |
Интеграция по всему предприятию, а также с внешними бизнес-партнерами Четко определенная корпоративная архитектура, где подробно прописаны как последовательности внутренних процессов, так и аутсорсинговые процессы со службами бизнес-партнеров и между ними. Активное использование мониторинга бизнес-операций (ВАМ) |
60 |
4, 5, 6, 7, 9, 11, 12, 13, 14, 15, 19 |
|
Динамически реконфигурируемые сервисы (уровень 7) Сочетание и комбинирование бизнес-возможностей через сервисы с учетом контекста |
Формальное определение и документация бизнес-факторов и бизнес-процессов организации |
Корпоративные сервисы по запросу Четко определенная корпоративная архитектура, в которую входит комплексное определение последовательности бизнес-процессов Менеджмент бизнес-процессов (ВРМ) использован для определения и тестирования последовательностей процессов, необходимых для соблюдения четко определенных SLA |
70 |
5, 6, 13, 15, 16 6, 13, 14 |
8 Направление "Руководство и организация": базовая модель
Этот раздел определяет базовую модель OSIMM для направления "Руководство и организация". В базовой модели определен набор универсальных индикаторов и атрибутов, по которым уровень завершенности SOA в организации можно оценить относительно матрицы завершенности OSIMM. Для расширения базовой модели OSIMM поставщики и пользователи могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты.
Перечисленные далее вопросы для оценки помогут получить сведения о том, каким образом в компании формально определены и документированы процессы руководства и организации, начиная с "ситуационной ИТ-стратегии и управления по подразделениям" и заканчивая "управлением на основе политик".
Рисунок 4 - Направление "Руководство и организация" в модели OSIMM
8.1 Направление "Руководство и организация": базовая модель. Индикатор завершенности
Базовая модель OSIMM предоставляет один из нескольких возможных индикаторов завершенности для каждого направления. Организации, поставщики и консультанты могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты для выработки дополнительных рекомендаций, необходимых для повышения уровня завершенности SOA в организации.
Базовая спецификация модели OSIMM направления "Руководство и организация" определяет следующий индикатор завершенности:
- оценку завершенности интеграции сервисов по направлению "Руководство и организация" в модели 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 |
|
Интегрированный (уровень 2) ИТ-трансформация |
Официальное применение управления сервисами и 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 |
|
Виртуальные сервисы (уровень 6) Согласованное управление инфраструктурой SOA и ИТ |
Официальное применение управления сервисами и SOA в масштабах всей организации для разработки, развертывания и менеджмента бизнес-и ИТ-сервисов (решений SOA) |
Интеграция по всему предприятию, а также с внешними бизнес-партнерами. Управление SOA является частью организационной культуры Организация рассматривает сервисы SОА как корпоративные ресурсы В организации имеются четко определенные показатели и индикаторы эффективности SOA |
60 |
3, 10 2 4 |
|
Динамически реконфигурируемые сервисы (уровень 7) Управление реализовано с использованием автоматизированных политик |
Официальное применение управления сервисами и SOA в масштабах всей организации для разработки, развертывания и менеджмента бизнес- и ИТ-сервисов (решений SOA) |
Адаптивное предприятие Моделирование и менеджмент сервисов являются элементами совершенствующейся бизнес-стратегии Метрики сервисов собираются автоматически и используются в качестве входных данных при принятии важнейших бизнес-решений |
70 |
2, 3, 4, 5, 6 4, 11 |
9 Направление "Методы": базовая модель
В этом разделе определено направление "Методы" в базовой модели OSIMM. В базовой модели приведен набор универсальных индикаторов и атрибутов, по которым уровень завершенности SOA в организации можно оценивать относительно матрицы завершенности OSIMM. Для расширения базовой модели OSIMM поставщики и пользователи могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты.
Приведенные далее вопросы оценки помогут определить уровень формализации внедрения в организации официальных методологий разработки и развертывания SOA - начиная со "структурного проектирования и анализа" и заканчивая "моделированием бизнеса, ориентированным на грамматику".
9.1 Направление "Методы": базовая модель. Индикатор завершенности
Базовая модель OSIMM предоставляет один из нескольких возможных индикаторов завершенности для каждого направления. Организации, поставщики и консультанты могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты для выработки дополнительных рекомендаций, необходимых для повышения уровня завершенности SOA организации.
Базовая спецификация модели OSIMM направления "Методы" определяет следующий индикатор завершенности:
- оценку завершенности SOA по направлению "Методы" в OSIMM можно проводить путем выявления формального использования методологии архитектурного проектирования, построения и развертывания SОА для реализации сервисов SOA.
Рисунок 5 - Направление "Методы" в модели OSIMM
9.2 Направление "Методы": вопросы для оценки
Обработав ответы на следующие вопросы, эксперт по оценке может поставить в соответствие индикатору завершенности соответствующие атрибуты завершенности, тем самым определив уровень завершенности по направлению "Методы":
1 какие в настоящее время применены практики сбора информации о требованиях к приложениям и системам и практики менеджмента требований?
2 какие методологии и передовые практики проектирования внедрены в настоящее время?
3 какие методики проектирования SOA использованы?
4 какие инструментальные средства проектирования использованы в настоящее время?
5 какие практики разработки и менеджмента сервисов применены в настоящее время?
6 какова структура менеджмента проектов использована в настоящее время?
7 как организован менеджмент ИТ-проектов?
8 какие процессы обеспечения качества в настоящее время использованы в организации?
9 имеется ли активное сообщество, которое работает над совершенствованием методов и практик SOA?
10 разработан ли в организации репозиторий для повторного использования передовых практик и ресурсов?
9.3 Направление "Методы": соответствие индикаторов завершенности атрибутам завершенности
Далее приведен базовый набор индикаторов завершенности по направлению "Методы" в модели OSIMM. Каждый индикатор завершенности связан с набором атрибутов завершенности. Атрибуты завершенности - это выявленные характеристики индикатора завершенности для каждого уровня завершенности. Вопросы оценки необходимы для проведения опроса по направлению "Методы" в организации. Полученные ответы на вопросы для оценки направления "Методы" используют для определения уровня завершенности посредством оценивания результата и выбора тех атрибутов завершенности, которые наилучшим образом соответствуют полученным результатам. Показатели значимостей уровня завершенности используют для определения средних количественных показателей завершенности по нескольким индикаторам завершенности. Модель может быть расширена путем добавления дополнительных индикаторов завершенности и присвоения значимостям индикаторов уровня завершенности значений, определенных проводящей оценку организацией для индикаторов завершенности.
Таблица 3 - Индикаторы завершенности по направлению "Методы"
|
Уровень завершенности |
Индикатор завершенности |
Атрибуты завершенности |
Значимость завершенности |
Соответствие вопросов оценки |
|
Разрозненный (уровень 1) Структурный анализ и проектирование |
Официальное применение методологии архитектурного проектирования, построения и развертывания SOA для реализации сервисов |
Низкий уровень или отсутствует. Отсутствует официальное применение методологии проектирования и реализации SOA. ИТ- и бизнес-сотрудники слабо понимают или не ценят реализацию бизнес-процессов как услуги |
10 |
2, 3 5, 6 |
|
Интегрированный (уровень 2) Объектно-ориентированное моделирование |
Официальное применение методологии архитектурного проектирования, построения и развертывания в SОА для реализации сервисов |
Ограниченный. Методы и практики SOA используют только в командах ИТ-разработки и не были формализованы для использования другими группами |
20 |
1, 2, 3 |
|
Компонентный (уровень 3) Компонентно-ориентированная разработка |
Официальное применение методологии архитектурного проектирования, построения и развертывания SOA для реализации сервисов |
Между организациями Методы и практики SOA были усовершенствованы для решения вопросов создания и развертывания сервисов. Методология по большей части сфокусирована на реализации ИТ-инфраструктуры и интеграции сервисов |
30 |
1, 2, 3, 4, 5, 6, 7 |
|
Сервисы (уровень 4) Сервис-ориентированное моделирование |
Официальное применение методологии архитектурного проектирования, построения и развертывания БОА для реализации сервисов |
В масштабах всего предприятия. Методы и практики SOA были реализованы по всему предприятию. Не все организации соблюдают унифицированный подход |
40 |
1, 2, 3, 4, 5, 6, 7 |
|
Композитные сервисы (уровень 5) Сервис-ориентированное моделирование |
Официальное применение методологии архитектурного проектирования, построения и развертывания SOA для реализации сервисов |
Интегрированные в масштабах предприятия. Используется формальная, признанная методология создания, разработки, развертывания и менеджмента. Признанное сообщество наделено полномочиями по менеджменту, обучению и обновлению корпоративных методов и практик SOA |
50 |
1, 2, 3, 5, 7, 9 |
|
Виртуальные сервисы (уровень 6) Сервис-ориентированное моделирование для инфраструктуры |
Официальное применение методологии архитектурного проектирования, построения и развертывания SOA для реализации сервисов |
Интеграция по всему предприятию, а также с внешними бизнес-партнерами. Используются формальные методы создания и управления как внутренними, так и внешними (партнерскими) сервисами. Разработано руководство по передовым практикам для упрощения согласованного внедрения методик SOA и виртуализации, например корпоративной сервисной шины (ESB) и реестра сервисов. Виртуализация является ключевым элементом методов эксплуатации ИТ-сервисов и используется для повышения их эффективности |
60 |
1, 2, 3 4, 9, 10 2, 8 |
|
Динамически реконфигурируемые сервисы (уровень 7) Моделирование бизнес-процессов |
Официальное применение методологии архитектурного проектирования, построения и развертывания SOA для реализации сервисов |
Адаптивное предприятие. В формальных методах используются архитектурные компоненты и ресурсы для поддержки виртуализации и динамических сервисов, а также моделирования бизнес-процессов |
70 |
1, 2, 3, 4, 5, 9, 10 |
10 Направление "Приложения": базовая модель
В этом разделе определено направление "Приложения" в базовой модели OSIMM. В базовой модели приведен набор универсальных индикаторов и атрибутов, по которым уровень завершенности SOA в организации можно оценивать относительно матрицы завершенности OSIMM. Для расширения базовой модели OSIMM поставщики и пользователи могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты.
Приведенные далее вопросы оценки помогут определить уровень формализации успешного применения в организации принципов проектирования, разработки и развертывания приложений и систем SOA, внедрения технологий обеспечения работы SOA, таких как корпоративная сервисная шина (ESB) и реестр сервисов. Уровень завершенности может быть от "модульных приложений" до "динамической сборки приложений".
Рисунок 6 - Направление "Приложения" в модели OSIMM
10.1 Направление "Приложения": базовая модель. Индикатор завершенности
Базовая модель OSIMM предоставляет один из нескольких возможных индикаторов завершенности для каждого направления. Организации, поставщики и консультанты могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты для выработки дополнительных рекомендаций, необходимых для повышения уровня завершенности SOA организации.
Базовая спецификация модели OSIMM направления "Приложения" определяет следующий индикатор завершенности:
- оценку завершенности SOA по направлению "Приложения" в OSIMM можно проводить путем выявления архитектуры приложений, которые были спроектированы и реализованы с использованием принципов и практик разработки SOA и в которых применены такие концепции, как слабая связанность и разделение функций, а также технологии на базе таких сервисов, как XML, веб-сервисы, сервисная шина, реестры служб и виртуализация.
10.2 Направление "Приложения": вопросы для оценки
Обработав ответы на следующие вопросы, эксперт по оценке может поставить в соответствие индикатору завершенности определенные атрибуты завершенности, тем самым определив уровень завершенности по направлению "Приложения":
1 какой стиль разработки приложений используют в настоящее время?
2 насколько широко в организации распространено повторное использование?
3 какие типы повторного использования использованы и как измеряют удобство повторного использования?
4 каким образом интегрированы приложения/системы в организации?
5 какие типы языков использованы в организации?
6 какие типы технологий интеграции применяют в организации?
7 каким образом в приложениях организации представлена бизнес-логика?
8 насколько надежны критически важные приложения организации?
9 насколько широко в организации используют XML? Насколько сложно его использование?
10 какие частота изменений и требуемое время вывода на рынок текущих приложений зафиксированы?
11 используют ли технологии обеспечения работы SOA, например ESB, совместное использование среды обработки данных или реестр служб?
10.3 Направление "Приложения": соответствие индикаторов завершенности атрибутам завершенности
Далее приведен базовый набор индикаторов завершенности по направлению "Приложения" в модели OSIMM. Каждый индикатор завершенности связан с набором атрибутов завершенности. Атрибуты завершенности - это выявленные характеристики индикатора завершенности для каждого уровня завершенности. Вопросы оценки необходимы для проведения опроса по направлению "Приложения" в организации. Полученные ответы на вопросы для оценки направления "Приложения" используют для определения уровня завершенности посредством оценивания результата и выбора тех атрибутов завершенности, которые наилучшим образом соответствуют полученным результатам. Показатели значимостей уровня завершенности используют для определения средних количественных показателей завершенности по нескольким индикаторам завершенности. Модель может быть расширена путем добавления дополнительных индикаторов завершенности и присвоения значимостям индикаторов уровня завершенности значений, определенных проводящей оценку организацией для индикаторов завершенности.
Таблица 4 - Индикаторы завершенности по направлению "Приложения"
|
Уровень завершенности |
Индикатор завершенности |
Атрибуты завершенности |
Значимость завершенности |
Соответствие вопросов оценки |
|
Разрозненный (уровень 1) Модули |
Архитектура приложений разработана и реализована с использованием принципов и практик разработки SOA с применением таких концепций, как слабая связанность и разделение функций, а также использования эффективных сервис-технологий, таких как XML, веб-сервисы, сервисная шина, реестры служб и виртуализация |
Низкий уровень или отсутствует Архитектура и топология приложений являются монолитными с недостаточной интеграцией систем по всему предприятию Веб-сервисы и другие концепции SOA не используются |
10 |
1, 4, 7, 10 6, 9 |
|
Интегрированный (уровень 2) Объекты |
Архитектура приложений разработана и реализована с использованием принципов и практик разработки SOA с применением таких концепций, как слабая связанность и разделение функций, а также использования эффективных сервис-технологий, таких как XML, веб-сервисы, сервисная шина, реестры служб и виртуализация |
Ограниченный Архитектура и топология приложений являются монолитными; имеется минимальное разделение функций между архитектурными слоями или уровнями приложений Минимальная интеграция приложений с другими системами. Интеграция обычно реализована по принципу "точка-точка" |
20 |
1, 2, 3, 7 4, 6 |
|
Компонентный (уровень 3) Компоненты |
Архитектура приложений разработана и реализована с использованием принципов и практик разработки SOA с применением таких концепций, как слабая связанность и разделение функций, а также использования эффективных сервис-технологий, таких как XML, веб-сервисы, сервисная шина, реестры служб и виртуализация |
Между организациями Практики разработки SOA в масштабах всей организации применяются несогласованно В большинстве архитектур и топологий приложений используется как физическое, так и логическое разделение функций представлений, бизнес-логики и уровней данных. Технологии обеспечения работы SOA, такие как ESB, по всему предприятию применяются несогласованно |
30 |
1, 2, 3, 4 5, 7, 10 6, 9, 11 |
|
Сервисы (уровень 4) Сервисы |
Архитектура приложений разработана и реализована с использованием принципов и практик разработки SOA с применением таких концепций, как слабая связанность и разделение функций, а также использования эффективных сервис-технологий, таких как XML, веб-сервисы, сервисная шина, реестры служб и виртуализация |
В масштабах всего предприятия В архитектуре сервисных компонентов приложений используются концепции SOA, такие, как разделение функций между логическим и физическим уровнями представлений и бизнес-логики В некоторых, но не во всех подразделениях интеграция сервисов обеспечивается с использованием ESB |
40 |
1, 2, 3, 4 5, 6 |
|
Композитные сервисы (уровень 5) Приложения, состоящие из композитных сервисов |
Архитектура приложений разработана и реализована с использованием принципов и практик разработки SOA с применением таких концепций, как слабая связанность и разделение функций, а также использования эффективных сервис-технологий, таких как XML, веб-сервисы, сервисная шина, реестры служб и виртуализация |
Интегрированные в масштабах предприятия Архитектура приложений обеспечивает разделение функций на логическом и физическом уровнях Модели интеграции ESB используются для обеспечения интеграции приложений и процессов для поддержки совместного использования сервисов |
50 |
1, 2, 3, 7 4, 6, 11 |
|
Виртуальные сервисы (уровень 6) Виртуальные сервисы |
Архитектура приложений разработана и реализована с использованием принципов и практик разработки SOA с применением таких концепций, как слабая связанность и разделение функций, а также использования эффективных сервис-технологий, таких как XML, веб-сервисы, сервисная шина, реестры служб и виртуализация |
Интеграция по всему предприятию, а также с внешними бизнес-партнерами Архитектура приложений отделена от инфраструктурных компонентов Активное использование архитектурных моделей ESB для поддержки менеджмента бизнес-процессов (ВРМ) |
60 |
1, 2, 3, 10 6, 7, 8, 11 |
|
Динамически реконфигурируемые сервисы (уровень 7) Динамическая сборка приложений, вызов с учетом контекста |
Архитектура приложений разработана и реализована с использованием принципов и практик разработки SOA с применением таких концепций, как слабая связанность и разделение функций, а также использования эффективных сервис-технологий, таких как XML, веб-сервисы, сервисная шина, реестры служб и виртуализация |
Адаптивное предприятие Архитектура приложений поддерживает динамически реконфигурируемые бизнес- и инфраструктурные сервисы и решения SOA для использования внутренними или внешними партнерами |
70 |
Все |
11 Направление "Архитектура": базовая модель
В этом разделе определено направление "Архитектура" в базовой модели OSIMM. В базовой модели приведен набор универсальных индикаторов и атрибутов, по которым уровень завершенности SOA в организации можно оценивать относительно матрицы завершенности OSIMM. Для расширения базовой модели OSIMM поставщики и пользователи могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты.
Приведенные далее вопросы оценки помогут определить уровень формализации внедрения в организации формальных методов, принципов и структуры разработки SOA. Уровень завершенности принимает значения от монолитной до динамически реконфигурируемой архитектуры.
Рисунок 7 - Направление "Архитектура" в модели OSIMM
11.1 Направление "Архитектура": базовая модель. Индикатор завершенности
Базовая модель OSIMM предоставляет один из нескольких возможных индикаторов завершенности для каждого направления. Организации, поставщики и консультанты могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты для выработки дополнительных рекомендаций, необходимых для повышения уровня завершенности SOA в организации.
Базовая спецификация модели OSIMM направления "Архитектура" определяет следующий индикатор завершенности:
- оценку завершенности SOA по направлению "Архитектура" в OSIMM можно проводить путем выявления тех компонентов сервисов, которые были разработаны и развернуты с использованием формальных методов, принципов, моделей, структур или методик SOA.
11.2 Направление "Архитектура": вопросы для оценки
Обработав ответы на следующие вопросы, эксперт по оценке может поставить в соответствие индикатору завершенности соответствующие атрибуты завершенности, тем самым определив уровень завершенности по направлению "Архитектура":
1 как охарактеризовать архитектурные топологии в компании?
2 какие типы репозиториев данных используют в организации?
3 какой стандартный коммуникационный стиль в архитектуре использован?
4 каким образом в архитектуре обеспечена интеграция?
5 какие используют методы разработки архитектуры?
6 какой уровень завершенности внедрения сервисов применяют?
7 насколько широко используют SOA?
8 какими архитектурными принципами определен подход в организации?
9 насколько широко и продуманно в организации использованы архитектурные структуры?
10 как в организации принимают архитектурные решения?
11 используют ли в организации эталонные архитектуры?
11.3 Направление "Архитектура": соответствие индикаторов завершенности атрибутам завершенности
Далее приведен базовый набор индикаторов завершенности по направлению "Архитектура" в модели OSIMM. Каждый индикатор завершенности связан с набором атрибутов завершенности. Атрибуты завершенности - это выявленные характеристики индикатора завершенности для каждого уровня завершенности. Вопросы оценки необходимы для проведения опроса по направлению "Архитектура" в организации. Полученные ответы на вопросы для оценки направления "Архитектура" используют для определения уровня завершенности посредством оценивания результата и выбора тех атрибутов завершенности, которые наилучшим образом соответствуют полученным результатам. Показатели значимостей уровня завершенности применяют для определения средних количественных показателей завершенности по нескольким индикаторам завершенности. Модель может быть расширена путем добавления дополнительных индикаторов завершенности и присвоения значимостям индикаторов уровня завершенности значений, определенных проводящей оценку организацией для индикаторов завершенности.
Таблица 5 - Индикаторы завершенности по направлению "Архитектура"
|
Уровень завершенности |
Индикатор завершенности |
Атрибуты завершенности |
Значимость завершенности |
Соответствие вопросов оценки |
|
Разрозненный (уровень 1) Монолитная архитектура |
Сервисные компоненты разработаны с использованием формальных методов, принципов, шаблонов, структур или технологий SOA |
Низкий уровень или отсутствует Методы или практики SOA не присутствуют |
10 |
1, 7 |
|
Интегрированный (уровень 2) Многоуровневая архитектура |
Сервисные компоненты разработаны с использованием формальных методов, принципов, шаблонов, структур или технологий SOA |
Ограниченный Имеет место ограниченное использование формальных методов и практик SOA. Методы и практики ограничены использованием для интеграции приложений или систем |
20 |
1, 2, 5, 6, 7 4, 8, 9 |
|
Компонентный (уровень 3) Компонентная архитектура |
Сервисные компоненты разработаны с использованием формальных методов, принципов, шаблонов, структур или технологий SOA |
Между организациями Формальные методы и практики SOA использованы многими группами на предприятии В организации имеется не строго определенная корпоративная архитектура, поддерживаемая ограниченным набором инструментов и практик управления |
30 |
4, 5, 6, 7, 8 9, 10, 11 |
|
Сервисы (уровень 4) Включение SOA |
Сервисные компоненты разработаны с использованием формальных методов, принципов, шаблонов, структур или технологий SOA |
В масштабах всего предприятия Формальные методы и практики SOA используются по всему предприятию и поддерживаются формальным процессом управления Приложения и сервисы спроектированы с использованием формальных принципов и моделей SOA |
40 |
4, 5, 6 1, 7, 8, 11 |
|
Композитные сервисы (уровень 5) SOA |
Сервисные компоненты разработаны с использованием формальных методов, принципов, шаблонов, структур или технологий SOA |
Интегрированные в масштабах предприятия Корпоративные структуры и практики поддерживают посредством использования формального метода и эталонных архитектур SOA по всему предприятию Развивается формальная корпоративная бизнес-информационная модель |
50 |
7, 8, 9, 11 2, 10 |
|
Виртуальные сервисы (уровень 6) SOA на базе грид-системы |
Сервисные компоненты разработаны с использованием формальных методов, принципов, шаблонов, структур или технологий SOA |
Интеграция по всему предприятию, а также с внешними бизнес-партнерами Сервисные компоненты спроектированы с использованием формальных методов, практик и структур, которые обеспечивают повторное использование ресурсов Разработаны и развернуты формальные общекорпоративные бизнес-информационные сервисы |
60 |
1, 3, 4, 5, 6, 9 2, 8, 10, 11 |
|
Динамически реконфигурируемые сервисы (уровень 7) Динамически реконфигурируемая архитектура |
Сервисные компоненты разработаны с использованием формальных методов, принципов, шаблонов, структур или технологий SOA |
Адаптивное предприятие Сервисные компоненты разработаны с использованием формальных методов, принципов, шаблонов, структур или технологий SOA Разработаны и реализованы формальные корпоративные бизнес-информационные сервисы, в которые входят объекты как корпоративных, так и внешних взаимосвязей |
70 |
1, 3, 4, 5, 6, 9 2, 8, 10, 11 |
12 Направление "Информация": базовая модель
В этом разделе определено направление "Информация" в базовой модели OSIMM. В базовой модели приведен набор универсальных индикаторов и атрибутов, по которым уровень завершенности SOA в организации можно оценивать относительно матрицы завершенности OSIMM. Для расширения базовой модели OSIMM поставщики и пользователи могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты.
Приведенные далее вопросы оценки помогут определить уровень формализации внедрения успешного использования в организации принципов проектирования, разработки и развертывания приложений (или систем) SOA, внедрения технологий поддержки работы SOA, таких как корпоративная сервисная шина (ESB) и реестр сервисов. Уровень завершенности может варьироваться от "решений данных для конкретных приложений" до "семантических словарей данных".
Рисунок 8 - Направление "Информация" в модели OSIMM
12.1 Направление "Информация": базовая модель. Индикатор завершенности
Базовая модель OSIMM предоставляет один из нескольких возможных индикаторов завершенности для каждого направления. Организации, поставщики и консультанты могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты для выработки дополнительных рекомендаций, необходимых для повышения уровня завершенности SOA в организации.
Базовая спецификация модели OSIMM направления "Информация" определяет следующий индикатор завершенности:
- оценку завершенности SOA по направлению "Информация" в OSIMM можно проводить путем выявления архитектуры информации, которая поддерживает основную модель данных (сервис интегрированных данных) и реализует общий словарь бизнес-данных.
12.2 Направление "Информация": вопросы для оценки
Обработав ответы на следующие вопросы, эксперт по оценке может поставить в соответствие индикатору завершенности определенные атрибуты завершенности, тем самым определив уровень завершенности по направлению "Информация":
1 имеется ли для всех приложений общая модель данных?
2 имеются ли независимые модели данных для разных приложений?
3 используют ли правила отображения для преобразования из одной модели данных в другую?
4 возникают ли сложности при передаче данных из одного приложения в другое? Для всех приложений? Только для некоторых приложений?
5 имеется ли в организации общая модель данных (или отображения между несколькими моделями данных)? Каким образом она определена: посредством программных объектов в API; XSD-схем; письменных документов; других компьютерных средств моделирования; других некомпьютерных средств моделирования?
6 представлены ли модели данных в форме моделей бизнес-объектов (их могут понимать и их владельцами являются бизнес-пользователи) или в форме моделей ИТ-объектов (их могут понимать и их владельцами является только ИТ-персонал)?
7 имеются ли правила отображения между разными моделями, которые понятны бизнес- и ИТ-персоналу и которые сопровождает бизнес- и ИТ-персонал? Выполняется ли отображение по этим правилам инфраструктурой?
8 определены ли модели данных на языке, который обеспечивает таксономии, онтологии и другие высокоуровневые логические представления?
9 осуществляют ли ведение глобального каталога или базу данных объектов с глобальными идентификаторами? Имеют ли механизмы отображения этих объектов между разными БД или каталогами? Каким образом реализованы эти механизмы - автоматически или вручную? Возможно отображение всех объектов или это реализовано только для определенных приложений и наборов объектов? Выполняются ли такие отображения инфраструктурой автоматически?
10 имеются ли механизмы поиска глобальных объектов по их характеристикам?
11 как обеспечивается передача данных между приложениями? Используется ли для передачи данных корпоративная сервисная шина (ESB), или это обеспечивается в соответствии с требованиями посредством специализированных интерфейсов; или с помощью универсального набора API, или путем вызова сервиса?
12 имеются ли средства выполнения сложного логического анализа для отображения данных из одной формы, определенной в онтологии, в другую? Существует ли сервис для основных данных?
13 имеется или разрабатывается в организации бизнес-информационная модель для стандартизации форматов и концепций данных и сообщений по всему предприятию?
12.3 Направление "Информация": соответствие индикаторов завершенности атрибутам завершенности
Далее приведен базовый набор индикаторов завершенности по направлению "Информация" в модели OSIMM. Каждый индикатор завершенности связан с набором атрибутов завершенности. Атрибуты завершенности - это выявленные характеристики индикатора завершенности для каждого уровня завершенности. Вопросы оценки необходимы для проведения опроса по направлению "Информация" в организации. Полученные ответы на вопросы для оценки направления "Информация" используют для определения уровня завершенности посредством оценивания результата и выбора тех атрибутов завершенности, которые наилучшим образом соответствуют полученным результатам. Показатели значимостей уровня завершенности применяют для определения средних количественных показателей завершенности по нескольким индикаторам завершенности. Модель может быть расширена путем добавления дополнительных индикаторов завершенности и присвоения значимостям индикаторов уровня завершенности значений, определенных проводящей оценку организацией для индикаторов завершенности.
Таблица 6 - Индикаторы завершенности по направлению "Информация"
|
Уровень завершенности |
Индикатор завершенности |
Атрибуты завершенности |
Значимость завершенности |
Соответствие вопросов оценки |
|
Разрозненный (уровень 1) Решение данных для конкретных приложений |
Информационная архитектура поддерживает основную модель данных, в которой реализован общий словарь бизнес-данных |
Низкий уровень или отсутствует Информация реплицируется и обладает избыточностью. Отсутствует концептуальная корпоративная информационная модель |
10 |
1, 2, 3, 4, 5 |
|
Интегрированный (уровень 2) Для бизнес-подразделений или для предприятия |
Информационная архитектура поддерживает основную модель данных, в которой реализован общий словарь бизнес-данных |
Ограниченный Некоторые приложения совместно используют информацию путем извлечения, преобразования, загрузки и манипуляции (ETLM) или с помощью технологий, ориентированных на сообщения. Начинают появляться первые словари данных |
20 |
1, 2, 3, 4, 5, 11 |
|
Компонентный (уровень 3) Канонические модели |
Информационная архитектура поддерживает основную модель данных, в которой реализован общий словарь бизнес-данных |
Между организациями Словари бизнес-данных появились, однако остаются специфическими для приложений или систем Появились формальные бизнес-информационные модели, зачастую доступные через интерфейсы в стиле XML-схем |
30 |
1, 2, 3, 4, 5, 6 8, 13 |
|
Сервисы (уровень 4) Информация как услуга |
Информационная архитектура поддерживает основную модель данных, в которой реализован общий словарь бизнес-данных |
В масштабах всего предприятия. Во многих подразделениях используются взаимосвязи метаданных. Словари бизнес-данных стандартизированы в пределах подразделения или области процесса. Возможно последовательное совместное использование бизнес-данных в пределах подразделения и с бизнес-партнерами. Интерфейсы определены с использованием общих словарей данных сообщений |
40 |
5, 7 6 8, 13 |
|
Композитные сервисы (уровень 5) Словарь и репозиторий бизнес-данных |
Информационная архитектура поддерживает основную модель данных, в которой реализован общий словарь бизнес-данных |
Интегрированные в масштабах предприятия Имеются информационные сервисы, такие как проверка данных, очистка данных, преобразование данных, интеграция данных партнеров или др. Имеются и применяются по всему предприятию сервисы основных данных Словари бизнес-данных стандартизированы для использования по всему предприятию |
50 |
7, 8, 9, 10 11, 12 13 |
|
Виртуальные сервисы (уровень 6) Виртуальные информационные сервисы |
Информационная архитектура поддерживает основную модель данных, в которой реализован общий словарь бизнес-данных |
Интеграция по всему предприятию, а также с внешними бизнес-партнерами При необходимости словари бизнес-данных могут быть расширены и усовершенствованы для поддержки новых сервисов и внешних партнеров, а также для реконфигурации бизнес-процессов Реестр с метаданными использован для управления ресурсами корпоративных сервисов Разработана и развернута формальная общекорпоративная бизнес-информационная модель |
60 |
7, 8, 9 10, 11, 12 13 |
|
Динамически реконфигурируемые сервисы (уровень 7) Семантические словари данных |
Информационная архитектура поддерживает основную модель данных, в которой реализован общий словарь бизнес-данных |
Адаптивное предприятие. При необходимости словари бизнес-данных могут быть легко расширены и усовершенствованы для поддержки новых сервисов и внешних партнеров, а также для реконфигурации бизнес-процессов. Бизнес-данные определены при помощи семантических веб-компонентов или онтологии (пример - базовые компоненты UN/CEFACT, ISO 11179). Спроектирована и реализована формальная корпоративная бизнес-информационная модель, в которую входят как корпоративные, так и внешние объекты взаимодействия |
70 |
1, 2, 3, 4, 5, 6, 7, 8, 9 8, 9, 10, 11, 12 13 |
13 Направление "Инфраструктура и менеджмент": базовая модель
В этом разделе определено направление "Инфраструктура и менеджмент" в базовой модели OSIMM. В базовой модели приведен набор универсальных индикаторов и атрибутов, по которым уровень завершенности SOA в организации можно оценивать относительно матрицы завершенности OSIMM. Для расширения базовой модели OSIMM поставщики и пользователи могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты.
Приведенные далее вопросы оценки помогут определить уровень формализации успешного применения в организации принципов проектирования, разработки и развертывания приложений и систем SOA и внедрения технологий обеспечения работы SOA, таких как корпоративная сервисная шина (ESB) и реестр сервисов. Уровень завершенности может иметь значение от "платформ по бизнес-подразделениям" до "обнаружения и реакции с учетом контекста и на основе событий".
Рисунок 9 - Направление "Инфраструктура и менеджмент" в модели OSIMM
13.1 Направление "Инфраструктура и менеджмент": базовая модель. Индикатор завершенности
Базовая модель OSIMM предоставляет один из нескольких возможных индикаторов завершенности для каждого направления. Организации, поставщики и консультанты могут добавлять дополнительные индикаторы завершенности, вопросы для оценки и атрибуты для выработки дополнительных рекомендаций, необходимых для повышения уровня завершенности SOA в организации.
Базовая спецификация модели OSIMM направления "Инфраструктура и менеджмент" определяет следующий индикатор завершенности:
- оценку завершенности SOA по направлению "Инфраструктура и менеджмент" в OSIMM проводят путем выявления ИТ-инфраструктуры, которая поддерживает нефункциональные и операционные требования и SLA, необходимые для работы среды SOA.
13.2 Направление "Инфраструктура и менеджмент": вопросы для оценки
Обработав ответы на следующие вопросы, эксперт по оценке может поставить в соответствие индикатору завершенности определенные атрибуты завершенности, тем самым определив уровень завершенности по направлению "Инфраструктура и менеджмент":
1 какие методические материалы по использованию инфраструктуры применяют в организации в настоящий момент?
2 каким образом SLA для ИТ получают из SLA для бизнеса?
3 были ли определены SLA относительно качества обслуживания? Каким образом осуществляют этот мониторинг и измерение?
4 были ли определены SLA относительно обеспечения безопасности и конфиденциальности? Каким образом осуществляют мониторинг и измерение?
5 какой уровень мониторинга реализован на текущий момент? Какие инструменты менеджмента используют в настоящий момент?
6 какие платформы для интеграции используют в настоящий момент?
7 для каких ресурсов осуществляют контроль версий?
8 какой процесс менеджмента изменений используют в настоящий момент?
9 какие инструменты используют для менеджмента конфигураций?
10 что признано ИТ-активами в организации (за исключением персонала)? Каким образом осуществляют менеджмент этих активов?
11 как выглядит текущая операционная архитектура?
12 каким образом операционная архитектура поддерживает нефункциональные требования к приложениям и сервисам?
13.3 Направление "Инфраструктура и менеджмент": соответствие индикаторов завершенности атрибутам завершенности
Далее приведен базовый набор индикаторов завершенности по направлению "Инфраструктура и менеджмент" в модели OSIMM. Каждый индикатор завершенности связан с набором атрибутов завершенности. Атрибуты завершенности - это выявленные характеристики индикатора завершенности для каждого уровня завершенности. Вопросы оценки необходимы для проведения опроса по направлению "Инфраструктура и менеджмент" в организации. Полученные ответы на вопросы для оценки направления "Инфраструктура и менеджмент" используют для определения уровня завершенности посредством оценивания результата и выбора тех атрибутов завершенности, которые наилучшим образом соответствуют полученным результатам. Показатели значимостей уровня завершенности используют для определения средних количественных показателей завершенности по нескольким индикаторам завершенности. Модель может быть расширена путем добавления дополнительных индикаторов завершенности и присвоения значимостям индикаторов уровня завершенности значений, определенных проводящей оценку организацией для индикаторов завершенности.
Таблица 7 - Индикаторы завершенности по направлению "Инфраструктура и менеджмент"
|
Уровень завершенности |
Индикатор завершенности |
Атрибуты завершенности |
Значимость завершенности |
Соответствие вопросов оценки |
|
Разрозненный (уровень 1) Платформы по бизнес-подразделениям |
ИТ-инфраструктура поддерживает нефункциональные и операционные требования и SLA, необходимые для работы архитектуры SOA |
Низкий уровень или отсутствует Операционная поддержка развертывания сервисов находится на низком уровне или отсутствует |
10 |
1, 5, 6, 7, 8, 9, 11 |
|
Интегрированный (уровень 2) Платформы |
ИТ-инфраструктура поддерживает нефункциональные и операционные требования и SLA, необходимые для работы архитектуры SOA |
Ограниченный Имеются решения на базе сообщений для интеграции приложений и поддержки миграции на ESB Менеджмент сервисов и обеспечение безопасности сервисов реализованы частично |
20 |
1, 6 3, 4, 5, 12 |
|
Компонентный (уровень 3) Общая инфраструктура с возможностью повторного использования |
ИТ-инфраструктура поддерживает нефункциональные и операционные требования и SLA, необходимые для работы архитектуры SOA |
Между организациями Процессы менеджмента и обеспечения безопасности сервисов документированы и использованы для подразделений и предприятия |
30 |
1, 3, 4, 5, 12 |
|
Сервисы (уровень 4) Проектная среда SOA |
ИТ-инфраструктура поддерживает нефункциональные и операционные требования и SLA, необходимые для работы архитектуры SOA |
В масштабах всего предприятия Операционная среда поддерживает развертывание сервисов в масштабах предприятия. Администрирование и менеджмент могут осуществляться для пользователей, работающих в различных департаментах, организациях и предприятиях |
40 |
3, 4, 5, 6, 11, 12 |
|
Композитные сервисы (уровень 5) Общая среда SOA |
ИТ-инфраструктура поддерживает нефункциональные и операционные требования и SLA, необходимые для работы архитектуры SOA |
Интегрированный в масштабах всего предприятия. Менеджмент сервисов поддерживает качество обслуживания и композитные приложения. Осуществляют менеджмент и принудительное применение политик безопасности |
50 |
2, 3, 5, 11, 12 4 |
|
Виртуальные сервисы (уровень 6) Обнаружение и реакция в виртуальной среде SOA |
ИТ-инфраструктура поддерживает нефункциональные и операционные требования и SLA, необходимые для работы архитектуры SOA |
Интеграция по всему предприятию, а также с внешними бизнес-партнерами. Сервисы как ресурсы могут быть виртуальными, что позволяет развертывать экземпляры в нескольких средах выполнения Менеджмент производительности и мониторинга сервисов поддерживает развертывание новых сервисов |
60 |
1, 2, 3, 5, 6, 7 5, 7, 8, 9 |
|
Динамически реконфигурируемые сервисы (уровень 7) Обнаружение и реакция с учетом контекста и на основе событий |
ИТ-инфраструктура поддерживает нефункциональные и операционные требования и SLA, необходимые для работы архитектуры SOA |
Адаптивное предприятие Менеджмент адаптивных корпоративных сервисов отслеживает и прогнозирует изменения в сервисах, необходимые для оптимизации их качества. Сервисы могут повторно использовать новые и динамические способы, которые не будут оказывать негативного воздействия на качество обслуживания существующих сервисов. Динамические политики безопасности сервисов; их менеджмент осуществляют в режиме реального времени |
70 |
2, 3, 8, 9 2, 4, 11, 12 4 |
14 Метод оценки OSIMM
Модель OSIMM можно использовать для оценки SOA как отдельный проект, так и целое бизнес-подразделение всего предприятия, экосистемы сервисов или целой отрасли. Метод оценки OSIMM применяют для выявления текущего уровня завершенности и определения целевого уровня завершенности (целевое состояние), необходимого для выполнения заявленных бизнес-задач.
Расширение модели OSIMM для оценки завершенности по дополнительным индикаторам, такое как на структура отрасли SOA, не только возможно, но и рекомендовано. Метод оценки OSIMM носит итеративный и эволюционный характер. По мере того как организация внедряет стратегию SOA, более подробно знакомится с оценками OSIMM и накапливает опыт по внедрению систем SOA, она может добавлять в эту модель собственные индикаторы.
Ценность модели OSIMM в качестве инструмента оценки состоит в том, что она представляет собой руководство по трансформации и адаптации SОА для процесса управления SOA.
14.1 Общие положения
Анализ включает в себя три этапа:
1 оценка текущих уровней завершенности для бизнеса, организации и ИТ;
2 выявление и определение целевого состояния, формирование понимания того, как выглядели бы бизнес, процессы, персонал и ИТ-решения организации, если бы они были трансформированы в высокопроизводительную систему SOA;
3 создание отчета с рекомендациями, в котором отображены текущие уровни завершенности по разным областям, описано идеальное целевое состояние и определен план мероприятий, необходимых для достижения этого целевого состояния.
Эти этапы выполняют в ходе анализа по модели OSIMM, который состоит из следующих шагов:
- выявление бизнес-задач для проведения целевой оценки (в качестве исходных данных используют артефакты корпоративной архитектуры);
- расширение модели OSIMM путем добавления необходимых индикаторов завершенности;
- добавление необходимых атрибутов к индикаторам завершенности для каждого уровня завершенности. Расширение базовой модели OSIMM при помощи дополнительных индикаторов завершенности позволяет организации привязать внедрение SOA к своей стратегии, смягчив тем самым проблемные вопросы или добавив бизнес-возможности;
- оценивание текущего уровня завершенности путем сравнения текущего состояния внедрения SOA в организации с индикаторами завершенности. Для этого их сопоставляют с соответствующими атрибутами завершенности;
- определение целевого состояния уровней завершенности, основываясь на требуемом уровне завершенности SOA, необходимом для достижения заявленных бизнес-целей;
- сравнение текущих и целевых значений индикаторов завершенности для выявления недостатков и составления плана трансформации организации с текущего уровня завершенности к требуемым целевым показателям;
- документирование результатов оценки и плана трансформации в отчете по оценке.
14.2 Шаги оценки OSIMM
14.2.1 Определение проблемных вопросов, области использования и бизнес-задач
Ответы на проблемные вопросы выявляют, какие процессы организация считает необходимым совершенствовать, что может определить направление последующего анализа по модели OSIMM. Эксперту по оценке следует собрать материал, который поможет определить требуемые целевые состояния уровней завершенности SOA. К такому материалу относятся документы по стратегиям, требования пользователей и артефакты корпоративной архитектуры. На этом этапе приведен первоначальный список проблемных вопросов или стратегических целей. После этого может быть определен объем работ и план мероприятий для трансформации SOA. Для определения области использования могут быть применены направления и области модели OSIMM.
Рисунок 10 - Анализ модели OSIMM
14.2.2 Оценка текущего состояния
Эксперт по оценке использует расширенную модель OSIMM, полученную на предыдущем этапе, для опроса ключевых сотрудников организации для оценивания ее текущего состояния, а, следовательно, и текущего уровня завершенности. При проведении опроса следует использовать как базовые вопросы для оценки, которые входят в модель OSIMM, так и вопросы, добавленные в ходе ее расширения. В опрос могут быть включены дополнительные вопросы, которые эксперт по оценке считает важными и которые могут помочь в сопоставлении индикаторов и атрибутов завершенности. Исходя из ответов на вопросы для оценки, для каждой области определяют текущий уровень завершенности и количественный показатель, который выбирают исходя из шкалы значимостей с шагом 10 баллов. Далее они объединяются (суммируются) по направлениям в результат, который отражает общее состояние организации.
14.2.3 Определение будущего состояния
Требуемое будущее состояние определяют на основе документов по требованиям, артефактов корпоративной архитектуры, а также опроса ключевых сотрудников. Исключительно важно провести работу с теми сотрудниками, у которых имеется понимание и сложившаяся концепция требований к будущим бизнес-сервисам и инфраструктуре SOA. Целевое состояние определяют путем оценки окупаемости инвестиций при более высоком уровне завершенности SOA. Такую оценку проводят по каждому из направлений OSIMM на основе бизнес-требований. Таким образом устанавливают целевые количественные показатели по областям, а путем их сложения определяют целевой уровень завершенности для всей организации.
14.2.4 Выявление недостатков и разработка плана мероприятий
На предыдущих этапах были выявлены текущие и будущие уровни завершенности по всем областям и направлениям матрицы оценки, созданной на первом этапе. Далее эксперту по оценке следует определить пробелы между текущими и будущими уровнями завершенности, а также разработать план мероприятий, который позволит организации перейти от текущего состояния к целевому. Индикаторы завершенности по каждой области отражают текущее и требуемое состояние. А план мероприятий должен быть составлен таким образом, чтобы перевести области из текущего в требуемое состояние, а также выполнить бизнес-задачи и разрешить проблемные вопросы. Кроме того, эксперту по оценке необходимо учитывать ограничения и требования, которые могут возникнуть при создании разных объектов ИТ и бизнеса. Следует отметить, что итоговый план мероприятий OSIMM должен содержать относительно высокоуровневые определения операций, которые потребуется осуществить, и что впоследствии можно провести более подробный анализ операций, выходящих за рамки анализа по модели OSIMM.
Результаты оценки по модели OSIMM, включая проблемные вопросы, матрицу оценки, текущий уровень завершенности, целевой уровень завершенности, решение проблемных вопросов и план мероприятий, следует представить в отчете для использования в качестве руководства по следующим этапам анализа и планирования, а также в качестве исходных данных для будущих мероприятий по развитию SOA, операций по управлению SOA и спиралей развития корпоративной архитектуры.
Следует периодически проводить повторную оценку завершенности. Общие показатели текущего состояния по областям и отдельные количественные показатели можно сравнить с целевыми количественными показателями для организации, что позволит отразить текущий прогресс на пути к достижению целей в области завершенности. Тем не менее количественные показатели завершенности не предназначены для сравнения разных организаций, поскольку все организации уникальны.
Приложение А
(справочное)
Пример оценки
В этом приложении приведен пример оценки на основе модели OSIMM. Компания HEALTHCO является вымышленной. Оценка описана в общих чертах и отражает только основные свойства метода. Подробные сведения о конкретных индикаторах, атрибутах, значимостях и вопросах для оценки не приведены.
А.1 Бизнес-задача
Компания HEALTHCO, поставщик услуг в области здравоохранения, рассматривает SOA как средство повысить уровень интеграции, внедрить общую концепцию развития бизнеса и ИТ, а также оптимизировать ИТ-расходы для достижения бизнес-целей. Для того, чтобы реализовать эту концепцию, HEALTHCO было необходимо определить пробелы в текущей ИТ-среде с точки зрения интеграции сервисов. Модель OSIMM использовалась для оценки текущего состояния, определения целевого состояния, а также составления рекомендаций по всем направлениям модели OSIMM.
А.2 Анализ
В этом примере некоторое количество приложений было разделено на две группы (интерфейсные и унаследованные), а затем был проведен анализ по модели OSIMM. Ниже приведено краткое описание этапов, связанных с направлением "Бизнес".
Проблемные вопросы состоят в том, что с точки зрения бизнеса ИТ-среда не обладает достаточной гибкостью для успешного внедрения новых бизнес-процессов.
Путем анализа индикаторов завершенности было определено, что бизнес рассматривает ИТ как приложения, а не как композитные сервисы, которые могут создаваться из других сервисов.
Таким образом, в настоящее время организация находится на уровне 2 по направлению "Бизнес".
Приложения являются монолитными и не интегрируются с другими системами.
Рассмотрев характеристики различных уровней, которые определены в модели OSIMM, можно увидеть, что на уровне 5 организации удастся разрешить этот проблемный вопрос, облегчая проектирование новых бизнес-процессов на основе сервисов.
Необходимость в переходе с уровня 2 на уровень 5 (как минимум) по направлению "Бизнес" определяет этап развития, связанный с внедрением бизнес-процессов и сервисов для структурирования функциональности.
А.3 Рекомендации
Рекомендации в краткой форме приведены в таблице А1. В ней также указаны текущие и целевые уровни завершенности по каждому из направлений.
Таблица А.1 - Рекомендации
|
Направление OSIMM |
Текущий уровень завершенности |
Краткая оценка |
Целевой уровень завершенности |
Рекомендации |
|
Бизнес |
2 |
Сильные стороны: - бизнес хорошо понимает возможности ИТ. Слабые стороны: - бизнес рассматривает ИТ как набор приложений, которые обеспечивают возможности для поддержки бизнес-процессов; - бизнес-возможности не соотносятся с ИТ; - независимость и сложность приложений снижает гибкость бизнеса |
6 |
Следует разработать компонентное представление бизнес-возможностей, при котором бизнес будет рассматривать сервисы как ресурсы, на смену текущей концепции, фокусирующейся на приложениях |
|
Организация |
3 |
Сильные стороны: - внедрена организация между приложениями; - осуществляется менеджмент обязанностей по работе сервисов Слабые стороны: ИТ-организация по большей части ориентирована на приложения. Имеются узко квалифицированные специалисты для разработки и поддержки конкретных приложений |
4 |
Владельцам бизнеса следует продвигать изменения сервисов, бизнес-процессов и архитектуры компонентов для соответствия изменяющимся бизнес-потребностям. Следует назначить владельцев ИТ, которые будут поддерживать конкретные области бизнес-возможностей и владельцев бизнеса. Следует предоставить полномочия владельцам бизнес-возможностей, чтобы они могли сфокусироваться на повышении устойчивости и совершенствовании конкретных возможностей |
|
Методы |
2 |
Сильные стороны: - имеется процесс ИТ-планирования и управления; - соблюдается методология последовательной разработки; - присутствуют практики объектно-ориентированного проектирования и разработки для интерфейсных приложений; - опубликованы стандарты и руководства по сервисам. Слабые стороны: - процесс планирования и разработки не поддерживает моделирование сервисов и повторное использование кода. Поддержка моделирования бизнес-процессов ограничена; - процесс планирования и разработки не обладает гибкостью и организован по каскадной модели |
4 |
Усовершенствовать методы планирования и разработки для обеспечения идентификации, проектирования и разработки сервисов. Внедрить процесс управления сервисами. Усовершенствовать методы планирования и разработки для обеспечения более активного повторного использования кода. Усовершенствовать методы планирования и разработки для обеспечения итеративной разработки. Усовершенствовать метод разработки ПО для поддержки моделирования и реализации бизнес-процессов |
|
Инфраструктура |
3 |
Сильные стороны: - имеется ПО для менеджмента систем; - имеется инфраструктура безопасности. Слабые стороны: - отсутствует инфраструктура для SOA (Менеджмент сервисов и бизнес-процессов) |
5 |
Внедрить инфраструктуру менеджмента веб-сервисов для поддержки развертывания SOA корпоративного масштаба. Внедрить инфраструктуру менеджмента бизнес-процессов (ВРМ). Развернуть инфраструктуру безопасности SOA, чтобы иметь возможность поддерживать политики безопасности, определяемые на уровне сервисов |
|
Приложения (интерфейсные) |
3 |
Сильные стороны: - компонентная, многоуровневая архитектура; - используются объектные модели. Слабые стороны: - минимальная степень повторного использования кода; - объектные модели не поддерживают совместного использования и разрабатываются независимо друг от друга; - используются специализированные (или не используются вовсе) ВРМ и рабочие процессы; архитектура приложения не стандартизирована |
5 |
Реализовать объектную модель в масштабе всего предприятия. Обеспечить повторное использование кода на уровне компонента и библиотеки. Стандартизировать эталонную архитектуру приложений, шаблоны проектирования и передовые практики. Реализовать механизм управления бизнес-правилами. Модернизировать и разбить на компоненты приложения, созданные на Коболе |
|
Приложения (унаследованные) |
2 |
Сильные стороны: - проводятся работы по модернизации архитектуры приложении; - унаследованные представления доступа обеспечивают последовательный подход к повторному использованию кода. Слабые стороны: - унаследованная архитектура, связанная с разработкой на Коболе, сложна в изменении; - нет единого подхода к компонентному представлению системы; - используются специализированные (или не используются вовсе) ВРМ и рабочие процессы; - архитектура приложений не стандартизирована и не направлена на использование серверных приложений | ||
|
Интеграция архитектуры и сервисы (интерфейсные) |
3 |
Сильные стороны: - в большинстве приложений использованы унаследованные представления доступа, основанные на стандартном подходе; - некоторые приложения действуют как поставщики сервисов; - файлы WSDL публикуются в каждом приложении. Слабые стороны: - интеграция точка - точка; для интеграции с мейнфреймом использованы разные протоколы и механизмы трансляции; - несогласованная архитектура без опасности |
5 |
Реализовать бизнес-сервисы с возможностью повторного использования. Реализовать корпоративную интеграционную модель данных (каноническую модель данных). Реализовать унифицированный транспортный протокол для веб-сервисов. Весь обмен данными с внутренними и внешними системами следует осуществлять через ESB. Поддерживать клиентов унаследованных приложений через ESB. |
|
Интеграция архитектуры и сервисы (унаследованные) |
3 |
Сильные стороны: унаследованные представления доступа используются для предоставления сервисов другим приложениям; эти представления документированы; имеется подход, который позволяет предоставить унаследованные представления доступа системам-потребителям; ESB реализована. Слабые стороны: серверные системы тесно связаны; некоторые унаследованные представления доступа не являются универсальными; отсутствует корпоративная модель данных для интеграции систем; бизнес-функции дублируются в нескольких системах; сильная зависимость от пакетных потоков; несогласованная архитектура безопасности |
Реализовать некоторые из компонентов в виде крупно модульных сервисных компонентов, интерфейсы которых доступны через веб-сервисы. Все приложения, включая серверные системы на мейнфреймах, обмениваются данными через веб-сервисы, вместо прямого повторного использования устаревших методов и унаследованных представлений доступа. Приложениям на Коболе следует предоставить возможность выступать в качестве потребителей веб-сервисов, предоставляемых другими серверными системами. SOA должна предоставить поддержку пакетной обработки, которая должна быть реализована параллельно. Разработать и реализовать политики безопасности на уровне сервиса |
Приложение В
(справочное)
Преимущества перехода на более высокие уровни завершенности
B.1 Переход с уровня "Разрозненный" на уровень "Интегрированный"
Организации, осуществляющие переход с "Разрозненного" на "Интегрированный" уровень завершенности, значительно сокращают операционные расходы и затраты на обслуживание. Такое сокращение затрат реализуют за счет сокращения избыточных и трудоемких процессов ввода данных, уменьшения циклов пакетной обработки для преобразования и передачи данных из одной системы в другую. В результате такого перехода данные становятся доступными в режиме реального времени, доставляются более надежно, а их преобразование в другие форматы для интегрированных систем выполняется автоматически. Трансформация от структурного к объектно-ориентированному программированию также позволит внедрить повторное использование кода и будет способствовать упрощению обслуживания ПО, поскольку ПО станет более модульным. Модульность повышает читаемость кода, что сокращает время, необходимое на его обслуживание.
B.2 Переход с уровня "Интегрированный" на уровень "Компонентный"
Организации, осуществляющие переход с "Интегрированного" на "Компонентный" уровень завершенности, выигрывают в подготовке к переводу бизнес-функциональности на более детализированный уровень, что необходимо на более высоких уровнях завершенности. Кроме того, на более высоких уровнях завершенности повторное использование уже относится к уровню бизнес-функций, а не к уровню приложений. Усовершенствования и новые функции достигаются путем реструктуризации существующих приложений с разбиением на повторно используемые компоненты меньшего размера. Разбиение бизнеса на составные части само по себе помогает снизить уровень сложности и упрощает анализ воздействия компонентной организации на новые бизнес-модели и бизнес-трансформации. Кроме того, такое компонентное представление помогает организации ускорить вывод решений на рынок и повысить готовность ИТ реагировать на бизнес-изменения.
B.3 Переход с уровня "Компонентный" на уровень "Сервисы"
После перехода с уровня завершенности "Компонентный" на уровень "Сервисы" организацию уже можно рассматривать как поставщика сервисов для других организаций в рамках предприятия или для его внешних партнеров, участвующих в цепочке создания стоимости. Бизнес-сервисы теперь можно использовать повторно. Этот уровень завершенности снижает потребность в повторной разработке одних и тех же функций для разных систем (и, следовательно, затраты на этот процесс). Это достигается за счет подготовки повторно используемых сервисов, которые вызываются через стандартизированные интерфейсы и не зависят оттого, на какой технологической платформе работает приложение. Такие сервисы также могут обеспечивать контролируемый и своевременный доступ к данным, что сокращает несогласованность данных в системах, которые их получают и обновляют. Инвестиции в идентификацию, спецификацию, разработку, тестирование и развертывание сервиса окупается, когда новым системам потребуется такой сервис от поставщика услуг, поскольку сокращаются затраты на инфраструктуру и обслуживание общей функциональности.
B.4 Переход с уровня "Сервисы" до уровня "Композитные сервисы"
Организации, осуществляющие переход с уровня завершенности "Сервисы" до уровня "Композитные сервисы", уже структурировали свой бизнес и ИТ-поддержку таким образом, чтобы новые бизнес-процессы можно было быстро создавать на основе сервисов, а подготовка новых бизнес-функций для разных частей организации выполнена с меньшими трудозатратами. При этом сокращено время вывода новых бизнес-моделей на рынок, что связано с изменениями в бизнес-стратегии и (или) бизнес-трансформацией. Этот уровень трансформации в основном заключается в повторном объединении сервисов, предоставляемых различными организациями в пределах предприятия или его цепочки создания ценности.
B.5 Переход с уровня "Композитные сервисы" до уровня "Виртуальные сервисы"
Организации, осуществляющие переход с уровня завершенности "Композитные сервисы" до уровня "Виртуальные сервисы", выигрывают благодаря значительной степени гибкости в проектировании интегрированных систем в том плане, что они получают возможность легко интегрировать различные типы сервисов (с точки зрения протокола, моделей данных и т.д.), которые в противном случае были бы несовместимы. Дополнительно система может быть реконфигурирована для повышения уровня надежности, причем потребителям не придется модифицировать свой код. Виртуальные сервисы позволяют организациям лучше соотносить бизнес-требования с ИТ-возможностями, выстраивая надежные сервисы с высоким уровнем гибкости, управляемости и унифицированной масштабируемости.
B.6 Переход с уровня "Виртуальные сервисы" до уровня "Динамически реконфигурируемые сервисы"
Организации, достигшие этого уровня завершенности, уже выполнили полную декомпозицию сервисов. Информация о конфигурации сервисов хранится в базе данных для того, чтобы сервисы можно было динамически конфигурировать, исходя из динамического характера запросов к сервисам, который обеспечивает высочайшую гибкость с точки зрения трансформации бизнеса и помогает полностью соотнести бизнес и ИТ. Инфраструктура наделена функциями автономности с высокой отказоустойчивостью для обнаружения и обработки запросов сервисов в пределах организации и предприятия.
Организации на этом уровне завершенности уже имеют сервисы, которые предоставляют гибкие возможности по выполнению SLA за счет динамического, более гибкого выделения мощностей, что повышает конкурентоспособность организации. Такая возможность также позволяет организации оптимизировать сервисы для достижения высокой доступности и масштабируемости без снижения уровня обслуживания, а также упростить развертывание сервисов.
Приложение С
(справочное)
Взаимосвязь с другими стандартами SOA
Совместный официальный документ "Путеводитель по открытым стандартам SOA, связанным с архитектурой" (Navigating the SOA Open Standards Landscape Around Architecture), подготовленный организациями OASIS, OMG и Open Group [SOA WP], призван помочь сообществу SOA разобраться во множестве пересекающихся технических продуктов, созданных этими организациями. В центре внимания данного документа находится архитектура.
В этом совместном документе описаны и позиционированы стандарты эталонных моделей SOA, онтологии, эталонные архитектуры, модели завершенности, языки моделирования и стандарты по управлению SOA. В нем отмечено, в каком аспекте эти работы схожи, рассмотрены сильные стороны каждого документа и упомянуто, каким образом эти работы можно использовать как параллельно, так и дополняя друг друга. Кроме того, документ создан в качестве руководства для пользователей этих спецификаций. Он поможет выбрать технические продукты, которые лучше всего отвечают их потребностям, соответствуют текущим задачам и планам по дальнейшему совершенствованию SOA.
Хотя понимание SOA концепций управления SOA этих работах похоже, стандарты создают исходя из разных точек зрения и со временем модернизируют. Все спецификации поддерживают схожий набор возможностей, однако обеспечивают разные уровни детализации одних и тех же аспектов, на которых они сфокусированы. Таким образом, хотя определения и выражения в некоторых отношениях могут различаться, фундаментальные концепции SOA и управления SOA целом совпадают.
Ниже приведен краткий обзор размещения и резюме этих спецификаций:
- "Эталонная модель OASIS для SOA" (The OASIS Reference Model for SOA, SOA RM) - это наиболее абстрактная из спецификаций. Она позволяет понять ключевые концепции SOA (см. [SOA RM]).
- "Онтология SOA консорциума Open Group" (The Open Group SOA Ontology) расширяет, уточняет и формализует некоторые из ключевых концепций документа SOA RM. Этот документ позволяет разобраться в ключевых концепциях SOA и пропагандирует подход к разработке SOA, основанный на моделях (см. [SOA ONT]).
- "Эталонная архитектура OASIS для базовых уровней SOA" (The OASIS Reference Architecture for SOA Foundation) рассматривает создание парадигмы SOA и взаимодействие в ней с точки зрения экосистемы. Этот документ позволяет разобраться в различных элементах SOA и полноте архитектур и реализаций SOA, а также рассматривает вопросы архитектур с несколькими владельцами, при которых для SOA и управления SOA нет единого полномочного субъекта (см. документ: http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf).
- "Эталонная архитектура SOA консорциума Open Group" (The Open Group SOA Reference Architecture) - это многоуровневая архитектура, которая определяется с точки зрения потребителя и поставщика. В этом документе рассмотрены междисциплинарные вопросы и описаны архитектурные компоненты и принципы, которые способствуют реализации SOA. Документ позволяет разобраться в различных элементах SOA и развертывании SOA на предприятии, определяет основу для эталонной отраслевой или организационной архитектуры и рассматривает последствия архитектурных решений, а также позиционирование продуктов различных поставщиков в контексте SOA (см. документ: www.opengroup.org/projects/soa-ref-arch).
- "Структура управления SOA консорциума Open Group" (The Open Group SOA Governance Framework) представляет собой эталонную модель и метод для области "Управление". Его назначение - помочь разобраться в управлении SOA в организациях. В документе "Эталонная модель OASIS для базовых уровней SOA" (The OASIS Reference Architecture for SOA Foundation) содержится абстрактное описание принципов управления применительно к SOA. Особое внимание уделяется межорганизационному управлению (см. [SOA GF]).
- "Модель завершенности интеграции сервисов консорциума Open Group" (The Open Group SOA Integration Maturity Model, OSIMM) позволяет оценить завершенность интеграции сервисов в организации по обширному спектру уровней SOA. В нем также определена программа поэтапного внедрения. Этот документ позволяет понять, на каком уровне завершенности SOA находится организация (см. настоящий стандарт).
- "Спецификация языка SoaML консорциума Object Management Group" (The Object Management Group SoaML Specification) определяет расширения языка UML для моделирования сервисов. Ее можно рассматривать как конкретизацию эталонной архитектуры SOA консорциума Open Group для представления артефактов SOA в языке UML (см. документ: www.omg.org).
Рисунок 11 - Платформа бизнес-трансформации на базе SOA (SBTF)
Многие независимые спецификации и стандарты SOA схожи в понимании базовых, центральных концепций. Это можно объяснить обширным и аналогичным опытом пользователей SOA и тем, что данная технология уже давно присутствует на рынке. Кроме того, это гарантирует, что инвестиции в бизнес- и ИТ-трансформацию на базе SOA, включающие в себя и использующие подобные спецификации и стандарты, помогут снизить риски, которые способны поставить под угрозу успех решения SOA. Ожидается, что в будущих работах по стандартам SOA могут быть пересмотрены концепции позиционирования, приведенные в настоящем стандарте, чтобы снизить уровень противоречий, пересекающихся и неохваченных областей рассмотрения стандартов, и обеспечить их максимально единообразное и полноценное дальнейшее развитие.
Приложение D
(справочное)
Взаимосвязь с другими международными стандартами
Другие международные стандарты, связанные с OSIMM, либо уже существуют, либо идет их подготавка# ИСО/МЭК СТК 1. В этом приложении приведена краткая информация о некоторых особенно важных стандартах, а также описаны предполагаемые будущие направления работы по OSIMM.
D.1 SC38
В спецификации OSIMM содержатся определения терминов, которые имеют особую важность для ее понимания.
В SC38 WG2 разрабатывают терминологию и технические принципы технических отчетов по SOA.
Поскольку в SC38 WG2 продолжается разработка терминологии из WD 30102 (подготовленного ИСО/МЭК СТК 1), в то время как конечная версия технического отчета уже готова, в будущем спецификация OSIMM может быть пересмотрена, чтобы согласовать терминологию, особенно в тех аспектах, где она конфликтует и затрудняет понимание и применение OSIMM.
D.2 SC7
D.2.1 Направления OSIMM и области SC7
D.2.1.1 Направления OSIMM
В стандарте OSIMM определен набор направлений, отражающих различные представления (например, представление бизнеса или архитектуры) организации. К ним отнесены следующие представления:
- бизнес;
- руководство и организация;
- методы;
- приложения;
- архитектура;
- информация;
- инфраструктура и менеджмент.
Это важные индикаторы эффективного внедрения сервисов для SOA и облачных инфраструктур. Индикаторы завершенности определяют путем оценивания по ряду вопросов, которые позволяют получить сведения о текущих и целевых практиках с точки зрения бизнес- и ИТ-сервисов, а также SOA. Результаты такой оценки могут сравнивать с оценками целевого уровня завершенности, а также пересматривать для того, чтобы определить прогресс в переходе к целевым уровням завершенности.
D.2.1.2 Области SC7
Цель SC7 состоит в создании международного стандарта, однако его область и сферу деятельности лучше всего можно описать не текущим техническим заданием, а путем классификации его программы работ.
Основная деятельность SC7 связана с бизнес-процессами и методами, относящимися к ИТ-инфраструктурам и системам на базе ИТ. В прошлом тем не менее ИТ-системам уделялось больше внимания, чем поддержке бизнеса.
Стандарты и проекты SC7 можно логически сгруппировать либо по процессам, либо по продуктам. Следует заметить, что SC7 охватывает не все поле стандартизации в этих областях, так что его сфера деятельности в какой-то мере ограничена. Для того, чтобы дать о ней некоторое представление, далее приведены примеры рабочих групп, действующих на момент публикации.
Корпоративные процессы ИТ-систем
Корпоративными называют процессы, которые не связаны с одним конкретным проектом, решением, системой или организационным подразделением, например:
- корпоративная архитектура;
- планирование;
- менеджмент портфеля продуктов;
- менеджмент, контроль и управление.
В настоящее время ведется работа групп WG42 "Архитектура", WG40 "Управление", WG19 "Открытая распределенная обработка" и WG27 "Высокоэффективные ИТ сервисы". Хотя эти темы подробно изучены отраслевыми консорциумами, международная стандартизация в данных областях находится на самых ранних этапах развития, и в SC7 в настоящее время разрабатывают несколько проектов такого рода.
Процессы инженерной разработки ИТ-систем
Эта область (точнее, "Программная инженерия ПО", что можно рассматривать как раздел инженерной разработки ИТ-систем) исторически была ядром программы работ SC7. Добавление проектов из области "Программная инженерия систем" сегодня позволяет расширить данное направление. В целом это следующие процессы:
- архитектура решений;
- менеджмент требований;
- проектирование;
- спецификация;
- приобретение;
- построение;
- реализация;
- менеджмент;
- оценка;
- измерение.
В настоящее время этими областями инженерной разработки занимаются рабочие группы WG07 "Процессы жизненного цикла", WG02 "Жизненный цикл рабочего продукта", WG24 "Жизненный цикл сверхмалого объекта" и WG26 "Тестирование".
Инструментальные средства и методики инженерной разработки ИТ-систем
Для поддержки этих процессов используют методики и инструментальные средства. Поскольку они в основном поддерживают более одного из указанных выше процессов, их рассматривают в отдельной области. Ими занимаются рабочие группы WG04 "Инструментальные средства и среда" и WG19 "Открытая распределенная обработка и языки моделирования".
Сервисы ИТ-систем
Проекты в области менеджмента и сервисов систем были назначены SC7 несколько лет назад (WG25 "Менеджмент сервисов" и WG21 "Менеджмент ресурсов ПО"), и сегодня важность этой области повышается. К ней относятся следующие процессы:
- менеджмент сервисов;
- менеджмент реализаций;
- доставка сервисов;
- поддержка сервисов;
- менеджмент конфигураций;
- менеджмент взаимодействия.
Качество, оценка и документирование ИТ-систем
Это вспомогательная область инженерной разработки ИТ-систем, которая относится к продуктам. В нее входят следующее:
- характеристики качества систем на базе ИТ;
- оценка систем на базе ИТ;
- оценка процессов, связанных с ИТ;
- документирование систем на базе ИТ.
Ими занимаются, в частности, рабочие группы WG23 "Сопоставление с 900-1", WG06 "Оценка и метрики" и WG10 "Оценка процессов".
D.2.1.3 Стандарты SC7
С точки зрения метода в SC7 разработаны эталонные стандарты по процессам и продуктам, например:
- ИСО/МЭК 12207-2008 Системная и программная инженерия. Процессы жизненного цикла программного обеспечения (Systems and Software Engineering - Software Life Cycle Processes).
- ИСО/МЭК 15288:2008 Системная и программная инженерия. Процессы жизненного цикла систем (Systems and Software Engineering - System Life Cycle Processes).
- ИСО/МЭК 15289-2006 Системная и программная инженерия. Содержимое информационных продуктов по процессам жизненного цикла систем и программного обеспечения (документация) [Systems and Software Engineering - Content of Systems and Software Life Cycle Process Information Products (Documentation)].
- ИСО/МЭК 90003-2004 Программная инженерия. Руководство по применению стандарта ИСО 9001:2000 к компьютерному программному обеспечению (Software Engineering - Guidelines for the Application of ISO 9001:2000 to Computer Software).
- ИСО/МЭК 10746-2009 Информационные технологии. Открытая распределенная разработка. Эталонная модель (Information Technology - Open Distributed Processing - Reference Model).
- ИСО/МЭК CD 26550 Системная и программная инженерия. Эталонная модель продуктовых линеек программного обеспечения и систем (Software and Systems Engineering - Reference Model for Software and Systems Product Lines).
- ИСО/МЭК 42010-2007 Системная и программная инженерия. Рекомендуемые практики для архитектурного описания систем с интенсивным использованием программного обеспечения (Recommended Practice for Architectural Description of Software-Intensive Systems).
- Кроме того, приняты стандарты в области реализации процессов и продуктов, например:
- ИСО/МЭК 14764-2006 Программная инженерия. Процессы жизненного цикла программного обеспечения. Обслуживание (Software Engineering - Software Life Cycle Processes - Maintenance).
- ИСО/МЭК 16085:2006 Системная и программная инженерия. Процессы жизненного цикла систем. Менеджмент рисков (Systems and Software Engineering - Life Cycle Processes - Risk Management).
- ИСО/МЭК/IЕЕЕ 16326:2009 Системная и программная инженерия. Процессы жизненного цикла систем. Менеджмент проектов (Systems and Software Engineering - Life Cycle Processes - Project Management).
- ИСО/МЭК CD 29119 Информационные технологии. Программная инженерия. Тестирование (Information Technology - Software Engineering - Testing).
- ИСО/МЭК/IEEE 29148 Системная и программная инженерия. Процессы жизненного цикла систем. Разработка требований (Systems and Software Engineering - Life Cycle Processes - Requirements Engineering).
- ИСО/МЭК 29110:2011 Программная инженерия. Профили жизненного цикла для сверхмалых объектов [Software Engineering - Life Cycle Profiles for Very Small Entities (VSEs)].
- С точки зрения менеджмента сервисов стандарты SC7 образуют серию 20000:
- ИСО/МЭК 20000-1:2011 Информационные технологии. Менеджмент сервисов - Часть 1. Системные требования к менеджменту сервисов (Information Technology - Service Management - Part 1: Service Management System Requirements).
- ИСО/МЭК 20000-2:2005 Информационные технологии. Менеджмент сервисов. Часть 2. Руководство по применению систем менеджмента услуг (Information Technology - Service Management - Part 2: Code of Practice).
- ИСО/МЭК ТО 20000-3:2009 Информационные технологии. Менеджмент сервисов. Часть 3. Руководство по определению области применения и применимости ИСО/МЭК 20000-1 (Information Technology - Service Management - Part 3: Guidance on Scope, Definition, and Applicability of ISO/IEC 20000-1).
- ИСО/МЭК ТО 20000-4:2010 Информационные технологии. Менеджмент услуг. Часть 4. Эталонная модель процессов (Information Technology - Service Management - Part 4: Process Reference Model).
- ИСО/МЭК ТО 20000-5:2010 Информационные технологии. Менеджмент услуг Часть 5. Пример плана реализации ИСО/МЭК 20000-1 (Information Technology - Service Management - Part 5: Exemplar Implementation Plan for ISO/IEC 20000-1).
- ИСО/МЭК НП TO 20000-10 Информационные технологии. Менеджмент услуг. Часть 10. Концепции и терминология (Information Technology - Service Management - Part 5: Concepts and Terminology).
D.2.1.4 SC7 и OSIMM
Задача модели OSIMM состоит в том, чтобы оценить завершенность текущих инфраструктурных и бизнес-сервисов и практике области SOA в организации. SOA - это архитектурный стиль, применяемый для разработки сервис-ориентированных систем. Кроме того, в OSIMM устанавливают требования к формальным методам разработки и развертывания SOA.
Формализация методов и практик в области архитектуры, методологии моделирования, инженерной разработки систем и ПО и менеджмента сервисов является основной задачей SC7. Естественно, что многие из направлений, отобранных для модели OSIMM (а именно: "Методы", "Архитектура", "Инфраструктура" и "Менеджмент"), также охвачены стандартами и действующими проектами SC7.
D.2.1.5 Заключение
Если терминология, используемая в настоящем стандарте, а именно в контрольных списках, будет приведена в соответствие с существующими стандартами FDIS 15504, это позволит более тесно интегрировать стандарт OSIMM с набором стандартов ИСО по инженерной разработке ПО и систем.
Задача OSIMM состоит не в том, чтобы измерить степень соблюдения стандартов в организации, поэтому в этой модели нет необходимости использовать стандарты SC7 в качестве нормативных документов.
D.2.2 Оценка по SC7 и OSIMM
D.2.2.1 Оценка по OSIMM
Стандарт OSIMM предназначен для проведения оценки, которая поможет компаниям определить пробелы и составить план мероприятий, чтобы изменить использование сервисов в своих решениях. Целью оценки OSIMM является использование сервисов и применение ориентированности на сервисы к бизнес-решениям. Сравнение уровней завершенности решения на разных этапах может принести значительную пользу для оценки прогресса на пути к внедрению SOA. Тем не менее сравнивать уровень завершенности двух разных решений в двух разных организациях будет некорректно, так как каждую оценку проводят с учетом значимостей и бизнес-задач конкретного предприятия. Точно так же некорректно устанавливать определенный уровень завершенности для всех организаций или требовать от них достижения такого уровня.
В стандарте OSIMM использованы понятия "оценка" и "метод оценки". Обозначаемые ими явления имеют менее формальную природу, чем в принятом значении этих терминов в SC7 FDIS 15504. Процесс, предлагаемый стандартом OSIMM, ближе к операциям по оценке жизненного цикла планирования или к процессам корпоративной архитектуры. В процессе данных операций и процессов также изучают текущую ситуацию, определяют целевые показатели, а затем проводят своего рода анализ пробелов между этими уровнями для того, чтобы определить план будущих мероприятий и установить их приоритет.
D.2.2.2 Оценка по SC7
В стандартах SC7 термины "оценка" и "метод оценки" имеют другое, более формальное значение. Работы, проводившиеся в последние 15 лет, породили и усовершенствовали платформу и структуру модели оценки завершенности/возможностей, которую используют как основу не только для интеграции (с другими измеряемыми аспектами организации), но и для гармонизации (средство, при помощи которого эти стандарты могут работать в пределах организации). Без такой совместно используемой модели и структуры результаты невозможно ни сравнить, ни даже сопоставить с результатами по другим аспектам организации.
Подход, принятый SC7, заключается в том, чтобы разделить процессы и продукты оценки на три независимых, но взаимосвязанных группы:
1 метод оценки, документированный в стандартах и технических отчетах, приведенных в следующем разделе;
2 база оценки - так называемая эталонная модель процесса;
3 критерии оценки - так называемая модель оценки процесса.
Этот метод применим ко всем процессам (а не только к инженерной разработке ПО и систем), поскольку его компоненты определены стандартным образом.
D.2.2.3 Стандарты SC7
В области оценки возможностей процесса SC7 принят ряд документов, опубликованных в составе ИСО/МЭК 15504. Эти документы были реструктурированы и переработаны и сегодня входят в серию 33000:
- ИСО/МЭК 15504-1-2004 Информационные технологии. Оценка процессов. Часть 1. Концепции и словарь (Information Technology - Process Assessment - Part 1: Concepts and Vocabulary).
- ИСО/МЭК TR 15504-2-1998 Информационные технологии. Оценка процессов программного обеспечения. Часть 2. Эталонная модель для процессов и возможностей процессов (Information Technology - Software Process Assessment - Part 2: A Reference Model for Processes and Process Capability).
- ИСО/МЭК 15504-3-2004 Информационные технологии. Оценка процессов. Часть 3. Руководство по проведению оценки (Information Technology - Process Assessment - Part 3: Guidance on Performing an Assessment).
- ИСО/МЭК 15504-4-2004 Информационные технологии. Оценка процессов. Часть 4. Руководство по использованию для совершенствования процессов и определения возможностей процессов (Information Technology - Process Assessment - Part 4: Guidance on Use for Process Improvement and Process Capability Determination).
- ИСО/МЭК 15504-5-2006 Информационные технологии. Оценка процессов - Часть 5. Пример модели оценки процессов (Information Technology - Process Assessment - Part 5: An Exemplar Process Assessment Model).
- ИСО/МЭК TR 15504-6-2008 Информационные технологии. Оценка процессов. Часть 6. Пример модели оценки процессов жизненного цикла систем (Information Technology - Process Assessment - Part 6: An Exemplar System Life Cycle Process Assessment Model).
- ИСО/МЭК ТО 15504-7-2008 Информационные технологии. Оценка процессов. Часть 7. Оценка организационной завершенности (Information Technology - Process Assessment - Part 7: Assessment of Organizational Maturity).
- ИСО/МЭК TO 15504-8-1998 Информационные технологии. Оценка процессов ПО. Часть 8. Руководство по использованию при определении возможностей процессов поставщиков (Information Technology - Software Process Assessment - Part 8: Guide for Use in Determining Supplier Process Capability).
- ИСО/МЭК TO 15504-9-1998 Информационные технологии. Оценка процессов ПО. Часть 9. Словарь (Information Technology - Software Process Assessment - Part 9: Vocabulary).
- ИСО/МЭК ДТО 15504-10 Информационные технологии. Оценка процессов. Часть 10. Расширение безопасности (Information Technology - Process Assessment - Part 10: Safety Extension).
D.2.2.4 SC7 и OSIMM
Хотя при описании оценки в OSIMM nSC7 используют одну и ту же терминологию, взятую из ИСО/МЭК 15504, очевидно, что имеется два разных набора требований к оценке и два разных метода оценки.
D.2.2.5 Заключение
Если SC38 примет решение уточнить подход OSIMM до такого уровня, при котором можно будет сравнивать результаты оценки разных организаций, а целью использования документов и экспертных знаний SC7. Необходимо отметить, что методы оценки возможностей и завершенности SC7 (ИСО/МЭК 15504) являются универсальными; в них использованы эквиваленты "подключаемых модулей", зависящие оттого, в какой области проводят оценку. Проводят оценивание и в других областях таких как программная инженерия (ИСО/МЭК 12207), программная инженерия систем (ИСО/МЭК 15288), менеджмент сервисов (ИСО/МЭК 20000) и жизненный цикл сверхмалых объектов (ИСО/МЭК 29110) (см. www.spiceusergroup.org).
Подход OSIMM может быть формализован в рамках структуры, совместимой с ИСО/МЭК 15504 (эталонная модель процессов), и критериев оценки, совместимых с ИСО/МЭК 15504 (модель оценки процессов).
Это даст возможность сравнивать оценки и позволит включить уровни завершенности в установленную структуру SC7.
На момент публикации планов по такому уточнению нет. Поскольку OSIMM представляет собой модель оценки, производимой самостоятельно, то она не пересекается с программой работ или стандартами оценки SC7.
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации
Таблица ДА.1
|
Обозначение ссылочного международного стандарта |
Степень соответствия |
Обозначение и наименование соответствующего национального стандарта |
|
ИСО/МЭК 30102 |
- |
* |
|
* Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. | ||
(Нет голосов) |
-
12.04.2024
Названы города России с самым доступным жильем
Городом с самыми дешевыми квартирами в новостройках оказался Воронеж
-
12.04.2024
Россиянам назвали лучшее время для продажи дачи
Аналитик Гутман: период с мая по июль является лучшим периодом для продажи дачи
-
12.04.2024
Предсказано будущее рынка жилья в России
«МК»: в России не отменят льготную ипотеку
-
12.04.2024
В Москве подешевела аренда квартир
Аренда квартир в Москве подешевела на 10 %
-
22.03.2024
Хуснуллин назвал необходимый размер ставки по ипотеке
Вице-премьер Хуснуллин: ставка по ипотеке должна быть пять процентов