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

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

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

‍

1. Способность к обновлению — в IT-инфраструктурах она соответствует способности относительно быстро и без потерь для бизнес-процессов масштабироваться или заменять существующие системы на более новые или подходящие под текущие цели бизнеса.

2. Способность быстро передавать и обрабатывать информацию — для IT это столь же важно, как и для нервной системы.

3. Быстрое формирование новых нейронных связей — т. е. создание новых и переработка существующих интеграций.

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

5. Хорошая память — самой близкой, хотя и не совсем точной, аналогией в IT будет логирование событий, т. е. «запоминание» всего, что происходит с файлами и сообщениями. В IT-инфраструктуре оптимален вариант, когда логирование событий устроено единообразно, все события фиксируются и их легко отследить.

Признаки молодости IT-инфраструктуры компании

В одной из предыдущих статей мы сравнивали IT-инфраструктуру компании с нервной системой. Эта метафора кажется нам удачной и в разрезе молодости/старости бизнеса. Более того, свойства молодой нервной системы в полной мере характерны и для молодой IT-инфраструктуры.

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

Возрастные изменения

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

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

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

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

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

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

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

Как стареет IT-инфраструктура?

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

• Когда количество систем и интеграций в IT-инфраструктуре превышает критическое значение. Для компании с численностью персонала 500 человек, например, вполне нормально иметь в контуре многие десятки систем. А point-to-point интеграций, связывающих их, — сотни, а то и тысячи. С каждой новой системой и интеграцией система становится менее гибкой.

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

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

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

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

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

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

• когда изменение одной системы влияло на изменение другой системы;

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

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

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

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

Возможные причины «старения» инфраструктуры

• В момент формирования архитектуры, склонной к старению, компания не думала о развитии IT-инфраструктуры и планировала остановиться на 3–5 самых нужных системах. Но со временем требования бизнеса заставляли пересматривать количество систем и их функции, что не учитывалось первоначальной архитектурой.

• Альтернативная архитектура показалась нецелесообразно дорогой, её внедрение отложили на «потом» — но «потом», с ростом инфраструктуры, рефакторинг сочли дорогостоящим и длительным, а масштабы переработок оказались неподъёмными для компании.

Можно ли сохранить молодость IT-инфраструктуры?

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

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

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

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

2. Системы должны быть слабо связаны между собой.

Что такое слабая связь? Всем понятно, что делает сервис, но при этом для обмена используются абстрактные, а не конкретные сообщения. Например, сервису нужно передать заказ на комплектацию, но другие системы не «знают», в каком именно виде заказ ожидается конечным сервисом: файлом, по API или записью в общей таблице. Они также не «знают», какие нюансы нужно обеспечить для преобразования атрибутов. Возможно, сервис ожидает адрес в виде КЛАДР, а он поступил текстовой строкой. Это будет проблемой интеграционного слоя, а не конечных систем.

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

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

1. Способность к обновлению. Чтобы добавить или обновить конкретную систему, подключить дополнительный канал продаж или нового поставщика, не нужно перелопачивать всю сложившуюся архитектуру. Нужно подключить их к ESB-слою и доработать джобы (или написать новые). Это — вместо десятков интеграций между системами. Выигрыш по времени и финансам колоссален.

2. Способность быстро передавать и обрабатывать информацию. Вспомним схему с длинной цепочкой передачи информации между «Битриксом» и тремя сайтами. С ESB схема выглядела бы так.

Скорость обработки и передачи информации в такой схеме завязана на ESB — слой, который изначально предназначен для этих действий и ориентирован на highload. Изменения в ценах, описаниях товаров и складских остатках синхронно отображаются на всех каналах продаж и не «застревают» в промежуточных системах.

3. Быстрое формирование новых связей. Продумать логику и интегрировать систему через ESB гораздо быстрее, чем продумать и написать десятки интеграций на все необходимые взаимосвязи.

Интеграциями типа point-to-point обычно занимаются команды разработки, которые сфокусированы на отдельной системе, и логику интеграции они реализуют через призму выбранной системы. С интеграцией через ESB ситуация иная: команда разработки сфокусирована на бизнес-логике и ответственна только за передачу информации из своей системы в шину и обратно.

4. Быстрая реакция. Этот пункт тесно связан с предыдущим. Чем быстрее формируются новые интеграции, тем оперативнее компания реагирует на внешние обстоятельства средствами IT и тем быстрее IT приходит в соответствие с новыми бизнес-процессами.

5. Память. Логирование и сохранение информации до момента доставки заложены в саму концепцию ESB-слоя и реализованы с помощью внутренних и внешних инструментов шины.

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

Решение в пользу ESB

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

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

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

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

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

• собирать все данные о продуктах, заказах, ценах, остатках, клиентах и пр. из систем, которые входят в IT-контур компании;

• комбинировать и (или) конвертировать собранные данные;

• передавать данные как во внутренние системы, так и на каналы онлайн-продаж.

‍

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

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

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

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

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

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