Процесс определения требований для SOA-проектов: Часть 3. Сбор требований на этапе использования SOA-сервисов

Кунал Миттал, директор Domestic TV IT,

Sony Pictures Entertainment

Когда на вашем предприятии уже имеется некоторое количество сервисов SOA (Service-Oriented Architecture - сервис-ориентированная архитектура), процесс сбора требований для них может стать сложным делом. Как справиться с ситуацией, когда одному бизнес-подразделению требуются те же сервисы, что и другому? Узнайте, как лучше всего собирать и документировать многочисленные требования от различных подразделений.

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

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

Теперь же вы узнаете, как перейти от первоначального набора SOA-сервисов к развернутой SOA-платформе, и какие требования необходимо удовлетворить перед созданием корпоративной SOA-платформы. В статье мы делаем упор на бизнесе и не останавливаемся на конкретных технических продуктах (таких как, например, Enterprise Service Bus).

Корпоративная SOA

В первой статье данной серии рассказывалось о бизнес-требованиях для вашего первого набора SOA-сервисов. На этом этапе вы выбирали не больше трех-пяти сервисов. Сейчас же мы собираемся поговорить о бизнес-требованиях для вашей корпоративной SOA.

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

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

Технические требования для корпоративного SOA-проекта

Хотя большая часть статьи посвящена вопросам бизнес-требований, сначала остановимся на некоторых основных технических вопросах.

Требования из вашего первоначального SOA-проекта

Как было рассказано в предыдущей статье, при составлении требований для первых SOA-сервисов следовало ориентироваться на пять основных категорий.

●     Удобство использования. При использовании сотен сервисов вам нужно определить четкий способ, с помощью которого пользователи будут находить правильные сервисы и всегда знать, как использовать их эффективно. Я, как правило, не ратую за использование реестров или UDDI (Universal Description, Discovery, and Integration - инструмент для расположения описаний Web-сервисов (WSDL) для последующего их поиска другими организациями и интеграции в свои системы) в первоначальном проекте SOA. Разумный порог для начала использования реестров - 50 сервисов. Это не магическое число и не базовая рекомендация, какое число взять; это решение вам нужно принять самостоятельно.

●     Функциональность. Поскольку вы создаете все больше сервисов, важно анализировать функциональность каждого сервиса. Старайтесь минимизировать перекрытие. Задумайтесь, например, может ли новый сервис, который вы собираетесь создать, быть композицией существующих сервисов? Действительно ли этот сервис новый или он представляет собой просто иное воплощение существующего сервиса?

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

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

●     Процесс. Как 50, 100 или 200 сервисов в вашей организации работают вместе? Как изменяются эти процессы и как эти изменения влияют на каждый отдельный процесс?

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

Дополнительные требования для корпоративной SOA

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

В число высокоуровневых категорий для таких требований входят следующие:

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

●     Безопасность. Несомненно, возникнут вопросы, связанные с безопасностью. Серьезно озаботьтесь вопросами безопасности ваших SOA-сервисов. Кто к какому сервису имеет доступ? Кто к каким данным имеет доступ в рамках каждого сервиса? И как обеспечивается защита данных при их передаче между сервисами?

●     KISS (Keep It Simple, Stupid - Не усложняйте). Насколько легко тот, кто захочет воспользоваться сервисом, сможет им в действительности воспользоваться? Это требование находится на границе техники и бизнеса, но его необходимо учесть в полной мере. Сделайте минимальные предположения касательно подкованности потенциального пользователя сервиса в технических или бизнес-вопросах. сервисы должны легко вызываться, отлично работать, иметь хорошую систему сообщений об ошибках и в целом уметь интегрироваться с другими сервисами. Ваши сервисы должны быть доступны даже не очень технически подготовленной компании без больших инвестиций в технологии и серьезных изменений в бизнес-процессах.

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

●     Глобализация. Нужна ли локализация ваших сервисов для пользователей из других регионов мира? Как она отразится на производительности, готовности, пропускной способности и т.п.?

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

Технические требования для корпоративной SOA

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

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

Пересмотр процесса определения требований

Всетипичныепроцессыопределениятребованийприменимык SOA-проектам, используетеливыформальныесредства, такиекак IBM® Rational® RequisitePro®, CaliberRM или iRise Application Simulator, илинеформальныесредства, такиекак Microsoft® Office Word или Visio. Сделайте наброски двух процессов сбора требований для вашего корпоративного SOA-проекта: один для процесса сбора требований для каждого отдельного сервиса, который описан во второй статье данной серии, и второй для процесса сбора требований для встраивания этого сервиса в существующий SOA-проект, который описан в данной статье.

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

Заключение

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

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