Пять советов по разработке data products

Создание data products — хороший способ ускорить поставку, повторно использовать данные, снизить риски и управлять затратами. Стандартизированные data products также помогают улучшить аналитику и возможности AI.

Data products помогают стандартизировать то, как сырые наборы данных, представления data warehouse и логические представления data lake объединяются и используются для предоставления аналитики и AI-возможностей. Разрабатывая data products, команды могут заметно сократить объем предварительной работы по data pipelines, governance и управлению, необходимой для создания надежных data assets, которыми затем могут пользоваться люди, инструменты и AI для разных целей.

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

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

Когда стоит создавать data product?

Большинство организаций не могут позволить себе разрабатывать data products как промежуточный слой для каждой визуализации данных, модели machine learning или AI agent. На создание data products нужны время и деньги, а после вывода их «на полку» product managers должны отвечать за поддержку и управление жизненным циклом. Так когда agile data teams должны создавать data products и как им приоритизировать более важные из них? Один из отправных пунктов — рассматривать data products, построенные на одном наборе данных, и понимать, что значит продуктировать их.

«Набор данных действительно должен становиться data product тогда, когда на него начинают опираться несколько команд, чтобы принимать решения или запускать приложения», — говорит Danielle Ben-Gera, вице-президент по engineering в Crunchbase. «Тогда становятся важны правильный governance, понятная ответственность, версионирование и управляемый жизненный цикл изменений, иначе вы просто будете поставлять хрупкие pipelines, которые ломают downstream-работу».

Второй критерий — рассматривать использование неуправляемых наборов данных как форму data debt. Создание data product может быть тактическим способом стандартизировать использование и снизить риски.

«Организациям стоит строить data product, когда наборы данных используются несколькими командами без сильного governance, четко определенных процессов или понятной ответственности», — говорит Yaad Oren, управляющий директор SAP Labs US и глобальный руководитель исследований и инноваций в SAP. «Когда data products опираются на единую data foundation, они устраняют silos, формируют общее понимание и обеспечивают безопасный, стандартизированный доступ, который позволяет командам уверенно использовать одни и те же assets».

Третье соображение — применять производственные принципы: создавать data products для определенных клиентов, стимулировать повторное использование и добиваться эффективности. Формулировка vision statement для data product и оценка его business value особенно важны, когда продукт требует объединения нескольких источников данных. Это поднимает вопрос о том, как стандартизация дает экономию, улучшает качество, снижает риски data security и приносит другие преимущества.

Christopher Zangrilli, вице-президент по technology strategy в Vertex, говорит: «Руководителям стоит спрашивать, сократят ли данные cycle time, повысят ли точность решений или снизят compliance risk, чтобы оценить бизнес-эффект. Когда governance, change management для внедрения, качество и измерение ценности заложены с самого начала, data products превращаются из экспериментальных инструментов в стратегические активы».

Зачем задавать стандарты для data products?

У товаров в продуктовом магазине есть упаковка с подробным списком ингредиентов, сроком годности и ценой. Руководители по data governance тоже должны стандартизировать то, как data products определяются, каталогизируются и управляются.

«Любой современный data product должен четко отвечать на четыре вопроса: откуда берутся данные, как они преобразуются между системами, кто или что их потребляет и какие обязательства по governance применяются на каждом этапе», — говорит Abhi Sharma, сооснователь и CEO в Relyance AI. «Без такого end-to-end контекста команды строят функции на данных, которые не до конца понимают».

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

«Без lineage команды действуют вслепую, а governance превращается в реактивную уборку последствий», — говорит Carter Page, исполнительный вице-президент по исследованиям и разработке в Astronomer. «Когда команды видят, откуда возникли данные, как они были преобразованы и какие системы на них зависят, обновления становятся предсказуемыми, нужные pipelines тестируются, нужные стейкхолдеры уведомляются, а breaking changes документируются до того, как вызовут инциденты».

Каков жизненный цикл data product?

Управление жизненным циклом API, приложения или AI-модели требует определения графика релизов для исправлений, улучшений и других необходимых обновлений. Управление жизненным циклом data product включает несколько похожих дисциплин. Ulf Viney, исполнительный вице-президент по engineering, support и operations в Precisely, говорит: «Управление жизненным циклом должно включать версионирование, тестирование, структурированное развертывание и коммуникацию со стейкхолдерами».

Одно фундаментальное отличие data products в том, что их жизненный цикл тесно связан с тем, как растут или структурно меняются лежащие в основе наборы данных. Data product, который работает сегодня, но не устойчив к изменениям или не отправляет предупреждения, когда нужны исправления, может сломать downstream-сценарии и подорвать доверие стейкхолдеров и пользователей к данным.

«Управлять данными как продуктом — значит, что потребители данных могут доверять им с самого начала, а для этого нужен устойчивый и масштабируемый framework governance, который гарантирует, что данные легко найти, понять и использовать», — говорит Bethany Sehon, старший директор по enterprise data в Capital One. «Если с первого дня встроить observability, проверки качества и interoperability, можно управлять полным жизненным циклом данных — от версионирования и тестирования до измерения внедрения и производительности».

Командам, которые управляют критически важными data products в реальном времени и которые питают несколько downstream-аналитик и AI use cases, стоит учитывать следующие devops- и data governance-практики.

• Установите обязательные правила data governance, особенно в части заданных порогов качества данных, оценки возможных bias и соблюдения data privacy policies.
• Поддерживайте продвинутые continuous integration/continuous delivery (CI/CD) и continuous deployment, при этом continuous testing и production deployments должны быть полностью автоматизированы.
• Убедитесь, что все data integrations имеют observable dataops с мониторингом проблем качества данных и уведомлениями, если pipelines перестают работать. IT services должны быть определены для обработки запросов и инцидентов.
• Согласуйте это со стратегиями data management technology platform, включая data fabrics, data security posture management (DSPM), document processing и vector databases.

Как стимулировать внедрение?

К сожалению, создание data product не гарантирует его внедрение. Вспомните сложности с повторным использованием кода, внедрением API или стандартизацией внутренних devops tools. Это все примеры промежуточных продуктов, нацеленных на снижение developer toil и повышение качества, но многие команды занимали позицию not-invented-here и предпочитали практики «сделаем сами», а не изучали и не принимали стандарты, созданные другими командами.

У data products трудности еще выше, особенно когда они нацелены на консолидацию data silos или отказ от таблиц spreadsheets. Product managers, которые отвечают за data products, должны разработать change management program, чтобы наращивать внедрение и собирать обратную связь.

«Data product заслуживает своего места, когда он помогает принять реальное бизнес-решение и ему можно доверять в масштабе», — говорит Quais Taraki, CTO в EnterpriseDB. «Относитесь к data products как к software: с версионированием, тестированием и контролируемыми релизами, а не как к одноразовым pipelines. Такая дисциплина безопасно доставляет нужные данные в нужное место и превращает данные в измеримую ценность через внедрение, скорость и снижение рисков».

Product managers могут ускорить внедрение, показывая, как data product соответствует AI strategy бизнеса и трансформации культуры. Например, можно показать, как data product повышает AI literacy, democratizes AI через правильные business use cases или готовит сотрудников к работе с AI agents.

Как измерять business value?

Ценность customer-facing product часто измеряют через влияние на выручку, метрики использования и customer satisfaction (CSat). Внутренние продукты для сотрудников можно оценивать по эффективности рабочих процессов, росту продуктивности и employee satisfaction (ESat). Data products выступают промежуточным слоем, поэтому количественно оценить их ценность сложнее.

«Слишком многие организации по-прежнему рассматривают data products как технические результаты, а не как стратегические активы», — говорит Daniel Ziv, глобальный вице-президент по AI и analytics в Verint. «Их реальная ценность становится очевидной, когда оцениваешь, насколько уникально генерируются данные, какой измеримый эффект они могут дать в решениях и как безопасно извлекать из них insight при управлении рисками. Когда у всех организаций есть доступ к одним и тем же AI models, конкурентное преимущество создают ваши уникальные данные и то, как быстро вы превращаете их в действие».

Sunil Kalra, руководитель центра компетенций Databricks в LatentView Analytics, добавляет: «Ценность нужно измерять через внедрение, использование и результаты, такие как более быстрые инсайты, меньше ручной работы и лучшее влияние на выручку или затраты».

Лучшая практика — использовать metrics скорости цифровой трансформации, такие как time to data, time to decision, time to innovation и time to value. По мере того как все больше организаций стремится извлекать business value из AI agents, создание data products будет рассматриваться как способ ускорить поставку, повторно использовать data assets, снизить риски и управлять затратами.

Материал — перевод статьи с английского.

Оригинал: Five tips for developing data products