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