Начнем с начала – с момента, когда в принципе стоит начинать задумываться, что вам нужна корпоративная шина данных (КШД или ESB – Enterprise Service Bus).
Нулевая точка отсчета – это разросшийся IT-ландшафт (10+ систем). На таком масштабе с каждым новым процессом становится все сложнее отслеживать, что с чем взаимодействует. При этом IT-директор постоянно сталкивается со следующими вызовами со стороны бизнеса:
Обеспечить устойчивое развитие IT-ландшафта под нужды бизнеса
Задачи при этом появляются регулярно и могут быть как локальными, так и достаточно большими.
Снизить затраты на развитие в горизонте
Запросов все больше, и надо, чтобы стоимость поддержки была в пределах разумного.
Обеспечить скорость доработок/развития
Чтобы, когда сложность ландшафта повышается, изменений не приходилось ждать по полгода-год.
Как правило, в такой ситуации приходится идти в сторону композитной архитектуры (отсюда и 10+ систем). С монолитом легче в моменте, но в перспективе есть концептуальные риски сильно непростого и затянутого по времени перехода на новое решение, так как придется переносить сразу все процессы. Яркий пример – когда западные вендоры стали уходить с рынка, у их клиентов тут же появилась проблема с поддержкой. Кто-то организовал себе покупку лицензии, но проблемы с получением обновлений никуда не исчезли. И как при этом всей группой компаний, например, с одного решения на другое прыгнуть? А бизнесу простаивать нельзя…
Чтобы не сталкиваться ни с рисками необходимости единовременного переноса всех процессов на новую систему, ни с тяготами работы в хитросплетении нескольких систем, логично организовывать IT-ландшафт так, чтобы отдельные бизнес-приложения коммуницировали с корпоративной шиной данных.
И таким образом приложения связаны не со всем вокруг, а только с шиной. Такая конструкция является гораздо более «легкой», чем когда все элементы системы напрямую связаны между собой. За счёт этого мы имеем возможность строить, в принципе, любые замки на понятном фундаменте.
Но есть один нюанс :-) Несмотря на то, что КШД открывает перед предприятием дополнительные инструменты для управляемого развития IT‑ландшафта, она становится критически важным его компонентом. Если с шиной что-то случится, остальные приложения взаимодействовать не смогут. Это надо понимать. Однако, это всего лишь особенность. Сегодня расскажу, что нужно сделать, чтобы не только спокойно с ней жить, но и получить максимальный эффект от использования КШД для бизнеса.
Задачи предприятия при появлении КШД
Задача 1. Формализовать связи в текущем IT-ландшафте
Первое, что нужно сделать, если вы планируете переход на корпоративную шину данных – это формализовать текущие связи между системами. То есть понять состав систем, а также какими данными и в каком формате они обмениваются.
Когда ясности по взаимодействию систем между собой у вас нет – IT-ландшафт выглядит как клубок из переплетенных между собой проводов. Затраты на поддержку и развитие при этом растут, а скорость достижения бизнес-результатов снижается.
Если мы хотим вести речь об эффективной работе, сначала этот клубок надо распутать. Надо понять, какой пучок тех самых «проводов» мы отделим и отправим в КШД в первую очередь. Совершенно не обязательно пытаться переносить все сразу. Такая задача может оказаться для предприятия неприподъемной. Однако, с каждым последующим переносимым приложением и уходом от типовых конфигураций с обменами, общий механизм будет работать все более слажено.
Решение этой задачи несет прямую пользу бизнесу. Когда процессы хорошо формализованы, встроить в них что-то новое гораздо проще. Соответственно, сокращается время на внедрение систем и ожидаемые результаты можно начать получать быстрее.
Например, если мы говорим про WMS, то один из эффектов – это повышение оборачиваемости на складе. И чем раньше мы её внедрим, тем быстрее начнут сокращаться списания из-за того, что кладовщики не нашли тот или иной товар.
Задача 2. Выстроить процессы разработки
Если предприятие пришло к необходимости внедрения КШД, значит объём бизнес-приложений уже очень большой. И, конечно, теперь мы хотим иметь более качественную разработку. Потому что чем больше данных, тем выше риск ошибок, которые могут привести нас к прямым экономическим потерям. Ладно еще, если ошиблись в тесте. А если сразу в продуктиве?.. Страшно представить.
Соответственно, здесь появляется цикл CI/CD (Сontinuous Integration Сontinuous Delivery). Не сам по себе, конечно) Мы должны его у себя выстроить, если раньше не было.
Сontinuous Integration – это цикл разработки. Мы планируем, собираем, тестируем и готовим релиз к выходу. Сontinuous Delivery – это непрерывная доставка. Когда релиз готов, мы его накатили, и мониторим – нормально ли идет выполнение. Ну, и потом переходим уже к следующему витку нашего замкнутого цикла.
У каждого предприятия есть особенно важные бизнес-процессы, которые приносят деньги. Именно их мы и должны покрыть тестами в первую очередь. Чтобы они функционировали максимально качественно. Например, если произойдет какой-нибудь сбой в маркировке (коды не будут получены или будут, но не верные), сумма ущерба для предприятия может исчисляться миллионами.
Задача 3. Настроить активный мониторинг
Предприятий, у которых никогда ничего не сбоит, не бывает. Однако, об этих сбоях можно узнавать своевременно (и сразу их чинить), или не очень (когда они тем или иным образом уже нанесли ущерб бизнесу).
Чтобы IT-команда узнавала о проблемах раньше, чем придёт бизнес с претензиями, наиболее критичные обмены логично оснастить активным мониторингом – инструментами диагностики и оповещения, если что-то пошло не так.
Пример из практики: однажды отвалился сайт, который базировался на стороннем хостинге. Как только это произошло, ответственному специалисту пришло уведомление, что сайт перестал взаимодействовать с шиной. В течении 2 минут специалист дозвонился до подрядчика и еще 15 минут понадобилось на то, чтобы вер��уть сайт в работоспособное состояние. Уточню, что это был продающий сайт. И если бы о поломке узнали позже, то всего за несколько часов компания потеряла бы достаточно серьёзно(неполучения заказов).
Задача 4. Вопрос отказоустойчивости и DRP
Учитывая на КШД завязано работоспособность множества важных для предприятия систем, у нас возникает два вопроса.
Первый – это сама работа КШД. Каков уровень ее отказоустойчивости? Здесь решением является построение кластера, который базируется на нескольких серверах, и в случае выхода одного из них из строя, приложение все равно продолжит функционировать.
Второй вопрос касается безопасности. Речь идет про аварийный план восстановления. Он нужен для того, чтобы в случае какой-то глобальной проблемы мы смогли восстановить и запустить взаимодействие бизнес-приложений из бэкапов. Для этого нам потребуется:
Формализованный процесс (кто что и когда делает)
Требования к резервным копиям (чтобы быть уверенными, что у нас всегда будет, на основе чего восстановиться)
Четкие инструкции для участников (без ТЗ ведь результат – сами знаете…)
Периодические учения (нечто вроде учебной пожарной тревоги, чтобы наработать навык вне режима реальной опасности)
Можно ли не решать? Можно. Но тут важно осознавать потенциальные проблемы, связанные с отказом инфраструктуры.
Задача 5. Обеспечить легкий онбординг сотрудников/ команд
Встраивать в команду новых специалистов – задача не простая и, как правило, не быстро решаемая. То же самое и с подрядчиками. А хочется начать получать пользу от «свежей крови» как можно скорее. Что для этого требуется:
Распространенное в рынке решение, чтобы было легче найти людей
Единая централизованная документация по всем обменам
Стандарты разработки обменов внутри команды
Особое внимание хотелось бы уделить документации по данным и интеграциям. Это не формальность после проекта, а часть инженерного процесса. Пока знания живут в головах, компания платит за риски и простои. А когда знания закреплены, ландшафт становится устойчивым и быстрее развивается.
Это очень помогает, если во время большого проекта внезапно увольняется какой-то ключевой сотрудник. Просадка по разработке в таких ситуациях очень ощутима. Сроки реализации сдвигаются, а вместе с ними откладывается и получение достижение бизнесом заявленных целей, которые порой бывают не просто хотелками, а необходимостью.
Конечно, срок адаптации человека к команде в любом случае зависит от индивидуальных особенностей компании. Однако, если эти три пункта закрыты, то процесс ассимиляции пройдет быстрее и проще.
Используйте систему по назначению
Корпоративная шина данных может и должна приносить очень ощутимую пользу бизнесу, если ее использовать как инструмент.
Если внедрить КШД и не решать задачи, которые я описал в статье, разумеется, она тоже будет нести пользу сама по себе (сделает легче взаимодействие ИТ-систем и приложений). Однако из ее огромного потенциала вы будете использовать лишь часть. Это как купить Lamborghini и ездить на ней в магазин за картошкой. Легче, чем пешком? Однозначно. Но какое-то странное решение, не правда ли?
Если уж внедрили инфраструктурное решение с широкими возможностями, так эксплуатируйте его по полной. Если предприятие инвестировало в КШД, важно изначально заложить процессы, которые помогут использовать её возможности в полном объёме, а не только для базового обмена данными.
