Процесс определения требований для SOA-проектов, Часть 1: Сбор требований для SOA-приложения

Кунал Миттал, архитектор Portal/J2EE, консультант.

Начальные требования для создания вашей SOA

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

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

Сбор требований требует наличия уникального набора навыков; это одновременно и наука, и искусство. Например, вы не можете исключить человеческий фактор - люди иногда меняют свое мнение о том, чего они хотят. Не стоит предполагать, что вы определите 100 процентов требований или что требования не изменятся. Хороший бизнес-аналитик подключает в процесс пользователей и убеждает их в значении точности требований. Аналитик демонстрирует чрезвычайную важность участия пользователей в этом процессе и заставляет их брать на себя ответственность за любые изменения или упущения. Это как раз случай "ерунда на входе, ерунда на выходе" - если вы начнете с плохо определенных требований, вы наверняка закончите бесполезным продуктом.

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

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

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

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

Как бы я ни хотел сфокусироваться сначала на бизнес-требованиях, большинство SOA-инициатив руководятся ИТ-группами, а не бизнес-группами в сотрудничестве с ИТ. ИТ-группы осознают необходимость в новой технологии быстрее, чем бизнес-группы. Они начинают поднимать вопросы об управлении, поддержке, моделях затрат и т.д. С точки зрения технологии они начинают говорить о UDDI-репозиториях (Universal Description, Discovery, and Integration), технологических интегрированных средах для создания сервисов, ESB (Enterprise Service Buse) и т.д. Я редко видел ИТ-группы, занимающиеся выбором бизнес-сервиса и подтверждением концепции (proof of concept - POC). Они действительно выбирают сервис, но затем концентрируются исключительно на технологии. Они говорят о том, какую технологию использовать для POC, какой стандарт XML (Extensible Markup Language) использовать, какую платформу, какую ESB и т.д. Не является неправильным начать с этого; я не встречал SOA-проект, который замедлился или был отложен на следующий финансовый год из-за того, что ИТ-группа не согласилась с этими аспектами внедрения SOA. Поэтому я начну здесь именно с этого, а затем перейду к бизнес-требованиям для сервисов.

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

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

Как собрать технические требования для вашего SOA-проекта? Я полагаю, что вы уже определили три-пять сервисов, которые планируете внедрить как часть SOA-проекта.

Для начала вы должны быть способны поддерживать несколько сервисов. Для этого вы должны определить следующее:

●     Эксплуатационные соглашения об уровне сервиса (service-level agreements - SLA)

●     Поддержку SLA-соглашений

●     Требования по реализации для сервисов

●     Требования по развертыванию

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

●     Полные эксплуатационные стратегии для долговременного использования SOA

●     Управление обнаружением, обеспечением и доставкой сервисов

●     Передовой опыт и шаблоны по сервис-ориентированной разработке

●     Эксплуатационные SLA-соглашения

●     Поддержка SLA-соглашений

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

Сбор технических требований

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

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

Другие требования

SLA-соглашения и соглашения по уровню эксплуатации (Operational-Level Agreements - OLA) являются самым трудным набором технических требований к SOA, поскольку каждый хочет самой быстрой реакции системы, доступности 24/7, поддержки неограниченного числа пользователей и т.д. Трудно разработать четко определенные параметры для сервиса и реализовать их. Если у вас есть бизнес-требования (обсуждаемые во второй части данной серии статей), SLA-соглашения и OLA-соглашения, то вы можете начать составлять ваши требования к реализации и развертыванию. Как упоминалось ранее, на этом этапе вы не должны обращать внимание на технологии, интегрированные среды, инструментальные средства, продукты или даже на слишком многие стандарты. Начните с простого, используя SOAP и WSDL (Web Services Description Language) в качестве фундаментальных стандартов. Используйте технологии .NET® или Java™ - любую, которая используется на вашем предприятии в качестве стандарта, или в использовании которой у вас есть больший опыт. Выберите необходимое минимальное число инструментальных средств разработки. С точки зрения развертывания используйте Internet Information Server (IIS), если выбрали технологию .NET. Однако если вы выбрали технологию Java, используйте простой сервер приложений, например, Tomcat или Geronimo. Вам никогда не понадобится JBoss на данном этапе, оставьте в стороне WebLogic или IBM WebSphere®. Однако если на вашем предприятии в качестве стандарта используется конкретный контейнер развертывания (WebSphere, WebLogic либо какой-то другой), конечно, работайте с ним.

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

Заключение

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

Подход к SOA-проекту и сбору технических требований очень похож на модель развития функциональных возможностей (CMM - Capability Maturity Model). В начале работы представьте себя находящимся на уровне 1 CMM. Не пытайтесь решить проблемы уровня 4 и 5. Сконцентрируйтесь на быстром внедрении SOA, помня и об общей картине.

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

Об авторе

Кунал Миттал – консультант, специализирующийся в технологиях Java, J2EE, технологиях web-сервисов. Он - соавтор и активный участник создания нескольких книг по этим темам. Кунал в настоящее время работает над портальным проектом для Sony Pictures Entertainment. Для получения более подробной информации посетите сайт автора.

Оригинал статьи "Requirements process for SOA projects, Part 1: Capturing requirements for an SOA application".