Почему внедрение сервис-ориентированной архитектуры требует много времени
Известный факт: приступив к проекту по внедрению SOA, многие организации обнаруживают, что это гораздо более трудная задача, чем казалось вначале.
На современной стадии развития рынка многие ИТ-cпециалисты в организациях уже понимают, что такое SOA и для чего она необходима. Но по-прежнему нет единого мнения относительно того, как нужно осуществлять ее внедрение, чтобы это дало выгоду для бизнеса и обеспечило успешное функционирование SOA в течение многих лет.
Но некоторые фирмы обнаруживают, что определенное сочетание организационных, технологических или архитектурных проблем приводит к стагнации проекта по внедрению SOA. В других компаниях руководство не проявляет необходимой настойчивости и желания, чтобы проект вышел за рамки пилотной фазы. В целом существует несколько существенных препятствий, которые затрудняют успешное развитие проектов по внедрению SOA. Ниже приведены самые значимые из них.
Настоящая функциональная совместимость еще во многом недоступна. Современное представление о SOA связано со слабыми взаимодействиями между гетерогенными системами, а также с основанной на стандартах функциональной совместимостью.
В конце концов, функциональная совместимость различных программных продуктов и платформ составляет смысл web-сервисов. Но, несмотря на значительную работу, проделанную стандартизирующими организациями и Организацией по развитию возможности взаимодействия Web-сервисов (Web Services Interoperabiity Organization, сокр. WS-I ), многие компании жалуются, что по-прежнему существуют пусть небольшие, но существенные различия в применении даже самых основных стандартов web-сервисов – SOAP/WSDL. И если поставщики до сих пор не могут добиться функциональной совместимости даже этих стандартов, то что можно говорить о множестве других стандартов, которые сейчас разрабатываются. Для того чтобы обойти это препятствие, компании должны заставить своих поставщиков делать продукты, совместимые как минимум с самыми основными стандартами web-сервисов. А если поставщики не идут навстречу, то имеет смысл заменить их теми, кто лучше готов к сотрудничеству.
Сравнительно немногие знают, как правильно составить контракт или разработать соответствующую политику. Как выясняется из опросов корпоративных архитекторов, большинство из них имеет очень небольшой опыт работы с так называемыми контрактами на обслуживание (Service contract) - основными документами метаданных, которые моделируют интерфейсы между провайдерами сервисов и потребителями. Несколько из опрошенных архитекторов внедрили основные контракты с помощью WSDL, но никто пока не вышел за пределы ограниченных рамок WSDL на дополнительные метаданные, задающие уровни сервисов, безопасность или другую информацию, необходимую для разработки политики. На деле выясняется, что очень немногие специалисты знают, как превратить политику, описываемую на обычном языке, в метаданные, "понимаемые" программными средствами. Развивающийся стандарт WS-Policy предусматривает контейнеры для хранения политик, но не может разработать саму политику. Однако даже этот стандарт пока используется очень мало.
Компаниям недостает архитекторов, обладающих соответствующими навыками. Во многих корпорациях все еще плохо понимают дисциплину программной архитектуры. Эта ситуация осложняется тем фактом, что существует множество различных разновидностей архитектуры, но большинство архитекторов обычно работают лишь с одним или двумя из них. Для того чтобы быть настоящим специалистом по SOA, архитектор должен хорошо владеть корпоративной архитектурой, а также быть знакомым с технической и информационной архитектурой, архитектурой бизнес-процесов и архитектурой данных. Специалисты такой квалификации встречаются весьма нечасто. Организациям необходимо понимать, что в будущем архитектор будет гораздо более значимой фигурой, чем разработчик.
Стандарты являются неполными, слишком ограниченными или плохо разработанными. Несколько органов, занимающихся стандартами, и их члены разработали детальные планы развития предлагаемых стандартов, в которые входят интеграция, управление, безопасность и т.д. Они достигли значительных успехов в создании стандартов на основе этих планов. Тем не менее, для получения полного согласованного списка стандартов, функционально совместимых с SOA, еще очень многое предстоит сделать. Но гораздо более важная проблема - это то, что некоторые стандарты слишком ограничены, и, более того, плохо разработаны. Например, стандарт WSDL ограничен, поскольку он не способен обеспечить требования к сервису или контрактные ограничения для пользователя сервиса. Среди плохо разработанных стандартов можно назвать UDDI и WS-BPEL. UDDI страдает от того, что при его создании в течение нескольких лет менялись приоритеты, а в WS-BPEL сочетаются две предыдущие спецификации, плохо подходящие друг к другу. Помимо этого, в WS-BPEL до сих пор нет возможностей для работы с документооборотом.
Корпоративная политика. Во многих организациях отношения между направлениями деятельности компании и информационными технологиями в лучшем случае можно назвать напряженной, а в худшем - антагонистической. Слишком часто менеджмент рассматривает ИТ как рискованное и бесполезное вложение денег, ограничивающее возможности компании в достижении своих стратегических целей.
В действительности, многие сотрудники ИТ-отделов признают, что история ИТ в их организациях связана с превышением бюджетов, неуспешными проектами и разнообразной деятельностью, которая никак не способствовала практическим результатам. Тем не менее, глубоко укоренившееся недоверие между бизнесом и ИТ загоняет любой проект SOA в "политическое болото", поскольку руководители ИТ должны приводить аргументы в пользу мощного, но пока труднообъяснимого архитектурного подхода, который все еще находится в процессе развития и поэтому может включать скрытые риски. Компании, внедряющие SOA, должны стараться снизить это напряжение, демонстрируя, какие последовательные бизнес преимущества это может дать уже на ранних стадиях. ИТ-сотрудникам необходимо работать оперативно, осуществлять внедрение последовательно, шаг за шагом, и обеспечивать, чтобы SOA реально увеличивала ценность бизнеса. Тогда менеджеры не будут чинить препятствия дальнейшему прогрессу в этом направлении.
Выбор продуктов либо слишком фрагментирован, либо излишне направлен на интеграцию. Создание SOA не может быть решено путем приобретения какого-то одного программного продукта или технического устройства, но любой проект SOA потребует появления новых продуктов для обеспечения возникающих потребностей. Хотя многие компании используют специализированные продукты SOA, проблема состоит в том, что для получения требуемых возможностей необходимо объединить несколько различных продуктов от разнообразных поставщиков. А эти поставщики все еще пытаются добиться функциональная совместимость, как уже указывалось выше. Выход из такой ситуации обеспечивают крупные поставщики, которые пытаются создать комплексные предложения для SOA. Но на деле эти поставщики занимаются обновлением старых продуктов, относящихся к классу интеграционного связующего программного обеспечения, переделывая их применительно к новой роли инфраструктуры SOA, независимо от того, насколько они действительно подходят для этого. Со временем рынок решений SOA будет все больше консолидироваться. Те компании, которые начинали с планирования архитектуры, а лишь потом подбирали продукты, окажутся в более выигрышной ситуации и смогут легче развивать SOA.
Скептицизм, эгоизм и упрямство. Человеку свойственно сопротивляться переменам. Хотя надо реально представлять ограничения и проблемы SOA, в любой организации найдутся слишком подозрительные сотрудники, чей скептицизм переходит разумные границы и превращается в излишние эмоции относительно выбора платформы, пристрастного обсуждения поставщиков или персональных предпочтений.
Более того, слишком многие будут сопротивляться внедрению новых подходов, и не потому, что они действительно видят какие-то недостатки, а лишь поскольку их удовлетворяют те возможности, которые уже есть, и им не хочется учиться чему-то новому. Другие рассматривают сферу своего влияния как некое "феодальное владение", и когда кто-то за пределами их группы начинает разговоры об общих сервисах или федеративной политике, они начинают защищать свою территорию. Компании, желающие последовательно развивать проекты SOA, должны выявлять не только лидеров, которые будут этому способствовать, но и противников, старающихся остановить осуществление любых начинаний, которые могут угрожать их интересам.
Хотя препятствия, перечисленные выше, достаточно серьезны, все они преодолимы, если действовать последовательно. SOA требует итеративного подхода: не только потому, что требования постоянно меняются, но также поскольку на пути к успешному внедрению SOA в корпорации находится много "подводных камней", как было продемонстрировано выше.
Если архитекторы медленно работают, то им нужен дополнительный тренинг. Если стандарты недостаточно развиты, то их можно улучшать. Упрямцев и эгоистов можно убеждать или переназначать на другие должности. Если поставщики отделываются туманными объяснениями, на них можно "надавить" или заменить их. Ни одна из этих проблем не может препятствовать тому, чтобы сделать первый шаг к созданию на высшем уровне плана по внедрению SOA или собрать воедино несколько слабо связанных сервисов. Проблемы способны замедлить процесс создания SOA, но для большинства организаций преимущества SOA перевесят недостатки. Успех проекта SOA определяется терпением, настойчивостью и готовностью познавать новое.
На современной стадии развития рынка многие ИТ-cпециалисты в организациях уже понимают, что такое SOA и для чего она необходима. Но по-прежнему нет единого мнения относительно того, как нужно осуществлять ее внедрение, чтобы это дало выгоду для бизнеса и обеспечило успешное функционирование SOA в течение многих лет.
Но некоторые фирмы обнаруживают, что определенное сочетание организационных, технологических или архитектурных проблем приводит к стагнации проекта по внедрению SOA. В других компаниях руководство не проявляет необходимой настойчивости и желания, чтобы проект вышел за рамки пилотной фазы. В целом существует несколько существенных препятствий, которые затрудняют успешное развитие проектов по внедрению SOA. Ниже приведены самые значимые из них.
Настоящая функциональная совместимость еще во многом недоступна. Современное представление о SOA связано со слабыми взаимодействиями между гетерогенными системами, а также с основанной на стандартах функциональной совместимостью.
В конце концов, функциональная совместимость различных программных продуктов и платформ составляет смысл web-сервисов. Но, несмотря на значительную работу, проделанную стандартизирующими организациями и Организацией по развитию возможности взаимодействия Web-сервисов (Web Services Interoperabiity Organization, сокр. WS-I ), многие компании жалуются, что по-прежнему существуют пусть небольшие, но существенные различия в применении даже самых основных стандартов web-сервисов – SOAP/WSDL. И если поставщики до сих пор не могут добиться функциональной совместимости даже этих стандартов, то что можно говорить о множестве других стандартов, которые сейчас разрабатываются. Для того чтобы обойти это препятствие, компании должны заставить своих поставщиков делать продукты, совместимые как минимум с самыми основными стандартами web-сервисов. А если поставщики не идут навстречу, то имеет смысл заменить их теми, кто лучше готов к сотрудничеству.
Сравнительно немногие знают, как правильно составить контракт или разработать соответствующую политику. Как выясняется из опросов корпоративных архитекторов, большинство из них имеет очень небольшой опыт работы с так называемыми контрактами на обслуживание (Service contract) - основными документами метаданных, которые моделируют интерфейсы между провайдерами сервисов и потребителями. Несколько из опрошенных архитекторов внедрили основные контракты с помощью WSDL, но никто пока не вышел за пределы ограниченных рамок WSDL на дополнительные метаданные, задающие уровни сервисов, безопасность или другую информацию, необходимую для разработки политики. На деле выясняется, что очень немногие специалисты знают, как превратить политику, описываемую на обычном языке, в метаданные, "понимаемые" программными средствами. Развивающийся стандарт WS-Policy предусматривает контейнеры для хранения политик, но не может разработать саму политику. Однако даже этот стандарт пока используется очень мало.
Компаниям недостает архитекторов, обладающих соответствующими навыками. Во многих корпорациях все еще плохо понимают дисциплину программной архитектуры. Эта ситуация осложняется тем фактом, что существует множество различных разновидностей архитектуры, но большинство архитекторов обычно работают лишь с одним или двумя из них. Для того чтобы быть настоящим специалистом по SOA, архитектор должен хорошо владеть корпоративной архитектурой, а также быть знакомым с технической и информационной архитектурой, архитектурой бизнес-процесов и архитектурой данных. Специалисты такой квалификации встречаются весьма нечасто. Организациям необходимо понимать, что в будущем архитектор будет гораздо более значимой фигурой, чем разработчик.
Стандарты являются неполными, слишком ограниченными или плохо разработанными. Несколько органов, занимающихся стандартами, и их члены разработали детальные планы развития предлагаемых стандартов, в которые входят интеграция, управление, безопасность и т.д. Они достигли значительных успехов в создании стандартов на основе этих планов. Тем не менее, для получения полного согласованного списка стандартов, функционально совместимых с SOA, еще очень многое предстоит сделать. Но гораздо более важная проблема - это то, что некоторые стандарты слишком ограничены, и, более того, плохо разработаны. Например, стандарт WSDL ограничен, поскольку он не способен обеспечить требования к сервису или контрактные ограничения для пользователя сервиса. Среди плохо разработанных стандартов можно назвать UDDI и WS-BPEL. UDDI страдает от того, что при его создании в течение нескольких лет менялись приоритеты, а в WS-BPEL сочетаются две предыдущие спецификации, плохо подходящие друг к другу. Помимо этого, в WS-BPEL до сих пор нет возможностей для работы с документооборотом.
Корпоративная политика. Во многих организациях отношения между направлениями деятельности компании и информационными технологиями в лучшем случае можно назвать напряженной, а в худшем - антагонистической. Слишком часто менеджмент рассматривает ИТ как рискованное и бесполезное вложение денег, ограничивающее возможности компании в достижении своих стратегических целей.
В действительности, многие сотрудники ИТ-отделов признают, что история ИТ в их организациях связана с превышением бюджетов, неуспешными проектами и разнообразной деятельностью, которая никак не способствовала практическим результатам. Тем не менее, глубоко укоренившееся недоверие между бизнесом и ИТ загоняет любой проект SOA в "политическое болото", поскольку руководители ИТ должны приводить аргументы в пользу мощного, но пока труднообъяснимого архитектурного подхода, который все еще находится в процессе развития и поэтому может включать скрытые риски. Компании, внедряющие SOA, должны стараться снизить это напряжение, демонстрируя, какие последовательные бизнес преимущества это может дать уже на ранних стадиях. ИТ-сотрудникам необходимо работать оперативно, осуществлять внедрение последовательно, шаг за шагом, и обеспечивать, чтобы SOA реально увеличивала ценность бизнеса. Тогда менеджеры не будут чинить препятствия дальнейшему прогрессу в этом направлении.
Выбор продуктов либо слишком фрагментирован, либо излишне направлен на интеграцию. Создание SOA не может быть решено путем приобретения какого-то одного программного продукта или технического устройства, но любой проект SOA потребует появления новых продуктов для обеспечения возникающих потребностей. Хотя многие компании используют специализированные продукты SOA, проблема состоит в том, что для получения требуемых возможностей необходимо объединить несколько различных продуктов от разнообразных поставщиков. А эти поставщики все еще пытаются добиться функциональная совместимость, как уже указывалось выше. Выход из такой ситуации обеспечивают крупные поставщики, которые пытаются создать комплексные предложения для SOA. Но на деле эти поставщики занимаются обновлением старых продуктов, относящихся к классу интеграционного связующего программного обеспечения, переделывая их применительно к новой роли инфраструктуры SOA, независимо от того, насколько они действительно подходят для этого. Со временем рынок решений SOA будет все больше консолидироваться. Те компании, которые начинали с планирования архитектуры, а лишь потом подбирали продукты, окажутся в более выигрышной ситуации и смогут легче развивать SOA.
Скептицизм, эгоизм и упрямство. Человеку свойственно сопротивляться переменам. Хотя надо реально представлять ограничения и проблемы SOA, в любой организации найдутся слишком подозрительные сотрудники, чей скептицизм переходит разумные границы и превращается в излишние эмоции относительно выбора платформы, пристрастного обсуждения поставщиков или персональных предпочтений.
Более того, слишком многие будут сопротивляться внедрению новых подходов, и не потому, что они действительно видят какие-то недостатки, а лишь поскольку их удовлетворяют те возможности, которые уже есть, и им не хочется учиться чему-то новому. Другие рассматривают сферу своего влияния как некое "феодальное владение", и когда кто-то за пределами их группы начинает разговоры об общих сервисах или федеративной политике, они начинают защищать свою территорию. Компании, желающие последовательно развивать проекты SOA, должны выявлять не только лидеров, которые будут этому способствовать, но и противников, старающихся остановить осуществление любых начинаний, которые могут угрожать их интересам.
Заключение
Хотя препятствия, перечисленные выше, достаточно серьезны, все они преодолимы, если действовать последовательно. SOA требует итеративного подхода: не только потому, что требования постоянно меняются, но также поскольку на пути к успешному внедрению SOA в корпорации находится много "подводных камней", как было продемонстрировано выше.
Если архитекторы медленно работают, то им нужен дополнительный тренинг. Если стандарты недостаточно развиты, то их можно улучшать. Упрямцев и эгоистов можно убеждать или переназначать на другие должности. Если поставщики отделываются туманными объяснениями, на них можно "надавить" или заменить их. Ни одна из этих проблем не может препятствовать тому, чтобы сделать первый шаг к созданию на высшем уровне плана по внедрению SOA или собрать воедино несколько слабо связанных сервисов. Проблемы способны замедлить процесс создания SOA, но для большинства организаций преимущества SOA перевесят недостатки. Успех проекта SOA определяется терпением, настойчивостью и готовностью познавать новое.
© Галактика, 2005
© Издание 12NEWS (ИП Маринин А.Л.), 2005
