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

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

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

В беседе приняли участие: Александр ГЕРШОЙГ, коммерческий директор компании Unitspace; Даниил ФЕЙГИН, технический директор компании Unitspace; Вячеслав АБРОСИМОВ, руководитель аналитической службы BCC Company; Анатолий ГАЙДАЙ, технический директор компании "Аплана"; Григорий СИЗОНЕНКО, генеральный директор ИВК; Валерий АНДРЕЕВ, директор по науке и развитию ИВК.

В крупных компаниях сегодня существуют "зоопарки" унаследованных систем. Что делать с этим разнообразием? Некоторые "радикалы" от ИТ предлагают "снести" все и начать строить системы с чистого листа.

Г. Сизоненко: Такой подход не решает проблему даже теоретически, ведь через несколько лет вы вернетесь к тому, от чего ушли. Только недальновидный хозяин выбрасывает все, что работало в компании прежде. У рачительного хозяина вложения в ИТ эффективно работают, а не влекут за собой новые затраты. Программисты говорят: "Софт" как коньяк, чем старше — тем лучше становится". Действительно, в таких приложениях уже практически все ошибки обнаружены, все коды исправлены, никаких неожиданностей в их работе не предвидится. Единственно разумным представляется решение интегрировать все "островки автоматизации"в единое информационное пространство организации.

В. Абросимов: Безусловно. Причем сразу хотелось бы развеять один из мифов о российских особенностях интеграции приложений. Зарубежные специалисты нередко утверждают, что интегрировать информационные ресурсы в России намного легче, чем на Западе, поскольку Россия якобы не прошла тот длинный и трудный путь, который вынужден проходить Запад, все время внедряя новые и новые стандарты и решения по интеграции. Россия, по утверждению заокеанских коллег, миновала этап длительного и сложного становления ИТ-отрасли, и теперь, внедряя решения, условно говоря, hi-end, якобы избавлена от многих проблем с интеграцией унаследованных систем. С такой точкой зрения трудно согласиться. Наоборот, в России огромное количество разноплановых унаследованных систем, и нам намного сложнее заниматься интеграционными процессами. И в этом контексте использование современных информационных технологий интеграции данных и приложений для нас просто жизненно необходимо. Более того, чем дольше мы будем игнорировать эти технологии, тем сложнее будет идти процесс интеграции, тем сильнее увеличится разрыв между потребностями и возможностями. "Дорогу осилит идущий", — говорит китайская мудрость.

Как только принимается решение об интеграции приложений, сразу встает вопрос: как это сделать?

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

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

Интеграция может происходить в любом из этих трех уровней. Интеграция на уровне баз данных обычно используется, когда достаточно обеспечить только обмен данными между приложениями. В то же время, когда обсуждаются проблемы и вопросы интеграции, чаще всего имеется в виду интеграция в среднем слое. Это подразумевает интеграцию на уровне бизнес-процессов. Как правило, здесь применяется специализированное ПО промежуточного слоя (middleware) или создаются решения под конкретную задачу. Примером интеграции на уровне пользовательского интерфейса является портал, который объединяет несколько приложений в один пользовательский интерфейс.

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

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

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

Д. Фейгин: Мы нередко сталкиваемся у заказчиков с интеграцией с использованием различного рода СУБД, когда одна система загружает данные куда-то, другая пытается их там найти и т. п. Через одну базу данных интегрированные приложения могут быть связаны как одно с другим, так и "сообществом". Это порождает множество проблем, поскольку описание схем баз данных, как правило, не ведется, для этого нет стандартных механизмов, формальные зависимости, таким образом, не "прописаны". Системы с течением времени меняются, и зависимости, если они не учтены, со временем нарушаются. До поры до времени это работает, но в целом способствует нарастанию хаоса в организациях.

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

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

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

Мы в последнее время активно работаем с заказчиками с использованием модели Захмана, который предлагает упорядоченно рассматривать архитектуру деятельности предприятия. В рамках модели Захмана необходимо найти ответы на шесть стандартных и понятных вопросов, которые, по существу, всегда интересуют любого бизнесмена: кто, что, где, как, когда и почему реализует то или иное решение. Эти вопросы можно условно рассматривать с нескольких сторон, выделяя, например:
- архитектуру деятельности;
- архитектуру приложений;
- архитектуру технических систем.

Мы сегодня ведем разговор в основном о построении архитектуры интеграции приложений, второй строке, но нельзя рассматривать вторую в отрыве от первой. Более того — если вы хотите осуществить интеграцию приложений, то вы сначала должны понять, зачем вам это надо. Конечно, на интуитивном уровне такое понимание, как правило, есть: надо все интегрировать. Но встает вопрос: зачем? Какую целевую установку вы при этом преследуете? Ответ обычно бывает размыто-воодушевленным, под олимпийским девизом: "Быстрее, выше, сильнее". Начинаем добиваться конкретики, задаем вопросы "по Захману": кто интегрирует, что интегрируется, где планируется интегрировать? Какие бизнес-процессы и каким образом будут обеспечиваться и поддерживаться в результате интеграции? И только дойдя до вопроса "как", можно рассматривать варианты решений. Но нельзя рассматривать интеграцию систем в отрыве от бизнеса компании.

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

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

Играют роль и традиции. Запад привык к рабочим группам, к горизонтальной системе управления. У нас глубоко укоренилась иерархическая структура. Понятно, что иногда она бывает неэффективна. С другой стороны, миллионы людей именно так воспитаны и работают, невозможно в одночасье их перестроить и добиться того, чтобы руководители разных уровней добровольно согласились стать "винтиками"в механизме бизнес-процесса. Это неприятие проявляется и на уровне корпоративной культуры, и на личностном уровне. Поэтому фактически бизнес-процессы используются или глубоко внутри организации, или в компаниях, создаваемых с нуля по западному образцу, в большинстве случаев — с привлечением западных менеджеров. В организациях, чья история уходит в советское прошлое, это сделать крайне тяжело, и, наверное, эта инерция сохранится на многие десятилетия. Причем, повторюсь, в той области, где есть взаимоотношения с клиентами, проблема будет особенно сложной, потому что нельзя экспериментировать на собственных клиентах. Нельзя попробовать внедрить систему бизнес-процессов, распугать клиентов, а потом задуматься — а правильно ли мы поступили? Это, конечно, несколько утрированный взгляд, но в каждой шутке есть доля правды.

Формы управленческих структур — очень интересная тема, но это "боковая ветвь"нашей сегодняшней беседы. Мы немного отклонились от основной темы. А говорили мы об интеграции приложений.

Д. Фейгин: Универсального технологического рецепта интеграции приложений не существует. На сегодняшний день есть очень много разных технологий интеграции, которые предназначены для разных ситуаций и разных компаний. Чтобы определить, какой должна быть интеграция, нужно идентифицировать необходимые характеристики решения. Они могут состоять из различных измерений, таких, как безопасность, надежность, адаптивность (устойчивость к изменениям), масштабируемость. Исходя из них, формируется архитектура интеграции, имеющая определяющее значение, и возможные необходимые средства интеграции.

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

Конечно, полученное решение не будет очень гибким и расширяемым, но решит задачу интеграции в данной конкретной ситуации. С другой стороны, к тому моменту, когда возникнет реальная необходимость внедрения интеграционной платформы, стандарты и подходы могут и измениться — в первую очередь, внутри самой организации.

В. Андреев: Есть два популярных подхода к интеграции приложений: использование шлюзов и встраивание механизмов взаимодействия непосредственно в прикладные программы. Эти подходы кажутся настолько естественными, что ими начинают активно пользоваться, не задумываясь о последствиях.

Для организации взаимодействия приложений можно создать так называемый шлюз — специальную программу, написанную под конкретную задачу взаимодействия и использующую все специфические возможности каждого из приложений. Если таких программ немного, то этот подход на определенном этапе приемлем, но когда количество взаимодействующих программ растет, гораздо быстрее растет количество связей между ними — пропорционально квадрату числа взаимодействующих элементов. Так, если в системе, скажем, около 100 приложений, то количество связей между ними будет уже порядка 5 000. Поддержка и управление развитием всего набора многих тысяч, а то и миллионов уникальных шлюзов является практически невыполнимой задачей. Коренная переработка шлюзов может потребоваться и в случае, если некоторые из приложений, ранее работавших рядом, позже окажутся территориально разнесены. Шлюзы не только надо будет переписывать, но и превращать их в территориально-распределенные.

Если же встраивать средства взаимодействия непосредственно в прикладные программы, они начинают усложняться, выполняя все больше функций, которые с первоначальной задачей никак не связаны. Нужно поддерживать разнообразные коммуникационные протоколы и различные форматы данных, учитывать особенности вычислительных платформ и возможность отказа технических и программных частей системы, обеспечивать надежную передачу данных. Разнообразие и сложность этих задач возрастают настолько, что собственно функциональная часть программы составит 10% кода, а остальные 90% будут приходиться на код системного уровня. Для создания и поддержки этого системного кода потребуется гораздо более квалифицированный разработчик. Причем этот код никоим образом не связан с той задачей, для решения которой приложение создавалось.

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

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

А. Гайдай: Сейчас найти "волшебное" средство, которое бы интегрировало все возможные приложения, при этом стоило дешево и практически не требовало настройки, невозможно. Ближе всего к такой широте охвата подходят веб-сервисы. Они начинают встраиваться во все большее число программных продуктов, от самых "тяжелых" до самых "легких". Сами вендоры начинают предлагать веб-сервисы как средство для интеграции. Другой вопрос, что внутри этих программных продуктов должен быть целый слой приложений, которые должны заниматься интеграцией. Но сегодня у каждого вендора есть такой продукт, который занимается только интеграцией; обычно в этот продукт еще встроены некие средства, позволяющие этим управлять, то есть из веб-сервисов выстраивать бизнес-процессы.

На мой взгляд, самый лучший способ интеграции унаследованных приложений — написать к ним некую "оболочку", которая преобразует вызовы внутреннего API (application programming interfaces, интерфейс приложения, обеспечивающий доступ к его внутренним функциям) в веб-сервисы. Это позволит приложению существовать достаточно долго, потому что стандарт веб-сервисов, скорее всего, тоже будет существовать достаточно долго, и проблемы с интеграцией будут сняты.

С другой стороны, мы сейчас говорим о технологических стандартах, а ведь есть еще стандарты отраслевые, с учетом которых нужно подбирать решение в каждом конкретном случае.

Д. Фейгин: Все большее распространение получает архитектура интеграции, основанная на сервисах (SOA). Ее активно и, на мой взгляд, небезосновательно, продвигают все представленные в России вендоры: IBM, BEA, Oracle, CA, HP, Microsoft, SAP, Sun и др. — продукты которых обеспечивают интеграцию на основе SOA. Это архитектура организации информационных систем, для которой поддержка взаимодействия является неотъемлемым свойством, вытекающим из самого определения сервисов, — доступных по сети элементов информационных систем.

При текущем уровне развития стандартов веб-сервисов и поддерживающих их инструментов (брокеров, Enterprise Service Bus, серверов приложений и пр.) можно создать отвечающую самым жестким требованиям корпоративную SOA и методы управления ею — все зависит только от дальновидности ИТ-менеджеров. Не случайно в последнее время в российской прессе так много пишут о SOA. Конечно, и стандарты, и возможности программной инфраструктуры не перестанут развиваться. В частности, в 2006 году выйдут спецификация OASIS BPEL 2.0, важные дополнения к UDDI 3, консолидированная спецификация надежной передачи сообщений WS-RX (на основе WS-ReliableMessaging и WS-Reliability).

В. Абросимов: Все говорят: должны быть стандарты. Но на самом деле у российских организаций не видно стремления к стандартизации как таковой. Более того, многие ведомства — особенно госструктуры — внедряют собственные стандарты обмена информацией, и, несмотря на усилия верхних эшелонов власти создать единые стандарты в рамках крупных государственных проектов, этого не происходит. Почему? На мой взгляд, причина в воинствующем непрофессионализме. Он не только противодействует нововведениям, а идет на них в атаку. Мы это часто наблюдаем на практике. Как только предлагается выбрать стандарт и применить некое современное решение, все начинают от этого отмахиваться. И дело не только в том, что мы объективно отстаем. Хуже то, что мы не желаем знать и осваивать новое. Так, анализ различных проектов, выполненных в рамках "Электронной России", рисует далеко не радужную картину.

А. Гершойг: Не хватает элементарной культуры. Мы сплошь и рядом встречаемся с ИТ-специалистами, которые попали на свои позиции не в силу профессиональных качеств, а исторически. Но это естественно — в России рыночная экономика развивается совсем недавно, компаниям максимум по 10–15 лет. В университетах специалистов не успели научить тому, что действительно необходимо на практике. Это могут быть люди с хорошими природными данными, которым не хватает образования. В результате они сейчас делают, что умеют. Переломить ситуацию очень сложно, потому что кадровая политика многих компаний не направлена на отбор на руководящие позиции настоящих профессионалов, в отличие от западных компаний, где идет очень жесткий профессиональный отбор. Да и оценить уровень профессионализма у нас зачастую бывает некому. Поэтому специалисту, в резюме которого перечислен длинный список реализованных проектов, автоматически присваивается статус профессионала. А настоящие профессионалы, не умеющие представить себя в выгодном свете, оказываются недооценены. Отсутствие культуры восприятия нового и является серьезным тормозом правильного использования технологий.

В. Андреев: Причины того, что всеобщей стандартизации не происходит, гораздо более серьезны, чем просто неприятие нового. Вспомним недавнее прошлое. Западные разработчики, сделавшие ставку на открытые стандарты, создали XML и декларировали, что все проблемы интеграции исчезнут, поскольку теперь буквально все можно написать на XML. Но вскоре шум поутих. "Неожиданно" выяснилось, что заказчик вовсе не безлик. Есть отраслевые рынки — например, авиапромышленности, электронной коммерции и прочие. И каждая из крупных компаний отрасли уже до появления XML разработала собственные электронные стандарты взаимодействий со своими поставщиками и потребителями. С появлением XML каждая компания заявила о готовности оформить свои разработки в виде XML и дать их как спецификацию для отрасли. Но эти спецификации совершенно разные. Начинается процесс переговоров, в котором каждый из участников стремится "протолкнуть" свои стандарты. Что вполне объяснимо — у них все бизнес-системы построены на этих стандартах, масштабная перестройка, по понятным причинам, никого не вдохновляет. Начинается непримиримая битва, которая, как показывает практика разных отраслей, завершается одним из двух финалов. Либо, в результате искусственного объединения, возникает некий уродливый гибрид, либо появляются несколько конкурирующих стандартов, которые расчленяют однородный рынок на сегменты. Поэтому всеобщего счастья на основе всеобщей стандартизации в скором времени не предвидится.

А. Гайдай: Не соглашусь. Посмотрите на то, что происходит с программным обеспечением в корпоративном секторе: к нему начинают предъявлять те же требования, которые предъявляются к аппаратным средствам. Если раньше как аксиома принималось, что в программе могут быть ошибки и она может не стыковаться с другими программами, то сейчас все больше заказчиков требуют, чтобы решение встраивалось в их информационные системы и без проблем интегрировалось с другими приложениями. То есть от приложений ожидают "plug and play" при любых обстоятельствах.

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

Наличие интеграционного стандарта, поддержанного всеми вендорами, решило бы проблемы совместимости. Можно провести аналогию со стандартом TCP/IP — конечно, аналогия не совсем прямая, но, тем не менее, она есть.

Хотя уже многое достигнуто в области веб-сервисов, далеко не все еще оформлено в виде стандартов, не говоря уже о том, что не все реализовано в продуктах вендоров. Пока эта работа не завершена, разработчики либо ориентируются на один из широко распространенных стандартов, либо изобретают и продвигают собственную технологию. А то, что требования к ПО сегодня предъявляются гораздо более жесткие, мы ощущаем на себе.

Комментарии: (0)   Рейтинг: