Привет, Хабр! Меня зовут Константин Шимановский. Почти 20 лет своей жизни я работаю с российской BI-платформой «Форсайт. Аналитическая платформа», и сейчас возглавляю Департамент управления продуктами одноименной компании «Форсайт». Мы с моей командой продуктовых менеджеров, архитекторов, методологических и технологических экспертов определяем вектор развития нашей платформы и вырабатываем best-practice ее применения. Всем своим опытом мы хотим поделиться в цикле статей на Хабре. Следите за новыми публикациями. Будет интересно! 

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

Платформа «Форсайт»: что это такое и с чем ее «едят»?

Итак, давайте начнем. Что такое «Форсайт. Аналитическая платформа» (далее просто платформа «Форсайт»)? До 2018 года она называлась платформа «Прогноз» (англ. название - Prognoz Platform). Это одна из самых «мудрых» («древних») платформ класса Business Intelligence, разрабатываемых российскими разработчиками. История создания этой платформы уходит еще в середину 90-х годов, когда на базе кафедры экономической кибернетики Пермского университета группа энтузиастов начала создавать свой собственный российский продукт для анализа данных. Конечно, тогда это был совершенно не тот уровень Self-Service или Enterprise BI в современном его понимании. Но заложенные еще в то время базовые основы дали очень важный и совершенно правильный вектор движения российскому платформенному решению, которое в будущем получило высокое признание на российской и зарубежной сцене.

Самая первая версия платформы «Прогноз» была разработана еще для MS DOS (и называлась она Global). Затем следующие две версии под Windows уже были разработаны на Delphi, и появился бренд «Прогноз». Тогда продукт еще не назывался платформой, а имел скромное название «программный комплекс», или сокращенно ПК. Лично я сам познакомился с ним в самом начале нулевых годов, когда стал работать в компании «Прогноз» (на тот момент правообладатель платформы «Прогноз»). По меркам того времени, у меня уже были неплохие знания и опыт в области разработки и внедрения ПО, но тот микс возможностей первых версий платформы произвел на меня очень сильное впечатление.

Программный комплекс комбинировал в себе инструментарий самых разных программных продуктов. Тут тебе и электронные таблицы практически со всеми возможностями Excel, и конструктор SQL-скриптов (как в Toad и других подобных средах разработки БД), и средства проектирования OLAP-кубов, и статистическая обработка данных (как в EViews/R), и встроенный язык программирования (похожий на Delphi или VBA), и дизайнер экранных форм и много другое... Общий подход использования платформы был сильно похож на комбинацию MS Excel + VBA. При этом, в отличие от Excel, все данные не статично размещались в ячейках таблицы, а были связаны со срезами данных, которыми управляла многомерная модель кубов. Данные в эти кубы можно загрузить инструментом экспорта/импорта (достаточно только сконфигурировать связи между полями источника и приемника). Если в настроечных мастерах чего-то не хватало, то можно было запрограммировать собственную экранную форму во встроенной среде разработки, визуально очень похожей на Delphi или VB. Все отчеты можно было автоматически опубликовать в веб-версии платформы. И огромный список других разнообразных возможностей. Все сейчас и не вспомнишь.

Тогда это меня очень сильно поразило. Столько возможностей, и все в одном продукте. Причем это не разработка заморского гиганта Microsoft (или ему подобных), а, что немаловажно, полностью собственная разработка «с нуля», силами немногочисленного коллектива, состоящего тогда из пары десятков российских программистов. Наверное, я до сих пор нахожусь под этим впечатлением и продолжаю связывать свою жизнь именно с этим российским платформенным продуктом.

Новый год, новые правила

В середине нулевых была смена технологического стека платформы. В 2005 год вышла пятая версия, она получила название Аналитический комплекс «Прогноз-5». Четвертую мажорную версию решено было пропустить, связав это с круглой датой: пятый год, пятая версия. Тогда верилось, что мажорную версию можно будет выпускать каждый год. Сейчас понятно, что это было заблуждение, и выдержать такой ритм для мажорных версий даже сейчас не представляется возможным (несмотря на возросшую динамику развития индустрии ПО).

Основная отличительная особенность новой пятой версии заключалась в том, что базовым языком разработки back-end платформы стал C++. Низкоуровневый язык разработки позволил достичь очень высокой для того времени производительности всех BI-инструментов. Также на существенно новый уровень перешел принцип разработки проектных решений на базе платформы. Появился встроенный в платформу объектно-ориентированный язык Fore. Его отличительная особенность от процедурного языка второй и третьей версии ПК «Прогноз», заключалась в том, что все «сишное» API из back-end стало доступно для обычных пользователей в виде объектной модели на упрощенном высокоуровневом языке. Т.е. теперь все предусмотренные через GUI платформы настройки и функции можно было выполнить и через API. Но с той лишь большой разницей, что, в отличие от жестко «зашитых» визуальных интерфейсов в мастерах платформы, наборы программных команд на Fore можно использовать в произвольной комбинации и трансформировать в любую визуальную бизнес-логику программы.

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

Объектный язык Fore, являющийся калькой программной объектной модели платформы, был не единственным достоинством пятой версии. Примерно в тот же период были сформированы основы собственной уникальной технологии представления реляционных данных в оперативной памяти в виде многомерной матрицы (IMatrix). Это была собственная разработка OLAP-движка. Фактически это был хранимый в оперативной памяти кэш многомерного представления данных кубов платформы, получаемых из ROLAP-модели. Это позволяло обращаться приложению к серверу БД только при необходимости, например, при смене отметки в измерениях куба.

В следующих мажорных версиях платформы этот технологический подход дал возможность реализовать уже полноценную модель данных MOLAP, в том числе с полной загрузкой и обработкой всех данных в ОЗУ (in-memory) или с возможностью формирования данных в виде предподготовленного файлового кэша на жестком диске. Правда, тогда это была технология, больше ориентированная на быстрое чтение данных. С записью дела обстояли не так хорошо, и задачу больших вычислений в оперативной памяти (где в том числе требуется и запись в IMatrix большого количества измененных расчетных данных) мы решим только в этом году в очередной минорной версии платформы. Но об этом подробнее мы тоже расскажем в отдельной статье в ближайшем будущем.

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

У каждого метаобъекта при создании формируется уникальный ключ и указывается собственный строковый идентификатор (отражающий бизнес-смысл объекта). Далее все обращения к метаобъекту происходят уже по этому уникальному идентификатору. Кроме того, репозитории системы из разных ландшафтов (PROD, DEV, TEST) могут быть синхронизированы между собой и выполнена репликация (перенос) метаданных с одного ландшафта на другой. Репликация выполняется с помощью формирования в платформе pefx (Platform Export File) файла обновления. Он «собирается» с репозитория одного ландшафта и устанавливается в репозиторий другого ландшафта.

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

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

В этот же период в платформе появилось большое количество эконометрических и оптимизационных методов. Эти методы наши программисты реализовали самостоятельно. Т.е. все было из коробки и не требовалось дополнительных статистических пакетов и расчетного ПО. При этом все методы тщательно тестировались и сравнивались по всем характеристикам с популярными в то время стат. пакетами: SPSS, Statistica, gretl.          

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

Кроме этого, настраиваемые модели можно было объединять в единую последовательную цепочку расчета – метамодель. А также генерировать список альтернативных вариантов расчета и многое другое. Иными словами, это была уже вторая версия конструктора моделей в платформе. Мы назвали ее «Контейнер моделирования». Он мог работать как с временными рядами, так и с панельными данными.

Эти и многие другие возможности Аналитического комплекса «Прогноз-5» в течение примерно пяти лет были апробированы на проектах для разных клиентов в государственном, корпоративном и финансовом секторах в России и СНГ. Было реализовано много интересных проектных кейсов. Но раз уже чуть выше затронули тематику зарубежных активностей, предлагаю перейти на следующую страницу эволюционной истории развития платформы.  Она очень тесно связана с международной деятельностью.

Международное признание: свои требования, вызовы, задачи

По традиции, шестую мажорную версию платформы опять пропустили. Сразу вышла версия 7. Случилось это в 2012 году. И сразу платформа попала в магический квадрант Gartner в классе Business Intelligence. В квадранте она уверенно продержалась 4 года подряд и до сих пор остается единственной российской BI-платформой, побывавшей в этом квадранте наравне с мировыми гигантами: Oracle, SAP, IBM, Tableau, Qlik, MicroStrategy и др.

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

Для себя я определяю этот период развития платформы с 2010 по 2015 гг. Фактически он начался чуть раньше, когда в 2008-2009 гг. началась реализация зарубежных проектов. Первое, что для этого потребовалось – это обеспечить поддержку мультиязычности во всех инструментах платформы. И это касалось как данных, так и метаданных. Т.е. при изменении в приложении языка (например, с русского на английский), предполагалось, что поменяется как язык интерфейса (причем и встроенных объектов самой платформы, и реализованных интеграторами прикладных метаобъектов/экранных форм), так и язык данных (в первую очередь текстовые атрибуты у справочников). Но это еще не все. Очень быстро мы поняли, что недостаточно просто реализовать поддержку двух и более «зашитых» языков. Первые международные проектные решения были с очень схожей функциональностью, но имели очень разную географию: английский, французский, немецкий, испанский и др. Казалось, нет этому конца и края. А тут еще и проекты в СНГ стали требовать к себе национального лингвистического внимания.

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

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

Другим значимым направлением, на котором мы сфокусировались в период общения с экспертами Gartner, стало развитие конструктора аналитических панелей (или dashboards). Это направление развивалось в платформе и ранее, но существенное развитие оно получило именно в тот период. Разметка экрана, расположение разных визуализаторов для разных источников данных, управление внешним видом каждого блока. Уже тогда, 10 лет назад, появились первые прообразы настройки ассоциативных связей между визуальными блоками.

В тот же период существенно расширился и набор инфографики: от простых линейчатых диаграмм до сложных многомерных пузырьковых 3D-сцен. При этом мы научились публиковать эти визуализаторы на IPad, с поддержкой интерактивности и 3D-картами. Далее этот инструмент все время совершенствовался и развивался как с точки зрения функционально-графических возможностей (закладки, слайды и др.), так с точки зрения скорости их работы (например, возможность одновременного формирования сразу всех визуализаторов дэшборда в параллельном режиме).

Дополнительно стоит отметить, что, начиная с 7 версии платформы конструктор аналитических панелей был реализован как для desktop, так и для веб-версий. Причем с полностью одинаковой функциональностью. В более ранних версиях в веб-интерфейсе мы могли поддерживать только режим работы бизнес-интерфейса, не позволяющий настройку и переконфигурирование метаобъектов (только просмотр и ввод данных).

Наверное, именно с этой даты история GUI платформы разделилась на «до» и «после». На тот период уровень развития веб-технологий не позволял нам воспроизвести весь объем конструкторов наших инструментов полностью в веб-реализации. Но мы начали к этому стремиться.

Правда, быстро пришло понимание, что уже реализованное для desktop количество мастеров и экранных форм настолько велико, что создание веб-интерфейсов потребует значительного времени. Да и уровень гибкости и эргономики веб-технологий в тот период сильно уступал настольным приложениям и явно был менее производителен.  Но мы не отчаивались и планомерно продолжали двигаться в этом направлении.

Первым шагом было создание специализированных DHTML-компонентов платформы и формирование набора веб-сервисов для базовых команд API. Это позволило реализовывать на Java Script разнообразные экранные формы для веб-клиента и «верстать» сложные кастомизированные веб-страницы.

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

Data Discovery and Big Data: все в одном

Казалось бы, к 2013 году в платформе было уже очень многое: реляционный слой, настройка кубов, отчетность, программирование сложных задач, интеллектуальное моделирование и др. Но все равно чего-то не хватало. На практике все эти инструменты были как будто разрозненны. Отчет в одном месте, расчеты в другом, загрузка данных – в третьем. Хотелось все это объединить в единое неразрывное целое, чтобы все и сразу и в одном месте. И данные загрузил, и куб сформировал и формулу здесь же написал, и другие операции выполнил. Но пока это все было в разных инструментах, хоть и использовались одни данные.

С точки зрения исследования данных это было, конечно, очень функционально, но неудобно. Так мы начали свой длинный путь по внедрению инструментов Data Discovery. Частично эта задача уже была решена, и платформа умела объединять данные разных кубов в виде общего виртуального куба. Но такие виртуальные представления данных нужно было заранее подготовить специалисту-настройщику. Поэтому конечный бизнес-потребитель мог их использовать только для получения выборки данных, в рамках заданной виртуализированной области данных.

Для устранения этого недостатка в платформе появился Multi OLAP.  Он позволил объединять в рамках одного ad-hoc запроса несколько разнородных, с точки зрения структуры, кубов на одном визуальном представлении. При этом справочники, которых не было во всех объединяемых кубах, формировали общее составное измерение (Compound Dimension). В нем требовалось зафиксировать все элементы «не общих» измерений.

Правило объединения элементов и порядок их следования можно было гибко настроить. Это позволило в рамках единого каталога показателей формировать визуальные представления с различными аналитиками у каждого показателя. Например, в справочнике социально-экономических показателей можно было определить группу элементов с разрезом ОКВЭД, другую группу - с разрезом ТН ВЭД и т.п. Дополнительно такие кубы позволяли для каждого показателя задавать расчетную меру (стоимости, площади, длины, веса и т.п.) и далее в рамках одной меры переводить показатель в разные единицы измерения (руб., тыс. руб., млн. руб., …; метры, км, мили и т.д.). Также для простоты использования ad-hoc запросов мы научились применять в OLAP внутренние альтернативные иерархии. Это позволило в рамках визуального представления куба для каждого его измерения изменять последовательность и иерархию элементов. Т.е. на уровне отдельного отчета стало возможно настраивать собственные локальные представления этого измерения, в том числе добавлять новые группировочные или фиктивные элементы.  

Второй важный момент – это вычисления и аналитические расчеты.  Хотелось сразу в сформированных электронных таблицах с данными добавлять новые расчетные показатели. Причем не ограничиваться только данными текущей электронной таблицы, а использовать данные из других источников – выходящих за рамки Multi OLAP. Так в платформе появился Универсальный Редактор Формул (УРФ). Это был конструктор формул, но в отличие от Excel он оперировал не ячейками электронной таблицы (A1+B6+C10+…), а сразу давал возможность пользователю настроить уравнение расчета в бизнес-терминах многомерной модели куба (т.е. выбрать показатель и значения всех его аналитик). Причем в формуле можно было использовать любой куб, зарегистрированный в репозитории платформы, с учетом всех прав и привилегий текущего пользователя. Далее электронная таблица при обновлении данных сама определяла, какие дополнительные источники нужны для расчета. И кроме исходных данных пользователь мог сразу получить значения дополнительных вычисленных элементов.   

Все эти возможности в 2014 году мы объединили в платформе в рамках одного объекта – аналитической области данных (EaxDataArea). Этот объект стал универсальным движком формирования всех визуальных представлений во всех инструментах отчетности платформы: дэшборды, аналитические запросы (OLAP), регламентные отчеты. Таким образом, настраивать сложные выборки данных стало возможно во всех инструментах по одному общему принципу, плюс сразу обогащать эти методики расчетными показателями любой сложности вычисления.  

Другим направлением в области исследования данных стало развитие инструментов поиска. Это было очень актуально, когда на платформе создавались большие корпоративные ХД и вручную уже невозможно было найти ту или иную информацию. Для этого в платформе был создан внутренний движок полнотекстового смарт-поиска данных по ключевым словам (BI Search). Он основывался на технологиях поисковой платформы Apache Solr и позволял находить релевантные заданному поисковому запросу соответствия. Пользователю необходимо было только ввести фрагмент текста для поиска, например, «валовый внутренний продукт», и платформа автоматически выводила всю информацию, где в элементах измерений присутствует такой показатель. Кроме структуры данных, можно было выполнять поиск и среди текстовых документов, прикрепленных к платформе или в наборе дополнительных атрибутов у метаобъектов репозитория. Поиск осуществлялся на основе заранее проиндексированных метаданных, и скорость реакции на запрос пользователя была практически мгновенной. При индексации определялась степень релевантности поиска. Это позволяло при поиске учитывать разные склонения, спряжения и другие изменения свойств для найденных словоформ, а также взаимозаменяемость слов синонимов.

Кроме инструментов исследования данных в 2013-2015 годах мы развивали и коннекторы к разным промышленным СУБД. По-крупному тут, наверное, стоит выделить два больших направления: скорость обработки данных и их объемы. Первой на очереди стала модная в те годы СУБД Teradata. Это был наш первый опыт использования массово-параллельной СУБД, и он тогда произвел на нас сильное впечатление. В сравнении с классическими Oracle или MS SQL Server, которые мы тогда в основном использовали, скорость обработки больших объемов была намного выше.

Первый опыт практического использования был в федеральных органах – в ФНС и Казначействе. Там обрабатывались данные по финансовым потокам отдельных контрагентов. Используя эту СУБД, наш BI смог обрабатывать данные каждого физического лица, формировать для них произвольные выборки. При этом важно понимать, что с точки зрения BI, это были не предподготовленные заранее SQL-скрипты (адаптированы СУБД-разработчиком индивидуально для каждого запроса), а ROLAP-движок (который должен автоматический формировать универсальный SQL-запрос на основе заданной пользователем в кубе бизнес-логики и фильтров отметки).

С точки зрения быстрого извлечения данных, сформировать такие универсальные SQL-запросы намного сложнее. При повышении сложности условия выборки, они все время начинали «тормозить». Поэтому мы обратили внимание на In-Memory СУБД. Сначала реализовали в платформе поддержку Vertica. Затем ClickHouse и Greenplum. Параллельно в этот же период реализовали коннектор к Apache Hive, что позволило на языке HiveQL выполнять запросы к данным из Hadoop. Также в контексте импортозамещения в 2019-2020 годах мы стали поддерживать работу платформы с российскими проприетарными СУБД: PostgrePRO, Arenadata, защищенной Jatoba. Сейчас смотрим в сторону Tarantool.

Тем не менее подключение высокопроизводительных СУБД не давало нужного эффекта по скорости работы нашего движка ROLAP. Логика была простая – чем больше данных и чем сложнее условие SQL-запроса к БД (а на это в первую очередь влияло, сколько элементов в каждом измерении куба выбрал пользователь), тем длительнее была скорость реакции системы на запросы пользователей. И большая часть времени уходила на выборку данных из БД. То есть со стороны BI мы не могли повлиять на это. Для компактных и плотных данных (форма-центричная модель ХД) ситуация была не так критична, а вот для сильно разряженных данных (дата-центричная модель) все было не очень хорошо…  Для этих целей еще в 2013 году мы начали создавать в платформе MOLAP-технологию. Мы попробовали реализовать свои собственные наработки. Получилось неплохо.

Сейчас в платформе есть два альтернативных подхода работы с MOLAP-кубами: глобальный инстанс куба и файловый кэш. Оба этих подхода хранят данные куба в специализированном адаптированном формате (кэш) и обрабатывают всю информацию в ОЗУ (In-Memory). При этом у них по-разному организованы способ формирования спец. структуры данных и механизм «прогрева кэша» (загрузки данных из HDD в RAM).

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

А как же смежные системы?

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

Все реляционные объекты регистрировались на уровне репозитория платформы. На их основе можно было формировать логические источники данных (кубы). Устанавливать для таблиц права доступа, которые на уровне СУБД трансформировались платформой в набор grants и synonyms. Обращение к данным из этих таблиц выполнялось платформой в online режиме через ODBC драйвер (или нативные драйвера для C++). При этом какие-либо трансформации данных при их извлечении в такой реализации были доступы только на уровне SQL-преобразований в тексте самого запроса.

Для реализации более сложных цепочек трансформации входных данных уже в пятой версии платформы появился инструмент ETL. В 2005-2007 годах в этом инструменте мы активно наращивали набор поддерживаемых источников и приемников данных, а также блоков трансформации. В первую очередь, научили его работать с плоскими источниками – файлами (txt, csv, dbf, xls, html) и реляционными объектами. Затем появились блоки трансформации данных: объединение, пересечение, исключение, фильтр и др. Принцип работы заключался в том, чтобы пользователь на рабочую область «накидывал» блоки обработки данных и «склеивал» их в единую цепочку преобразования (соединяя выходные поля предшествующего блока с входными полями последующего). Все связи и соединения визуализировались в виде стрелок. Таким образом, при работе с ETL пользователь сразу видел графическую схему информационного потока данных.

Тогда эта первая версия ETL умела работает только с плоскими данными. Этого, конечно же, не хватало. В первую очередь мы столкнулись с этим в рамках работы над проектом МВФ, где нужно было обрабатывать макроэкономическую статистику стран мира из форматов SDMX (основанных на иерархической XML-разметке). Плюс актуальна была задача загрузки данных не в реляционные структуры, а сразу в куб. Так в рамках ETL была реализована возможность работы с многомерными (не плоскими) структурами данных. Это была своего рода вторая версия инструмента ETL, работу над которой мы активно вели в период с 2009 по 2012 гг. Параллельно мы работали и в направлении повышения производительности. Для больших объемов данных стала доступна пакетная загрузка, когда данные извлекаются и загружаются порциями (если, конечно, такое частично-кусочное извлечение возможно, и в цепочке трансформации не применяется какое-нибудь правило «склеивания» двух массивов данных, требующее их полной предварительной загрузки в ОЗУ).

При этом сложная цепочка трансформации данных в прикладных задачах требовалась не всегда. Часто перегрузка данных сводилась к простой схеме: один источник, один приемник и мэппинг их полей. Для таких задач в платформе появились альтернативные инструменты - объект импорта данных и загрузчик кубов. Они умели выполнять простые перегрузки данных в куб из внешнего источника или реплицировать данные между кубами.

Но активность прикладных задач требовала все больше и больше наборов источников/приемников данных и типов связывающих их правил трансформации, а также появлялись все новые и новые требования к внешнему интерфейсу. В какой-то момент мы поняли, что, как бы мы ни старались, мы не сможем успевать за всеми «хотелками» наших потребителей. Нужно было сделать наш ETL открытым для самостоятельного расширения. Мы добавили пользовательские шаблоны, в которых специалист-настройщик сам смог программировать логику обработки данных, а также в среде разработки создать мастер для ее визуальной настройки. При этом все шаблоны регистрировались в задаче ETL и с точки зрения конечных бизнес-пользователей ничем не отличались от работы с обычными встроенными в платформу блоками обработки данных. Например, таким способом подключались вызовы SAP RFC, настраивались образы финансовых XBRL-файлов и многое другое.

Четвертым шагом развития ETL в 2018-2019 годах стала поддержка работы с REST-источниками, обеспечивающая взаимодействие с веб-сервисами в режиме get- или post-запросов. Дополнительно в этот же период была реализована поддержка JSON-форматов.  То есть стала доступна работа с разными веб-сервисами. Причем не просто подключение, а интеграция этой задачи в единую цепочку ETL как один из ее составных шагов.

Фреймворк для разработки собственных приложений

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

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

Встроенный язык программирования, мы назвали его Fore, позволяет реализовывать свои собственные интерфейсы и гибкую бизнес-логику. Для каждого проекта команды внедрения стали реализовывать собственные мастера для конфигурирования или работы пользователей с ИТ-решением. Причем ровно в таком виде, как просили их заказчики. Это стало очень user friendly. Командам внедрения понравилось, что можно на 100% выполнять пожелания заказчиков. Все стали этим активно пользоваться.

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

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

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

При этом такие новые типы объектов можно было переносить между разными репозиториями платформы. Компании-партнеры смогли обмениваться такими новыми объектами и переиспользовать их в своих проектах.

Сложный период, взлеты и падения

К сожалению, не все 20 лет моей истории работы с платформой были только веселыми и радужными. Были и печальные периоды. Один из самых тяжелых для меня моментов – это смена собственника и банкротство компании «Прогноз» в 2015-2016 гг. Тогда было всё: и задержки зарплаты, и снижение общего количества консультантов по данному решению, и многое другое. Платформа пережила сложный период. Но мы смогли выстоять, сохранить «костяк» коллектива и продолжить развивать наше решение, работать с новыми заказчиками. Черная полоса позволила нам по-другому взглянуть на архитектуру нашей платформы и выработать в ней принципиально новые инструменты.

Любая черная полоса всегда когда-нибудь заканчивается. С 2016 года развитие бренда «Прогноз» уже происходило в компании «Форсайт», которая стала эксклюзивным дистрибьютором платформы, с правом ее модификации и выпуском новых версий. В 2017 году «Форсайтом» была выпущена версия Prognoz Platform 8.2. А в 2018 году произведен ребрендинг, и появился товарный знак «Форсайт», который сопровождался выпуском 9 версии платформы. Версии с официальным названием «Форсайт. Аналитическая платформа». С этого периода компания «Форсайт» уже полностью самостоятельно развивала продукт. В 2019-2020 годах были организованы регулярные квартальные выпуски минорных релизов 9 версии «Форсайт. Аналитической платформы».  

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

«Форсайт» сегодня – это больше, чем просто BI

Одним из новых направлений, которое мы реализовали в 9 версии «Форсайт. Аналитической платформы», была возможность транзакционной работы с данными. Нет, речь не пойдет о системах с финансовыми транзакциями или о других подобных OLTP-системах. Это не наш профиль, мы все-таки BI-решение. Но четко было сформировано сознание того, что только BI-аналитикой не обойтись на современном рынке. Нам точно не хватало инструментов для организации поэтапного распределено или последовательного процесса обработки данных. Причем как в ручном, так и в автоматическом режимах, или их комбинации. При этом использование внешнего BPM-движка опять лишало нас ключевого преимущества нашей платформы – «бесшовной» интеграции всех ее инструментов.

Свой встроенный BPM

В 2018 году мы начали создавать собственный конструктор BPM-процессов. Долго спорили про нотацию. Конечно, хотелось полной поддержки спецификации BPMN 2.0. Но мы были только в начале пути, и в короткий срок догнать российских и зарубежных конкурентов нам было не под силу. А инструмент для формирования workflow хотелось иметь прямо сейчас. В итоге постарались взять основное из каждой категорий элементов BPMN 2.0: поток (Flow Objects), данные (Data), соединение (Connecting Objects), зоны ответственности (Swimlanes), артефакты (Artifacts). При этом акцент в первую очередь сделали не на графическую визуализацию или полноту процессных элементов, а на совместимость элементов нотации с существующими инструментами платформы.

Так, например, зоны ответственности сразу стали синхронизированы с ролевой моделью нашей платформы. Артефактами выступили этапы бизнес-процесса, группирующие его шаги. Данными являлись кубы или справочники. В потоках поддерживаются разные типы шлюзов и отправка сообщения через e-mail. И так далее. Также в BPM был реализован ряд интересных «фишек». Например, в элемент «сообщение» можно добавить гиперссылку для открытия соответствующего объекта платформы. Тогда при наступлении, например, шага «ввод данных», пользователь получает электронное информационное письмо, и в нем сразу есть гиперссылка для открытия соответствующего отчета в системы в веб-браузере. Очень удобно и функционально.

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

Создание конструктора BPM затронула и функциональность ролевой модели. В первую очередь это повлияло на права доступа к данными. Раньше область доступа определялась на уровне объекта целиком или отдельных элементов справочника (для классического BI этого было достаточно). Для процессных задач требовалось ограничение на уровне или атрибутивных правил (отчет согласован, утвержден и т.п.) или на уровне сегмента данных (например, ввести в отчет данные только по доходам за 2021 год). Для этого в ролевой модели платформы кроме дискреционных и мандатных прав доступа мы реализовали поддержку ABAC-правил.

А для управления доступом к сегментам данных появился объект полномочий. Он позволяет «разрезать» куб на отдельные многомерные сегменты и определить для каждого сегмента права на чтение и запись. Такие полномочия могут быть статичные (действовать всегда) или ассоциированы с шагом бизнес-процесса (т.е. автоматически включаться и выключаться по мере изменения состояния бизнес-процесса). В отчетности каждый сегмент и статус его состояния может визуализироваться. Тем самым, открывая любой отчет, пользователь всегда легко сможет понять, какие действия с отчетом ему нужно произвести (ввести или согласовать фрагменты данных, провести расчет и т.п.)

Конструктор алгоритмов – практичный инструмент для методологов

Развитие 9 версии «Форсайт. Аналитической платформы» продолжалось – в фокусе нашего внимания оказался инструмент моделирования. Интегрированный в отчетность универсальный редактор формул расчетных показателей хорошо подходил для Data Discovery, но был неэффективен, когда одна методология расчета переиспользуется в большом количестве разных отчетов. И еще хуже, когда количество отчетов постоянно растет, а часть показателей в них нужно рассчитывать по методике.

Для решения этой задачи мы выделили создание методик расчета в отдельный инструмент платформы – конструктор моделей и алгоритмов. Фактически после контейнера моделирования (из 5 версии платформы) это была уже третья эволюционная версия мастера настройки расчетов. Она обладала рядом новых особенностей и фишек.

Первое нововведение - мы интегрировали его с EaxDataArea. Теперь в аналитической области достаточно было просто указать, какие расчетные методики (настроенные этим конструктором моделей) нужно использовать, и далее платформа уже сама определяет, какие показатели в таблице с данными нужно получать запросами из БД, а какие рассчитывать. Тем самым мы смогли разделить настройку методологии и визуализации, но при этом технологически сохранить их полную совместимость.

Второе новшество -  конструктор моделей и алгоритмов кроме расчетных значений стал управлять и визуальным стилем этих данных (правила контроля). Это позволило в методике настраивать различные правила оформления данных с использованием логико-арифметических формул, например, задавать цвет заливки ячейки и др.

Также был доработан сам расчетный движок конструктора. Он стал позволять проводить частичный пересчет методики, в зависимости от измененных данных. Например, если для сложной методики, состоящей из 10 тыс. взаимосвязанных уравнений, вы изменили только 2 цифры, то платформа сама определит, в какие уравнения входят эти две точки данных, какие еще другие уравнения зависят от расчетов этих уравнений и т.д. Таким образом будет рассчитан только тот объем формул, на который влияют эти две измененные точки данных. Это позволило нам прямо в отчетах реализовать пересчет указанных в EaxDataArea в режиме online сразу после ввода данных. И все это выполняется достаточно быстро, за счет частичного пересчета. Фактически как в Excel. С той лишь разницей, что вся методология не хаотично раскидана по формулам в ячейках листов, а компактно сгруппирована в специализированном конструкторе. Для каждой методики можно задать свой набор параметров (отчетный период, список компаний, сценариев, версий и т.п.). Далее каждый расчет выполняется для конкретных значений этих параметров.

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

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

С точки зрения расчетных движков мы уже понимали, что своими силами нам не угнаться за мировой динамикой. Эйфория, присутствовавшая при создании контейнера моделирования («все методы сделаем сами»), прошла. Новый конструктор методик и алгоритмов стал открытым к внешним расчетным ПО. В первую очередь, мы провели интеграцию с распространенными пакетами R и Python. Кроме этого, появились и специфичные пакеты для решения узких специализированных задач. Например, для задач оптимизации мы интегрировали платформу с библиотеками бесплатного расчетного движка LpSolve, а также реализовали поддержку коммерческого солвера Gurobi. Т.е. при настройке формул расчета пользователь уже мог выбрать, каким способом ему выполнять расчеты и какой расчетный интерпретатор для этого использовать. При этом мы не просто реализовали вызов методов, но и обеспечили передачу параметров. Совместили типы данных нашей платформы и интегрируемых расчетных пакетов. Таким образом, данные нашей платформы из кубовой модели могут быть преобразованы в многомерные массивы на «питоне» и далее переданы как параметр в python-функцию. Тем самым интеграция с внешними расчетчиками происходит бесшовно и не требует выполнения дополнительных интеграционных работ при настройке методик.

Но внешние расчетчики использовались в первую очередь для вызова сложных научных методов. Все простые логико-арифметические формулы рассчитываются внутри платформы. Для их ускорения в 9 версии в 2018 году был реализован дополнительный облегченный расчетный движок, который поддерживал меньшее количество встроенных функций. Фактически поддерживал только основные математические операции и функции округления, суммы, модуля – т.е. только то, что нужно для бухгалтерских операций. И не поддерживал методы эконометрики, факторного анализа и т.п. Облегчение набора функций позволило сильно ускорить производительность. Примерно на порядок. При этом платформа самостоятельно определяет, каким движком выполнять расчет того или иного уравнения – «легким» или «тяжелым». Вроде бы простое и очевидное решение, но пришло оно нам не сразу. Вот как бывает, когда десятилетиями наращиваешь и наращиваешь функции инструмента. В какой-то момент понимаешь, что уже переборщили, и для распространенных простых кейсов можно применить и что-то попроще…  

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

Также для выполнения расчетов в кластере BI-серверов можно указать отдельно выделенный для расчетов сервер. Тогда не важно, в рамках «липкой сессии» на какой из BI-серверов попал пользователь при распределении нагрузки балансировщиком – любой запуск расчета перенаправит эту операцию на специально выделенный под расчеты сервер. Это позволяет эффективно организовывать кластер серверов для систем с «тяжелыми» расчетами. Для основной работы back-end платформы используются одни аппаратные мощности, а для самих расчетов – другие. С разными характеристиками и количеством серверов.

Формы ввода – технический интегратор всех инструментов платформы

Далее для работы с новыми алгоритмическими и процессными инструментами в 9 версии платформы «Форсайт» мы реализовали еще один новый инструмент - «Формы ввода». Фактически это собирательный образ всех транзакционных инструментов в конечном интерфейсе бизнес-пользователя. Каждая форма ввода представляет собой не просто отчет с выводом информации, а может объединить в себе и срезы данных, и права доступа к ним, и учитывать шаги ассоциированных с ней процессов, и применять расчетные правила из конструктора и многое другое.

Причем большинство операций в формах ввода платформа определяет автоматически или автоматизировано. Достаточно один раз настроить систему заказчика, и далее все самостоятельно работает, «как часы». Например, все активные шаги бизнес-процесса автоматически отображаются при открытии формы ввода. Дополнительно по каждому шагу процесса можно посмотреть его назначение (ввод или согласование данных и другие операции), а также визуально подцветить в форме ввода связанный с этим шагом фрагмент данных (когда согласуется не вся форма целиком, а только часть ее данных, такое тоже возможно).

Также в формах ввода можно указывать настроенные методики и алгоритмы, и как уже говорили ранее, платформа сама автоматически будет применять из них нужные фрагменты расчетов для срезов данных. При этом можно указывать разные события применения этих вычислений: сразу при вводе новых значений в ячейки таблицы (ввел значение, и соседние расчетные ячейки сразу пересчитались), только после сохранения новых данных в БД (в БД сохраняются и вручную введенные данные и дополнительные расчетные) и т.п. Это позволило гибко управлять логикой применения этих методик в системах у заказчиков.

Существенно изменилась и скорость работы самих форм ввода. Для веб-интерфейсов была реализована динамическая подгрузка только видимых строк на front-end. Таким образом, в формах ввода стало возможным размещать таблицы с большим объемом данных (до сотен тысяч строк и нескольких сотен колонок). Именно такие масштабные табличные и реестровые формы требовались нашим заказчикам, и мы смогли это сделать.

Также в формах ввода появилась новая интересная возможность (которой не было в предшествующих версиях платформы) – карточка объекта из реестра. Она позволяла размещать и группировать на листе поля с атрибутами этого реестра.

В плане визуального интерфейса мы продолжили приближаться к продуктам MS Office. Эксель-подобный интерфейс в регламентных отчетах применялся еще в ранних версиях платформы.  Электронные таблицы, оформление ячеек, формулы, размещение графиков и многое другое – все это было на 99% похоже на MS Excel. Пользователю наших систем не требовалось привыкать к новым интерфейсам. Они сразу начинали работать в привычной для себя среде.

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

Конструктор бизнес-приложений

Одна из часто возникающих проблем при внедрении систем на базе платформы «Форсайт» связана с тем, чтобы собрать все реализованные и настроенные интегратором модули в единое целое. В первую очередь, это нужно для компоновки всех платформенных метаобъектов в единый файл обновления (для последующего полного или частичного переноса с ландшафта на ландшафт).

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

Разработку такого инструмента мы начали в 9 версии платформы. Фактически так появился комплексный контейнер в репозитории, куда настройщики размещают все метаобъекты своей системы. Инструмент назвали «Контейнер бизнес-приложения». Логика проста. Всю систему размещаем в одном контейнере этого бизнес-приложения. В рамках одного репозитория может существовать неограниченное количество контейнеров с разными бизнес-приложениями. Уникальная идентификация метаобъектов организовывается уже не на уровне всего репозитория, а только в рамках этого контейнера.

Каждый контейнер оснащен набором сервисных функций. Нумерация версии, сбор файла обновления (с возможностью генерации шаблонов, определяющих состав таких обновлений), возможность сформировать контрольную сумму для каждого метаобъекта, частичный перенос элементов справочников (чтобы разделить типовую встроенную часть структур НСИ и дозаполненные заказчиком структуры). Также для каждого бизнес-приложения платформа автоматически генерирует типовой веб-портал для отображения объектов системы. Такой свой мини-навигатор системы, для которого можно задать визуальное оформление, в том числе применить корпоративный стиль заказчика.

Кроме «упаковки» бизнес-приложений конструктор позволяет создавать и контейнеры библиотек. Каждая библиотека включает в себя программные функции и, при необходимости, реализацию визуального интерфейса (тогда это уже называется не библиотека, а компонент). Между бизнес-приложениями и такими библиотеками/компонентами можно определять связи. Например, указать что для функционирования этого бизнес-приложения требуется такой-то набор библиотек и компонентов. При сборке обновления эти связи учитываются и формируется целостный файл обновления всех необходимых контейнеров.

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

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

Поддержка разных языков программирования

Еще одним выбранным вектором развития 9 версии платформы «Форсайт» стала адаптация ее среды разработки к широкому кругу языков программирования. Уже давно мы понимали, что встроенный в платформу верхнеуровневый скриптовый язык программирования – это очень классно. Но уникальная спецификация собственного языка программирования платформы Fore вызывала неоднозначную реакцию. С одной стороны, по синтаксису и структуре язык Fore был очень похож на C#. При этом Fore обладал важным преимуществом – кроссплатформенное выполнение, т.к. конечный базовый язык его реализации и интерпретации был C++.

Часть нашего community прониклась и сильно полюбила наш язык программирования. Но нужно быть откровенным, были и те, кто открыто его критиковал. Мне сложно понять почему, но факт остается фактом. Как говорится, насильно мил не будешь. Но community – это всё для вендора, наравне с конечными заказчиками. Таковы наши вендорские принципы. И мы стали развивать это направление, чтобы комфортно было всем.

Поддержка работы с .Net у нас уж была и в более ранних версиях платформы. Следующей на очереди стала поддержка Python, затем Java – их мы уже тоже поддерживаем. Сейчас обсуждаем и начинаем реализовывать поддержку Core .Net для Linux.

При этом поддержка любого языка программирования в платформе разделяется на две составляющих. Первое – весь открытый API платформы адаптируется для исполнения в синтаксисе поддерживаемых языков программирования через Interop сборки, которые нужны для работы с объектами «Форсайт. Аналитической платформы». С их помощью, например, на языке Python можно без проблем запрограммировать сохранение в кубы платформы информации, полученной на основе расчета нейронной сети. Или на языке Java применить специализированное оформление к форме ввода. И другие аналогичные примеры.

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

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

Преднастроенные конфигурации платформы

Реализация в 9 версии платформы новых инструментов для систем обработки данных и соответствие высоким современным enterprise-требованиям предопределили для нас выделение части команды для настройки прикладных и отраслевых конфигураций. Это стало возможным, так как реализованные конструкторы для формирования BPM, ETL, алгоритмов и т.п. подразумевали только настройки необходимого контента, а не создания новых версий платформы. С точки зрения ресурсов это стало гораздо менее затратно. А линейка ПО «Форсайт» c 2018 года стала существенно расширяться и содержала уже не только платформенные, но и узкоспециализированные решения.

Каждая конфигурация была реализована на платформе и состояла из уже преднастроенного базового контента для той или иной типовой задачи (ХД, отчет, методики, специализированные мастера и др.).

В настоящее время в линейке «Форсайт» реализовано 4 конфигурации платформы: «Бюджетирование», «Управление инвестиционными программами и проектами», «Сводная и управленческая отчетность», «Кредитный конвейер». Но мы не планируем на этом останавливаться и все время стремимся расширять этот список. Плюс, открытость платформы как фреймворка позволяет организовать создание таких контентных решений нашим партнерским сообществом. В настоящее время среди нашей партнерской экосистемы ряд компаний-интеграторов уже не просто выполняют внедрение проектов на «Форсайт. Аналитической платформе», но и ведут реализацию таких типовых предметных конфигураций.

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

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

Импортозамещение и Linux-ориентированное окружение

Импортозамещение в России четко сформировало направление для развития ИТ-отрасли. «Директива Силуанова» (см. http://government.ru/all/35256/) подтолкнула многие крупные ИТ-компании выбирать новое ПО и новых подрядчиков.  Уже в 2019 году мы это почувствовали через повышение спроса и увеличение пресейловых активностей. Вырос интерес к Linux-ориентированному ПО.

Еще с 5-й версии платформы основным низкоуровневым языком разработки back-end был и остался C++. За счет этого наши BI-серверы успешно работали и для Windows, и для разных версий Linux: ALT, Debian, Astra, Ubuntu, Red Hat. Также серверная часть платформы неплохо работала под Docker, это было заложено в ее архитектуре.

С клиентскими рабочими местами дело обстоит тоже неплохо. Созданный в 9-й версии Конструктор бизнес-приложений позволял автоматически из платформы формировать веб-порталы для полноценной работы бизнес-пользователей. Поддерживалось большое количество браузеров, в том числе функционирующих под OC Linux (Mozilla Firefox, Google Chrome, Opera, российские «Спутник» и «Яндекс»). Ну и также стандартные IE, Edge и Safari для Windows. Работа с данными, запуск расчетов, загрузки, бизнес-процессов, специализированные АРМы через формы ввода – все это было доступно на полностью Windows-независимом окружении в виде веб-решений. Также в виде веб-решения был доступен менеджер безопасности, позволяющий в том числе и под Linux-окружением администрировать системы и формировать файлы обновлений репозиториев между ландшафтами.

Единственным узким местом пока являются разработка и настройка метаданных (мастера кубов, справочников, конструкторы отчетов и т.п.), а также среда разработки Fore. Вот это, к сожалению, создавалось на протяжении многих лет и исторически имело только desktop-реализацию. Linux тогда не был столь популярен и развит. Но это ограничение распространяется только на разработочный ландшафт DEV. Ведь только там ведется разработка системы, а на TEST и PROD осуществляется только ее использование и не ведутся программные доработки (максимум только установка обновлений). В такой конфигурации ОС Windows необходима только на нескольких машинах разработчиков в DEV-контуре, который обычно не имеет прямого доступа к реальным данным. Это исключает возможность какой-либо утечки конфиденциальных данных.

Мы сейчас ведем работы над 10 версией платформы. Она будет целиком веб-ориентированной облачной платформой, и мы сможем полностью уйти от настольных интерфейсов для разработчика. Также мы сейчас серьезно развиваем работу нашей платформы под ОС Astra Linux CE и SE, в том числе поддержку меток безопасности для версии «Смоленск». Обзор всего многообразия новых функций 10 версии – это тема для отдельной статьи. Мы обязательно вам все это расскажем в ближайшем будущем.

---

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