При подходе к обработке данных в реальном времени необходимо определиться со стандартом обмена сообщениями между приложениями (т. е. платформой обмена сообщениями) и стандартом потоковой передачи данных. Платформы обмена сообщениями предоставляют цифровым приложениям возможность публиковать сообщения, на которые подписаны приложения, способные действовать по мере их получения. На уровне предприятия существует множество вариантов платформ обмена сообщениями (например, Apache ActiveMQ, Apache Kafka, RabbitMQ или Amazon Simple Queue Service). Выбор стандартной платформы обмена сообщениями позволяет цифровым приложениям отправлять и получать дискретные сообщения, не связывая их между собой.
Потоковая передача данных обычно используется для аналитики или обработки данных в реальном времени. Существуют различные виды потоков, например датчики или биржевые сводки, и для каждого из них должен быть свой стандарт. Например, при выявлении мошенничества потоковая передача данных может помочь вам проанализировать и интерпретировать группу транзакций по сравнению с каждой отдельной транзакцией (см. Рисунок 17.4). Как и в случае с платформами обмена сообщениями, существует множество вариантов потоковой передачи данных на уровне предприятия (например, Kafka, Amazon Kinesis, Apache Spark или Apache Flink).
Передача сообщений по сравнению с потоковой передачей
СООБЩЕНИЕ
Сообщение/событие Логика Действие
Входящее электронное письмо
Фильтр спама Отправкав папку нежелательной почты, если письмо распознано как спам.
СТРИМИНГ
Группа сообщений/событий
Логика Действие
Группа сделок
Алгоритмы обнаружения мошенничества
Блокируйте кредитную карту при обнаружении мошенничества
ПРИЛОЖЕНИЕ 17.4.
Команда по архитектуре предприятия должна на ранних этапах вместе с группами agile pods решить, какие возможности необходимы для обмена сообщениями и потоковой передачи данных в организации. Стандартизация на ранних этапах позволит гибким группам сотрудничать более эффективно.
Глава 18. Более
хирургический и ценностный подход к облачным технологиям
Откровения находятся в облаках.
-Сердж Кинг
Какой объем работ по миграции в облако вы должны выполнить в рамках цифровой трансформации? Это сложный вопрос, который усложняется зачастую ограниченным пониманием экономики облачных вычислений и эффективных стратегий миграции. Правда заключается в том, что результаты масштабных работ по миграции в облако слишком часто не оправдывают надежд и во многих случаях приводят к неожиданно высоким инвестициям и затяжным внедрениям1.
Успешная интеграция облака в цифровую трансформацию и трансформацию с помощью ИИ требует подхода, основанного на том, где находится ценность.
Какие бизнес-домены вы решили сделать приоритетными в своей цифровой дорожной карте и какой подход к миграции в облако - если таковой имеется - потребуется для существующих приложений в этих доменах? Более хирургический подход к облаку позволяет быстрее достичь ценности.
Одновременно переосмысливайте бизнес-сферу и базовые технологии
Большая часть выгоды от облачных вычислений связана с повышением гибкости, инновационности и устойчивости бизнеса, а не с более дешевой заменой традиционной инфраструктуры в центре обработки данных.
Начиная с приоритетных бизнес-доменов, не забудьте одновременно переосмыслить домен и лежащую в его основе технологию. Это позволит вам составить четкое представление о приложениях, которые необходимо перенести, чтобы получить максимальную отдачу, и при этом избежать ловушки переноса множества приложений, которые слишком связаны между собой, чтобы в полной мере использовать преимущества облака.
Например, одна страховая компания, которая хотела перестроить процесс привлечения клиентов, запустила два направления работы: одно - переосмысление и упрощение всего процесса привлечения клиентов, а другое - модернизация базовой технологии в облаке. Две команды, работая вместе, смогли модернизировать платформу omnichannel и технологию в облаке, что позволило им преобразовать набор разрозненных, бумажных, специфических для каждого канала процессов в бесшовный omnichannel опыт с использованием цифровых технологий.
По мере создания технологической дорожной карты для приоритетных областей уточняйте архитектурные решения для каждого из цифровых решений, включенных в дорожную карту, сразу (а не по частям). Это позволит вам получить полное представление о зависимостях и оптимальной последовательности действий, чтобы получить выгоду.
На рисунке 18.1 показаны наиболее распространенные варианты архитектурных решений и связанные с ними инженерные соображения, касающиеся облачных вычислений. Они могут варьироваться от оставления приложения "как есть" до переноса его в облако и вывода из эксплуатации.
Типовые варианты архитектуры для создания цифровых решений
архитектурные решения
Создание нового облачного приложения
Используйте основное системное приложение "как есть" (с оберткой)
