Почему технари против шин данных:
middleware, ESB, брокеров сообщений?

Итак, ваши разработчики взяли задачу в работу и дали оценку: «В следующем месяце сделаем». Или дают оценку, что сделают завтра, но по факту до сдачи проекта всё равно проходит месяц. У вас пригорает от сроков, но поделать ничего нельзя.

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

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

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

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

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

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

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

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

За счёт чего обеспечиваются быстрота, надёжность и прозрачность?
Быстрота обеспечивается за счёт того, что вашему 1С-разработчику не нужно писать логи, мониторинг, узнавать, как устроен Wildberries и т. д. 1С-разработчик изначально знает, что если его система является мастер-системой по товару, то в его сферу ответственности уже входит коннектор к шине и собственно качественные данные в 1С. Т. е. он, фактически, может настроить передачу задолго до появления задачи по выгрузке.

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

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

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

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

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

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

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

С шинами (при условии соблюдения сервис-ориентированного подхода) вы сможете спокойно масштабировать команду.

Использование шины положительно сказывается и на вашей 1С. В 1С нет специальных коннекторов для Wildberries — но они и не нужны, поскольку шина использует стандартный коробочный API вашей 1С.

В итоге:

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

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

Вроде бы, одни плюсы. Но обычно всё не так, как мы описываем в этой статье…

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

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

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

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

Разработчики часто говорят, что писать интеграцию кодом «трушнее»: быстрее, надёжнее, понятнее. Другая версия — «не хочу работать в шине», потому что «в шине нет очень нужных в разработке инструментов вроде версионирования». Разработчик вам скажет, что в шине разбираться долго, а «кодом я сейчас как сделаю! Через пару дней будет готово».

Пара дней обычно превращается в проблемы на месяц. И да: учиться — физически болезненный процесс. Задайте себе вопрос, сделает ли ваша команда за месяц интеграцию лучшую, чем разработчики шин сделали за 20 лет? Сколько тысяч интеграций прошло через инструменты шин, сколько проблем было выявлено и решено за всё это время?

По нашему опыту, разбор отговорок разработчика всегда приводил к настоящей причине: он просто не нашёл инструментов и подумал, что их нет.

Часто это утверждение подкрепляют наличием микросервисов.

Мысль о том, что ESB устарел, проистекает из непонимания фундаментальных принципов построения сервисных и микросервисных архитектур. Мы отдельно поговорим на эту тему в одной из следующих публикаций. Пока лишь скажем, что основоположник SOA и автор дважды переиздававшейся книги «SOA: Анализ и дизайн сервисной и микросервисной архитектуры» Томас Эрл так не считает, как не считают и другие великие умы в Computer Science. Настоятельно рекомендуем прочитать эту книгу и коллегам, и бизнесу.

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

Важно донести команде, что с применением low-code инструментов, и в частности шин данных, их работа станет более содержательной и интересной. Зачем тратить время на задачи, которые уже кто-то решил до тебя, если можно заниматься чем-то принципиально новым?

Скажем честно: правильно внедрить шину — задача непростая. Для того, чтобы успешно решить её, нужно понимать SOA-принципы, принципы low-code и нужно желать сделать хорошо в парадигме инструмента, а не как привык. Мы встречали огромное количество неправильно внедренных шин, которые создавали проблем больше, чем решали.

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

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

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

Но в реальности внедрение шины выгодно всем.

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

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

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

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