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

Приложение А
(справочное)

Пример оценки

В этом приложении приведен пример оценки на основе модели 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 должна предоставить поддержку пакетной обработки, которая должна быть реализована параллельно. Разработать и реализовать политики безопасности на уровне сервиса