Сервис-ориентированная архитектура многими рассматривается как перспективное направление интеграции, позволяющее увеличить степень соответствия информационно-технологического обеспечения управления запросам реальности. Однако ориентация на этот подход предъявляет особые требования к надежности вычислительных систем. Об интеграции на платформе SOA наш сегодняшний разговор с Александром Замятиным, директором департамента информационных технологий компании «ТехноСерв А/С».
–Отношение рынка к SOA оценивают по-разному. Каково ваше видение ситуации в этом сегменте?
— В настоящий момент, особенно в текущем году и в конце прошлого года, рынок продемонстрировал готовность к восприятию SOA и к реализации проектов на базе этой архитектуры. По данным последних исследований IDC, мы имеем ежегодный двукратный прирост по платформам SOA и полуторакратный прирост по разработке сервисов. В 2006 году объем рынка по платформам SOA составляет около 4 млрд. долларов, а по разработке сервисов — 150 млрд. долларов.
— Есть еще какие-нибудь признаки готовности?
— Достаточно зрелые продукты, которые на данный момент выпущены на рынок ведущими производителями.
— А со стороны заказчиков?
— Со стороны заказчиков — осознание того, что автоматизация с помощью монолитных систем, широко практиковавшаяся ранее, приводит сегодня в большинстве случаев к негативным результатам. Известно, что 60–70 процентов такого рода проектов выходят за запланированные сроки или бюджеты, а некоторые заканчиваются провалом.
Что касается собственно веб-сервисов, то активный рост начался в 2004 году, за 2005 год появилось достаточно много поставщиков соответствующих услуг, и на текущий момент на мировом рынке действуют шесть основных производителей платформ SOA — это IBM, BEA Systems, Microsoft, Tibco, SAP и Oracle. В 2005 году, по данным WinterGreen Research, их доли распределялись как 46, 13, 10, 8, 6 и 5 процентов, соответственно. При этом в России наиболее интересные позиции, наверное, у IBM и у Tibco. Что касается самих платформ, то они достаточно зрелые, ориентированные на принятые стандарты, что, естественно, обеспечивает их совместимость, взаимозаменяемость и так далее. В частности, мы начали исследование возможности взаимного использования платформ в аспекте обмена сообщениями, конкретнее — дополнения технологии IBM MQ технологией Message Bus, предлагаемой Tibco. Message Bus, или шина сообщений, в силу шинной архитектуры обеспечивающая более высокую производительность, чем очередь сообщений, ориентирована на приложения реального времени.
— Можно ли выделить организации — по масштабу или по каким-то другим признакам, для которых имеет смысл рассматривать внедрение сервис-ориентированной архитектуры?
— Каких-либо четких критериев на текущий момент не существует. Однако совершенно точно можно отметить интерес к SOA со стороны корпораций, которые имеют в своем распоряжении большое количество монолитных систем (как правило, это ERP-система, разного рода технологические подсистемы и тому подобное). Кроме того, это те предприятия, которым необходимо быстрое внесение изменений в бизнес-процессы и в бизнес-логику приложений, эти процессы автоматизирующих.
— Можете привести какой-нибудь пример?
— Давайте рассмотрим пример телекоммуникационного оператора. Традиционная реализация, то есть без использования SOA, включает в данном случае биллинговую систему (возможно, не одну, а несколько), ERP-систему, систему документооборота, а также систему управления сетью связи. В последнее время все чаще используются также различные компоненты OSS-систем. Все эти системы должны быть так или иначе интегрированы между собой, особенно на уровне справочников, а изменения в них, при необходимости, должны вноситься, что называется, на лету. Поскольку архитектура SOA является слабосвязанной, мы можем достаточно оперативно добавлять новые сервисы практически без ущерба для работающей системы. При этом затраты на реализацию каждого последующего модуля уменьшаются.
— Во всех ли случаях для организаций, отвечающих двум названным вами критериям, возможна интеграция на платформе SOA?
— Конечно, нет. Например, один из заказчиков «ТехноСерва», — крупная петербургская транспортная компания, которая отличается использованием передовых технологий информатизации, видя, что SOA — перспективная платформа, обратилась к нам с предложением ее у себя реализовать. Но оказалось, что в этой компании количество монолитных приложений и их связи таковы, что интеграцию этих приложений можно выполнить другими средствами с существенно меньшими затратами. В данном случае использовалось специализированное программное обеспечение логистики, которое требовалось связать лишь с бухгалтерской системой, поскольку функциональность CRM и все прочее были реализованы внутри этого ПО. Использование SOA для обеспечения обмена сообщениями здесь было бы неоправданным.
— Насколько тесна, на ваш взгляд, связь между сервис-ориентированной архитектурой и процессным подходом в управлении?
— Связь, по нашему мнению, непосредственная, поскольку перед тем, как обеспечить разложение системы на компоненты, мы ориентируемся как раз на процессный подход, и вся декомпозиция осуществляется на этой основе. При этом проектирование может быть как прямым, так и обратным, в зависимости от состояния организации.
— Следовательно, организация, которая хочет внедрить у себя SOA, должна быть готова при необходимости соответствующим образом модифицировать свои бизнес-процессы?
— Каких-либо жестких рекомендаций в данном случае, конечно же, нет. Однако в большинстве случаев, особенно если мы говорим об отечественных организациях, имеет место, как мы знаем, лоскутная автоматизация. И именно здесь, в рамках информатизации ключевых бизнес-процессов — может быть, наиболее затратных, может быть, наиболее значимых с точки зрения заказчика, — ориентация на процессный подход необходима. В остальных случаях организация может переходить к новой модели управления эволюционно.
Хотелось бы сказать несколько слов о нашем подходе к проектированию. При разработке решений для наших заказчиков мы используем систему сбалансированных показателей (BSC) и формируем техническое решение, исходя из четырех проекций: финансы, клиенты, процессы, потенциал.
В проекции финансов мы учитываем стоимость владения системой, возврат инвестиций, оптимальность затрат (с точки зрения соотношения «использованная функциональность — стоимость») и фактор масштаба, обеспечивающий, при достижении определенного уровня предоставления услуг, снижение затрат на каждую последующую реализуемую единицу сервиса. Причем снижение существенное. В случае, если предприятие предполагает поставить на сервисную шину, например, десять тысяч сервисов, фактор масштаба будет таков, что срок окупаемости сервисной платформы может начинаться от полугода.
— Насколько точно удается определить стоимость владения?
— Она складывается из трех компонентов. Во-первых, это начальная стоимость систем — то есть их стоимость до момента запуска в эксплуатацию, во-вторых, эксплуатационные расходы, в-третьих — расходы на модернизацию. Правильность расчета расходов на инсталляцию системы определяется всего лишь квалификацией системного интегратора. Далее, если мы говорим о достаточно статичной системе, то есть такой, которая не модернизируется, то эксплуатационные расходы могут быть определены с погрешностью, не превышающей, на мой взгляд, 15 процентов. Особенно, если эксплуатация системы осуществляется на условиях аутсорсинга. Что касается модернизации, которая требуется при изменении бизнес-процессов, то она складывается из затрат на дополнительную инфраструктуру (если нужно), на имплементацию новых сервисов и на систему эксплуатации.
Далее, возвращаясь к аспектам оценки решения с точки зрения BSC: проекция «клиенты» включает в себя учет текущих, плановых и перспективных потребностей организации, а также оперативность удовлетворения внеплановых потребностей. Проекция «процессы» включает в себя обеспечение соответствия проектируемой системы отраслевым стандартам, в том числе стандартам, регламентирующим управление ИТ-инфраструктурой (COBiT, ITIL, ISO 27001), а также обеспечение требуемых уровней сервиса, фиксируемых в соответствующем соглашении (SLA — Service Level Agreement). И, наконец, проекция «потенциал» предусматривает технологичность решений, включающую их гибкость, масштабируемость, тиражируемость и безопасность.
— Предположим, организация установила у себя такую систему. Легко ли ее инженерам научиться самим вносить изменения в функциональность?
— Это зависит лишь от квалификации инженера. Установка какого-либо процесса на шину в первую очередь сопровождается так называемой «хореографией», или «оркестровкой», которая определяет последовательность выполнения процессов. Стандартно используемый язык BPEL, который является не чем иным, как языком исполняемых сценариев, содержит около 20 зарезервированных слов, и, как правило, все программирование выполняется при помощи визуальных средств, предоставляемых разработчиком платформы SOA. Можно сказать, что это традиционное визуальное проектирование, и специалист, который владеет методологией описания бизнес-процессов, будь то IDEF0 или UML, думаю, сможет освоить работу с данными системами если не за сутки, то, наверное, за неделю.
Однако для качественного сопровождения подобного рода систем требуется все-таки специализированное обучение. Системы многокомпонентные, и, например, если реализация осуществляется на базе ПО IBM WebSphere, то мы задействуем около 15 продуктов разного рода, в том числе средства реализации платформы, средства имплементации бизнес-процессов, инструменты мониторинга и диагностики, средства разработки. Самостоятельно освоить такой широкий спектр продуктов, наверное, нереально. Какую-то часть сможет взять на себя ИТ-департамент организации, остальное берет на себя системный интегратор или же производитель продукта. Надо сказать, что мы, как системный интегратор, обеспечиваем, фактически «под ключ», исполнение типичных задач.
— Какие требования предъявляет сервис-ориентированная архитектура к аппаратному обеспечению, и чем это определяется?
— Главное требование — это надежность, поскольку продукты, реализующие сервис-ориентированную архитектуру, являются своего рода ядром, кровотоком всей системы. При отказе носителя платформы SOA происходит отказ всей системы. Ну, или, по крайней мере, недублируемой ее части.
Второе требование — необязательное, но желательное — это масштабируемость. Поскольку наращивание сервисов в дальнейшем потребует наращивания и вычислительной, и транзакционной мощности платформы.
— Можно ли сказать, что требования к надежности более высокие, чем при использовании нескольких монолитных систем?
— При корректной интеграции монолитные системы при выходе из строя интеграционной платформы (или какого-либо из ее компонентов) будут оставаться работоспособными в автономном режиме. Будет лишь отсутствовать связь между приложениями и, как следствие, некоторая функциональность. Если необходимо, и, как правило, это предусматривается планом восстановления после бедствия (DRP — Disaster Recovery Plan), можно обеспечить аварийную связь между приложениями на уровне обмена данными в формате XML или в другом необходимом формате.
— Число серверов всегда четное?
— Не совсем так. Вообще, для реализации SOA, если мы говорим о мэйнфреймах, достаточно одного сервера, скажем, IBM System z9 BC Model S07. Если проект предусматривает средства восстановления в случае бедствия, как правило, мы предлагаем решение, базирующееся на использовании двух серверов. Поскольку разного рода катаклизмы в последнее время учащаются — начиная от возгорания Останкинской башни и заканчивая провалами в центре Москвы, — нельзя быть уверенным в том, что инфраструктурное ядро системы по какой-либо причине не окажется вследствие подобной катастрофы неработоспособным. Но в некоторых случаях установки второго сервера не требуется, система задействуется, с понижением производительности, на других имеющихся мощностях. Все зависит от чувствительности бизнеса к конкретным сервисам, от требований заказчика и, конечно, его финансовых возможностей.
Если мы обратимся к истории распределенных систем, то увидим, что распределенность была обусловлена двумя факторами. Первый — это низкая надежность вычислительной техники, второй — высокая стоимость каналов передачи данных, вследствие чего было выгодно наращивать локальную вычислительную мощность для промежуточной обработки информации, с тем чтобы уменьшить затраты на ее передачу. Сегодня ситуация изменилась. Надежность компьютеров повышается, а стоимость передачи данных падает, и мы можем, не задумываясь о расходах, обрабатывать всю информацию централизованно.
Что же касается надежности, то классические мэйнфреймы IBM с операционной системой z/OS характеризуются сверхнадежностью.
— Ее можно выразить в определенном количестве девяток?
— Количество девяток зависит от конфигурации системы. При правильном проектировании мэйнфрейма, т. е. правильном выборе доступных его ресурсов, мы можем получить систему, например, с шестью девятками.
— Можно ли сказать, что мэйнфреймы абсолютно устойчивы к стандартным угрозам информационной безопасности, направленным на компьютеры, а не на сетевое оборудование?
— Я бы сказал, что да. Можно утверждать на настоящий момент, что подверженность мэйнфреймов такого рода атакам на несколько порядков ниже, чем для других вычислительных платформ. Определяется это, прежде всего, архитектурой системы, а также серьезным входным барьером для данного рода активности. Знания аппаратной и программной части мэйнфрейма для создания вредоносного ПО должны быть существенно выше, чем в случае с другими системами. А накопление экспертизы здесь занимает достаточно длительное время.
— Насколько эффективно использование мэйнфреймов?
— Достаточно долго бытовало мнение, что для большинства задач мэйнфреймы являются неэффективным решением. Оно было основано на том, что мэйнфрейм имеет высокую производительность, прежде всего транзакционную, и в ряде случаев мощности вычислительной системы были избыточны по отношению к задачам. За мощность приходится платить, и отношение стоимости к используемой производительности было очень велико. Можно сказать, что до 2004 года мэйнфреймы для приложений интеграции несколько проигрывали другим платформам.
Сейчас у IBM существует очень интересная программа — Capacity on Demand, то есть вычислительная мощность по требованию. Покупая сервер, мы можем заплатить не за всю производительность, которую могут обеспечить его процессоры, а лишь за ту, которая нужна на данный момент. Когда потребуется увеличить производительность, достаточно приобрести новую лицензию. Таким образом, можно существенно сократить расходы.
Кроме того, раньше цена мэйнфреймов была высока, и они были доступны только крупным предприятиям. Сейчас появились системы так называемого бизнес-класса (BC — Business Class), которые стоят менее ста тысяч долларов. При этом при наращивании их мощности до уровня серьезного мэйнфрейма (EC — Enterprise Class) обеспечивается полная защита ранее сделанных инвестиций.
Нужно сказать также, что мэйнфреймы IBM System z9 позволяют использовать специализированные процессоры для баз данных (zIIP — System z Integrated Information Processor) и для Java-приложений (zAAP — System z Application Assist Processor). Каждый из этих специализированных процессоров способен высвободить значительную часть производительности центральных процессоров, выполняя те или иные функции СУБД либо Java-приложений. Стоимость использования такого процессора примерно втрое-вчетверо ниже, чем стоимость использования центрального процессора.
Совокупное использование вычислительной мощности по требованию и специализированных процессоров дает существенный выигрыш в стоимости владения системой. При хорошо продуманном планировании можно получить, как минимум, 40-процентное увеличение показателя возврата инвестиций. Уверен, что для ряда корпораций показатель может быть значительно выше. Особенно для банков, которые ориентированы на терминальный доступ.
Мы предлагаем нашим заказчикам также гетерогенные системы на базе оборудования IBM: центр системы реализуется на высокопроизводительном транзакционном сервере System z9, серверы приложений — это System p5 (используют RISC-архитектуру и построены на технологии IBM Power5), а серверы начального уровня — eServer xSeries, основанные на процессорах Intel (реализуют концепции X-Architecture, заключающиеся в интеграции проверенных временем технологий RISC-систем и мэйнфреймов компании IBM в системы архитектуры IA). Преимущества использования оборудования одного вендора в данном случае очевидны.
— Кто потребляет подобные решения?
— Наши ключевые заказчики — это операторы связи, кредитные учреждения, железные дороги, органы власти и государственного управления, предприятия нефтегазового сектора. Однако у нас реализованы и крупные проекты по SOA за рубежом. Можно отметить проекты для ситуационного центра системы радиолокационного мониторинга сложных объектов в Тулузе (Франция), а также для центра распределенных исследований в области нанотехнологий в Мюнхене (Германия). Последний проект выполнялся в соответствии с тематикой Шестой рамочной программы Европейского Союза по научным исследованиям и техническому развитию. Это для нас является своего рода визитной карточкой по направлению SOA. В обоих случаях мы выступали как проектный системный интегратор; при этом поставку аппаратной платформы осуществлял региональный партнер.
Кроме того, сейчас мы выполняем проект для центра оценки состояния месторождений природных ископаемых в Каракасе (Венесуэла).
Из российских проектов следует особо выделить проект создания на базе SOA катастрофоустойчивой ИТ-инфраструктуры национального оператора широкополосной беспроводной связи на базе технологии Mobile WiMax. В этом проекте мы используем описанную выше гетерогенную платформу IBM, что позволило существенно оптимизировать предлагаемое заказчику решение с точки зрения BSC.
Надо сказать, что мы намерены активно развивать направление проектирования и инсталляции инфраструктур для SOA, сопровождения, выполнения работ по интеграции систем (то есть имплементации сервисов) и разработки веб-сервисов по заказу. Рассматривая SOA в качестве одного из стратегических направлений развития, мы предлагаем соответствующие услуги как нашим существующим, так и потенциальным заказчикам. Надо сказать, что любая исполняемая нами работа рассматривается как долгосрочное партнерство — мы предполагаем, что после инсталляции системы наше взаимодействие с заказчиком не останавливается. Мы готовы осуществлять модернизацию систем, планируя эти процессы на основе перспективы развития организации-заказчика в ближайшие несколько лет, а также их сопровождение, вплоть до полного аутсорсинга.
http://www.cio-world.ru
