Программное обеспечение может дать вам лишь 20% необходимой информации.

Итак, ваш директор по информационным технологиям говорит: «Внедряйте SOA». Ваши действия? Вы бросаетесь на поиски и приобретаете дорогостоящий инструментарий по управлению SOA. Думаете, это решит ваши проблемы? А вот и нет.

SOA – это не программный продукт, так что по большому счету почти не обсуждается в рамках программного обеспечения. Вывод: программное обеспечение - не самый лучший помощник в освоении SOA.

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

Однако это лишь малая толика того, что вам действительно нужно, чтобы управлять SOA.

Суть SOA заключается в том, чтобы создать гибкую среду, изначально облегчая создание полностью интегрированных приложений. Вот для чего она нужна. Если же ваши сервисы не позволяют вам создавать сервис-ориентированные приложения, тогда, увы, вы выбросили деньги на ветер и зря потратили время. Прежде всего, руководство SOA должно помочь вам удостовериться, что вы ни в коем случае не тратите деньги на создание ненужных вам сервисов, но можете создавать те сервисы, которые вам действительно нужны!

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

Действие	Что это вам дает	Этап программирования
Анализ бизнес-сервисов	Понимание информационных объектов и этапов их обработки, для которых и создается сервис.	Планирование
Декомпозиция сервисов	Понимание разных уровней сервисов (уровни данных, оркестрации, формирования, управления), необходимых для успешного ведения бизнеса. Понимание предназначения каждого сервиса. Здесь возникает необходимость рассмотреть такие понятия, как «бизнес-событие» и «документы».	Планирование, Разработка
Проектирование (описание) события и разработка схемы	Создание плана, которым будут руководствоваться сервисы в своем поведении, с целью обеспечить успешное ведение операционных, информационных и бизнес-процессов организации. Поведение часто описывается как протокол, но стоит также иметь ввиду, что оно может включать в себя такие понятия,как «уровень предоставления сервиса», «устранение ошибок» и «компенсация».	Планирование, Разработка
Создание политики безопасности и управление ею.	Набор стандартов, обеспечивающих безопасность сервисов, определяющих необходимый уровень авторизации для сервисов разных типов и просчитывающих, как границы сети будут влиять на доступ к данным тех или иных форм, уровней и типов.	Планирование
Создание операционной политики и управление ею	Набор стандартов, необходимых для создания сервисов. Использование стандартов позволяет нам видеть и отслеживать созданные сервисы, управлять ими, проверять и контролировать их.	Планирование
Проведение политики	Автоматическое применение политик к сервисам, запущенным в сеть.	Развертывание, Поддержка
Мониторинг сервисов	Автоматический мониторинг, регистрация и отслеживание вызовов сервисов с целью убедиться, что сервисные уровни поддерживаются. Все это также позволяет осуществлять помощь при отладке сервисов и устранении дефектов и отработке ошибок сервисов.	Развертывание, Поддержка
Обнаружение неисправных сервисов	Автоматическое обнаружение сервисов, запущенных в сеть, делает возможным зафиксировать сервисы, предлагающие неконтролируемые функциональные возможности, нелегальный доступ и вообще сервисы, за которыми по тем или иным причинам проблематично осуществлять контроль.	Поддержка
Реестр/Репозиторий сервисов	Инструментарий, позволяющий передавать информацию о сервисах как приложениям, которые используют эти сервисы, так и людям, которые их создают и используют.	Планирование,Разработка, Конструирование, Поддержка
Соответствие проекта концепции СОА	Процесс, позволяющий нам судить, действительно ли проекты, финансируемые корпоративными подразделениями ИТ используют и доставляют именно те сервисы, в которых предприятие нуждается.	Проектирование, Разработка, Конструирование

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

И, напоследок, несколько слов дабы защитить себя от яростных нападок поставщиков того или иного программного обеспечения:

1. Вероятно, в некоторых программных пакетах действительно частично предусмотрено решение ряда проблем, связанных с SOA. Однако они неспособны дать вам полное представление, скорее просто снабдят вас «дополнительной» информацией, не выходящей за рамки использования этих программных пакетов.
2. Во многих инструментариях имеется инструмент, позволяющий осуществлять доступ к библиотеке политик и управление ею. Но это ведь совсем не то же самое, что создание политики. Это кодирование политики. Утверждать, что это создание политики, так же смешно, как убеждать других в том, что адресная книга Outlook-а создает клиентов. В действительности создание политики – это бизнес-процесс. Вы можете приобрести шаблоны политик, но вы не можете купить сами политики.
3. И последнее. Мои слова – это всего лишь мое личное субъективное и независимое мнение. У моего работодателя, его партнеров и у кого угодно может быть совершенно иная точка зрения.

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

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

По материалам блога Inside Architecture

Комментарии