Все новости от 4 февраля 2004 г.

Образцовый зоопарк

В прошлом году ведущие экспертные группы предрекали наступление эпохи интеграции корпоративных приложений. Стройную череду трехсимвольных аббревиатур ERP (Enterprise Resource Planning), MRP (Material Requirements Planning/Manufacturing Resources Planning), CRM (Customer Relationship Management), SCM (Supply Chain Management) и т. д. поставщики ПО масштаба предприятия (IBM, Microsoft, Siebel, SAP, Oracle) продолжили аббревиатурами EAI (Enterprise Application Integration), EAS (Enterprise Application Suite), MOM (Message Oriented Middleware), ESA (Enterprise Service Architecture), UAN (Universal Application Network), ASI (Application Service Interfaces), ESB (Enterprise Service Bus) и другими.

Артак Оганесян

Российский рынок воспринял новую идею настороженно. Полномасштабное внедрение хорошо "раскрученных" ERP-систем не всегда оправдывает возлагаемые на них надежды, бума с CRM, как это было на Западе, у нас не наблюдалось, если не считать организации центров обработки звонков. Теперь вот вопрос -- нужен ли нам EAI ? (Обзоры по средствам EAI можно найти в PC Week/RE № 35/ 2003 с. 37, № 36/2003 с. 31, № 44/2003, с. 46, № 47/2003, с. 40).

В стране талантливых программистов задача интеграции двух, трех, десятка программ не кажется особо сложной. У нас на каждом втором предприятии используется самописная АСУ или КИС (или, по крайней мере, готовые программные продукты дополнены собственными разработками). А сколько мостов, шлюзов, переходников, адаптеров и коннекторов создано "народными" умельцами! В былые времена опытные АСУшники подключали персоналки к унаследованным базам на "ЕС-ках", а недавно я посетил отдел в ведомственном НИИ, где "продвинутые" специалисты уже второй год создают свою универсальную интеграционную платформу.

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

Ведь этот велосипед уже изобретен! Ведущие производители программного обеспечения -- системного (например, как IBM и BEA), прикладного (SAP и Siebel), системно-прикладного (Microsoft и Oracle) -- уже предложили рынку свои интеграционные платформы. В начале многих маркетинговых буклетов этих вендоров можно найти картинку, изображающую хаотическое переплетение связей приложений, с подписью типа "исторически сложившийся зоопарк", а в конце -- другую, демонстрирующую схему упорядоченной интегрированной системы, способной работать в гетерогенной среде, эдакий "образцовый зоопарк".

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

Будут ли они востребованы на российском рынке?

Для небольшой фирмы, чьи нужды в автоматизации покрываются одной

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

Для средних и крупных предприятий проблема интеграции так просто не решается. Остались в прошлом декларации разработчиков и внедренцев готовых ERP-приложений о том, что их интегрированные пакеты и вертикальные решения достаточны для предприятия в целом или хотя бы для критически важных бизнес-процессов.

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

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

Для полноты картины можно вспомнить корпоративные хранилища данных, требующие подключения ко всем источникам данных.

Попытки разработать отдельные мосты приводят к уже упоминавшейся картине с хаотическим переплетением взаимосвязей ("спагетти"), которой так любят пугать аналитики. Намерение построить свое интеграционное решение требует значительных инвестиций в создание базовых механизмов. Стоимость создания и сопровождения собственного инструментария может превысить затраты на саму автоматизацию.

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

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

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

• большое число приложений;

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

• гетерогенная ИТ-инфраструктура;

• территориально распределенная среда;

• объемные потоки данных;

• тенденции к росту бизнеса и диверсификации (увеличение числа ИС для обеспечения новых процессов).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• предсказуемой, так как можно оценить воздействие изменений на смежные приложения, зная взаимозависимости систем;

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

• контролируемой, благодаря тому что интеграционное решение не зависит от возможностей определенного приложения или команды ее разработчиков.

Если все это суммировать, то можно сказать, что интегрированная информационная система управления предприятием сама станет управляемой. С автором, менеджером по развитию бизнеса компании Vested Development Inc. (VDI), можно связаться по адресу: ArtakO@Moscow.vdiweb.com.