Новый архитектурный стиль

Глеб Ладыженский — директор по технологиям Oracle СНГ

Директор ИС #01/2008
http://www.osp.ru/cio/2008/01/4744326/

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

Одно из множества определений

Как всякая парадигма информационных технологий, сервис-ориентированная архитектура (Service-Oriented Architecture, SOA) имеет множество аспектов, и исчерпывающее определение дать довольно сложно.

Компании, специализирующиеся на информационных технологиях, — будь то разработчики программных продуктов или поставщики услуг, — предлагают разнообразные определения SOA. Разумеется, формулируя собственное определение, каждая компания фокусирует внимание на тех аспектах SOA, которые значимы для ее бизнеса. Для понимания парадигмы SOA полезно обратиться к мнению инженерного сообщества. Вот, к примеру, какое определение дает доктор Хао Хэ из рабочей группы W3C Web Services Architecture Working Group (World Wide Web Consortium, www.w3c.org ): «Сервис-ориентированная архитектура есть архитектурный стиль [построения информационных систем], главная идея которого заключается в достижении слабой связанности между взаимодействующими программными агентами. Сервис есть единица работы, выполненная поставщиком сервиса для достижения конечного результата, необходимого потребителю сервиса».

Программное обеспечение как сервис

В приведенном определении отлично отражена суть SOA, которая вовсе не сводится к формуле «программное обеспечение как сервис». Англоязычный термин service переводится и как «сервис», и как «услуга». В этой двойственности кроется суть непонимания парадигмы сервис-ориентированной архитектуры. Ведь SOA не имеет никакого (или почти никакого) отношен я к другой популярной ныне концепции — Software as a Service (SaaS). Говоря о сервис-ориентированной архитектуре, мы имеем в виду программный компонент (в определении выше программный агент), выполняющий полезную с точки зрения определенной прикладной области функцию; здесь сервис — это единица работы. Когда же мы говорим о SaaS, то имеем в виду использование программного обеспечения как услуги.

Понятие «сервис» в программной инженерии появилось достаточно давно. К примеру, еще в начале 90-х годов в мониторе транзакций Tuxedo одним из ключевых элементов всей программной конструкции был сервис — не что иное, как функция, реализованная на языке программирования Си и доступная извне программно по специализированному интерфейсу (Глеб Ладыженский. Технология «клиент/сервер» и мониторы транзакций // «Открытые системы», № 3, 1994). В те времена про SOA еще никто не упоминал, а вот понятие сервиса уже существовало.

У истоков SOA

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

Согласно опросу, проведенному журналом The Economist среди высших руководителей крупных компаний, 54% опрошенных заявили, что на перспективу до 2010 года рассматривают в качестве стратегического конкурентного преимущества компании новые бизнес-модели, считая их существенно более важными, чем новые продукты или услуги. Таким образом, оперативное приведение информационных систем в полное соответствие с требованиями бизнеса становится стратегическим преимуществом компании.

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

Цели перехода к SOA

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

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

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

Преемственность EAI и SOA

Говоря о преемственности EAI и SOA, следует помнить, что такая преемственность существует в смысле программной инфраструктуры, но не в плане методологии.

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

Первый вариант — это следование по пути управления бизнес-процессами (Business Process Management, BPM) и SOA, второй — это применение промышленных платформ интеграции приложений. Первый вариант — системный, второй — утилитарный, но оба имеют право на существование. Однако не нужно думать, что, выбрав второй вариант, потом можно с легкостью переключиться на первый. Конечно, воспользоваться унаследованной программной инфраструктурой будет можно; примером может служить развертывание корпоративной шины сервисов поверх систем класса Message Oriented Middleware, но придется заново осваивать блок проектирования и моделирования бизнес-процессов, а также переделывать программные интерфейсы у интегрируемых приложений. Потребуется существенная модернизация программной инфраструктуры и полный цикл работы над бизнес-процессами. Не лучше ли сразу начатьс BPM?

Связь интересов бизнеса и возможностей ИТ

По меткому высказыванию Дэниэла Серейна, увязка интересов бизнеса и возможностей информационных технологий как раз и есть та цель, на которую направлено применение новейших архитектур (Леонид Черняк. Поход за Чашей Грааля информационных технологий // «Открытые системы», № 1, 2006). Ефим Натис, вице-президент Gartner Research, говорит: «В конечном счете, движение к SOA сулит приблизить увязку информационных технологий и бизнеса, к которой издавна стремится программная индустрия» (Ефим Натис. Покорение сложности информационных систем // «Открытые системы», № 7—8, 2005).

Однако только SOA для достижения этой цели недостаточно. Ее дополняет архитектура, управляемая событиями (Event-Driven Architecture, EDA).

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

Объединение концепций SOA и EDA, принято называть SOA 2.0, или сервис-ориентированной архитектурой, управляемой событиями.

Архитектура, управляемая событиями

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

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

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

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

Эффективность инвестиций в ИТ

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

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

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

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

Управление архитектурой предприятия

Глядя на картину информационных технологий в любой современной организации, нетрудно видеть, что планирование и реализация встраивания ИТ в ее структуру ведется везде практически «вслепую», хаотично, ИТ-руководители действуют в основном «по обстановке», учитывая «политические течения», жертвуя стратегическими соображениями в угоду быстро окупаемым тактическим решениям. Требовать в такой обстановке точной оценки окупаемости инвестиций просто глупо. Если не использовать адекватный сложности задачи комплексный инструментарий управления архитектурой предприятия (Enterprise Architecture Management, EAM), то все рассуждения по поводу срока возврата инвестиций и суммарной стоимости владения никак не могут приниматься в рассмотрение. Невозможно всерьез браться за сколько-нибудь значимый проект по модернизации корпоративной информационной системы, не воспользовавшись предварительно методологией и инструментарием EAM. Превосходная общая характеристика относительно нового направления EAM и отличный обзор соответствующих инструментов содержится в статье Вячеслава Ерохина «Инструменты управления архитектурой предприятия» («Открытые системы», № 3, 2007). В связи с этим фраза: «Приведите понятные руководителям бизнеса аргументы в пользу перехода к SOA» не может не вызвать улыбки. Такие аргументы не вытекают непосредственно из самой парадигмы SOA, а потому их не может привести представитель любой компании, специализирующейся в области информационных технологий.

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

Перспективы SOA в России

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

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

Часто задаваемый вопрос о целесообразности применения SOA в зависимости от размера организации и от степени динамичности бизнеса не имеет однозначного ответа. Краткое описание SOA Maturity Model, одного из методов предварительной оценки точки положения организации «в пространстве» SOA можно найти в статье Леонида Черняка «Встреча «на SOA» («Открытые Системы», № 3, 2006). Но подобные методы подходят для тех, кто уже принял решение о глубокой модернизации информационных систем или об их построении «с нулевого цикла».

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

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

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

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

Аналитики AMR Research даже предложили создать постоянно действующий комитет регулирования SOA (Комитет регулирования SOA // «Открытые системы», № 7—8, 2005), в функции которого входил бы полный контроль над проектированием и исполнением сервисов, в том числе соблюдение гранулярности сервисов (разбиение функциональности приложений на сервисы, пригодные для многократного использования), проектирование единого репозитория сервисов, контроль принадлежности сервисов (распределение
задач по созданию, сопровождению и модернизации различных сервисов между индивидуальными командами), обеспечение управления, надежности, доступности и безопасности сервисов (регулярная ревизия сервисов с целью выявления необходимости их консолидации по мере эволюции технологий и приложений).

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

Технологический арсенал SOA

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

Прежде всего это исполнитель бизнес-процессов, формализованный с использованием специального языка BPEL (Business Process Execution Language). В терминологии Oracle этот исполнитель носит название BPEL Process Manager. Второй, не менее важный компонент — корпоративная шина сервисов (Enterprise Service Bus, ESB), в арсенале Oracle имеется соответствующий программный продукт Oracle Enterprise Service Bus. В качестве исполнителя бизнес-правил, которые целесообразно вынести «за скобки» бизнес-процессов для более простой их модификации, применяется программный продукт Oracle Business Rules.

Для управления, мониторинга и обеспечения безопасности сервисов может применяться программный продукт Oracle Web Services Manager. Наконец, движение в сторону сервис-ориентированной архитектуры, управляемой событиями, воплощается в компоненте мониторинга бизнес-активности (Business Activity Monitoring, BAM). Этот компонент (пример соответствующего программного продукта — Oracle Business Activity Monitoring) позволяет расставлять в значимых точках информационной системы программные датчики, которые по заранее определенным событиям собирают данные, ассоциированные с этими событиями, агрегируют их и доставляют линейным менеджерам на специальные приборные панели (dashboards) для принятия оперативных решений. Перечисленные пять компонентов — основа технологического арсенала SOA.

Говоря о полном цикле автоматизации бизнес-процессов предприятия, никак не обойтись без средств проектирования и моделирования бизнес-процессов. В Oracle в рамках OEM-соглашения с компанией IDS Sheer разработали на основе компонентов ARIS интегрированный набор инструментов проектирования бизнес-процессов с общим названием Business Analysis Suite (BPA Suite). Одна из его особенностей — обмен процессами с BPEL Process Manager на основе специализированного репозитория, что позволяет транслировать спроектированные в BPA Suite «бумажные» процессы в реально исполняемые BPEL Process Manager корпоративные бизнес-процессы.