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

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

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

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

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

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

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

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

Шина концентрирует сервисы

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

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

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

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

Если думать только об архитектуре

Интересно, что взгляд на SOA как на системную архитектуру, а не как на совокупность готовых к работе с прикладным функционалом программных платформ, похоже, несколько меняет изначальное отношение к ней как к архитектуре тяжеловесной, очень дорогой и чрезвычайно инерционной с точки зрения развертывания на предприятии. Действительно SOA — это прежде всего архитектура, призывающая во многом переосмыслить и при необходимости изменить подходы к информационной поддержке. Как справедливо замечает Сергей Кирюшин, с внедрением SOA традиционные «толстые» клиенты, уже отчасти вытесняемые из корпоративного ландшафта, могут исчезнуть полностью, и одновременно создаются хорошие предпосылки для универсального доступа к данным с любого устройства. Все это, безусловно, отражает влияние SOA как новой системной архитектуры. Однако архитектурная новизна может воздействовать ещё глубже, затрагивая не только привычные принципы использования создаваемых прикладных решений, но и логику их работы. Максим Смирнов комментирует тот факт, что относительно новая даже в масштабах рассматриваемой темы концепция управляемой событиями SOA (event driven SOA) очень хорошо подходит для автоматизации работы оператора связи, и данный акцент как раз демонстрирует, насколько SOA способна изменить логику ИТ-поддержки. Думается, не в последнюю очередь благодаря попытке использовать перспективные архитектурные особенности меняется и экономическое восприятие SOA, что чрезвычайно существенно. По словам Максима Смирнова, работу с управляемой по событиям SOA можно начинать в корпорации прямо сейчас. Для этого в качестве стартовой программной инфраструктуры не нужно иметь дорогостоящие интеграционные платформы, а достаточно задействовать лишь системы класса промежуточного ПО, основанного на передаче сообщений (Message Oriented Middleware — MOM), которое уже имеется в арсенале многих компаний. В подтверждение своих слов руководитель департамента архитектуры BSS «Вымпелкома» приводит пример одной из региональных услуг, запущенной именно с помощью event driven SOA. При этом было весьма точно подсчитано (как по деньгам, так и по времени), во что обошёлся бы вывод данной услуги на рынок без использования SOA. Экономия по обоим ресурсным параметрам оказалась более чем существенной. Иными словами становится понято, что отдачу от SOA, если смотреть на нее исключительно через призму архитектурных инноваций, можно хоть и в небольшом объеме, но все же получить гораздо раньше, чем в то время, когда предприятие в значительной мере освоит IBM WebSphere или SAP NetWeaver. А подобную тактику «быстрых побед» в деле убеждения топ-менеджмента (даже тогда, когда «тяжелые» SOA-платформы предполагается впоследствии использовать по полной программе) просто трудно переоценить.

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

Наконец, упомянем еще одну особенность, отмеченную участниками «SOA-2007». Например, Максим Смирнов считает, что главное в рассматриваемой нами архитектуре состоит в том, как мы сопоставим имеющиеся у нас ИТ-активы с теми событиями, на которые нам следует реагировать в информационной системе. То есть речь идет о подходе к проектированию программно-аппаратных ресурсов, существенно отличном от привычного сопоставления «под каждое приложение — один сервер». В новой ситуации речь скорее идет о том, чтобы весь пул сервисов сопоставить с суммарным пулом имеющихся или потенциально востребованных ИТ-ресурсов. По сути это во многом вопрос методически грамотного их учета, в силу чего параллельно с развитием SOA может возрасти интерес к управлению ИТ-ресурсами — как в виде небезызвестного Configuration management из сферы ITSM, так и в образе пока совсем незнакомого, но все же упомянутого на конференции Ярославом Медоксом направления под названием SOA Governance (управление SOA).