Как не запутаться в SOA?

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

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

Компании, начинающие внедрять SOA, должны отдавать себе отчет в том, что это весьма длительный процесс. Полное завершение проекта может занять около 15 лет, хотя первые преимущества SOA станут заметны уже в течение 6 месяцев, когда приложения будут интегрированы. Однако SOA – это гораздо шире, чем просто интеграция приложений. Сервисно-ориентированный подход предполагает исключение дублирующихся процессов и функций, настройка репликации, максимальное объединение всего, что может быть объединено для всех систем. После этого интеграция как таковая, то есть построение связей, уже не нужна.

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

Еще один ключевой момент – выбор исполнителя. Не столь важно, какой подход к SOA выбран при внедрении – от Oracle, SAP, IBM, Microsoft, или даже все вместе. Главное - найти того, кто все это реализует. Выбор должен основываться не только на изучении программных продуктов и услуг, предоставляемых поставщиками. Исполнитель должен доказать, что сможет поддерживать компанию на протяжении всего проекта и в полном объеме, включая как технологическую часть, так и ПО и даже оборудование.

Витрина данных НОТА ВИЗОР для налогового мониторинга

Грег Котичиа (Greg Coticchia), CEO компании LogicLibrary, сформулировал семь принципов успешного внедрения SOA, основанных на пятилетнем опыте компании LogicLibrary.

1. Не стоит пытаться «вскипятить океан», иными словами – объять необъятное.
Думать следует масштабно, однако начинать лучше со скромных небольших проектов. Идеально, если в проект вовлечены представители трех лагерей – разработчик архитектуры, руководитель проекта внедрения и специалист в конкретной области бизнеса. Главная цель первого проекта - продемонстрировать очевидные преимущества SOA. Например, можно переработать небольшой набор бизнес-процессов, повысив их гибкость и оперативность. При этом следует четко отследить, замерить и зафиксировать время выполнения этих процессов до и после внедрения SOA.

2. Соотносите ваши желания и ваши технические возможности.
Проясните для себя, в какой области лучше всего задействовать новые сервисы, кто будет их использовать, кто будет ими управлять. Можно модифицировать 10 из 20 узко-специализированных сервисов, это будет красиво, но хлопотно и малополезно. Следует сосредоточиться на обеспечении гибкости бизнеса и не выходить за рамки реальных технических условий. Убедитесь, что ваши наработки четко регистрируются и надежно хранятся, что масштаб проекта соответствует вашим требованиям. Вы должны иметь возможность понимать, наблюдать, оценивать и управлять как теми, кто создает ваши сервисы, так и теми, кто ими пользуется. Убедитесь, что процесс разработки и создаваемая архитектура обеспечат вам эти возможности.

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

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

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

5. Не упирайтесь в стандарты.
Стандарты можно обсуждать бесконечно, так как их создано великое множество. Большинство пользуется стандартами XML и SOAP, а применение остальных зависит от конкретной задачи. Распространен также стандарт для веб-сервисов UDDI, однако его использование приведет к тому, что вы будете заниматься в основном веб-сервисами, а это неправильно (см. п. 4)

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

7. Семь раз отмерь, один раз отрежь. Или хотя бы просто не забудь отмерить.
Ключевым пунктом внедрения SOA является измерение. Вы должны управлять сервисами, знать, кто их разработал, сколько их, где и кем они используются, для чего и как. Вы должны держать все это под четким контролем. Даже небольшое число внедренных сервисов может доставить много проблем без достаточного руководства на этапе их разработки и использования.

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

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

Где и когда SOA пригодится уже сейчас? На этот вопрос можно ответить двояко. Если говорить о принятой той или иной компанией стратегии развития информационной системы, эти технологии сегодня будут полезны либо при необходимости сохранения части унаследованных систем с переходом на новый уровень технологий, либо при ориентации на использование решений «best-of-breed». В первом случае SOA даст возможность сохранить ценные для бизнеса собственные наработки, но при этом обеспечит компании единое информационное пространство и использование современных технологий. Во втором же случае компания сможет обеспечить свою независимость от вендоров «тяжёлых» систем, поставляющих «всё в одном», и гарантировать своей информационной системе максимальную гибкость.

С другой стороны, можно говорить о соответствии использования SOA потребностям бизнеса. С этих позиций можно посоветовать задуматься об использовании этих технологий тем компаниям, которые активно используют функциональность ERPII. Если для них критично использование SCM, SRM и CRM, а также B2B, скорее всего, переход на SOA положительно на них отразится, а, может быть, и вообще станет неизбежным способом повысить свою эффективность.

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