Интеграционный слой что это
Автоматизация системного интеграционного тестирования
Хочу поделиться с вами личным опытом в системном интеграционном тестировании. Наша команда занимается разработкой интеграционного слоя, через который связаны все системы в банке. Задач у нас много, времени не хватает, и вопрос тестирования интеграции всегда откладывался.
Как же происходит тестирование интеграции? Самый короткий ответ — никак, хотя у нас больше сотни систем, которые взаимодействуют через интеграционную шину Oracle Service Bus(OSB). У этого продукта есть инструмент OSB Console, который позволяет послать тестовый запрос и отображает полученный ответ. После того как разработчик реализует на шине новый сервис, сервис вручную проверяется через OSB Console. Если проверка успешна, то сервис объявляется работающим и меняется, только если на него начинают жаловаться разработчики внешних систем.
Поддержка используемой нами OSB подходила к концу, и возникла необходимость перехода на новую версию. Хотя сама миграция больших проблем не вызывала, встал вопрос, а как проверить работоспособность смигрированного решения? И тут наша команда в очередной раз задумалась о внедрении автоматического тестирования.
Как мы себе это представляли
Картинка получилась простая и сразу всем понравилась. 
В самом деле, нам нужно просто автоматизировать то, что мы делаем руками. Так давайте создадим тест, который будет хранить пары сообщений (запрос, ответ). После запуска наш тест пошлет запрос, получит ответ и сравнит его с хранящимся у него ответом. Если ответы совпали, то тест прошел успешно.
Виртуализация сервисов (mocks, stubs)
Большие надежды возлагались на Soap UI, который умеет запускать mock-сервисы, как web-приложение. Но, оказалось, что SOAP UI уж очень «UI». Во-первых, он не thread-safe, а во-вторых, использует очень много памяти и работает нестабильно.
В процессе исследований выяснилось, что в нашем банке уже есть аж четыре(!) самописных симулятора web-сервисов. Один из них оказался очень даже ничего, был взят за основу и по мере надобности дописан. Так в тестовом окружении у нас появился симулятор — web-приложение, которое по определенным HTTP-запросам возвращает определенные HTTP-ответы.
Каждый виртуальный сервис — это maven проект. В конфигурации проекта (service-descriptor.xml, response-selector.xml) написано как на основании HTTP-запроса определить, какой вызван сервис, какая нужна операция и по какому правилу вернуть HTTP-ответ.
После изменений исходников проект автоматически собирается на Jenkins и при помощи maven wagon деплоится в работающее приложения симулятора.
А теперь пишем тест
Следующим шагом нам нужно написать тест, который фактически будет симулятором front-end системы. То есть нам нужно написать web-service клиент.
Наш тест является maven проектом. Внутри проекта находятся пары файлов (запрос, ответ), которые собственно и являются исходниками. Билд проекта состоит в том, что наш самописный maven plugin вызывает web-сервис передает ему тестовый запрос, получает ответ и сравнивает его с тестовым ответом.
Тесты запускаются автоматически каждую ночь на Jenkins.
Создание тестовых данных
Поскольку основная задача состояла в тестировании миграции, тестовые запросы и ответы были экспортированы из аудитной базы данных, которая работает в production. По этим данным были сгенерированы соответствующие maven-проекты.
В случае разработки новых сервисов, данных из живых систем еще нет. Для таких случаев мы написали свой инструмент на базе Eclipse. В несколько кликов мы можем создать новый проект, заполнить его тестовыми данных, положить в систему контроля версий и сделать новый проект на Jenkins.
Что получилось
Планы на будущее
Нам понравилось, и мы будем продолжать. В ближайшем будущем планируется добавить симуляторы для JMS, поддержку бизнес-процессов и придумать, как проводить тесты производительности.
А вы тестируете интеграцию? Поделитесь, своим опытом!
Управление данными в нефтегазовой отрасли
Особенности комплексного управления и анализа данных для нефтегазового сегмента
Не осталось отраслей экономики, для которых данные не имели бы огромного значения. Все больше компаний приходят к пониманию, что информация — это корпоративный и стратегический актив. При грамотном управлении данными и использовании аналитики для прогнозирования, ценность собираемой и накапливаемой информации только растет.
Данные — это не только сведения о бизнесе и сопутствующая ему атрибутика, но и активы, которые приносят прибыль. Именно поэтому ими можно и нужно управлять. Вовлечение полной структурированной и неструктурированной информации в аналитический оборот позволяет быстро и эффективно решать задачи, которые ранее выполнялись крайне сложно или не выполнялись вовсе.
Вся собираемая, обрабатываемая и используемая информация — надежная основа для увеличения производственной и экономической эффективности компании, повышения качества обслуживания оборудования, заказчиков, увеличения получаемых прямых и косвенных выгод. Это также опора для принятия взвешенных управленческих решений, подспорье для проведения различных исследований и разработок по повышению операционной эффективности и оптимизации существующих бизнес-процессов.
С помощью современных IT- и методологических решений можно поддерживать критически важную информацию в актуальном состоянии, контролировать ее целостность и непротиворечивость, оперативно устранять возникающие ошибки и неточности, использовать их для решения бизнес-задач, достижения стратегических и оперативных целей с минимальным привлечением технического персонала.
Специфика данных в нефтегазовом сегменте
Предприятия нефтегазового сектора занимаются геологоразведкой и добычей, хранением и транспортировкой добываемых продуктов и специализируются на работе с объемной геолого-геофизической информацией, промысловыми данными, информацией о процессах хранения и транспортировки, сопровождающих их рисках, диагностических проверках оборудования и т. д.
Занимаясь переработкой и сбытом, организации активно работают с огромными массивами данных по заводам, скважинам, трубопроводам, а также с информацией о торговых партнерах, дистрибьюторах, коммерческих и бытовых потребителях, объемах продаж, адресам отгрузок, расчетам — то есть с нормативно-справочной информацией. Кроме того, такие компании активно взаимодействуют с правилами, регламентами, инструкциями в области безопасности и охраны труда и пр.
Работа с информацией в нефтегазовом секторе имеет свои особенности. Во-первых, у предприятий отрасли традиционно сверхбольшой объем разнородных данных, часть из которых быстро устаревает или постоянно обновляется. Во-вторых, ими часто используются различные источники данных — это могут быть десятки, сотни IT-продуктов и специализированных решений. В-третьих, эффективная работа отрасли строится на сложных и интенсивных процессах обработки, анализа данных и создания отчетности.
Управление информационными ресурсами и анализ данных
Предприятия нефтегазовой отрасли могут сталкиваться с проблемой разрозненности большого количества бизнес-данных, их неструктированностью и быстрым устареванием, дублированием справочной информации, частыми изменениями в приложениях, недостоверной отчетностью, а также отсутствием единых стандартов и высокой стоимостью сопровождения используемых IT-систем.
При этом компании могут испытывать потребность:
Чтобы закрыть эти потребности, нужно комплексное решение по управлению данными на всем протяжении жизненного цикла, включающего методологию, сбор, обработку, хранение, управление, визуализацию, а также анализ и прогнозирование. С помощью инструментов анализа компании имеют возможность консолидировать данные и извлечь из них максимальную выгоду. Например, нефтегазовые компании могут прогнозировать добычу ресурсов, вести визуальный мониторинг, распознавание и классификацию объектов, проводить эффективное диагностическое обслуживание и оценку рисков.
Автоматизация процесса: платформа данных
Для максимальной эффективности процесса управления данными требуется ряд организационно-методологических и программно-технических решений.
Поскольку современные хранилища данных и аналитические системы для нефтегазовой отрасли все чаще представляют из себя сложные комплексные решения, команда IBS решила создать продукт, который объединял бы в себе все необходимые компоненты, имел модульную структуру, базировался на импортозамещенном стыке программного обеспечения. Так у IBS появилась собственная Платформа данных, решающая большую часть задач как предиктивной и регуляторной аналитики, так и в части хранения информации (Рис.1). Причем любой — структурированной, неструктурированной, больших и малых объемов.
Это комплексное инфраструктурное решение включает весь набор предопределенных компонентов, необходимых для:
Рис.1 Возможный вариант технической архитектуры 
Платформа данных IBS решает задачу по импортозамещению, так как абсолютное большинство компонент продукта составляют отечественные решения из Единого реестра российских программ для электронных вычислительных машин и баз данных. Кроме того, очень многие из них относятся к Open Source-приложениям (с открытым исходным кодом). Также в Платформе используются универсальная масштабируемая платформа данных Arenadata и зарекомендовавшая себя на рынке разработка IBS – платформа «Планета.Аналитика» (Рис.2).
Рис.2 Возможный вариант технической архитектуры 
Созданная Платформа данных может вмещать несколько модулей или работать без любого (любых) из них — количество легко варьируется в зависимости от потребностей бизнеса. Благодаря гибкости и масштабируемости она способна решать самый широкий спектр задач.
Важно отметить, что это не программный, а больше консалтинговый продукт. Команда IBS собирает, внедряет и настраивает все компоненты, исходя из нужд заказчика.
Основные компоненты системы: четыре модуля — четыре возможности
При разработке архитектуры решения команда экспертов IBS руководствовалась основными принципами, сформулированными Международной ассоциацией управления данными DAMA International. Поэтому в Платформе данных четыре больших блока: интеграционный слой, слой хранилища данных, слой аналитических сервисов и управления данными (Рис.3). Можно подключать все из них или только то, в чем есть необходимость на данный момент.
Рис.3 Концептуальная архитектура Платформы данных 
Первый модуль — это интеграционный слой. Он предназначен для взаимодействия с источниками данных, реализации внутренних алгоритмов в режиме реального времени и по расписанию, выстраивания оркестрациии и мониторинга интеграционных процессов.
В слое хранилища данных хранится информация, полученная из различных внешних и внутренних источников (системы промысловых данных, капитальное строительство, геолокация и разработка, финансовые системы, корпоративные системы управления, нормативно-справочная информация и др.). При этом данные не изменяемы, историчны и распределяются по «температурным слоям» в зависимости от требований к доступности.
Слой аналитических сервисов — это набор средств визуализации, библиотек машинного обучения, областей проведения экспериментов с данными и разработки сервисов.
В блоке управления данными происходит отслеживание качества и всего жизненного цикла данных. Там же хранится единое определение бизнес-терминов.
Чтобы лучше понять функциональность модулей, стоит остановиться на каждом подробнее.
Интеграционный слой
Компоненты этого модуля забирают данные из разных источников, перекладывают полученную информацию и выполняют алгоритмическую обработку (Рис. 4).
Рис.4 Интеграционный слой 
В Платформе данных интеграционный слой важен для проектирования и поддержки основных типов источников данных и методологий взаимодействия. Технология и подход к интеграции в каждом случае должен выбираться на основе анализа функциональных и нефункциональных требований к конкретному потоку. В целом Платформа может поддерживать весь спектр возникающих интеграционных задач.
Слой хранилища данных
Задача модуля — обеспечение хранения данных в соответствии с требованиями к составу, структуре, гранулярности, историчности для подготовки отчетов и проведения анализа. Хранилище данных может честно показать, что происходит в системе и что происходит на предприятии.
В этом слое объединены несколько баз данных для разных нужд и целей:
Рис. 5 Слой хранилища данных 
В слое хранилища есть база данных так называемого «холодного хранения», где лежит информация, нужная не часто (Рис. 5). Как правило, это большие объемы данных за большой период времени, к которому редко обращаются и в которых так же редко происходят какие-либо изменения.
Выше устанавливается база данных «теплого хранения» — ARENADATA DB — российское решение на базе продукта компании Greenplum. Здесь хранятся «нормальные» данные, средние по объему, к которым могут часто обращаться, но в которых редко происходят изменения, или к которым редко обращаются, но в них часто происходят изменения.
Обе системы горизонтально масштабируются: можно использовать дополнительные серверы и за счет их мощностей увеличивать производительность. Средние объемы, которые могут храниться на этом уровне составляют порядка пяти петабайт (5242880 гигабайт) данных.
Третий уровень, так называемый «горячий». Как правило, там хранятся витринные данные, на которых строятся отчеты, выгрузки, которые нужны очень быстро, но по объему относительно небольшие. Для Платформы используется решение ClickHouse от «Яндекса».
Слой аналитических сервисов
Аналитический сервис — это программный продукт, представляющий из себя отчеты, сервисы прогнозной аналитики, набор метрик для самостоятельного создания информационных панелей.
По сути, этот модуль — транс-аналитическая система — то, с чем работают конечные пользователи. На текущий момент здесь можно выделить несколько блоков.
Первый блок — это классическая отчетность: регуляторная, управленческая, а также информационные и аналитические панели, которые помогают руководству принимать управленческие решения. Это большая классическая отчетная аналитика.
Во втором блоке находятся предиктивная аналитика, Data Science, машинное обучение — специально для потребителей данных, которые смотрят в будущее, стараются прогнозировать, делать лучше, выявлять явные закономерности и т.д.
Еще стоит упомянуть большой блок процессов управления. Здесь особенно интересны геопроцессинг — управление командной разработкой — и блок внешней интеграции с различными приложениями, ведь хранилище не только потребляет данные, но может отдавать их во вне.
Рис. 6 Умные сервисы 
В слой аналитических сервисов входят (Рис. 6):
Модуль включает все необходимые инструменты для интеллектуального анализа данных, прогнозирования, визуализации и сценарного моделирования. Аналитический центр обеспечивает поддержку принятия управленческих решений, оперативный мониторинг достижения целевых показателей эффективности подразделений и организации в целом.
Управление данными
Управление данными — процесс, обеспечивающий контроль за успешным выполнением всех инициатив, связанных с данными, путем формирования целей, организационных изменений и создания политик и стандартов.
В Платформе от IBS система управления данными включает модуль жизненного цикла данных, глоссарий данных, модули справочной информации и контроля качества данных. Обеспечение качества данных — это планирование, организация и контроль выполнения работ по применению методов управления качеством в целях обеспечения пригодности данных к использованию (Рис. 7).
Основные аспекты качества данных: полнота (отсутствие пробелов); правильность (корректность, точность, достоверность); непротиворечивость (согласованность, целостность, уникальность); актуальность (своевременность обновления или реагирования); доступность, возможность использования (годность); безопасность (защищенность).
Рис. 7 Управление данными 
Цели качества данных:
Что касается стратегии управления данными, то в нее входят принципы классификации данных и критерии качества данных, принципы и цели управления данными, жизненный цикл данных, требования к организации управления данными, базовые требования для разработки архитектуры данных и базовые процессы управления данными.
Еще один важный и большой блок в модуле управления данными — Data Governance. Ее бизнес-задача – обеспечение организационного процесса управления корпоративными данными как активом организации. Это достаточно молодое направление, имеющее свою методологическую часть, собственные стратегии и решения. Оно может закрывать возможную потребность компании в монетизации данных.
Если рассматривать данные как актив компании наравне с заводами, произведенными продуктами и проч., то они представляют сопоставимую ценность. Самый простой вариант — продажа или торговля данными. Например, компания получает много геологоразведочных данных, которыми может обмениваться с другими, делиться полученной информацией. Пропуская их через модуль Data Science, можно узнать, например, что в конкретных точках нет нефти, но с высокой вероятность есть уран. Тогда можно продать эти данные заинтересованным компаниям. Data Governance помогает и с неявной монетизацией. Постоянный мониторинг данных, оптимизация процессов компании экономят значительные материальные ресурсы и повышают экономическую эффективность.
Бизнес-эффекты, технологические и функциональные преимущества для компаний нефтегазовой отрасли
Платформа данных, разработанная экспертами IBS, представляет собой надежную кастомизированную инфраструктуру, адаптивную к целям, задачам и потребностям различных предприятий. Система способна решать самые сложные задачи по обработке данных любого формата и объема, хранению, управлению, аналитике и интеграции.
Эффективное использование данных улучшает работу предприятия нефтегазового сегмента, сокращает излишние расходы, увеличивает эффективность добычи нефти и газа на действующих месторождениях, повышает безопасность и многое другое. А определить значимые данные, выбрать и настроить необходимые модули, построить и проверить гипотезы, используя аналитические решения, поможет проверенный внешний партнер.
Результаты использования Платформы данных:
Новая интеграционная стратегия
Возможно, планомерная реализация этой стратегии сможет положить конец многочисленным жалобам на медлительность и негибкость ИТ-отдела.
 |
| «Просто подсчитайте, сколько точечных соединений приходится на одну систему, и вы сможете почти наверняка определить, какой сервис будет у вас наиболее востребованным», — Мэтт Мишевски, ИТ-директор администрации штата Висконсин |
Много лет Мэтт Мишевски, ИТ-директор администрации штата Висконсин, пытался обсудить с руководством своего ведомства вопрос об интеграции систем. И каждый раз происходило одно и то же. «Как только они слышали о проблемах интеграции, то сразу же делали вид, будто ничего не видят и не понимают», — говорит он.
Более того, руководство считает, что трудности, возникающие при интеграции систем, — всего лишь очередная попытка ИТ-отдела оправдать свою медлительность, негибкость и неспособность решить поставленные задачи.
И Мишевски не за что винить начальство. Из-за технических и временных ограничений интеграция очень часто проводится бессистемно, впопыхах. Пытаясь уложиться в поставленные сроки, разработчики очень часто следуют принципам точечной интеграции, когда для обмена данными и принципами бизнес-логики между приложениями просто создаются прямые ссылки.
Данный вид интеграции на первый взгляд отличается быстротой и относительной простотой, однако со временем он подрывает функциональность и гибкость большинства ИТ-архитектур. В результате получается паутина из сотен, даже тысяч, неустойчивых точечных соединений, каждое из которых при смене хотя бы одного приложения приходится удалять и восстанавливать заново.
 |
| «Мало кто заботится о развитии уже существующих систем. И даже если их прижать к стенке, они вряд ли будут в состоянии разработать наилучший возможный интерфейс, а сделают ровно столько, чтобы можно было сказать, что работа выполнена», — Шадман Зафар, старший вице-президент по вопросам архитектуры и электронных сервисов компании Verizon |
Все эти точечные соединения, выстраиваемые десятки лет, стали причиной кризиса, который затронул не только ИТ-отделы. При массовом распространении Internet- и Web-технологий любые нововведения в компании невозможны без участия ИТ-отдела. Эти нововведения зачастую основываются на старых системах, при разработке которых не учитывалась возможность обмена данными, не говоря о создании единой глобальной сети. И пока ИТ-отдел будет распутывать провода в надежде найти хоть какое-то мало-мальски приемлемое интеграционное решение, целые поколения коммерческих возможностей (таких, как новая продукция, объединения, слияния и приобретение пакетов акций) устареют. Будучи не в состоянии объяснить сложность проблемы, ИТ-руководители вынуждены занимать оборонительную позицию. И только наиболее терпеливые и грамотные в технических вопросах генеральные директора могут посочувствовать им. Однако для того, чтобы преуспеть, необходимо быстро действовать. Времена Эзопа остались далеко в прошлом.
Безотлагательность и сложность решения этого вопроса отражена в исследовании «Положение ИТ-директора». В 2002 году, когда было проведено первое исследование, интеграция была признана наиболее важной технологической проблемой, стоящей перед ИТ-руководителем. (То же повторилось и в 2004 году.) При этом претензии генеральных директоров к ИТ-службе оставались неизменными: высокая затратная часть, медлительность и негибкость.
И у всех этих проблем причина одна — незавершенность или неэффективность интеграции.
Короче говоря, руководителям компаний надоело ждать, пока ИТ-служба справится с поставленными перед нею задачами.
Но и самих ИТ-руководителей такое состояние дел устраивает мало.
Как интеграционный слой поможет решить проблемы
Высокие затраты на системную интеграцию доставили много хлопот не одному поколению ИТ-руководителей. И практически ни у кого из них не было единой стратегии распределения средств при проведении интеграционных работ. Однако некоторое время назад на основе появившихся технологий была выработана новая стратегия, в основу которой легли уже существующие концепции и принципы работы. Реализация этой стратегии поможет не только значительно упростить существующие запутанные системы, но и радикально улучшить эффективность работы всего ИТ-отдела (в том числе снизить затратную часть интеграционных работ). Основная идея заключается во внедрении промежуточного уровня, своего рода виртуальной прослойки в ИТ-архитектуре, которая бы объединила две структуры — обмен сообщениями и сервисы.
Инфраструктура обмена сообщениями, лежащая в основе интеграционного процесса, подобна аккуратному исполнительному помощнику, переводящему, распределяющему и отслеживающему информацию, поступающую от разных систем, зачастую не соединенных друг с другом напрямую. Кроме того, при смене или удалении одной системы разработчику требуется всего лишь изменить одну ссылку, а не перестраивать целую сеть точечных соединений между различными приложениями.
Технология обмена сообщениями действительно упрощает процесс системной интеграции. Однако она не поможет выйти за рамки ограничения, накладываемого на бизнес-процессы мэйнфреймами, не обеспечит возможность сократить количество необходимых приложений или создать эффективную архитектуру. В самом деле, при всех своих достоинствах инфраструктура обмена сообщениями имеет и минусы: упрощая процесс работы с беспорядочной системой различных приложений, она не дает мотивации к усовершенствованиям, а, наоборот, делает хаос привычным состоянием.
Разумеется, не в каждой компании требуется большое количество систем и процессов. И в этом случае инфраструктура обмена сообщениями может быть вполне подходящим решением. Однако для большинства компаний, особенно крупных, в которых уживаются десятки различных ERP-систем, эта технология не сможет создать эффективный интеграционный слой.
Обмен сообщениями может быть использован в качестве ИТ-решения, но никак не является средством достижения стратегических целей, стоящих перед компанией. У информационных технологий очень долго не было так называемого «высшего предназначения», то есть стратегии применения. Теперь же эта стратегия выработана и в ее основе лежит концепция, сформулированная еще во времена объектно-ориентированного программирования в 80-х годах. Эта концепция фомулируется следующим образом: технология должна быть скорее элементом бизнес-процесса, такого как, например, «получение кредита» или «поиск клиента», нежели некой загадочной системой вроде ERP или CRM.
Объектное программирование
Сервис, применяемый в телекоммуникационной компании Verizon, называется «get CSR» (получить клиентскую запись) и представляет собой сложный комплекс действий, выполняемых программным обеспечением. Для доступа данного сервиса к более чем 25 системам, находящимся в четырех информационных центрах компании Verizon по всей стране, используется инфраструктура обмена сообщениями. До создания сервиса «get CSR» разработчикам Verizon приходилось выстраивать системные маршруты от каждого нового приложения ко всем 25 системам, добавляя все новые и новые подсоединения к уже существующей сети.
Теперь с внедрением «get CSR» разработчики создают единый маршрут к аккуратно выстроенному интерфейсу, который взаимодействует с самим сервисом с помощью простого протокола доступа (SOAP). Именно по этому маршруту сведения о клиентах из всех
25 систем поступают в новые приложения. Таким образом, каждое обращение к данному сервису позволяет сэкономить разработчикам месяцы, а то и годы.
Достоинства подобных решений ИТ-службы очевидны, но не менее важны стратегические преимущества, которые получила компания Verizon. Создание достаточного количества сервисов позволяет построить технологическую структуру коммерческой деятельности предприятия, а именно SOA. Для этого требуется разработать промежуточный уровень, состоящий из двух основных элементов: инфраструктуры обмена сообщениями и сервисов. По сути SOA является отражением всех бизнес- и технологических процессов, протекающих в компании. Кроме того, эта технология позволяет руководителям компании самим увидеть структуру своей компании с точки зрения используемых технологических решений.
«Мои руководители смогли понять, в чем заключается истинная причина возникновения многочисленных неполадок, когда я объяснил, что у нас есть, например, восемнадцать слегка отличающихся друг от друга версий функции «проверка кредита», используемых в различных приложениях, — говорит Мишевски. — И они поддержали меня, когда я предложил создать единую универсальную версию для всеобщего использования».
Тоби Редшоу, вице-президент по вопросам корпоративной ИТ-стратегии, архитектуры и электронного бизнеса компании Motorola услышал нечто подобное от своей 80-летней матери, когда попытался объяснить ей принцип построения единого ИТ-каталога бизнес-сервисов. «После того как я закончил свои объяснения, она сказала: «Разделение труда на производстве появилось 200 лет назад. Почему же ты так долго медлил?”»
«Когда промежуточный уровень содержит сервисы, на смену политики компании уйдет меньше времени, чем на создание нового проекта в приложении», — говорит Рэнди Хеффнер, вице-президент Forrester Research. Интеграция, таким образом, приобретает более важное стратегическое значение, нежели это можно было предположить. «Используя бизнес-сервисы, мы принимаем непосредственное участие в построении структуры деятельности нашей компании. А это — чрезвычайно ответственная задача, и ее нельзя поручать наспех созданным группам разработчиков, находящимся в условиях жесткой нехватки времени», — добавляет Хеффнер.
Процесс интеграции не только становится стратегической задачей, но и позволяет в значительной степени сократить финансовые (согласно оценкам компании Gartner, как минимум на 30 %) и временные затраты. По отзывам самих участников процесса экономия действительно превышает все ожидания. Редшоу из компании Motorola утверждает, что затраты на интеграцию сократились в десять раз по сравнению с прежними показателями. Шадман Зафар, старший вице-президент по вопросам архитектуры и электронных сервисов компании Verizon, говорит, что его каталог сервисов недавно позволил избежать создания группы специалистов для размещения заказов по телефону, так как все необходимые сервисы уже были готовы. «Если бы мы работали по системе точечной интеграции, нам бы пришлось создать центральную группу разработчиков для осуществления общего процесса интеграции нескольких систем и несколько местных группы, которые бы работали над каждой отдельной системой. В данном случае у нас была всего лишь одна группа, которая занималась исключительно тестированием маршрута передачи данных». Таким образом, данное решение позволяет не только сэкономить время и ресурсы, но и улучшить качество новых продуктов, так как тестирование теперь становится не последним препятствием в утомительном процессе внедрения нового приложения, а, наоборот, его целью.
При успешном внедрении подобной схемы генеральный директор более не будет изнывать от нетерпения, кляня ИТ-отдел за его медлительность, скорее, ждать теперь придется ИТ-директору, пока его руководство осознает необходимость внедрения новых бизнес-процессов и технологий.
Централизация руководства
Ни одну задачу, стоящую перед ИТ-отделом, нельзя назвать простой, даже если речь идет о создании промежуточного уровня. Цель данной стратегии заключается в ликвидации лишних систем и приложений путем введения минимально возможного количества инфраструктур обмена сообщениями и формировании единого архива сервисов. Именно поэтому при создании промежуточного уровня централизованное руководство становится особенно необходимым.
«SOA не является технологией. Это всего лишь структура, своего рода шаблон, и если вы не будете полностью контролировать ее внедрение и применение в организации, вам никогда не удастся выстроить настоящую сервис-ориентированную архитектуру. Существуют миллионы вариантов построения промежуточного уровня в корпоративной системе, но из них вам необходимо выбрать один, оптимальный», — говорит Рик Свини, главный архитектор Blue Cross and Blue Shield штата Массачусетс.
Например, компания Verizon, офисы которой находятся друг от друга на приличном расстоянии, располагает единой бизнес- и ИТ-моделью для всех подразделений, благодаря чему в компании никогда не возникало конфликтов при внедрении промежуточного уровня или реализации стратегии SOA. При разработке корпоративной стратегии одна из главных задач заключалась в ликвидации многообразия систем, возникшего после слияния с другими телекоммуникационными компаниями, такими, как GTE и Nynex.
И эта задача была не из легких. Когда в 2001 году команда Зафара начала выбирать наилучший вариант из имеющихся систем, им пришлось просмотреть каждую клавишу и ниспадающее меню в каждом приложении (которых всего было почти 2900) для того, чтобы найти функциональные элементы, которые могли бы быть использованы при разработке сервиса. Из тысяч функций было выбрано где-то между 200 и 500, необходимых для более чем 90 тыс. транзакций, выполняемых компанией. Затем при тщательной проверке инфраструктур было выявлено от 5 до 25 прототипов каждой функции. Зафар остался доволен проделанной работой, так же как генеральный директор Шайган Керадпир и другие руководители Verizon, которые на деле убедились в эффективности стратегии внедрения промежуточного слоя.
Проблема с разработчиками
Как ни странно, стратегия использования сервисов, несмотря на свои очевидные преимущества, может не пользоваться популярностью среди самих разработчиков. «Разработчики хотят простых решений», — говорит Клинт Пети, директор компании CommerceQuest, занимающейся обслуживанием программного обеспечения и разработкой сервисов.
С первого взгляда разработка сервиса — далеко не самое простое решение. Помимо всего прочего необходимы определенные затраты времени для создания интерфейса — того самого элемента, который наглядно демонстрирует, какую функцию выполняет данный сервис и с какими системами он взаимодействует. Удачный интерфейс подобен хорошему другу: прост в общении и не выказывает ни намека на сложную историю взаимоотношений. «Хороший сервис умеет сам определить своего пользователя и представиться ему», — говорит Джеф Глисон, директор по ИТ-стратегиям отдела финансовых рынков компании Transamerica Life Insurance and Annuity. — Интерфейс интеграционного сервиса должен быть интеллектуальным и коммуникабельным».
Разработчикам, создающим ссылки на хороший интерфейс, необходимо задать только основной коммуникационный код, своеобразную программную версию рукопожатия и приветствия. Все остальное сделает сам сервис. Разработчику вовсе не обязательно знать все составные элементы сервиса, язык программирования, на котором он написан, или даже принципы его работы. Все, что ему нужно, — понимать функциональное назначение данного сервиса.
Однако при построении данных интерфейсов разработчикам требуется определенная мотивация. «Все думают только о том, как бы поскорее запустить новое приложение в работу, — говорит Зафар из Verizon’s. — Мало кто заботится о развитии уже существующих систем. И даже если их прижать к стенке, они вряд ли будут в состоянии разработать наилучший возможный интерфейс, а сделают ровно столько, чтобы можно было сказать, что работа выполнена».
Зафар был первым, кто создал централизованную методологию разработки и хранения сервисов. Его принцип взаимодействия с разработчиками прост: он делает обзор существующей архитектуры в начале каждого проекта (чтобы взять с них слово, что во время работы над проектом они не только будут создавать новые сервисы, но и применять существующие) и по его завершении (чтобы выяснить, кто из разработчиков смог сдержать свое слово). Когда Зафар приступил к разработке каталога сервисов (известного в компании Verizon под названием «Рабочая панель ИТ») в 2001 году, многие разработчики так и не смогли выполнить свое обещание. «Нам даже пришлось свернуть несколько проектов, — говорит он. — Люди же смогли уяснить, что для успешной работы им необходимо использовать практические достижения, имеющиеся в компании».
По мере роста каталога в ход шли более привлекательные средства мотивации. Несмотря на то, что методология разработки имеет жестко централизованный характер, Зафар говорит, что самые удачные предложения по улучшению качества работы, поступающие от сотрудников, учитываются при определении общей методологии. На соответствующем Web-сайте Зафар регулярно выкладывает данные по наиболее часто используемым сервисам и приводит имена их разработчиков. Кроме того, Verizon предоставляет внешним партнерам доступ к некоторым своим Web-приложениям, поэтому шансы отдельного разработчика прославиться не только внутри своей компании, но и за ее пределами значительно возрастают. «Мы используем принцип гласности, — говорит Зафар. — Люди будут гордиться тем, что их разработки используются другими».
Однако перед тем как отдавать сервисы в пользование другим компаниям, необходимо удостовериться, что произведенный продукт является жизнеспособным и не приведет к сбоям в работе своих же приложений и процессов. (Это может произойти, например, когда сервис, предназначенный для выполнения 10 тыс. транзакций в день, подключается к приложению, выполняющему более 20 тыс. транзакций.) Централизованная структура управления не очень-то приветствуется разработчиками, однако она является гарантией того, что вся работа выполняется качественно и в соответствии с принятыми в компании стандартами. К этому Зафар еще добавляет гарантии уровня услуг, включающего предельное количество выполняемых транзакций, скорость выполнения транзакции, сроки доступности сервиса, а также стоимость предоставляемых услуг. «Пока в вашей компании не будет выстроена четкая структура разработки и внедрения, никто не будет воспринимать ваши сервисы как ключ к решению стратегических задач, — говорит Зафар. — Именно поэтому даже сейчас во многих компаниях SOA используется крайне неэффективно».
Подходит ли вам интеграционный уровень?
Поставив цель внедрить SOA в своей компании, необходимо определить, является ли данная задача долгосрочной или среднесрочной. В силу того, что инфраструктура обмена сообщениями необходима для поддержки большего количества сервисов и элементов SOA, компании, как правило, начинают с внедрения именной этой технологии. Обычно этого бывает вполне достаточно.
«Все расхваливают SOA как панацею, — рассказывает Ли Джонс, вице-президент по ИТ и ИТ-директор компании Stratex Networks, производителя беспроводного телефонного оборудования. — Идея глобального интерфейса до сих пор представляется мне сомнительной. Я не рассматриваю это решение как средство унификации моих приложений, потому как все мои системы работают бесперебойно». Джонс говорит, что ему удалось сократить расходы на интеграцию и повысить гибкость за счет интеллектуального промежуточного оборудования и минимизации сложных нестандартных приложений. Тем не менее он говорит: «Если у меня возникнут проблемы с интеграцией, SOA вполне может стать хорошим решением. Я буду рад, если мои сомнения окажутся напрасными».
Для ИТ-руководителей более крупных компаний хорошим подтверждением эффективности SOA может служить сокращение количества запутанных сетей, составлявших их системы. «Просто подсчитайте, сколько точечных соединений приходится на одну систему, и вы сможете почти наверняка определить, какой сервис будет у вас наиболее востребованным», — говорит Мишевски из Висконсина. Именно так он выбирал свой первый пилотный сервис, который встроен в одну из систем департамента транспорта и отвечает за преобразование адресов в указатели на графической карте. Поначалу руководители департамента испытывали сильное беспокойство по поводу успешности данного проекта, их волновала возможность сбоев при повышенных нагрузках, а также риск потери контроля над системой. Подобные опасения типичны для тех, кто начинает использовать технологию сервисов впервые. Однако «после того как мы запустили в работу еще два или три сервиса, все сомнения развеялись, — говорит Мишевски. — Как только становятся очевидны экономия средств и повышение качества работы, процесс внедрения новых технологий значительно упрощается».
При использовании сервисов в качестве отдельных элементов в традиционных приложениях затраты времени и средств действительно могут быть значительно сокращены. Однако наибольшую пользу данная технология приносит при использовании в качестве основы важного бизнес-процесса, охватывающего компанию в целом. В Verizon процесс размещения заказов целиком построен на сервисах, каждый из которых отвечает за выполнение своей конкретной задачи. Процесс начинается с момента поступления информации о клиенте в сервис подтверждения данных о кредитной карте. Сервис подтверждения адреса позволяет определить, может ли Verizon предоставить услуги телефонной связи клиенту, проживающему по конкретному адресу. Далее сервис резервирования определяет и закрепляет за клиентом новый номер телефона. Сервис активации линии производит запуск новой телефоннй линии. И, наконец, сервис оформления счетов за услуги собирает данные об использовании линии и подсчитывает, какую сумму следует заплатить за предоставленные услуги. (А если у клиента возникнут неполадки при использовании новой линии, будет запущен еще один сервис — тестирование линии.)
Тем не менее, не каждое действие в процессе заказа в компании Verizon может быть выполнено с помощью автоматизированного сервиса. Участие людей по-прежнему необходимо. Конкретно в данном случае границы между сферой, полностью обслуживаемой сервисом, и сферой, требующей вмешательства персонала, отмечены специальными уведомлениями. Например, если клиент пытается зарегистрировать новый счет, но компания Verizon еще не обслуживает район, в котором он проживает, система отправит специальное уведомление в региональное представительство. Таким образом местные представители будут знать о потенциальном клиенте и смогут связаться с ним, когда его район будет включен в зону обслуживания компании.
Последние шаги
Для каждого бизнес-процесса существует своя отправная точка. Такие точки называются событиями. Например, можно запрограммировать, что при определенном событии региональному сервисному представителю будет отправлено по электронной почте уведомление («чтобы сообщить о том, что на данный момент его район находится вне зоны обслуживания»), либо запустится определенный сервис («найти новый номер»). События, как, впрочем, и сервисы, проще описать на деловом, нежели на техническом языке.
Если сервисы отражают конкретные бизнес- функции, то события определяют условия, при которых данные функции выполняются. По мнению Дэвида Лукхэма, заслуженного профессора в отставке по техническим исследованиям Стэнфордского университета и пионера событийно-ориентированного программирования, бизнес-процессы во многих компаниях используются крайне нерационально. Истинная ценность сервис-ориентированных процессов становится очевидна только при их соответствии событиям, происходящим в компании. По прогнозу Роя Шульта, аналитика компании Gartner, эти возможности начнут более активно использоваться в 2007 году, когда станут появляться стандарты для так называемого «комплексного обмена сообщениями о событиях».
Однако полное использование возможностей промежуточного уровня начнется, только когда эта задача интеграции перейдет в ведение бизнес-руководителей предприятия. Теоретически, в силу того, что связь между сервисами и услугами становится более упрощенной и наглядной, бизнес-специалисты смогут самостоятельно выстраивать и модифицировать проекты через специальный интерфейс.
Данная модель уже используется поставщиками программного обеспечения в управлении бизнес-процессами (см. статью Бена Уортена «Был бы ботинок, а клей найдется?!», Директор ИС, № 3 за 2005 год). Однако доступные пакеты еще не в состоянии обеспечить полную передачу управления SOA в руки бизнес-руководителей.
Когда же необходимое программное обеспечение появится, последний барьер между ИТ-отделом и бизнес-подразделениями компаний (иначе говоря — чувство, испытываемое всеми без исключения руководителями компаний, что они не в состоянии контролировать ход событий) исчезнет. Разумеется, для этого потребуется время, но с развитием стандартов Web-сервисов, ИТ-руководители смогут сами приблизить этот момент.
«В процесс разработки новых решений мы хотели бы наладить со своим руководством диалог. Традиционный подход: “Скажите, что вам надо, и мы это сделаем” становится пережитком прошлого», — говорит Редшоу.
Мишевски считает, что диалог будет весьма продуктивным для обеих сторон и не таким затруднительным, как может показаться на первый взгляд. «Эта технология поможет окончательно решить все проблемы, связанные с интеграцией. Это вопрос времени», — уверен Мэтт Мишевски.
CHRISTOPHER KOCH. Integration’s New Strategy. CIO MAGAZINE. SEPTEMBER 15, 2005
Эволюция интеграции
Четыре стадии готовности
1 Точечная интеграция
Точечной интеграцией называется процесс выстраивания индивидуального коммуникационного соединения между двумя приложениями. Такой вид интеграции всегда являлся традиционным (а до середины 80-х — единственным). Его отличает простота, скорость и низкая стоимость. Однако по мере ввода большего количества приложений и подсоединений инфраструктура, построенная на точечном принципе, постепенно превращается в запутанную сеть, к тому же недешевую в эксплуатации. При смене одного из приложений изменению подлежат все ссылки на прочие приложения, в противном случае инфраструктура не будет работать. Финансовые и генеральные директора могут об этом не знать, но, когда они жалуются на медлительность, негибкость и высокую стоимость ИТ, они называют типичные недостатки точечной интеграции.
2 Обмен сообщениями
Данный вид интеграции предполагает введение третьего элемента, как правило представляющего собой лицензионное промежуточное ПО. Этот элемент внедряется в инфраструктуру для управления коммуникационными процессами между различными приложениями. Таким образом, обмен сообщениями между приложениями происходит посредством специальной инфраструктуры, поэтому при смене одного из них нет необходимости переписывать все ссылки. Инфраструктура обмена сообщениями очень часто выстраивается как центральный канал, через который сообщения попадают по нужному адресу. Вроде бы все просто. Однако этот же канал может легко стать причиной многих неприятностей. Для его обслуживания требуется целый штат специалистов по созданию маршрутов, что в некоторой степени лишает разработчиков гибкости, которую они имели при точечной интеграции. Усовершенствование промежуточного ПО и Web-технологий может слегка облегчить их задачу. Например, с помощью Web-сервисов разработчики могут снова напрямую соединять отдельные приложения друг с другом. Однако технология обмена сообщениями все-таки остается тактическим решением стратегической проблемы.
3 Сервисы
Популярность этой концепции приходится на 80-е годы, а это было время развития объектно-ориентированного программирования. Свое перерождение она пережила в наше время, с внедрением Internet-стандартов и Web-услуг, а также усовершенствованием промежуточного ПО. Идея данной стратегии проста: технология должна быть скорее элементом бизнес-процесса, такого, как, например, «получение кредита» или «поиск клиента», нежели некой загадочной системой вроде ERP или CRM. Как правило, сервис представляет собой комплекс сокрытых под сложным интерфейсом различных приложений и данных, позволяющий легко соединять несколько сервисов друг с другом. Кроме того, созданный элемент критически важного бизнес-процесса может быть использован неоднократно при построении других процессов, что значительно сокращает время разработки. У разработчиков снова появляется гибкость, которой они располагали при точечной интеграции; ссылки, создаваемые теперь в оптимальном случае на основе Web-сервисов, могут легко удаляться и восстанавливаться. Более того, при таком подходе происходит внедрение сервис-ориентированной архитектуры (SOA): ИТ-отдел организует архив сервисов, которые разработчики могут использовать (и, что более важно, использовать неоднократно) для построения новых приложений и технологических процессов.
4 Бизнес-конфигурации
Обеспечьте достаточно сервисов в SOA-репозитарии — и создание ПО для бизнес-процессов более не будет для вас утомительным делом, требующим значительных финансовых вложений. Вам потребуется всего лишь выстроить правильную комбинацию из уже готовых сервисов с помощью стандартного коммуникационного программирования или даже без него. Преимущество этого решения в том, что бизнес-специалисты посредством единого интерфейса смогут сами создавать нужные им приложения без привлечения ИТ-службы, а интеграционная логика создается автоматически при соединении различных элементов. Таким образом, интеграция из элемента, всячески тормозящего деятельность компании, превратится в мощного союзника.
Трудности с Web-услугами
А вы смогли перевести критически важные для вашей компании транзакции в такую неустойчивую среду, как Web?
Некоторые ИТ-руководители спят и видят, как бы избавиться от всех своих поставщиков интеграционных решений и их инфраструктур обмена сообщений, заменив последние на бесплатные стандартные Web-сервисы. Это бы сразу же сняло такие извечные проблемы, как несовместимость платформ, высокая стоимость программного обеспечения и отсутствие связи с поставщиком 24 часа в сутки. Однако в данном случае ограничения все же есть. Они связаны со стандартами и транспортными системами, используемыми для осуществления Web-сервисов, а именно с самим Internet или, если быть более конкретными, протоколом HTTP.
Вспомните все случаи, когда вы безуспешно пытались зайти на сайт или отправить электронную почту, при этом не получая никакого пояснения или сообщения о неисправности. Будьте готовы к появлению подобного рода проблем. Отчасти они возникают из-за того, что стандарты Web-услуг еще не до конца проработаны и не могут обеспечить устойчивость и безопасность. Но помимо этого, сам Internet по своей природе является неустойчивой системой. Поэтому для обеспечения надежности передачи объектных услуг как внутри компании, так и за ее пределами одними Web-технологиями не обойтись.
Различные поставщики компенсируют недостатки Web-услуг с помощью продуктов, которые обеспечивают стабильность инфраструктуры обмена сообщениями и выстраивают интеграционную платформу для сервисов. Несмотря на то, что современный рынок все еще разделен на отдельные ниши, налицо тенденция к объединению. Теперь наряду с программным обеспечением поставщики предлагают дорогостоящие пакеты интеграционного ПО. Использование подобного рода продукции имеет свои минусы: финансовые вложения требуются немалые, но при этом качество работы оценить достаточно сложно, особенно на первых порах. Однако в обозримом будущем инвестиции в межплатформное программное обеспечение неизбежны.
Поделитесь материалом с коллегами и друзьями