Процесс определения требований для SOA-проектов: Часть 2. Бизнес-требования для ваших первых SOA-сервисов

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

SonyPictures Entertainment

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

Введение

В первой статье данной серии вы узнали о том, как определять технические требования для проекта SOA (Service-Oriented Architecture – сервис-ориентированная архитектура). Мы начали с обсуждения того, что надо определять раньше - технические требования или требования бизнеса. Хотя "правильного" ответа на этот вопрос нет, судя по моему опыту, часто, если не всегда, SOA-проекты возглавляются департаментами информационных технологий (ИТ), и обсуждения, как правило, начинаются с технологии. В предыдущей статье подробно рассматриваются различные типы технических требований и разнообразные возможные ловушки, которых нужно остерегаться при определении этих требований.

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

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

С чего начать?

В этой статье предполагается, что вы четко определились с технологией SOA. Вы определили начальный набор технических требований для вашей SOA и сейчас спрашиваете себя: "Какие сервисы SOA мне следует внедрить?" Различные ИТ-подразделения вашей организации могут говорить разные вещи: одни захотят внедрить технические сервисы, такие как сервис управления контентом, другие - сервисы, связанные с безопасностью (аутентификация/авторизация), или что-то еще. Однако ключевым в SOA-проекте является первоначальный набор бизнес-требований. Я не хочу вдаваться в полемику о том, с чего начать, я предполагаю, что вы начинаете с бизнес-сервисов. Давайте для начала рассмотрим способы определения требований для этих бизнес-сервисов.

Определение сервиса

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

Определение сервисов сверху вниз

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

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

Рисунок 1. Нисходящий подход

Определение сервисов снизу вверх

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

На рисунке 2 показан пример восходящего подхода к определению сервисов. Он не сильно отличается от нисходящего подхода, однако начальные точки существенно различаются.

Рисунок 2. Восходящий подход

В разделе Ресурсы есть ссылка на полезную статью, в которой более подробно обсуждается концепция определения сервисов.

Сбор требований для одного сервиса

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

Типы требований

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

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

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

●     Взаимодействие. Как сервис или приложение, которое вызывает сервис, взаимодействует с этим сервисом? Как сервис обрабатывает ошибки?

●     Информация. Какие данные посылаются сервису и что он возвращает?

●     Процесс. Каковы взаимоотношения между действиями и событиями в сервисе?

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

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

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

С точки зрения процесса вам нужно получить от "поставщика" сервисов описание того, какая функциональность будет присутствовать в сервисе и какая отсутствовать. Сначала вы собираете различную информацию, описанную в предыдущей части статьи, используя любую методологию или инструментарий сбора требований: IBM® Rational® Unified Process и IBM Rational RequisitePro® или обычный текстовый документ по итогам импровизированного совещания по требованиям. На этом этапе я бы не рекомендовал слишком формализовать процесс. Идея в том, чтобы быстро реализовать несколько сервисов для демонстрации значимости вашего SOA-проекта. Однако вам все равно нужно как-то задокументировать эти требования.

Документирование требований для одного сервиса

Как эффективно задокументировать требования? Предлагаемый процесс документирования поможет вам согласовать требования с представителями бизнеса для получения утверждения, а также поможет довести эти требования до технической команды, которая будет реализовывать сервис.

Возможно, вам уже приходилось иметь дело со сценариями использования. Это превосходный способ определения требований для SOA-проекта. На рисунке 3 показан пример шаблона сценария использования, который вы можете использовать для документирования своих требований. В Rational RequisitePro и других средствах Rational имеется много других полезных шаблонов. Дело не в том, какой шаблон использовать. Если вы собираете типы требований, описанные ранее, все будет в порядке.

Рисунок 3. Шаблон сценария использования

Заключение

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

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

Оригиналстатьи "Requirements process for SOA projects, Part 2: Business requirements for your first SOA services"