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

Кому и зачем нужно быть гибкими

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

Почему гибкость бизнес-процессов стала столь востребованной? Ведь еще совсем недавно ничего подобного в России не наблюдалось. Выделим две основные причины.

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

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

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

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

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

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

Одним из способов решения этой проблемы является использование SOA, она дает возможность существенно упростить структуру корпоративной информационной системы и сформировать ее таким образом, чтобы она была подобна структуре бизнеса, а ее элементы были элементами ИТ-поддержки бизнес-процессов.

Состав и порядок реализации SOA-проекта

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

Подготовительный этап

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

Первичное определение целей и приоритетов процесса перехода к SOA

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

Обеспечение перехода к SOA

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

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

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

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

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

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

Разработка и внедрение

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

Обоснование проекта

Подготовительный этап имеет самостоятельную ценность для бизнеса и должен иметь отдельное обоснование. Обстоятельства могут сложиться так, что его завершение станет завершением всего проекта. В ряде случаев инвестиции в SOA могут себя не оправдать, например, в условиях устоявшегося бизнеса с относительно стабильной структурой бизнес-процессов. Кроме того, можно ограничиться локальными изменениями, например, только интеграцией данных, а реализацию SOA отложить. Если же бизнес и ИТ-руководство в результате подготовительного этапа осознали, что проект внедрения SOA необходим, то следует сделать полноценное обоснование проекта, но с детализацией только для «пилотной зоны».

На этом этапе проводится анализ необходимости внедрения SOA в компании, выявление и детализация конкретных преимуществ, которые обеспечит SOA. Кроме того, на данном этапе фактически идет сближение позиций ИТ-подразделения и бизнес-подразделений компании. Без поддержки бизнеса эффективно внедрить SОA не удастся, так как именно бизнес формулирует требования к ИТ-поддержке. В результате появляется документ «Обоснование необходимости проекта SOA в компании», который должен быть утвержден ИТ-руководителем и руководством бизнеса компании. Обоснование может состоять из нескольких частей (соответствующих своим подпроектам), а результаты должны отражать общую стратегию развития компании и ее цели. Обосновать внедрение SOA экономически бывает чрезвычайно сложно. С одной стороны, для этого нужно сравнить затраты на ИТ-поддержку бизнес-процессов «до внедрения SOA» и «после внедрения SOA». С другой стороны, именно SOA существенно облегчает оценку затрат на ИТ-поддержку каждого бизнес-процесса и управление этими затратами. На практике эффективнее обосновывать затраты на внедрение SOA либо с точки зрения повышения управляемости и прозрачности ИТ-поддержки бизнеса, либо с точки зрения ускорения и снижения рисков проведения изменений в организации. Удачным моментом для реализации SOA является поставленная бизнесом перед ИТ задача по внедрению новой услуги, предусматривающая интеграцию купленной новой информационной системы с существующими. От затрат на интеграцию здесь не уйти, так почему бы не использовать SOA?

Оценка имеющихся технологий

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

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

Реализация пилотного проекта

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

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

Сервис-ориентированная интеграция функций бизнеса. На этом этапе благодаря уже выявленным и сформированным сервисам происходит перестроение ИТ-поддержки бизнес-процессов на основе комбинирования сервисов. Это позволяет реализовать несколько видов собственно интеграции.

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

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

Интеграция ИТ-поддержки процессов — организация ИТ- поддержки сквозных бизнес-процессов на базе использования сервисов.

Развертывание проекта во всей компании

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

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

Мероприятия, способствующие успешной реализации SOA-проекта

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

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

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

Результаты реализации

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

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

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

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

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

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

Уменьшается стоимость внедрения новых или замены старых сервисов. Согласно статистике внедрения крупных корпоративных информационных систем, примерно 30% затрат приходится на обследование существующих информационных систем и еще 30% — на интеграцию новой системы. Поскольку интеграция приложений больше не нужна, а все сервисы описаны и упорядочены, экономится до 60% затрат на внедрение новой информационной системы при условии, что она имеет интерфейс к шине интеграции сервисов предприятия. Если интерфейс отсутствует, то есть возможность его разработать.

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

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

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

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

SOA — не панацея

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

  • увеличивающиеся темпы роста и размах глобального бизнеса, появление действительно гигантских глобальных корпораций;
  • формирование новых глобальных отраслевых структур;
  • возникновение взаимосвязанных «экосистем», объединяющих поставщиков, производителей и потребителей, и размывающих границы компаний.

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

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

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

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

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

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

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

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

Руслан Демидов — заместитель генерального директора компании BCC-Москва , rdemidov@bcc.ru

Ключевыеa положения SOA

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

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

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

Динамика ИТ-затрат

Согласно проведенному в 2006 году экспертами ЛИНЭКС анализу ИТ-рынка России, наряду с общим снижением темпов годового роста объема российского ИТ-рынка с 35,7% в 2002—2001 гг. до 19,1% в 2006—2005 гг., за этот же период наблюдается тенденция устойчивого роста расходов на собственный ИТ-персонал. Например, темп прироста затрат на собственный ИT-персонал вырос с 2,7% в 2002—2001 гг. до 13,6% в 2006—2005 гг. Прогнозируется, что в 2007-м рост этого показателя по отношению к 2006-му составит порядка 20%. При этом общая доля затрат на ИТ в разных отраслях неодинаковая, но находится в пределах 4—8% от оборота компании и доходит до 50% от объема капитальных затрат.