Инструмент,
который поможет сохранить молодость бизнеса

Бизнес часто сравнивают с живым организмом: он рождается, растёт, стареет и умирает. Но у бизнеса есть приятное отличие от, например, человека — его гораздо проще омолодить, тогда как у людей вопрос вечной молодости остаётся больным (и нерешённым).

Омоложение бизнеса может происходить на нескольких уровнях. Сегодня мы остановимся на вопросе, можно ли — и как именно — сохранить молодость IT-инфраструктуры компании, чтобы она не становилась для бизнеса «бутылочным горлышком».

Казалось бы, ничего сверхъестественного — именно этого бизнес ждёт от своей IT-инфраструктуры. Однако реальность далеко не всегда соответствует стандартам молодости.

IT-инфраструктура не рождается неповоротливой, тяжёлой и плохо масштабируемой. Такой она становится постепенно — когда в IT-контур добавляются новые системы и интеграции. Энтропию системы автоматически увеличивает любое расширение IT-инфраструктуры — вопрос в том, насколько сильно. И ответ на этот вопрос (а вместе с ним и секрет молодости) лежит в плоскости архитектуры.

Рассмотрим пару примеров постаревшей инфраструктуры из e-Commerce — компании из этой сферы обычно весьма показательны, поскольку работают на рынке, чувствительном к переменам, и вынуждены постоянно трансформироваться.

В одном из кейсов мы видели структуру, в которой информация о товаре двигалась по следующему пути.

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

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

Или классический пример — экосистема, построенная по принципу «звезды», с интеграциями типа point-to-point.

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

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

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

Всё это описывается кривыми сложности изменений монолитной архитектуры.

Пока систем и интеграций между ними не так много, разница по затратам на поддержку интеграций в сервис-ориентированной и монолитной архитектурах некритична. Но когда количество интеграций растёт, а их взаимозависимость в монолитной архитектуре усложняется, разница становится всё более заметной. И со временем она только увеличивается.

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

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

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

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

Чтобы обеспечить способность IT-экосистемы к изменениям, каждая система должна меняться без оглядки на другие и идти своим путём. Если вы решили заменить одну систему на другую, вы должны сделать это без проблем, и масштаб изменений ограничится только каким-то конкретным сервисом вашей компании.

Как обеспечить это в теории?

Итак, перейдём к проблеме слабой связанности. В сервис-ориентированных архитектурах (в т. ч. MSA) место обмена сообщениями является важнейшим признаком. Именно построение ESB-слоя (т. е. слоя сервисной шины предприятия) является, на наш взгляд, самым эффективным решением для омоложения IT-инфраструктуры организации.

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

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

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

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

Поэтому специалисты kt.team предложили клиенту доработать IT-архитектуру и интегрировать в неё ESB-слой на основе WSO2.

Чем будет заниматься ESB:

При этом для подключения нового канала продаж не придётся писать десятки интеграций — достаточно будет нескольких джоб.

WSO2 — low-code платформа с графическим интерфейсом. Поэтому за новыми интеграциями заказчику необязательно будет обращаться в IT-компанию — создать интеграцию смогут бизнес-аналитики или менеджеры с достаточным уровнем компетенций.

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

Архитектура, в центре которой находился интернет-магазин, противоречит задаче сохранения молодости IT-инфраструктуры. Ведь, во-первых, в такой архитектуре на интернет-магазин были бы возложены несвойственные ему функции: шина данных, PIM и пр. А во-вторых, неизбежная при омоложении замена центрального элемента — т. е. самого́ интернет-магазина — стала бы максимально сложной и затратной.

Отдельно хотим отметить, что ESB-шина и брокер сообщений — это не одно и то же.

Мы часто замечаем, что Kafka, RabbitMQ или code-first шины ставят в один ряд с low-code ESB. Это в корне неправильно. Лишь те системы, которые позволяют IT-департаменту в растущем контуре проверять любые интеграции, можно считать современными шинами. Это является частью современного определения интеграционной шины в той же степени, в какой в современное представление об автомобиле «вшиты» не только двигатель, трансмиссия и кресла, но и кондиционер, акустическая система, ABS и многое другое.