Показаны сообщения с ярлыком Интеграция данных и приложений. Показать все сообщения
Показаны сообщения с ярлыком Интеграция данных и приложений. Показать все сообщения

понедельник, 10 марта 2025 г.

Что такое информационный продукт?

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

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

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

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

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

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

Три архетипа архитектуры в монетизации данных:
  • Платформа данных. Актив - данные. Сырые данные, поставляеме посредством API или на площадках. Могут использоваться пользователями для анализа и кейсов.
  • Платформы анализа данных. Актив - знания. Разработка моделей на основе сырых даных, аналитическая экспертиза и технологии.
  • Интеллектуальные приложения. Актив - мудрость. Возможность распознавать паттерны, которые помогать принимать решения. Множественные приложения позволяют поддерживать различные требования покупателей.

Стратегия и критические факторы успеха в монетизации информационных продуктов.
  • Создание индустриального стандарта.
    • Стратегия. Построения решения для обработки отраслевых данных на базе большого массива уникальных данных.
    • Критические факторы успеха. 
      • Значительное число уникальных данных.
      • Преимущество первопроходца.
      • Прорывные кросс-индустриальные инновации, которые могут стать де-факто ответом на неудовлетворенные потребности отрасли.
  • Сбор данных из задействованных пользовательских баз данных
    • Стратегия. Разработка продукта, который использует дополнительные пользовательские инсайты и понимание драйверов стоимости как в пределах отрасли так и вне.
    • Критические факторы успеха.
      • Большая клиентская база.
      • Возможность создать "эффект маховика" для основного бизнеса.
  • Преобразование значительных организационных знаний в продукт.
    • Стратегия. Использование внутренних ценных данных и инсайтов для создания продукта, который может быть использован внешними компаниями.
    • Критические факторы успеха.
      • Внутренние данные и аналитические инструменты, которые представляют ценность для внешней аудитории.
      • Уникальные данные, собранные и подготовленные в виде продукта для использования основным бизнесом.
Рисунок из оригинала к тексту.



Источник.

https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/from-raw-data-to-real-profits-a-primer-for-building-a-thriving-data-business

вторник, 15 ноября 2022 г.

Преимущества и проблемы интеграции данных и приложений

Конкретные преимущества метода интеграции путем обмена сообщениями:

Удаленная связь. Обмен сообщениями позволяет отдельным приложениям обмениваться данными - принимать и передавать данные. В пределах одного приложения это не важно, так как объекты могут просто совместно использовать одни и те же данные, размещенные в памяти. А вот отправка данных на другой компьютер намного сложнее и требует копирования данных с одного компьютера на другой. Это означает, что объекты должны быть «сериализуемыми», то есть преобразоваными в простой поток байтов, который можно отправлять по сети. Удаленная связь позволяет организовать обмен сообщениями между отдельными приложениями.

Интеграция платформ/языков программирования. Возможно разные компьютерные системы используют разные языки программировани, разные технологии и платформы. Для интеграции таких разнородных приложений может потребоваться демилитаризованная зона промежуточного программного обеспечения для согласования приложений. Например, обмен может быть организован с помощью плоских файлов. В этих обстоятельствах система обмена сообщениями может быть универсальным переводчиком между приложениями, которая работает с разными языками программирования и платформами. Система обмена сообщения работает на своих условиях, но позволяет приложениям общаться так как использует общую парадигму обмена сообщениями. Эта универсальная связь является сердцем шаблона шины сообщений.

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

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

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

Надежная связь. Обмен сообщениями обеспечивает надежную доставку, которую не может обеспечить удаленный вызов процедур (RPC). Причина, по которой обмен сообщениями более надежен, чем RPC, заключается в том, что в ходе обмена сообщениями сообщения сохраняются в ходе передачи сообщений. Данные упакованы в виде сообщений, которые являются атомарными, независимыми единицами. Когда отправитель отправляет сообщение, система обмена сообщениями сохраняет это сообщение. Затем он доставляет сообщение, пересылая его на компьютер получателя, где оно снова сохраняется. Хранение сообщения на компьютере отправителя и компьютере получателя считается надежным. Что ненадежно, так это пересылка (перемещение) сообщения с компьютера отправителя на компьютер получателя, поскольку получатель или сеть могут не работать должным образом. Система обмена сообщениями преодолевает это, повторно отправляя сообщение до тех пор, пока оно не будет успешным. Этот автоматический повтор позволяет системе обмена сообщениями преодолевать проблемы с сетью, так что отправителю и получателю не нужно беспокоиться об этих деталях.

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

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

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

Недостатки асинхронного обмена сообщениями. Асинхронный обмен сообщениями не является панацеей интеграции. Он решает многие проблемы интеграции разрозненных систем элегантным способом, но также создает новые проблемы. Некоторые из этих проблем присущи асинхронной модели, в то время как другие проблемы зависят от конкретной реализации системы обмена сообщениями.

Комплексная модель программирования. Асинхронный обмен сообщениями требует от разработчиков работы с моделью программирования, управляемой событиями. Логика приложения больше не может быть закодирована одним методом., который вызывает другие методы. Логика делится на несколько обработчиков событий, которые реагируют на входящие сообщения. Такая система более сложна и труднее в разработке и отладке. Например, эквивалент простого вызова метода может потребовать сообщения запроса и канала запроса, сообщения ответа и канала ответа.

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

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

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

Ограниченная поддержка платформы. Многие проприетарные системы обмена сообщениями доступны не для всех платформах. Часто проще передать файл по FTP на другую платформу, чем получить к нему доступ через систему обмена сообщениями.

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

вторник, 21 июня 2022 г.

К вопросу интеграции данных и приложений

Если в области ИТ приходится заниматься интеграций на базе технологии обмена сообщениями, то прежде всего следует составить предствление и получить ответы на следующие вопросы:
  1. Преимущества и ограничения обмена сообщениями по сравнению с другими методами интеграции. А для этого нужно иметь предствление о "других" методах интеграции.
  2. Методы и способы идентификации каналов сообщений, которые потребуются интегрируемым приложениям.
  3. Способы контроля факта получения пользователям сообщений, их идентичности или недействительности.
  4. Способы отправки сообщений, что должны содержать сообщения, как использовать специальные свойства сообщений.
  5. Способы отправки сообщений конечным получателям с неизвестным местоположением или адресом.
  6. Способы преобразовать сообщений, если отправитель и получатель имеют свои форматы и не согласны приводить сообщение к общему форматы.
  7. Как разработать код, соединяющий приложение с системой обмена сообщениями.
  8. Как управлять и контролировать систему обмена сообщениями, знать - когда она используется.
Примечание.

Четыре основных подхода интеграции данных и приложений:
  1. Передача файлов. Одно приложение записывает файл, который позже читает другое. Приложения должны согласовать имя и местоположение файла, формат файла, время его записи и чтения, а также то, кто будет удалять файл.
  2. Общая база данных. Несколько приложений используют одну и ту же схему базы данных, расположенную в одной физической базе данных. Поскольку нет дублирующих хранилищ данных, нет необходимости передавать данные из одного приложения в другое.
  3. Удаленный вызов процедуры. Одно приложение предоставляет некоторые из своих функций, чтобы другие приложения могли получить к нему удаленный доступ как к удаленной процедуре. Коммуникация происходит в режиме реального времени и синхронно.
  4. Обмен сообщениями. Одно приложение публикует сообщение в общий канал сообщений. Другие приложения могут прочитать сообщение из канала позже. Приложения должны согласовать канал и формат сообщения. Коммуникация асинхронна.