Почему внедрение сервис-ориентированной архитектуры требует много времени

В материале рассматриваются причины, затрудняющие внедрение
сервис-ориентированной архитектуры (СОА) в организации.

Предлагаем читателям размышления специалистов авторитетной консалтинговой и аналитической фирмы ZapThink, которая специализируется в области XML, Web-сервисов и сервис-ориентированной архитектуры (СОА). Предмет их внимания в данном материале - проблемы, осложняющие внедрение СОА, и причины их возникновения.

Известный факт: начав проекты по внедрению СОА, многие организации обнаруживают, что это гораздо более трудная задача, чем казалось вначале.

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

• Настоящая функциональная совместимость еще во многом недоступна. Современное представление о СОА связано со слабыми взаимодействиями между гетерогенными системами, а также с основанной на стандартах функциональной совместимостью. В конце концов, функциональная совместимость различных программных продуктов и платформ составляет смысл web-сервисов. Но, несмотря на значительную работу, проделанную стандартизирующими организациями и Организацией по развитию возможности взаимодействия Web-сервисов (Web Services Interoperability Organization, сокр. WS-I ), многие компании жалуются, что по-прежнему существуют пусть небольшие, но существенные различия в применении даже самых основных стандартов web-сервисов - SOAP и WSDL. И если поставщики до сих пор не могут добиться функциональной совместимости даже этих стандартов, то что можно говорить о множестве других стандартов, которые сейчас разрабатываются. Для того чтобы обойти это препятствие, компании должны заставить своих поставщиков делать продукты, совместимые как минимум с самыми основными стандартами web-сервисов. А если поставщики не идут навстречу, то имеет смысл заменить их теми, кто лучше готов к сотрудничеству.
  
• Сравнительно немногие знают, как правильно составить контракт или разработать соответствующую политику. Как выясняется из опросов корпоративных архитекторов, большинство из них имеет очень небольшой опыт работы с так называемыми контрактами на обслуживание (Service contract) - основными документами метаданных, которые моделируют интерфейсы между провайдерами сервисов и потребителями. Несколько из опрошенных архитекторов внедрили основные контракты с помощью WSDL, но никто пока не вышел за пределы ограниченных рамок WSDL на дополнительные метаданные, задающие уровни сервисов, безопасность или другую информацию, необходимую для разработки политики. На деле выясняется, что очень немногие специалисты знают, как превратить политику, описываемую на обычном языке, в метаданные, "понимаемые" программными средствами. Развивающийся стандарт WS-Policy предусматривает контейнеры для хранения политик, но не может разработать саму политику. Однако даже этот стандарт пока используется очень мало.
  
• Компаниям недостает архитекторов, обладающих соответствующими навыками. Во многих корпорациях все еще плохо понимают дисциплину программной архитектуры. Эта ситуация осложняется тем фактом, что существует множество различных разновидностей архитектуры, но большинство архитекторов обычно работают лишь с одним или двумя из них. Для того чтобы быть настоящим специалистом по СОА, архитектор должен хорошо владеть корпоративной архитектурой, а также быть знакомым с технической и информационной архитектурой, архитектурой бизнес-процесов и архитектурой данных. Специалисты такой квалификации встречаются весьма нечасто. Организациям необходимо понимать, что в будущем архитектор будет гораздо более значимой фигурой, чем разработчик.
  
• Стандарты являются неполными, слишком ограниченными или плохо разработанными. Несколько органов, занимающихся стандартами, и их члены разработали детальные планы развития предлагаемых стандартов, в которые входят интеграция, управление, безопасность и т.д. Они достигли значительных успехов в создании стандартов на основе этих планов. Тем не менее, для получения полного согласованного списка стандартов, функционально совместимых с СОА, еще очень многое предстоит сделать. Но гораздо более важная проблема - это то, что некоторые стандарты слишком ограничены, и, более того, плохо разработаны. Например, стандарт WSDL ограничен, поскольку он не способен обеспечить требования к сервису или контрактные ограничения для пользователя сервиса. Среди плохо разработанных стандартов можно назвать UDDI и WS-BPEL. UDDI страдает от того, что при его создании в течение нескольких лет менялись приоритеты, а в WS-BPEL сочетаются две предыдущие спецификации, плохо подходящие друг к другу. Помимо этого, в WS-BPEL до сих пор нет возможностей для работы с документооборотом.
• Корпоративная политика. Во многих организациях отношения между направлениями деятельности компании и информационными технологиями (IT) в лучшем случае можно назвать напряженной, а в худшем - антагонистической. Слишком часто менеджмент рассматривает IT как рискованное и бесполезное вложение денег, ограничивающее возможности компании в достижении своих стратегических целей. В действительности, многие сотрудники IT-отделов признают, что история IT в их организациях связана с превышением бюджетов, неуспешными проектами и разнообразной деятельностью, которая никак не способствовала практическим результатам. Тем не менее, глубоко укоренившееся недоверие между бизнесом и IT загоняет любой проект СОА в "политическое болото", поскольку руководители IT должны приводить аргументы в пользу мощного, но пока труднообъяснимого архитектурного подхода, который все еще находится в процессе развития и поэтому может включать скрытые риски. Компании, внедряющие СОА, должны стараться снизить это напряжение, демонстрируя, какие последовательные бизнес-преимущеста это может дать уже на ранних стадиях. IT-персоналу необходимо работать оперативно, осуществлять внедрение последовательно, шаг за шагом, и обеспечивать, чтобы СОА реально увеличивала ценность бизнеса. Тогда менеджеры не будут чинить препятствия дальнейшему прогрессу в этом направлении.
  
• Выбор продуктов либо слишком фрагментирован, либо излишне направлен на интеграцию. Создание СОА не может быть решено путем приобретения какого-то одного программного продукта или технического устройства, но любой проект СОА потребует появления новых продуктов для обеспечения возникающих потребностей. Хотя многие компании используют специализированные продукты СОА, проблема состоит в том, что для получения требуемых возможностей необходимо объединить несколько различных продуктов от разнообразных поставщиков. А эти поставщики все еще пытаются добиться функциональная совместимость, как уже указывалось выше. Выход из такой ситуации обеспечивают крупные поставщики, которые пытаются создать комплексные предложения для СОА. Но на деле эти поставщики занимаются обновлением старых продуктов, относящихся к классу интеграционного связующего программного обеспечения, переделывая их применительно к новой роли инфраструктуры СОА, независимо от того, насколько они действительно подходят для этого. Со временем рынок решений СОА будет все больше консолидироваться. Те компании, которые начинали с планирования архитектуры, а лишь потом подбирали продукты, окажутся в более выигрышной ситуации и смогут легче развивать СОА.
  
• Скептицизм, эгоизм и упрямство. Человеку свойственно сопротивляться переменам. Хотя надо реально представлять ограничения и проблемы СОА, в любой организации найдутся слишком подозрительные сотрудники, чей скептицизм переходит разумные границы и превращается в излишние эмоции относительно выбора платформы, пристрастного обсуждения поставщиков или персональных предпочтений. Более того, слишком многие будут сопротивляться внедрению новых подходов, и не потому, что они действительно видят какие-то недостатки, а лишь поскольку их удовлетворяют те возможности, которые уже есть, и им не хочется учиться чему-то новому. Другие рассматривают сферу своего влияния как некое "феодальное владение", и когда кто-то за пределами их группы начинает разговоры об общих сервисах или федеративной политике, они начинают защищать свою территорию. Компании, желающие последовательно развивать проекты СОА, должны выявлять не только лидеров, которые будут этому способствовать, но и противников, старающихся остановить осуществление любых начинаний, которые могут угрожать их интересам.

Заключение

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

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

Автор: По материалам зарубежных сайтов