Сервис-ориентированная архитектура (SOA) «за» и «против. Технологическая архитектура, стандарты и шаблоны

Сервис-ориентированная архитектура (SOA) — настоящей статье рассматриваются способы обоснования эффективности, а также варианты ее внедрения с минимальными затратами.

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

Эффект от оптимизации процессов управления информационными технологиями для бизнеса незначителен: если затраты на ИТ были сокращены на 5%, а в общей сумме затрат компании они составляют всего 2%, то суммарный эффект от оптимизации — 0,1%. Достигнутые результаты не приносят ожидаемого эффекта на уровне бизнеса, поэтому энтузиазм ИТ-специалистов часто сопровождается разочарованием.

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

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

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

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

Для расчета ROI указанные преимущества необходимо оцифровать соответствующими показателями и отслеживать через них по ходу проекта экономическую эффективность применения SOA. Следовательно, внедряя SOA, важно анализировать получаемые преимущества уже на первых шагах, что и поможет получить одобрение и финансирование от бизнеса.
По прогнозу экспертов Aberdeen Group, в течение пяти лет крупнейшие мировые компании ожидают экономии до 53 трлн долл. за счет внедрения SOA.

Сервис-ориентированная архитектура — тактика внедрения

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

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

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

Сервис-ориентированная архитектура — стратегия внедрения

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

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

Система мотивации должна предусматривать следующие основные принципы:

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

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

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

Сервис-ориентированная архитектура и технологии BPM, ESB

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

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

Далее при внедрении SOA потребуется инструментарий SOA Governance — библиотека унифицированных сервисов, которая обеспечит общий доступ к компонентам композитной среды для их повторного использования. SOA также должна поддерживаться определенным интеграционным инструментарием (Enterprise Service Bus, ESB), предназначенным для интеграции разнородных ИТ-ресурсов и рационализации обмена данными с помощью сервисной шины. И хотя в принципе SOA может быть построена без ESB, по мнению большинства аналитиков, именно интеграционная шина служит ключевым решением для сервис-ориентированной архитектуры.

А.Коптелов
Руководитель практики внедрения бизнес-приложений IDS Scheer Россия и страны СНГ

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

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

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

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

Мировой рынок SOA

Российский рынок SOA

Развитие SOA

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

Своего рода предшественницей SOA стала технология Enterprise Service Bus , предоставлявшая унифицированный механизм взаимодействия приложений. Дополненная рядом других технологий, ESB позволила сформировать единую интеграционную платформу. По-видимому, качественный переход к SOA начался в тот момент, когда появилась возможность создавать поверх этого интеграционного слоя новые прикладные решения с использованием уже существующего функционала.

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

Сервисно-ориентированное и объектно-ориентированное программирование

Появление сервисно-ориентированного подхода произвело очередную реформу в теории разработки программного обеспечения, оставив в прошлом концепцию объектно-ориентированного программирования .

Как известно, повторное использование программного кода упрощает разработку больших информационных систем. До недавнего времени с этой целью традиционно применялся объектно-ориентированный подход, подразумевающий жёсткое объединение компонентов и объектов приложения в одно целое. В парадигме ООП от разработчика требуется знание прикладного программного интерфейса, в котором объединены атрибуты и методы, сообща реализующие необходимый функционал. Но поскольку объектные системы обычно создаются на основе какого-то одного языка программирования (Delphi , C Яык программирования++ , C Яык программирования# , Java и др.) и фиксированных механизмов обмена информацией между объектами и модулями информационной системы, то и в ООП сохраняются все зависимости и ограничения. Такой подход удобен не всегда - в частности, он не позволяет оперативно реагировать на изменение ситуации и, к примеру, проектировать новомодные системы, опирающиеся на концепцию «ресурсы по требованию». Кроме того, для модификации объектных систем нередко приходится переписывать коды связанных объектов и методов.

Cвести эти ограничения к минимуму позволяет технология SOA, которая многими уже признана как революция в технологии программирования.

Аналитики о сервисно-ориентированной архитектуре

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

Архитектурные особенности SOA

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

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

Архитектура веб-сервисов также является сервисно-ориентированной. Более того, веб-сервисы - это суть SOA c двумя дополнительными ограничениями: интерфейсы базируются на интернет-протоколах (HTTP , FTP , SMTP Simple Mail Transfer Protocol - Простой протокол передачи почты , TCP), а все сообщения описываются в формате XML . Детальные описания стандарта веб-сервисов и спецификаций SOA приводятся на сайтах консорциума W3C и организации OASIS .

Практические аспекты применения SOA

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

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

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

Вот шесть механизмов, с помощью которых поддерживается SOA-политика:

Операционная модель жизненного цикла SOA
Организация SOA
SOA-процесс
Портфель активов для сервисной интеграции в SOA
Инструментарий SOA
SOA-технологии

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

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

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

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

Архитектура предприятия

Зачастую сформированные требования к КИС изменяются еще до того, как она будет развернута. Как обеспечить требуемую гибкость? Один из возможных подходов (ключевой для SOA ) состоит в использовании типовых ИТ-сервисов.

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

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

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

Основные принципы SOA

Многие отождествляют SOA c Web-сервисами или workflow-системами, но это не так. SOA - не набор технологий, а прежде всего процессно-ориентированная архитектура ИС. Можно определить SOA следующим образом: это архитектура приложений, построенная на основе формализованных бизнес-процессов , функции которых представлены в виде многократно используемых сервисов с прозрачными описанными интерфейсами.

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

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

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

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

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

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

Преимущества и сложности подхода SOA

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

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

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

Для унификации описания процессов все чаще используется Business Process Executive Languages (BPEL) - язык исполнения бизнес-процессов, и его место в SOA очень важно, поскольку такое описание является необходимым условием для внедрения SOA. При этом оно должно быть понятным как владельцам бизнес-процессов, так и информационным системам. В данном случае использование нотации eEPC (событийной цепочки управления бизнес-процессом) для уровня бизнеса с последующей трансформацией полученных моделей в BPEL позволяет минимизировать затраты на формализацию процессов и их автоматизацию. На основании языка BPEL система автоматизации будет вызывать требуемые описанные сервисы, чтобы передать им необходимую для выполнения информацию.

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

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

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

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

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

Заключение

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

Первые шаги к SOA

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

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

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

Уже несколько лет в России, как и во всем мире, обсуждаются вопросы, связанные с применением принципов сервис-ориентированной архитектуры (Service Oriented Architecture, SOA). Многие производители информационных систем уже заявили о поддержке принципов SOA, но реализация этих принципов на практике пока ограничивается единичными случаями. Мы рассмотрим предпосылки появления SOA и основные требования, которые должна выполнить компания, чтобы успешно применять концепцию SOA в своей практике.

«Проблема в том, что в аббревиатуре SOA люди больше обращают внимание на «service oriented», нежели на «architecture». Однако именно архитектура и дисциплина могут помочь SOA принести реальный результат».

Джеймс Гавернор (James Governor), ведущий аналитик, компания Redmonk

Термин SOA пока что несет на себе сильный маркетинговый отпечаток, а для самого понятия SOA на сегодняшний день все еще существуют различные трактовки. Многие отождествляют SOA с технологией Web-сервисов или определенными информационными системами, например, системами для управления бизнес-процессами (Business Process Management, BPM). Но SOA — это не коробочный продукт или технология, а идеология информатизации бизнеса, основанная на процессном подходе и методологии управления бизнес-процессами BPM.

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

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

Принципы SOA

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

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

Аналогичная ситуация складывается сейчас с информационными решениями. Многие уже поняли на своем опыте, что монолитные системы (ERP, CRM, SCM и т. д.) обладают двумя врожденными пороками: ограниченной гибкостью (не всегда позволяют внести требуемые изменения в необходимые сроки) и высокой стоимостью владения и внесения изменений. Эти два фактора критичны для современных компаний, работающих в высококонкурентном и динамичном мире, что заставляет их уделять пристальное внимание оптимизации в данной области.

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

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

Оценив сложившуюся маркетинговую ситуацию и потенциал SOA для бизнеса, ведущие поставщики информационных систем поспешили заявить о своей готовности к SOA. Не отставали здесь ни пресса, ни аналитики. Если вспомнить начало кампании в 2005 г., то все единодушно говорили о большом потенциале SOA, и как следствие в 2006-2007 гг. было начато множество пилотных проектов SOA. Затем появилась информация о первых результатах, первых трудностях и неудачах. Темпы развития рынка SOA оказались не столь высоки, как ожидалось. По данным аналитиков, 90% компаний, запустивших пилотные проекты, завязли в них.

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

Цели и средства внедрения SOA

Изначально при внедрении SOA ставятся следующие цели:

сокращение времени адаптации сложных информационных систем к постоянно изменяющимся бизнес-процессам компании;
снижение стоимости владения ИТ (Total Cost of Ownership, TCO) в масштабе времени — за счет сокращения затрат на проектирование, внедрение, документирование, внесение изменений и т. п.;
систематизация компонентов ИТ-архитектуры и повышение степени интегрированности информационных систем компании.

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

Так какие же технологические средства необходимы для внедрения SOA? Для начала это инструментарий документирования бизнес-процессов, далее репозиторий — библиотека унифицированных сервисов, позволяющая быстро компоновать новые автоматизированные процессы, далее — технология перехода от описания бизнес-процессов и определения сервисов к их реализации, например, с возможностью генерации BPEL, и, наконец, среда вызова сервисов и выполнения бизнес-процессов (рис. 1).

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

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

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

Условия успешного применения SOA

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

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

Доходы будущих периодов

Этот тезис подтверждают и данные аналитиков: по прогнозу Aberdeen Group, в течение следующих пяти лет крупнейшие глобальные компании ожидают экономии до 53 трлн долл. за счет внедрения SOA. Эти данные заставляют задуматься над стратегическими вопросами применения SOA.

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

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

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

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

Игнорирование перечисленных условий и требований, чрезмерное увлечение технологической стороной в ущерб процессной грозят привести к совершенно противоположным результатам:

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

Заключение

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

Уроки первых проектов позволяют утверждать, что:

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

Не следует ждать немедленного сокращения времени внедрения и экономии от SOA: это «доходы будущих периодов», базирующиеся на предварительно созданной SOA-инфраструктуре и репозитории сервисов. Но если мы не хотим «остаться за бортом» и рассчитываем получить стратегические бизнес-преимущества, этим надо заниматься уже сейчас — потому что к 2010 г., согласно прогнозу аналитиков Gartner Group, по меньшей мере 65% больших компаний переведут более 35% своего портфеля приложений на SOA.

Андрей Коптелов , директор департамента развития и внедрения ИТ
Виктор Голубев , директор департамента продвижения продуктов и услуг компания «IDS Scheer Россия и страны СНГ»

Вячеслав Ерохин

В статье рассматривается сервис-ориентированная архитектура (SOA ) как бизнес-концепция. Предлагается подход к управлению жизненным циклом SOA с помощью методики «Управление SOA » (SOA Governance ), основанной на средствах управления архитектурой предприятия (Enterprise Architecture Management ) и стратегического управления ИТ.

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

SOA – это архитектура

SOA – Service Oriented Architecture – архитектура, ориентированная на сервисы. SOA – это прежде всего бизнес-концепция архитектурного подхода к построению предприятия. Более ранние концепции не ставили в центр внимания архитектуру предприятия

SOA – первая широко известная бизнес-концепция, концентрирующаяся на архитектуре. Таким, образом, SOA надо понимать и применять в контексте управления архитектурой предприятия (Enterprise Architecture Management ). Архитектура предприятия включает разные слои: бизнес-архитектура, информационная архитектура, техническая архитектура и т.д. SOA начинается с уровня бизнес-архитектуры.

SOA – это сервисы

Концепция SOA концентрируется на архитектуре, но архитектуре ориентированной на сервисы. Что такое сервисы и в чем разница с более ранними концепциями?

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

Таким образом, в SOA стоит выделить первый уровень - бизнес-архитектуры. В свою очередь бизнес-сервисы не существуют в отрыве от миссии компании, ее стратегии и целей. Бизнес-сервисы вытекают из места компании во внешней конкурентной среде. Долгосрочное развитие бизнеса может быть основано только на конкурентных преимуществах и их сочетании, обеспечивающем синергетический эффект. Обычно таких преимуществ немного – два-три. Большая удача – если их пять-шесть. Главная задача выживания компании – это задача создания и сохранения ее конкурентных преимуществ. Но конкурентные преимущества – или по-другому бизнес-потенциалы (Business Capabilities ) – не строятся на основе процессов. Это функции компании как целого организма во внешней среде.

Бизнес-потенциалы

Концепция бизнес-потенциалов (business capabilities ) получила в последнее время мощное развитие. Бизнес-потенциалы определяются как система конкурентных преимуществ, необходимых для реализации бизнес-стратегии предприятия. Бизнес-потенциалы ранжируются для определения их влияния на бизнес предприятия. Критически важные для бизнеса бизнес-потециалы получают максимальный приоритет. Такие бизнес-потенциалы являются самым высокоуровневым элементом построения архитектуры предприятия.

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

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

Основные правила, заложенные в основу концепции бизнес-потенциалов:

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

взаимодействие уровней управления для согласованной поддержки бизнес-потенциалов.

Цель предприятия в рамках концепции бизнес-потенциалов – построение эффективной архитектуры предприятия, позволяющей:

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

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

Сервис или процесс

Бизнес-потенциалы (Business Capabilities ) легко декомпозировать в бизнес-сервисы, но трудно – в бизнес-процессы. Сервисный подход ориентирован на стратегические цели компании – создание и сохранение бизнес-потенциалов.

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

В сервисном подходе –именно бизнес-сервис является основным объектом планирования и управления. Бизнес-процесс – это способ реализации бизнес-сервиса. В процессном подходе первичен бизнес-процесс, как уникальная цепочка создания стоимости. Бизнес-сервис в процессном подходе либо не актуализируется вовсе и заменяется на технический сервис, либо является подчиненным элементом бизнес-процесса, кирпичиком из которых строится бизнес-процесс.

SOA – это не технологическая платформа

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

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

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

SOA – вместо реинжиниринга бизнес-процессов – реинжиниринг предприятия

Стив Джонс, автор книги «Enterprise SOA Adoption Strategies. Using SOA to deliver IT to the businesss» утверждает: «Большинство компаний совершают одну принципиальную ошибку в отношении технологий: они рассмативают их через призму существующих процессов. Компании спрашивают: "Как эти новые технологические возможности могут улучшить и оптимизировать текущую работу?" Но вместо этого они должны спрашивать: "Что новое могут позволить нам делать технологии?" В отличие от автоматизации суть реинжиниринга - в новаторстве, в использовании новейших технологических возможностей для достижения совершенно новых целей. Один из самых сложных элементов реинжиниринга - умение найти новые, незнакомые возможности технологии».

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

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

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

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

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

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

Что такое SOA Governance ?

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

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

Создание инфраструктуры управления SOA, предполагает решение ряда типовых задач:

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

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

Создание высокоэффективных бизнес-сервисов

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

Реализация подхода SOA Governance позволяет ответить на следующие вопросы:

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

Управление жизненным циклом сервисов

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

Управление сервис-ориентированной архитектурой (SOA)
Управление изменениями
Управление вводом в эксплуатацию, использованием и выводом сервисов из эксплуатации
Выявление и учет существующих сервисов, а также управление доступом к ним

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

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

Оценка эффективности

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

Процесс SOA Governance

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

Процесс SOA Governance состоит из четырех этапов:

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

Планирование инфраструктуры SOA

На этапе планирования анализируются потребности организации и выявляются области, в которых требуется более эффективное управление.

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

На этом этапе реализуются следующие мероприятия:

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

Согласование и определение - проработка подхода к управлению SOA

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

На этапе определения принимаются различные решения в области управления SOA :

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

Разработка и реализация - ввод модели управления в действие

На этапе реализации решения по управлению SOA претворяются в жизнь. На этом этапе выполняются следующие работы:

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

Функционирование и оценка - мониторинг внедренных решений и управление ими

На этапе оценки осуществляется мониторинг методов и механизмов управления, выявленных на этапе определения и внедренных на этапе реализации.

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

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

Инструменты SOA Governance

Эффективное управление предприятия, построенного на основе SOA возможно только с использованием соответствующего инструментария.

Требования к инструментарию SOA Governance позволяют сформировать набор продуктов, отвечающий задачам управления SOA :

Поддержка архитектурного подхода

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

Поддержка элементов сервис-ориентированной архитектуры

Инструмент SOA Governance должен обеспечивать поддержку элементов сервис-ориентированной архитектуры. Наиболее важной является поддержка типов артефактов:

Логический сервис (бизнес-сервис)
Технический сервис (веб-сервис)
Функциональный домен
Функциональный модуль
Техническая операция

Поддержка процесса управления жизненным циклом сервис-ориентированной архитектуры

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

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

Ведущие поставщики программного обеспечения предлагают различные наборы инструментов, реализующих SOA Governance . Наиболее функционально полные решения предлагают компании IBM , Oracle , Software AG .

Пример реализации SOA Governance на основе Oracle Fusion Middleware и системы управления архитектурой предприятия Alfabet planningIT

Интегрированное решение на основе alfabet planningIT и Oracle Fusion Middleware позволяет предоставить сквозную услугу по управлению жизненным циклом ИТ-инфраструктуры на основе SOA . Благодаря взаимодействию Oracle Fusion Middleware и alfabet planningIT можно успешно проектировать, разрабатывать и внедрять сервис-ориентированную архитектуру (SOA ).

Решение alfabet /Oracle обладает определенными преимуществами перед другими решениями SOA Governance :

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

Процессы, поддерживаемые интегрированным решением

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

Функции, поддерживаемые интегрированным решением.

Создание в planningIT описания технических сервисов (WSDL ), соответствующих технической реализации логических сервисов, их экспорт в репозитарий Oracle .
Генерация из planningIT проектов Java в Oracle IDE для реализации соответствующих технических сервисов.
Импорт из Oracle в planningIT существующих технических сервисов для планирования бизнес-приложений и логических сервисов.
Формирование в planningIT описания бизнес-приложений в терминологии SOA – как набора логических сервисов, реализованных в виде технических сервисов (веб-сервисов).
Построение в planningIT упрощенных диаграмм процессов BPEL и их экспорт в Oracle .
Импорт из Oracle BPEL Engine в planningIT статистики об использовании сервисов для целей централизованного планирования SOA .

Компоненты, используемые в интегрированном решении

Компоненты Oracle Fusion Middleware (FMW ):

Oracle Services Registry (UDDI) – центральный реестр сервисов
BPEL PM & BPEL Designer (JDeveloper) – разработка и выполнение процессов на BPEL
Датчики (sensors) – сбор и нформации о KPI процесса
Web Services Manager – управление доступом к веб-сервисам

Компоненты alfabet planningIT :

Logical Inventory – единый репозитарий на основе развитой метамодели
Application Architecture Management – управление архитектурой приложений
Enterprise Architecture Management – управление архитектурой предприятия

Стадия планирование

Система управления архитектурой предприятия и стратегического планирования ИТ Alfabet planningIT поддерживает планирование «сверху-вниз» с возможностью многослойного обзора ИТ-активов: бизнес-требования, бизнес-процессы, организационная структура, поддержка бизнеса со стороны ИТ, бизнес-приложения, сервисы. Это позволяет оценить насколько эффективно ИТ-инфраструктура обеспечивает поддержку бизнес-стратегии, стратегических целей, бизнес-процессов и т.п. Кроме того, становится возможным рассчитать стоимость изменений в ИТ-инфрастуктуре.

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

Основным объектом интеграции alfabet planningIT и Oracle Fusion Middleware является объект «Сервис». В репозитарии alfabet planningIT существует артефакт «Технический сервис» (Technical Service ), который корреспондирует с термином «Сервис» (Service ) в SOA . Такой сервис может быть описан с использованием WSDL . Технический сервис в planningIT может быть создан или повторно использован для технической реализации логических сервисов. Логические сервисы в planningIT могут быть объединены в форме бизнес-приложений. Бизнес-приложение является артефактом репозитария, играющим ключевую роль в процессе планирования, управления, анализа затрат и т.п.

Продукты Oracle обеспечивают интегрированную поддержку проектирования, реализации и внедрения сервисов. Oracle Fusion Middleware реализует сервисную шину предприятия (ESB ) и оркестровку сервисов (BPEL ), а также предоставляет возможности мониторинга развернутых сервисов с помощью репозитария сервисов.

Система Alfabet planningIT также предоставляет инструментарий для оценки влияния изменений и проведения анализа затрат внедрения изменений. Oracle Fusion Middleware обеспечивает поддержку реализации, развертывания и выполнения сервисов, спланированных и прототипированных в planningIT .

Стадия согласование (определение)

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

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

Стадия разработка (реализация)

Для обеспечения технической реализации логических сервисов пользователи planningIT могут детализировать описание логических сервисов в терминах технических сервисов. При этом технические сервисы могут быть импортированы из репозитария веб-сервисов Oracle . Если же необходимого технического сервиса не существует, то описание такого сервиса может быть создано в planningIT и затем опубликовано в репозитарии Oracle (OraSR +WSM ) со статусом «В стадии разработки». В то же время генерируется новый проект Java для реализации соответствующего технического сервиса.

Диаграмма процессов BPEL в Oracle соотносится с объектом бизнес-приложение (Business Application ) в репозитарии planningIT . Бизнес-приложение в planningIT – это набор бизнес-сервисов, которые поддерживают бизнес деятельность – а не программный компонент. Таким образом, бизнес-приложение может быть описано в виде диаграммы BPEL , описывающей оркестровку технических сервисов.

Бизнес-приложение может быть экспортировано из planningIT в виде проекта BPEL в формате XML . Все технические сервисы, соответствующие бизнес-приложению, должны быть включены в проект в формате XML и экспортированы в репозитарий Oracle (OraSR +WSM ). Диаграмма BPEL , разработанная в planningIT также может быть экспортирована для последующего использования в среде разработки Oracle (Oracle IDE ).

Стадия функционирование (оценка)

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

Сквозная интеграция alfabet planningIT с Oracle FMW означает, что предприятия теперь могут вести управление эволюцией элементов SOA и жизненным циклом сервисов на основе надежных и последовательных данных и визуальной информации.

Модуль «Управление архитектурой предприятия» planningIT может использоваться для передачи и агрегирования данных с уровня внедренных сервисов на уровень бизнес-планирования, где менеджеры осуществляют оценку рисков, затрат, доступности и качества ИТ-сервисов для важных бизнес-процессов и продуктов. planningIT может импортировать статистику об использовании сервисов из Oracle BPEL Engine . Эта информация может использоваться для централизованного планирования SOA .

Заключение

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