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

Офис компании в Российской Федерации входит в европейское подразделение, оно располагает двумя центрами обработки данных — в Лондоне и Москве. Размещенные в московском ЦОД унаследованные приложения поддерживают работу сотрудников бэк-офиса компании. В число таких приложений входит, например, программный продукт, написанный в свое время на языке Кобол для мэйнфрейма и потом адаптированный для работы на платформе СУБД Oracle. В архитектуре ИТ-систем, обеспечивающих ИТ-поддержку основных бизнес-процессов компании, он находится на самом нижнем уровне. Исторически это транзакционное приложение было создано для поддержки продаж, осуществляемых без использования Интернета. В частности, данные о заказах приходилось вводить вручную. В настоящее время в этом приложении фиксируется история продажи рассчитываются значения специфических для индустрии показателей. Также на этом уровне находятся приложение для управления счетами клиентов, созданное на платформе Oracle штатными ИТ-сотрудниками компании, и основательно доработанная их силами промышленная система управления запасами. На верхнем уровне ИТ-поддержки располагается система электронной коммерции, созданная ИТ-специалистами Mary Kay на платформе. NET Framework. В качестве СУБД эта система использует Microsoft SQL Server. Европейская версия приложения развернута в лондонском ЦОД. Интеграция систем верхнего и нижнего уровней была для компании задачей первостепенной важности.

В лондонском ЦОД компании также развернута CRM-система, созданная, как и многие другие, в ходе внутренней разработки на платформе. NET с использованием Microsoft SQL Server. Она появилась в компании позже других систем, и для ее интеграции с остальными приложениями использовался уже накопленный опыт.

Илья Садовенко, Европейский регион компании Mary Kay
«Нужно не фокусироваться исключительно на проблемах сегодняшнего дня, а продумать, как должна выглядеть архитектура приложений в компании через два-три года», Илья Садовенко, директор по ИТ Европейского региона компании Mary Kay

Онлайн-система размещения заказов — высокопроизводительная информационная система, обрабатывающая сотни тысяч заказов в месяц.

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

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

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

После неоднократных попыток реализовать различными способами эту идею интеграционное решение было создано на платформе Oracle. В ходе обработки нисходящих потоков данных одни веб-сервисы передают в это решение данные из СУБД на основе приложения Microsoft SQL Server электронного магазина, а другие веб-сервисы передают эти данные в Oracle. Для «восходящих потоков» данных операции, соответственно, выполняются в обратном порядке.

Примерно полтора года назад обнаружилось, что производительности построенной системы интеграции уже не хватает для обработки динамично растущего объема транзакций — данные стали теряться или поступать с опозданием. Следует учитывать, что через приложение промежуточного слоя проходят все восходящие и нисходящие потоки данных во всех точках присутствия компании Mary Kay в Европейском регионе.

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

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

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