Привет, Хабр!
Меня зовут Илья Петров, я руковожу продуктом Digital Q.Sensor BI в «Диасофт». За последний год я неоднократно слышал одну и ту же фразу от разных команд — и своих, и клиентских: «нам бы сюда буквально пару графиков». И каждый раз внутри у меня загорается тревожная лампочка, потому что я примерно знаю, чем это заканчивается.
Это не рекламный текст про то, какой у нас хороший продукт. Это скорее попытка разложить по полочкам инженерную развилку, с которой мы регулярно сталкиваемся и сами, и в разговорах с клиентами: когда визуальная аналитика перестаёт быть фичей одного экрана и становится отдельным слоем архитектуры — и что с этим делать.
Я не предлагаю заменить вашу систему нашим BI. Я предлагаю не писать BI внутри вашей системы.
Как всё начинается с одного графика
Один график делается быстро. Проблема начинается не с первого требования, а со второго, третьего и двадцать седьмого. В этот момент команда уже не пишет экран. Она пишет свой BI.
Есть один довольно надёжный способ понять, что корпоративная система успешно развивается. В какой-то момент кто-нибудь обязательно говорит: «А давайте здесь график».
График — это прекрасно. Подключили библиотеку, получили JSON, нарисовали линию. Все довольны. Через неделю появляется фильтр по периоду. Потом детализация по клику. Потом таблица рядом. Потом связанные графики. Потом пользовательские роли и разные наборы данных. Потом сохранение выбранных фильтров, экспорт, печать и возможность собрать другой экран без нового релиза фронтенда.
Я специально не драматизирую: каждая отдельная задача выглядит небольшой. Никакого архитектурного события не происходит — никто не собирает комитет и не утверждает ADR «создать собственную BI-платформу». Просто очередная задача попадает в спринт.
А через несколько месяцев в проекте уже есть модель дашборда, механизм фильтрации, состояние интерфейса, права, конфигурация компонентов, связи между виджетами и набор внутренних API. То есть появился новый продукт внутри продукта — только никто его так не называл. Он просто завёлся. Как любой достаточно крупный внутренний фреймворк.
Сначала у него три класса. Потом собственный жизненный цикл. Потом документация. Потом человек, который «лучше всех знает, как это работает». А потом этот человек уходит в отпуск. С этого момента решение официально считается enterprise.
Проблема не в ECharts: график дешёвый, аналитический интерфейс — уже нет
Спор «BI-платформа или библиотека графиков» обычно начинается не с того уровня абстракции, и я это тоже проходил на своём опыте.
Если задача правда состоит из одного графика — берите ECharts, Chart.js, Highcharts или то, что уже принято в вашем стеке. Тащить BI-платформу ради одного графика — это доставка булочки фурой, я сам бы отговорил так делать.
Но реальная стоимость визуальной аналитики почти никогда не сидит в рисовании столбика или линии. Она сидит в инфраструктуре вокруг: кто видит данные, как синхронизируются фильтры, что происходит при drill-down, можно ли менять структуру экрана, как сохраняются представления, как ведут себя связанные компоненты, как всё это экспортируется и сопровождается.
Плюс скучная, но важная часть: единая семантика показателей, правила форматирования, обработка пустых значений, большие наборы данных, повторное использование компонентов, аудит доступа, совместимость версий. Это уже не «сделать красивый график». Это продуктовая платформа — и как раз здесь команды чаще всего недооценивают объём работы.
Самописный путь («сделаем небольшой экран»): chart lib → filters → RBAC → state → export → layout → custom logic. Каждый элемент реалистичен по отдельности, но сумма превращается в отдельную подсистему, которую нужно проектировать, тестировать и сопровождать годами.
Платформенный путь («возьмём готовый визуальный слой»): данные → Digital Q.Sensor BI → интерактивный UI. Команда продукта продолжает заниматься предметной областью, а визуально-аналитическая инфраструктура становится отдельным готовым компонентом.
Экономия здесь не в том, что график рисуется быстрее. А в том, что вам не приходится постепенно выращивать вокруг графика собственную платформу: связанные визуальные компоненты, глобальные и локальные фильтры, drill-down/up, таблицы и сводные представления, права на данные и интерфейс, сохранённые представления, экспорт и печать, адаптивную компоновку, кастомные сценарии - их поддержку и развитие.
Что если BI — не место, а часть продукта?
Именно к этой мысли нас подтолкнул внутренний кейс с генератором отчётности. Коллеги из департамента «Экономика данных» компании «Диасофт», в которой я работаю, показывали свой генератор отчётности. У продукта собственная логика, свои данные и правила формирования результата. Но визуальную часть они не стали превращать в ещё один самостоятельный frontend-проект - для неё использовали Digital Q.Sensor BI.
И тут привычная картина BI немного переворачивается. Обычно BI представляется как отдельная система: пользователь работает в одном приложении, потом переходит в другое, ищет нужный дашборд и уже там смотрит показатели. В embedded-сценарии аналитика приезжает к пользователю сама.
Чем лучше встроен BI, тем меньше он похож на отдельный BI-продукт.
Из того, что мы публично заявляем про Digital Q.Sensor BI:
встраивание интерактивных отчётов и графиков в корпоративные приложения через API;
фильтры, drill-down/drill-up и взаимовлияющие виджеты;
RBAC/ABAC (RLS), SSO и enterprise-сценарии доступа;
no-code сборка дашбордов;
глубокая кастомизация через JavaScript,
алертинг.
Это не список фич для очередной сравнительной таблицы BI-систем. Вместе эти возможности дают архитектурную границу: продукт отвечает за предметную область и данные, а Digital Q.Sensor BI отвечает за их представление и интерактивное исследование. Пользователь при этом может вообще не знать, что внутри работает BI-компонент – он просто видит аналитику там, где уже работает: в CRM, системе мониторинга, отчётности или внутреннем сервисе.
И это, пожалуй, самый интересный для меня эффект embedded analytics: BI перестаёт быть пунктом назначения.
Фреймворк? Почти. Пусть каждый слой занимается своей работой
Слово "фреймворк" здесь я использую не как формальный термин, а как способ мышления.
Когда мы пишем бэкенд, никого не удивляет, что команда не реализует самостоятельно HTTP-сервер, брокер сообщений, полнотекстовый поиск или workflow engine — это отдельные классы задач с огромным количеством уже решённых проблем. Никто в здравом уме не приходит с фразой «Elasticsearch — это, конечно, удобно, но настоящий программист должен написать поиск сам».
С визуализацией данных исторически часто происходит обратное: подключаем charting library и незаметно начинаем писать всё вокруг неё. Поэтому формулировка «Digital Q.Sensor BI как фреймворк» мне кажется полезной именно в архитектурном смысле — готовый building block вместо самодельной инфраструктуры.
Граница ответственности получается довольно чистой. Ваше приложение знает, что такое клиент, отчёт, станок, сделка или риск. Бэкенд знает, откуда взять данные и какие правила применить. Digital Q.Sensor BI знает, как представить результат пользователю и дать с ним взаимодействовать.
То есть low-code здесь не означает «программисты больше не нужны». Это менее драматичная, но куда более полезная вещь: часть изменений визуального слоя можно отделить от жизненного цикла основного приложения.
Кейс: генератор отчётности — каждый отвечает за своё
Хороший архитектурный пример тот, где граница между компонентами видна без презентации на 74 слайда.
Генератор отчётности (данные, структура, бизнес-правила, расчёты) →
Digital Q.Sensor BI (графики, таблицы, фильтры, интерактивность) →
Пользователь, который работает с результатом.
Генератор отчётности не становится BI-системой. Он по-прежнему отвечает за то, что умеет лучше всего: правила отчёта, структуру, подготовку результата и предметную логику. Digital Q.Sensor BI, в свою очередь, не пытается стать генератором: он получает подготовленные данные и превращает их в интерактивное представление.
Стыковка хороша тогда, когда после неё оба продукта остаются самими собой.
Это не единичный случай. У «Диасофт» публично описана интеграция продукта «Отчётность МСФО» с Digital Q.Sensor BI, где последний используется для визуализации отчётных форм и детализации данных. Есть и другой публичный кейс, где инструменты Digital Q.Sensor BI используются для визуализации результатов управленческой отчётности. Так что идея «предметный продукт плюс готовый визуальный слой» - это не архитектурная фантазия для статьи, а рабочая практика.
ETL и DWH увольнять пока не надо
Embedded analytics - не повод объявлять весь data stack устаревшим. Это вообще другая ось.
Здесь я хочу отдельно остановиться, потому что самая простая ошибка в статье про BI-продукт - попытаться доказать, что новый инструмент заменяет вообще всё: ETL, DWH, бэкенд, аналитику, разработку, Excel и, вероятно, половину отдела. Для технической аудитории это не звучит смело. Это звучит подозрительно, и я сам не поверил бы такому тексту.
У Digital Q.Sensor BI гораздо более узкая и понятная роль. Если данные надо собирать и преобразовывать — нужен соответствующий контур. Если нужна витрина или хранилище — они остаются. Если есть доменная бизнес-логика — она живёт в продукте. Sensor занимает визуально-аналитический слой:
Наш Digital Q.Sensor BI не обязан заменять ETL/ELT и подготовку данных, DWH и Data Mart, бэкенд и доменную логику, специализированные расчётные системы, полноценный data governance. Его задача — дать готовый слой визуализации, добавить интерактивность и исследование, встроиться в рабочий сценарий и не заставлять каждую продуктовую команду писать это заново.
Это, кстати, соответствует и нашей публичной архитектуре "Фабрики данных" (Digital Q.DataFactory): загрузка и преобразование данных выделены в отдельный ETL-компонент DataStreamer, а Digital Q.Sensor BI находится в блоке BI и отчётности. Так что тезис не требует делать вид, что визуальный слой внезапно стал системой подготовки данных.
Вместо вывода: BI, которого не видно
Возможно, один из признаков зрелости BI-платформы — момент, когда пользователю уже необязательно знать, что перед ним BI.
Пользователь работает в CRM, системе мониторинга, генераторе отчётности или внутреннем сервисе. Он видит показатели, фильтрует данные, проваливается в детали и меняет представление результата. Для него это один рабочий процесс. BI при этом никуда не исчезает — меняется его роль: из отдельного места, куда нужно идти «за аналитикой», он превращается в инфраструктурный визуальный слой, который встраивается в продукт.
Мне этот взгляд полезен очень практически — и как продакту, и как человеку, к которому периодически приходят с вопросом «а можно нам тут ещё немного аналитики». Если аналитическая часть приложения уже начинает требовать собственной модели экранов, фильтров, прав, состояния и экспорта — стоит хотя бы задать себе вопрос:
Мы всё ещё делаем функцию продукта — или уже незаметно пишем ещё одну платформу?
Если завтра бизнес попросит ещё три экрана, ещё две роли и сохранённые представления — вы расширяете продукт или расширяете свой самописный BI?
Ещё раз повторю тезис статьи, потому что он легко теряется под примерами:
Я не предлагаю заменить вашу систему нашим BI. Я предлагаю не писать BI внутри вашей системы.
Если у вас в бэклоге прямо сейчас лежит задача «добавить небольшой аналитический экран, там буквально пара графиков», мне было бы интересно узнать в комментариях, чем это в итоге обернулось у вас: осталось парой графиков или тоже незаметно обзавелось собственным DashboardStateRegistry.
