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

В IBM утверждают, что именно они первыми выдвинули идею синхронизации ИТ и бизнеса. Идею, которая под разными названиями продвигается сегодня многими участниками ИТ-рынка. IBM называет свою стратегию «бизнес по требованию» и ведет работы по ее реализации в нескольких направлениях. Одним из основных направлений является создание соответствующей информационной архитектуры, которую в корпорации называют «операционной средой бизнеса по требованию» — On Demand Operating Environment. С директором IBM по стратегии и маркетингу технологий операционной среды бизнеса по требованию Энджел Диаз беседовала редактор журнала «Открытые системы» Наталья Дубова.

Энджел Диаз: «Архитектуры все больше приближаются к реализации принципов сервисной ориентированности, появляется больше возможностей управлять эффективностью бизнеса»

В чем состоит суть стратегии «бизнеса по требованию» с точки зрения бизнеса как такового и с точки зрения технологий?

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

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

Какова взаимосвязь между управлением бизнес-процессами и реализацией стратегии on demand?

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

IBM говорит о «хореографии» бизнес-процессов, Microsoft в похожем контексте использует термин «оркестровка». Поясните, в чем разница — в терминологии или по существу?

Действительно, в этой области терминология очень запутана. Попытаемся разобраться. Есть управление бизнес-процессами (Business Performance Management, BPM), есть управление бизнес-сервисами (Business Service Management, BSM) и есть управление эффективностью бизнеса (Business Performance Management, BPM). Последнее, по сути, является основной целью реализации стратегии on demand. Но для ее достижения необходимо решить две основные задачи. Во-первых, управлять бизнес-процессами, для этого существует язык выполнения бизнес-процессов Business Process Execution Language (BPEL). Во-вторых, управлять ИТ-инфраструктурой, что подразумевает управление и центром данных, и приложениями, и бизнес-сервисами. Реализация этих двух компонентов в тесной взаимосвязи обеспечит управление эффективностью бизнеса. Идеальную картину мы представляем так: руководитель компании смотрит на таблицы с ключевыми показателями эффективности бизнеса, жмет на соответствующие кнопки, и меняется конфигурация бизнес-процессов, включая процессы партнеров, а ИТ-сервисы поддерживают любые такие изменения.

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

Я не знаю точно, как это называет в своих решениях Microsoft, но мы тесно сотрудничаем в этой технологической области, и наше определение BPEL и понимание его роли одинаково.

Что ждет в ближайшем будущем многочисленные программные технологии промежуточного уровня? Я имею в виду мониторы транзакций, брокеры объектных запросов, системы, ориентированные на передачу сообщений. Складывается впечатление, что все они будут вытеснены Web-сервисами как универсальной технологией интеграции. Или просто изменится их роль?

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

Стандарты необходимы для решения определенных задач, например, для обеспечения интероперабельности, для соблюдения определенной архитектурной дисциплины, например, поддержки принципов SOA. Или другой пример. Сетевые устройства, — скажем, маршрутизатор — по-разному конфигурируются и взаимодействуют. Для того чтобы система Tivoli могла обеспечить нормальную работу сети, ей необходимо понимать действия каждого из маршрутизаторов. Спецификация Web Services for Distributed Management (WSDM), предназначенная для управления центрами данных на основе Web-сервисов, — возможный подход к единообразному представлению таких ресурсов, который значительно упростит взаимодействие Tivoli с сетевыми устройствами.

Какую роль играют каждое из пяти программных семейств IВМ в реализации стратегии «бизнеса по требованию»?

Если пытаться определить архитектурный центр, то это, конечно, шина ESB, которая реализуется в продуктах WebSphere Business Integration и Message Broker и позволяет построить SOA. По мере развития семейства WebSphere, с выпуском его шестой версии оно станет единственным способом интеграции приложений.

Функциональность Tivoli находится на уровне центра данных. Здесь обеспечивается управление ИТ-инфраструктурой и поддерживаются технологии виртуализации и автоматизации, которые реализованы в серверах и Tivoli. Шина ESB соединяет центр данных с бизнес-приложениями. Выше уровня приложений находится информация, на этом уровне работают продукты семейства DB2, портальные технологии WebSphere. Есть еще один важный элемент — это разработка, инструменты представления моделей бизнеса. Сейчас все они, включая инструментарий WebSphere Studio, сосредотачиваются в семействе Rational. Единая среда, включающая в себя разработку, тестирование, развертывание бизнес-приложений.

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

Новые стандарты в области ESB, WSDM позволят включать в эту картину на разных уровнях решения других вендоров?

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

Надо отметить еще один интересный момент. То, о чем я рассказывал — это горизонтальный набор технологий, который универсален для многих индустрий. Но если применять эти технологии, зная специфику определенных отраслей, можно добиться лучшего результата. Поэтому в IBM на базе основных программных брендов разрабатываются решения для 17 различных отраслевых направлений, включая финансы, здравоохранение, розничную торговлю, автоиндустрию, правительственные организации и т. д. Это имеет важнейшее значение для адаптации идей «бизнеса по требованию», поскольку такие решения настроены с учетом специфики клиентского бизнеса. Вместо того чтобы просто предоставить им реализацию BPEL, мы добавляем поддержку потоков работ, специфичных, например, для банковской индустрии. Здесь ключевую роль играют бизнес-партнеры, которые имеют возможность дополнить базовые технологии IBM своей экспертизой в специализированных, отраслевых областях.

Что представляет собой среда On Demand Operating Environment

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

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

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

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