Уже около десяти лет предприятия и технологическая отрасль одержимы идеями больших данных, аналитики, машинного обучения и внедрения практик, основанных на данных. Между тем, локдауны COVID-19 и их последствия ускорили усилия и расширили мандаты по цифровой трансформации, которая сама по себе зиждется на культуре и операциях на основе данных. Хотя это вызвало массу инноваций со стороны поставщиков и инвестиций со стороны заказчиков, это также привело к неизбежно высокому уровню неудач в проектах, что является отличительной чертой безоглядного внедрения технологий, пишет на портале The New Stack Эндрю Бруст, основатель и генеральный директор консалтинговой компании Blue Badge Insights.
Хорошей новостью является то, что появились различные архитектурные и методологические подходы, которые помогают избежать неудачных внедрений или смягчить их последствия. Но готовы ли эти подходы к использованию заказчиками? Являются ли они прагматичными, а не пуристскими? Прошли ли они стресс-тестирование? Хорошо ли они вообще понятны?
Ниже я расскажу о двух ведущих архитектурах: Data Fabric (ткань данных) и Data Mesh (сетка данных). При этом я попытаюсь выйти за рамки обычного объяснения, контекстуализируя эти модели через аналогию с типами государственного управления. Возможно, рассмотрение прошлых геополитических событий позволит активизировать наше аналитическое мышление и подскажет технологические выводы, которые помогут снизить риски и повысить шансы на успех.
Суть проблемы
Одним из ключевых факторов неудачи проекта является несоответствие между требованиями платформы и реалиями заказчика. Большинство аналитических платформ основаны на том, что данные должны быть доступны, открыты для обнаружения, очищены и консолидированы. Реальность же клиентских данных резко контрастирует с этими требованиями.
Хотя практически все поставщики и специалисты-практики знают, что данные образуются в неочищенном и разрозненном виде, многие рассматривают это исходное состояние как дефект, который необходимо исправить и в дальнейшем избегать. Хотя эта сложная реальность признается, она не поощряется, принижается и рассматривается как цель для исправления.
Для исправления этого несовершенного состояния и предоставления организации устойчивой основы в виде хорошо интегрированных данных, на основе которых можно выполнять множество аналитических задач, применяются ETL (извлечение, преобразование и загрузка данных), конвейеры данных, заказной код и интеграция «точка-точка». После того, как все будет полностью в рабочем состоянии и единое хранилище данных будет готово к работе, организации смогут выдохнуть и сделать вид, что предыдущего, несовершенного состояния никогда не существовало.
Помимо того, что такой подход утопичен и на самом деле является своего рода снобизмом, он еще и является заблуждением и имеет другие недостатки. Хорошая новость заключается в том, что коллективное сознание индустрии и потребителей абсолютно точно просыпается от всей этой бесполезности и отрицания и начинает решать эту проблему. В 2022 г. организациям придется вплотную заняться этим вопросом.
Неудобство аналитики не является операционной халатностью
Рассредоточенная природа операционных данных — это не недостаток. Это не несовершенство. Это не результат плохого планирования. Рассредоточение — это естественное состояние операционных данных. Общий свод операционных данных и должен быть разрозненным. Он стал таким благодаря оптимизации, а не некомпетентности или непродуманности.
И Data Fabric, и Data Mesh признают тщетность попыток централизовать все данные физически. А так же то, что объемы данных только растут, а источники данных только множатся. В результате эти два понятия иногда смешивают. Однако они совершенно разные, как по философии, так и по реализации, и у каждого подхода есть свои достоинства.
Data Fabric: оливковая ветвь вендоров
Платформы Data Fabric признают физическую реальность разрозненности данных и стремятся смягчить ее, создавая виртуализированные уровни доступа, которые все же объединяют данные — логически. Это логическое объединение означает, что центральный орган — будь то ИТ-отдел, директор по данным или аналитический центр передового опыта — все-таки может управлять данными, регулировать их и приводить в соответствие с корпоративными стандартами.
Data Fabric также объединяет множество технологий, используемых для преобразования и анализа данных, и делает их доступными для бизнес-подразделений организации по выбору («a la carte»), чтобы обеспечить самообслуживание аналитиков. Таким образом, ткань данных коррелирует со стеками поставщиков, особенно тех, которые предлагают полные платформы данных.
Во многих отношениях Data Fabric — это реализация платформы данных поставщика, которая чувствительна к несовершенному состоянию хранилища данных клиента, допускает его и гибко регулирует его. Вместо того, чтобы продавать и устанавливать платформу и заставлять клиента соответствовать ее требованиям, процесс внедрения определяют обстоятельства и требования клиента.
Data Mesh: кооперативная автономия
Сетка данных, с другой стороны, утверждает, что различные подмножества данных должны полностью управляться командами в бизнес-областях, которые работают с ними больше всего. Эти доменные команды должны сделать данные в виде потоков событий, таблиц или сервисов, управляемых API, доступными для других команд в других бизнес-подразделениях/предметных областях, а также сделать их максимально простыми в использовании в качестве строительных блоков, которые можно комбинировать с другими данными.
По словам Жамака Дехгани из Thoughtworks, первопроходца архитектуры Data Mesh, она основана на следующих принципах: децентрализованное владение данными и ориентация на конкретную область, данные как продукт, инфраструктура самообслуживания как платформа и федеративное управление вычислениями. Кроме того, продукты данных, создаваемые каждой доменной командой, должны быть обнаруживаемыми, адресуемыми, надежными и обладать самоописываемой семантикой и синтаксисом. Они также должны быть совместимыми, безопасными и управляться глобальными стандартами и средствами контроля доступа.
Другими словами, относительно небольшие межфункциональные группы владеют разработкой, развертыванием и обслуживанием всех активов данных, относящихся к их бизнес-домену. Наборы данных домена, сервисы и API разрабатываются с ориентацией на продукт, с акцентом на обнаруживаемость и удобство использования. Потребители наборов данных представляют собой клиентов команды; их уровень удовлетворенности и принятия являются важными показателями успеха команды домена. Внедрение, обеспечение и обслуживание инфраструктуры, а также стандарты управления и контроль централизованы. Все остальное находится под контролем команд бизнес-доменов.
Идея, лежащая в основе Data Mesh, очень похожа на ту, которая легла в основу сервисно-ориентированной архитектуры (SOA) середины
Доменные команды во вселенной сетки данных похожи на команды разработчиков в мире ПО, поскольку последние являются межфункциональными и берут на себя полную ответственность за программные продукты, которые они проектируют, разрабатывают и доставляют. С другой стороны, различия в стиле реализации, семантике и подходе к разработке между командами разработчиков и их кодовыми базами, конечно, могут иметь место.
Управление данными и госуправление
По сути, Data Mesh — это модель, сопоставимая с федеративным правительством, а Data Fabric — аналог централизованного. Я предлагаю эту аналогию не для того, чтобы придать новизну или умничать, а совершенно серьезно. Хотя управление данными и управление государством — это не одно и то же, оба они связаны с людьми, политикой, конкурирующими интересами, предпочтениями, страхами и давлением.
Если вспомнить о централизованных правительствах, то они часто вызывают недовольство населения, находящегося под их властью. Законы, налоги и правила могут казаться произвольно навязанными, плохо обоснованными и иногда несправедливыми или, по крайней мере, непрактичными. Именно по этой причине центральное правительство часто предоставляет регионам автономию. Взгляните на Соединенное Королевство, где Шотландия, Северная Ирландия и Уэльс имеют автономные парламенты. Или на Испанию с ее автономными сообществами.
Как пример федерации рассмотрим США, состоящие из 50 штатов и дополнительных территорий, где главенствуют собственные судебные системы. И, конечно, Европейский Союз — это еще более свободная конфедерация суверенных образований, которая иногда больше похожа на ассоциацию. Теперь сравните все эти автономные и федеративные государства с сетками данных. Хотя аналогия и не идеальна, она может помочь прояснить концепцию.
Суверенные и автономные государства часто имеют более счастливых граждан. Они могут чувствовать, что могут лучше контролировать власть, и быть более законопослушными, поскольку законы для них были разработаны на местном уровне. В некоторых странах автономные правительства ведут дела на местном диалекте или языке региона. В случае Испании, хотя большинство граждан в полной мере владеют кастильским испанским языком, в культурном плане им удобнее общаться с правительством на том же языке, на котором они говорят дома.
Аналогичным образом, организации, придерживающиеся подхода Data Mesh, могут иметь более счастливых сотрудников, которые чувствуют себя более контролирующими свои собственные данные, способными потреблять и использовать их более интуитивно. А семантика сервисов данных, управляемых доменами, может оказаться более удобной, чем работа с какой-то общекорпоративной моделью данных.
По сути, если граждане автономных регионов получают персонализированное правительство, то участники Data Mesh — персонализированные активы данных. И то, и другое обеспечивает комфорт, поддержку и уважение. И то, и другое делает тактическую работу более простой, с меньшим трением. Вместо универсального подхода все становится более индивидуальным, более деликатным и более... местным. Это может привести к большей вовлеченности, большему энтузиазму и более богатому диалогу между правительством и гражданами или между информационными ресурсами и их пользователями. Это снижает трение и способствует политическому участию или техническому внедрению.
Все это хорошо... до определенного момента.
Неприятности в раю
Автономность может также создавать проблемы. Для правительств ведение дел на нескольких языках может затруднить общение, а несколько уровней управления могут привести к дублированию усилий, ролей и обязанностей. Бюрократия может увеличиться, а работать в широком национальном масштабе может быть сложнее, что влечет за собой экономические последствия. В сфере технологий дела обстоят примерно так же. Сосуществование нескольких межфункциональных команд может привести к дублированию усилий, несовместимости и коллективному техническому долгу.
Хуже того, культурная автономия и слабость центрального правительства могут привести к попыткам прямого отделения. Так, например, произошло с Каталонией в Испании и Квебеком в Канаде. Это может произойти даже на муниципальном уровне, как это случилось в
Аналоги каждого из этих явлений существуют в технологиях. Если каждая сфера бизнеса отвечает за свои собственные данные, могут появиться многочисленные стандарты. Даже если во всех доменах созданы дружественные API, их семантика может отличаться, что приводит к так называемому несоответствию импеданса, когда работники умственного труда сталкиваются с трудностями при переходе между наборами данных в разных доменах. А некоторые API могут придерживаться настолько разной семантики, что образуют изолированные сервисы, отделенные от других. Переданные полномочия и контроль, которые уменьшили трение на уровне домена, внезапно добавляют трение на уровне организации. Хотя архитектура Data Mesh призывает к операционной совместимости доменных служб в качестве основного постулата, эта деталь может остаться без внимания.
О централизованной модели и ее потенциальной глухоте и непригодности можно говорить что угодно, но она позволяет избежать ситуаций, подобных тем, о которых говорилось выше. Автономия может быть прекрасной, но анархия — нет. Сторонники подхода Data Mesh должны помнить об этом. Иногда для обеспечения совместимости необходим централизованный мандат на следование общей модели. Такие диктаторские мандаты могут показаться регрессивными, но они могут быть необходимы, особенно потому, что, в отличие от многих государств, компании не являются демократическими ни функционально, ни даже риторически. Какой бы просвещенной ни казалась архитектура Data Mesh, различные элементы подхода Data Fabric могут быть более реалистичными и выполнимыми. Реальная политика применима в корпоративных структурах так же, как и в политических.
Что дальше?
Как и многое другое в технологии, методологии будут изменяться в соответствии с конкретными обстоятельствами и вкусами клиентов и будут внедряться с разной степенью строгости. Даже если та или иная методология философски совместима с корпоративной культурой, ее все равно может быть невозможно внедрить ортодоксальным образом. Иногда лучше всего установить архитектуру в качестве базовой линии и идеала, признавая, что отклонения будут иметь место, и явно разрешая их. Элементы других архитектур могут быть даже включены в базовую архитектуру в качестве модификаций. И это нормально.
Если архитектура внедряется догматически, она, скорее всего, потерпит неудачу. В 2022 г. организации должны найти подходы, которые будут работать в гармонии с производством и потреблением данных и реальностью того, как различные группы обмениваются данными, взаимодействуют и конкурируют. Операционные данные — это просто привязанные ко времени записи людей, объектов, процессов и операций. Они будут отличаться по структуре и семантике настолько, насколько команды, производящие их, отличаются по своему поведению, философии бизнеса и практике.
Сбор и анализ данных в таких группах может быть таким же сложным делом, как и управление разнообразными сообществами. Аналогичным образом, чтобы сбалансировать и удовлетворить потребности различных бизнес-групп в данных и аналитике, потребуется терпение, тонкость, дипломатия и готовность групп к достижению положительных результатов сотрудничества.
Просвещенные архитектуры, расширение прав и возможностей и автономия помогут в этом. Но они должны быть основаны на реалиях обеспечения соответствия и совместимости, избегая при этом технического долга и фрагментации.
