Выстроить процесс управления качеством данных без системы MDM (master data management) при нынешних требованиях к данным очень и очень сложно. Так что когда обсуждается стратегия построения процессов управления, то в качестве инструментов в первую очередь рассматривают именно MDM-системы. Однако это не единственный инструмент, который следует использовать для повышения качества данных. Помимо ведения и хранения в управлении данными есть не менее важный пункт — их доставка до потребителя. Об этом мы и поговорим в статье.
Процессы управления, реализованные в MDM-системе, безусловно повышают качество данных как в самой MDM, так и в тех информационных системах, которые пользуются данными из неё. Кроме того, как мы знаем, MDM-система управляет мастер-данными, которые по сути являются неким описанием объектов реального мира.
Стоит, однако, принять во внимание следующее: во-первых, мастер-данные — это не единственные данные в компании, а во-вторых, MDM не управляет способом использования данных в других информационных системах, особенно их распространением между другими информационными системами. Почему это важно? Потому что качество данных — это не просто их «нормализованность» и «правдивость».
За «правдивостью» или, скорее, «истинностью» данных скрывается несколько свойств, одно из которых часто упускается из виду, а именно — «актуальность». Но не в том смысле, что данные по конкретному объекту, например, по какой-то организации, должны быть «свежими», верными в текущий момент времени, а в том, что эти данные должны быть вовремя доставлены до нужного потребителя (информационной системы). Рассмотрим «актуальность» данных с этой точки зрения.
Транспортировка данных по расписанию или синхронно: в чем недостатки?
Часто наблюдаемый вариант распространения данных между системами представляет собой взаимодействие между системами по расписанию. Это либо выгрузка пакетов накопленных изменений по расписанию, либо запрос изменений по расписанию. Чем чаще требуется выполнение такого взаимодействия по расписанию, тем выше холостая нагрузка на информационные системы и аппаратные ресурсы, так как не всегда данные обновляются с той частотой, с которой настроено расписание. Другими словами, между предыдущим и следующим, ближайшим к нему моментом по расписанию может не произойти ни одного изменения данных, и информационная система в момент мониторинга изменений (срабатывания расписания) выполнит действие напрасно, вхолостую. И тогда выбирается вариант некого баланса, в котором расписание «не очень частое», с наибольшей вероятностью накопления изменений между назначенным временем «срабатываний» обмена. Это приводит к определенным последствиям, которые редко прогнозируются и рассматриваются при выборе средств распространения данных.
Наиболее частые последствия такого подхода заключаются в следующем:
- если объект в мастер-системе меняется непосредственно после сеанса обмена данными, то до следующего сеанса в остальных системах этот объект не актуален, что приводит к простоям в ожидании сеанса обмена для принятия решений или для выполнения процесса в системах. Чем реже настроено расписание обменов, тем более вероятен простой;
- бизнес-пользователи не контролируют обмен данными между системами и, получив информацию о том, что изменения внесены в мастер-систему, не дожидаясь выполнения обмена, производят свои действия. В зависимости от архитектуры конечной системы неактуальные данные попадают во вновь созданные объекты (проводки) и используются в дальнейшем, в том числе и другими бизнес-пользователями. Длинная цепочка возможных последствий приводит к тому, что в конечном итоге принимаются неверные решения, для анализа и исправления которых требуются время и ресурсы, что снова ведёт к простоям;
- объем данных, передаваемых в рамках одного сеанса обмена, может оказаться настолько большим (например, при массовом изменении свойств целых групп номенклатуры), что времени до начала следующего сеанса просто не хватит для обработки накопленных изменений. В результате некоторые данные могут «зависнуть» на несколько сеансов и дойдут до потребителя с существенной задержкой. А если бизнес-пользователь не контролирует обмен, то после первого сеанса он может быть уверен в том, что обмен прошел и в системе содержатся верные данные. Последствия этого случая обнаруживаются, как правило, в конце отчетного периода.
Для повышения актуальности данных во всех информационных системах наиболее часто выбирается вариант полностью синхронного взаимодействия всех информационных систем, включая систему управления мастер-данными. При небольшом количестве информационных систем (от двух до четырех) такой вариант взаимодействия не приносит каких-либо серьезных проблем. Но если систем становится больше, то количество прямых связей между ними (типа «точка — точка») растет в геометрической прогрессии, увеличивается сложность отслеживания работоспособности всех связей и квадратично или даже экспоненциально возрастает сложность расследования сбоев. В зависимости от организации процессов в компании сбои могут быть обнаружены не сразу, а после выполнения нескольких шагов бизнес-процесса. Чем больше связей задействовано в этих шагах, тем сложнее будет найти причину и место сбоя, тем больше ресурсов понадобится и больше будет простой в организации.
Синхронный обмен и обмен по расписанию имеют один и тот же серьезный недостаток при сбоях, поиске их причин и устранении последствий. Чем больше связей, тем сложнее обнаружить причину, и чем позднее обнаруживаются последствия, тем больше ресурсов требуется на их устранение. Тем не менее очевидно, что обмен данными, происходящий по событию изменения объектов, выигрывает в актуальности данных перед обменом по расписанию.
Передача данных с помощью ESB
Наиболее эффективным средством минимизации описанных выше рисков является инструмент типа ESB (корпоративная шина данных), позволяющий организовать как синхронный, так и асинхронный обмен. К самым значимым свойствам корпоративной шины данных относятся гарантированная доставка данных и средства мониторинга, позволяющие быстро реагировать на любые сбои и дающие возможность исправлять сбои еще до того, как их последствия проникнут в дальнейшие шаги бизнес-процессов.
Однако «шина» «шине» рознь. Не все продукты на рынке позволяют одинаково эффективно организовать обмен. Часть представленных продуктов по своей сути представляют собой «брокеры очередей», которые получают сообщения от систем и распределяют эти сообщения по контейнерам в соответствии с настроенной логикой маршрутизации. Забирают же сообщения из контейнеров информационные системы самостоятельно, что снова приводит к необходимости использовать расписание, так как нужно периодически проверять наличие новых данных в контейнерах.
Продвинутые решения доводят сообщение непосредственно до систем-потребителей и передают его в их сервисы сразу после инициации обмена со стороны мастер-системы, таким образом наиболее полно реализуя принцип гарантированной доставки и позволяя осуществить более эффективный с точки зрения использования ресурсов асинхронный обмен.
Асинхронный обмен посредством ESB
Асинхронный обмен позволяет системе не простаивать в ожидании ответа, занимая аппаратные ресурсы, а передать сообщение и сразу выполнять другую работу. Но чтобы получить ответ и обработать его, такую возможность в системе необходимо предусмотреть, а в самих сообщениях передавать идентификаторы, с помощью которых система поймёт, к чему относится полученный ответ. То есть асинхронный метод при большей эффективности потребления аппаратных ресурсов требует более глубокого анализа и осознанного подхода при построении обменов; кроме того, он более трудоемок при проектировании.
Организовав асинхронный событийный обмен с использованием подходящих для этого программных решений, компания одновременно снижает простой аппаратных и системных ресурсов, повышает актуальность информации во всех информационных системах, реализует принцип гарантированной доставки данных и получает возможность оперативно реагировать на сбои еще до того, как их последствия проникнут в следующие шаги бизнес-процесса.
Таким образом, для обеспечения качества данных в компании необходимо использовать не только MDM-систему, но и систему организации распространения данных между информационными системами, именуемую корпоративной шиной данных.
Для построения максимально эффективных обменов корпоративная шина данных должна обладать следующими возможностями:
- доводить данные непосредственно до системы, а не складывать их в контейнеры, из которых системы должны забирать данные самостоятельно;
- организовывать асинхронный обмен для эффективного использования аппаратных и системных ресурсов;
- мгновенно получать уведомления на любые сбои для немедленного их устранения, не допуская влияния последствий на бизнес-процессы;
- вести мониторинг всех обменов для оценки состояния настроенных обменов (хотя этот критерий больше необходим для спокойствия администрирующего персонала, что тоже немаловажно для их рассудительных действий при обслуживании решений).
Перечисленные возможности позволят организовать эффективный со всех точек зрения обмен данными между информационными системами, поддерживать его постоянно в рабочем состоянии, очень быстро реагировать на любые сбои и устранять их оперативно и без последствий.