Ставка ЦБ изменилась. Конкурент выкатил акцию. Регулятор ввел новое требование. Вопрос один: сколько времени займет обновление вашей продуктовой линейки? Если от недели до полугода — эта статья для вас.

Привет, Хабр!

Меня зовут Данила Ильичев, я инженер-аналитик продукта Digital Q.Sensor BI в компании «Диасофт». Недавно я провел вебинар, на котором мы разбирали практический вопрос: как далеко сегодня можно зайти в финансовой аналитике, если отдать часть рутинной работы искусственному интеллекту.

ИИ в финансовой аналитике для нас – это не история про модную технологию, которую нужно куда-нибудь встроить ради факта использования ИИ. В первую очередь это вопрос: какие этапы аналитики можно ускорить с помощью ИИ, сохранив контроль над данными, расчетами и результатом. Одним из ответов стала легковесная платформа Digital Q.Sensor BI.

Еще несколько лет назад low-code воспринимался прежде всего как способ ускорить разработку. Но с появлением генеративного AI вопрос стал звучать иначе: если код теперь может писать модель, зачем вообще нужны low-code и no-code платформы?

Этому вопросу и был посвящен эфир AM Live, в котором приняли участие Дмитрий Старов («Диасофт»), Антон Симуни (ИТ-экосистема «Лукоморье»), Ева Беляева (Security Vision) и Александр Жуланов (SimpleOne). Эксперты обсудили, где проходит граница между low-code и no-code, какие задачи такие платформы решают в enterprise-разработке, как в этот процесс встраиваются AI-агенты и что происходит с привычными ролями внутри IT-команд.

По мнению Дмитрия Старова, low-code – это уже про то, как удержать разработку под контролем. Особенно теперь, когда код начинают массово генерировать AI-агенты. Платформа в новых условиях становится набором правил и ограничений: она задает архитектуру, стандарты, готовые компоненты и не дает агенту каждый раз изобретать систему заново.

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

Такая функциональная насыщенность стала естественным результатом развития рынка. Однако вместе с возможностями росла и сложность систем: увеличивалось число настроек, интерфейсов и сценариев работы, а внедрение СЭД все чаще превращалось в отдельный ИТ‑проект, требующий настройки, интеграции и обучения пользователей.

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

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

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

В результате электронный сбыт оказывается не интерфейсом для создания заказа, а сквозным процессом, связывающим клиента, склад, производство, закупки и сотрудников компании.

И здесь возникает главный вопрос: как сделать так, чтобы заказ не потерялся между всеми этими этапами?

14 октября 2025 года вышла Camunda 7.24. Это был последний релиз Community Edition. GitHub‑репозиторий переведен в архив, issue закрыты, патчей безопасности больше не будет.

Никаких громких заголовков по этому поводу не случилось. А между тем на Camunda 7 в России работают сотни систем: кредитные конвейеры, согласование документов, клиентские заявки, внутренние процессы госкомпаний. Все они теперь работают на движке, который больше никто не поддерживает.

Сразу дисклеймер: у нас в Диасофт есть своя BPM‑платформа на форке Camunda 7, поэтому тема миграции нам небезразлична. Но разберем варианты честно, даже те, где наше решение не нужно.

Привет, Хабр!

Меня зовут Илья Петров, я руковожу продуктом Digital Q.Sensor BI в «Диасофт». За последний год я неоднократно слышал одну и ту же фразу от разных команд — и своих, и клиентских: «нам бы сюда буквально пару графиков». И каждый раз внутри у меня загорается тревожная лампочка, потому что я примерно знаю, чем это заканчивается.

Это не рекламный текст про то, какой у нас хороший продукт. Это скорее попытка разложить по полочкам инженерную развилку, с которой мы регулярно сталкиваемся и сами, и в разговорах с клиентами: когда визуальная аналитика перестаёт быть фичей одного экрана и становится отдельным слоем архитектуры — и что с этим делать.

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

Давайте разберемся, что на самом деле происходит: куда движется мировой рынок CRM, что происходит в России и как на эти тренды отвечают платформы, которые не просто пишут на сайте «у нас есть ИИ», а действительно встраивают его в ядро.

Привет, Хабр.

Мы в Диасофт развиваем Digital Q.Sensor BI — промышленную BI‑платформу, в которую команда продукта встраивает мультиагентные ИИ‑системы. И поэтому хорошо понимаем, почему вокруг AI‑native аналитики сегодня столько споров.

Сторонники self‑service BI со встроенными LLM обещают бизнесу свободу: дашборд теперь собирает не BI‑разработчик за три недели, а сам аналитик за десять минут — обычным текстовым запросом. Скептики возражают: вместе со свободой компании могут получить сотни несогласованных отчетов, цифры с неясным происхождением и решения, принятые на основе галлюцинаций языковой модели.

В статье эксперт «Диасофт» делится своими выводами — без попытки представить единственно правильный ответ. Скорее, это взгляд человека, который непосредственно работает с внедрением мультиагентных ИИ‑систем в промышленную BI‑платформу и наблюдает за тем, как меняется сам подход к аналитике.

Кстати, тех, кто дочитает статью до конца, ждет бонус.

Привет, Хабр!

На связи Илья Виссарионов, директор департамента «Аппаратно‑системная платформа» компании «Диасофт».
 
Про DevSecOps написаны тонны текстов, но почти все они – про инструменты: какой SAST выбрать, куда «воткнуть» Trivy, как подружить сканеры с GitLab. Реальная проблема 2026 года в другом. Сканеры давно стоят на всех стадиях пайплайна, базы уязвимостей обновляются ежедневно, а криты все равно доезжают до заказчика. Проблема сместилась в другую плоскость: как приоритизировать, чинить и ретестить находки, когда у тебя 2000+ развертываний в день и больше сотни команд. Проще говоря – как управлять security-долгом на конвейере.

Этот текст – результат внутренней дискуссии, в которой участвуют три стороны: те, кто отвечает за конвейер и инструменты выпуска, те, кто пишет продукты, и те, кто несет эти продукты заказчикам и первыми улавливают требования рынка. У каждой стороны своя правда, и мы решили не сглаживать углы, а честно показать, как выглядит взросление DevSecOps изнутри – со всеми компромиссами, экономическими выкладками и парадоксами, о которых обычно не пишут.

Apache Kafka можно бесплатно скачать, развернуть и подключить к приложениям. При небольшом проекте этого может быть достаточно: создали несколько топиков, настроили потребителей — и обмен сообщениями работает.

Но по мере роста инфраструктуры Kafka перестает быть просто брокером. От нее начинают зависеть функциональность микросервисов, интеграции, тестовые стенды, CI/CD‑процессы и рабочие системы. Вместе с нагрузкой растет и список вопросов: как обновлять кластеры, отслеживать очереди, устранять уязвимости и восстанавливать работу после отказа.

Меня зовут Илья Виссарионов, я директор департамента «Аппаратно‑системная платформа» компании «Диасофт», и в этой статье расскажу, как мы используем Kafka в DevOps‑инфраструктуре «Диасофта», какие проблемы обнаружили при эксплуатации под высокой нагрузкой и почему в итоге стали рассматривать брокер сообщений не как отдельный open‑source‑компонент, а как полноценную инфраструктурную платформу.

Привет, Хабр!

Меня зовут Жуйков Андрей, занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

Сегодня для многих организаций импортозамещения СУБД - уже практическая задача, которую необходимо решать без остановки бизнес-процессов и без многомесячной переработки прикладных систем. Одним из ключевых требований при выборе новой платформы становится возможность сохранить существующую прикладную логику и минимизировать объем изменений в коде приложений.

В этой статье я покажу, как установить Digital Q.DataBase 18.2 на РЕД ОС 8.0.3, познакомлю с новой архитектурой СУБД и продемонстрирую подключение к каждому из поддерживаемых диалектов.

Импортозамещение сервера приложений — это не только перенос Java‑систем в новую среду. Нужно сохранить привычные сценарии эксплуатации, централизовать управление и встроить решение в существующий технологический ландшафт заказчика.

Я Сергей Рощупкин, занимаюсь развитием платформы управления серверами приложений Digital Q.AppServer в «Диасофт». В статье разберу реальный кейс миграции с Oracle WebLogic в крупном банке, покажу, как устроена платформа и где в ней работают ИИ‑агенты, а в конце — практические советы инженерам, которые мы сформулировали по итогам проектов.

Привет, Хабр!

Я Михаил Кулаков, в «Диасофт» занимаюсь развитием импортонезависимой платформы распределенных реестров Digital Q.Blockchain.

Про закон «О цифровых валютах и цифровых правах» написано уже достаточно, и подробных разборов по статьям хватает. Ограничусь рамкой: закон вступает в силу 1 сентября 2026 года, требования к предотвращению операций без добровольного согласия клиента – годом позже, и на финансовом рынке появляется новый профессиональный участник. Цифровой депозитарий ведет учет цифровых валют и цифровых прав по цифровым счетам и предоставляет доступ к адресам-идентификаторам, а работать в этом статусе можно только после включения в соответствующий реестр Банка России.

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

Переход крупных корпоративных систем на отечественные СУБД остается одной из наиболее актуальных задач последних лет. Однако основная сложность подобных проектов заключается не столько в переносе данных, сколько в сохранении работоспособности существующих приложений, написанных под Microsoft SQL Server и Oracle Database.

Именно поэтому развитие Digital Q.DataBase сосредоточено сразу на нескольких направлениях: расширении совместимости с зарубежными СУБД, автоматизации миграции и создании инструментов, позволяющих минимизировать объем ручной доработки приложений.

Версия 18.2 стала одним из наиболее масштабных обновлений платформы. В релиз вошли изменения архитектуры продукта, значительное развитие совместимости с Microsoft SQL Server и Oracle Database, новые возможности мастера миграции, первая версия службы построения отчётов, совместимой с SQL Server Reporting Services, а также десятки других улучшений.

Подробнее об изменениях - в этой статье.

Мы в Диасофт несколько лет назад начали строить Digital Q.DevOps — внутренний конвейер сборки, тестирования, доставки и развёртывания, — и сейчас через него проходит больше 2000 развёртываний в сутки. На прошлой неделе собрали внутренний митап с разработчиками, тестировщиками и DevOps-инженерами, чтобы честно разобрать, что в продукте получилось, что до сих пор болит, и куда мы движемся.

Что важнее при выборе СУБД: выручка разработчика или реальные возможности продукта?

На российском рынке долгое время ответ фактически сводился к рейтингам продаж. Но ситуация постепенно меняется. Исследование ЛАНИТ стало одной из первых попыток сравнить отечественные СУБД не по финансовым показателям, а по техническим характеристикам — от совместимости и миграции до безопасности и администрирования.

Однако при внимательном изучении результатов возникли вопросы ....

Привет, Хабр!

Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

Импортозамещение СУБД перешло из разряда регуляторных требований в практическую плоскость: компаниям нужно менять платформы без остановки бизнеса. Типичная проблема — огромная экосистема вокруг MS SQL, PostgreSQL или Oracle с тысячами процедур, отчетов и интеграций. Ручной перенос такого объема (например, 900 тысяч строк кода) занимает месяцы и несет риски, при этом даже автоматизация не исключает доработок.

Даже с автоматизированными средствами конвертации большинство проектов миграции СУБД требует доработок и тестирования, поэтому ключевым требованием становится сохранение существующей логики приложений. Digital Q.DataBase решает эту задачу через воспроизведение функциональности популярных СУБД и поддержку их диалектов SQL, что позволяет переносить системы быстрее без масштабной переработки прикладного слоя.

В новой версии Digital Q.DataBase существенно переработана архитектура продукта. Вместо единого монолитного решения СУБД получила независимые модули, воспроизводящие функциональность PostgreSQL, Microsoft SQL Server и Oracle Database. Это упрощает установку, сопровождение и обновление системы, а также позволяет использовать только те компоненты, которые действительно необходимы в конкретном проекте.

В этой статье покажу, как установить Digital Q.DataBase 18.2 на Astra Linux 1.8, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.

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

Проблема в том, что этим набором серверов нужно управлять ежедневно. Администратору уже недостаточно просто понимать, что приложение запущено: нужно контролировать состояние серверов, следить за приложениями и метриками, развертывать новые версии и быстро выполнять типовые операции без лишней ручной работы. Когда ИТ-контуров становится больше, разница между «в целом работает» и «удобно эксплуатируется» начинает ощущаться особенно остро.

Digital Q.AppServer как раз закрывает эту задачу: платформа дает единый интерфейс для работы с серверами приложений Digital Q.TomEE и Digital Q.WildFly и собирает в одном месте основные операции сопровождения. В центре внимания здесь – уже не сам по себе выбор между серверами, а то, что ими можно управлять как частью одного эксплуатационного процесса, а не как набором разрозненных систем.

Привет, Хабр!

Это Андрей Ловлин, руководитель команды «Фабрика данных. Платформа» компании Диасофт. В предыдущей статье мы рассказывали про S3 Архипелаг – слой хранения для нашей «Фабрики данных» (Digital Q.DataFactory). Сегодня речь пойдет о другой задаче: построение конвейера интеллектуального распознавания документов, загружаемых в нашу «Фабрику данных».

PDF-файлы, сканы, фотографии договоров – все это накапливается в организациях годами. Для построения RAG-систем и работы с LLM эти данные необходимо извлечь из неструктурированных документов и преобразовать в структурированный формат. Задача, на первый взгляд, тривиальная. На практике – не совсем.