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

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

Разработчик сервиса

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

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

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

Какое же отношение все вышесказанное имеет к управлению. Дело в том, что процесс разработки сервисов должен отвечать политике компании. Например, могут существовать четкие требования к началу разработки сервисов, к осуществлению передачи артефактов из одной фазы жизненного цикла сервиса в другую, к грануляции или кластеризации сервисов (в группы, домены или еще во что-то). Таким образом, справедливо будет сказать, что система управления компании направлена в первую очередь на контроль за деятельностью разработчика сервисов.

Разработчик архитектуры домена SOA

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

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

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

Разработчик архитектуры платформы SOA

Не секрет, что вопрос о «правильной» технологии для введения SOA поднимался несчётное количество раз. Ответ заключается в том, что какое бы технологическое решение не было выбрано, сервис–ориентированная архитектура будет полностью реализована только в случае их согласованности и последовательности. Другими словами, SOA может основываться на чем угодно: на Web-сервисах, REST, CORBA, Java и JMC или C# и MQ - или на любой их комбинации. Каким бы ни было технологическое решение, необходимо выбрать из этого (или расширенного) списка технологий одну единственную (или комбинацию из нескольких).

В этом и заключается первоочередная задача разработчика архитектуры платформы SOA. После того как необходимая комбинация стандартов выбрана, допустим в нашем случае это Web-сервисы, согласованные с WS-I Basic Profile 1.2, связанные с WS-Addressing, WS-ReliableMessaging и UDDI v3, задача разработчика платформы SOA - обеспечить дальнейшую их поддержку. Например, может понадобиться ввести новые стандарты или заменить уже существующее на альтернативные.

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

Бизнес-владелец сервиса

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

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

Технический владелец сервиса

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

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

Заключение

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

По материалам портала InfoQ

Комментарии