Как раз для этого нужна виртуализация данных, упомянутая в статье. Корпоративный граф знаний в нашем понимании - это не просто слепок информации из корпоративных приложений. Это виртуальная конструкция, которая формируется по частям "на лету" во время выполнения запросов.
Чтобы это воплотить в реальности, мы делаем следующее:
создаем онтологическую модель предметной области, в которой описаны классы и атрибуты: сотрудник, объект, согласование доступа и др.
создаем адаптеры для доступа к данным корпоративных систем с помощью веб-сервисов на их стороне, или прямого доступа к их СУБД на чтение
создаем в онтологии правила сопоставления элементов модели предметной области элементам структуры данных корпоративных систем: список актуальных сотрудников находится в таком-то справочнике системы кадрового учета, сведения о маршрутах согласования - в таком-то виде в СЭД, и так далее
платформа виртуализации данных умеет принимать SPARQL-запросы в терминах модели предметной области (их она получает в результате преобразования вопросов пользователей), с помощью правил мэппинга извлекать на лету данные из систем-источников, строить временный граф, необходимый для ответа на запрос, и формировать ответ.
Благодаря такому подходу информация в корпоративном графе знаний всегда актуальна.
Возможность внести такое изменение только средствами моделирования зависит от того, подумали ли об этом при проектировании системы. Напомню, я не говорил в статье о том, что код полностью заменяется на модель - заменяется в некоторой части.
Если при проектировании подумали о том, что могут существовать перевозчики с закрытым алгоритмом расчета, то в модели должна быть описана сущность "внешний веб-сервис". Здесь уже стандартными спецификациями не обойтись. Для каждого сервиса формально описываются параметры и возвращаемое значение - что-то вроде SHACL Function, только для самого расчета вместо SPARQL-запроса нужно будет делать вызов внешнего сервиса.
К каждому перевозчику в модели привязываем метод расчета стоимости - это может быть SHACL Rule / Function или конкретный "внешний веб-сервис". Алгоритм выбора перевозчика для конкретного заказа, вполне вероятно, останется в коде и будет заключаться в асинхронном запуске расчета стоимости для всех перевозчиков согласно определенным в модели алгоритмам.
Если при проектировании о таком варианте не подумали, значит предстоит рефакторинг кода и модели.
Да, это похожий пример. И пример со SPARQL был бы валиден, у нас для таких есть конструктор.
Приведенная запись - один из вариантов сериализации онтологии. Есть и другие варианты, например в RDF/XML или OWL/XML. Все они при импорте в графовую СУБД дают один и тот же набор триплетов, и при просмотре через редактор выглядят одинаковым образом.
Вы можете зарегистрироваться на https://webprotege.stanford.edu или скачать десктопную версию Protege, загрузить туда этот фрагмент и посмотреть, как он будет выглядеть в редакторе. Увидите иерархию классов, среди которых будут классы NodeShape, RectangleShape, TripleRule и т.д., и индивидуальные объекты этих классов, представляющие конкретное правило.
Редактируется с помощью визуального конструктора формул и правил, если он есть в составе платформы, на которой ведется разработка (таких платформ существует несколько), или путем ручного создания элементов онтологии. Можно хоть в Protege создать, при желании - это базовый open source редактор онтологий.
Тут, видимо, можно долго спорить о терминологии "программисты"/"аналитики". Также понятно, что хочется обсуждаемое явление свести к тому, что уже известно. Хотя лично я не могу называть программистами людей, которые работают только с редактором онтологии и не написали за свою жизнь ни строчки программного кода.
Я понимаю, что одной статьей сложно убедить всех в том, что то, что толком не получилось у Low code платформ, можно сделать другим способом, не создавая очередного внутриплатформенного языка программирования (онтологическая модель - это не код даже в том смысле, в котором им является язык 1С).
Все, на что я надеюсь - что кто-то из читателей заинтересуется онтологическим моделированием, почитает про него и подумает над тем, как можно применять такие модели в программных продуктах.
Пример про несколько версий данных: пусть у нас есть справочник тарифов, с 01.01.2022 тарифы должны измениться. Такое изменение планируется заранее. В системе должны быть программно доступны и старая, и новая версия тарифов. Алгоритмы биллинга должны ночью на 1 января автоматически перейти на расчет по новым тарифам. Поскольку система хранит данные "в 4D", в ней одновременно существуют и старые тарифы, и новые. При запросе к API системы клиент может указать метку времени и получить тарифы, актуальные на это время. Если метку не указать, то вернутся значения, актуальные на текущее время - это обеспечит автоматическое переключение на новые тарифы.
Про историю модели: клиент при работе через API может явно указать, что хочет использовать не текущую версию модели, а версию, актуальную на заданное им время. При этом сами данные одни и те же. В таком случае, да, может возникнуть ситуация, что в одной версии модели какой-то атрибут не обязателен, а в другой обязателен.
Про квалификацию добавлю, что специальность "онтолог" набирает популярность. Поскольку методы онтологического моделирования описаны спецификациями W3C и позволяют моделировать что угодно, скиллы обучившегося им человека не привязан к платформе, на которой он работает в компании X.
Модель - это набор триплетов в графовой базе данных. Есть транзакции, которые изменяют состояние этой базы. Как и в обычной базе, транзакции можно записать в журнал и получить возможность "бегать" вперед-назад по состояниям базы. Мы с графом работаем не напрямую, а через платформу, которая обеспечивает такую возможность (получить состояние модели на любой момент времени).
Чтобы привести прод в состояние, в котором находится staging, надо применить на нем некий набор транзакций. У нас этот набор формируется автоматически с помощью механизма распространения изменений по подписке через менеджер очередей. То есть в условной очереди Kafka или RabbitMQ копится набор пакетов с транзакциями, и в нужный момент мы перекидываем их в другую очередь, откуда их заберет система на проде и обновит свою модель до очередного состояния.
Совместная работа с моделью происходит через веб-приложение, редактор онтологий. Редактор тоже работает с графом через платформу, соответственно все выполняемые с его помощью действия попадают в журнал транзакций.
Все тем же: методы/процедуры/обработчики создаются в программном коде, а правила создаются в онтологической модели. В нашем случае они физически лежат в той же графовой базе (или в других базах, которые на уровне API выглядят как графовая, но это уже детали). Лежат в виде точно таких же триплетов (элементарная единица информации в графовой СУБД), что и описание структуры данных, и сами данные. Технологически все это вместе образует единое и неразрывное структурированное описание знаний об автоматизируемой предметной области, корпоративный граф знаний (см. Enterprise knowledge graph).
Эта технологическая неразрывность означает, что описание правил редактируется теми же инструментами и людьми, что и описание структуры данных, и сами данные (по крайней мере в части справочных данных, с оперативными данными работают пользователи через свои фронт-энды, но и аналитикам они доступны через универсальные инструменты).
По просьбе одного из читателей, с кем переписывались в личке, привожу пример алгоритма, работающего с моделью.
Пусть в онтологии описаны некие структурные подразделения или организации, сотрудникам которых доступны некоторые операции с объектами определенных классов (типов) в зависимости от их функциональной роли. В онтологии формализованы правила, каждое из которых представляет собой связку объектов:
[ организация, роль пользователей, класс модели предметной области, операция ]
например:
[ Департамент маркетинга, Ведущий специалист, Клиент, Просмотр ]
[ Департамент маркетинга, Ведущий специалист, Потенциальный клиент, Создание ]
Организационные единицы и классы модели предметной области образуют иерархии, т.е. Департамент маркетинга может содержать вложенные орг. единицы (отделы, группы и т.д.), класс Клиент также может содержать подклассы, например Потенциальный клиент/Активный клиент или Юр. лицо/Физ. лицо.
Пусть пользователь работает со списком клиентов. Системе нужно определить,какие операции он сможет выполнить с каждым из них. Алгоритм будет таким:
1) Построить список всех родителей той орг. единицы, к которой относится пользователь (пройти вверх по иерархии орг. единиц)
2) Построить список всех родителей того класса(-ов), к которому относится проверяемый объект
3) Найти правила, в которых "организация" равна одной из полученных орг. единиц, "класс" равен одному из полученных классов, "роль" равна роли текущего пользователя. Ранжировать правила по степени спецфичности, т.е. правила, определенные для потомков, переопределяют правила, определенные для родителей.
4) По полученному списку правил составить список операций, доступных пользователю.
Подобным образом формализуются и другие правила: перехода процесса между стадиями, видимости свойств объекта разным пользователям, формирования карточки объекта и т.д. При появлении в системе нового класса объектов достаточно создать для него набор правил, и система сможет его обрабатывать.
нет необходимости "протаскивать" изменение схемы по слоям
Это - один из главных моментов, но и в остальном полностью согласен.
Change tracking усложнен т.к. классические VCS (Git) построены на сравнении text data, а в системе сравнивать нужно транзакции (record changes).
Да, добавляется проблема ведения версий модели и - при существенном изменении модели - деплоя модели одновременно с кодом, который готов с ней работать. Особенно печально, если на продуктиве нельзя заменить модель целиком - например потому, что заказчик со своей стороны сам в ней что-то редактирует. Мы к таким операциям приспособились с помощью а) механизма версионирования модели в платформе, б) механизма подписки на изменения в модели - с его помощью можно на сервере разработки формировать лог транзакций, которые меняют модель, и затем применять их на тесте и проде.
Сложно найти разработчиков, на иную модель разработки т.к. переиспользование знаний нулевое и в резюме не напишешь
Мы при найме разработчиков даже ничего не говорим про иную модель) Уже в процессе работы плавно вводим в курс дела.
Мой пойнт как раз в том, что ваше "формально описать" — это и есть программирование.
Тут, наверное, могут быть разные мнения. Для меня программирование - это написание кода, а манипуляции с элементами онтологической модели - не программирование. Допускаю, что можно считать иначе.
То есть, на самом деле, программисты. Иными словами, ваше противопоставление "изменения в модель будут вносить не программисты, а аналитики" теряет всякий смысл.
Да нет, почему. У нас в компании программисты и аналитики - разные люди с разной квалификацией, я их не путаю) И зарплаты у них разные.
Проблема в том, что это ваш опыт. То есть вы выкатываете решения на своей платформе быстрее, чем вы же выкатили бы "в классическом цикле разработки". Это ничего не говорит о том, за сколько бы выкатила другая команда, работающая "в классическом цикле".
Разумеется, я и не говорю ничего про другие команды. Я привел цикл наблюдений: у нас получилось вот так, а у отдельных других известных мне команд не получилось при другом подходе. Никаких обобщений)
Можно запрограммировать (точнее, формально описать в онтологии) новый процесс, можно модифицировать существующий.
Гм, а как вы проводите разделение между аналитиками и программистами?
Это хороший вопрос: в разных компаниях под аналитиками понимают разное. У нас аналитики - это прежде всего те, кто работает с онтологической моделью. Они описывают структуру данных и способы их обработки, часто - в виде формальных правил в онтологии.
Это утверждение нуждается в формализуемой проверке.
Я всего лишь обобщаю наш собственный опыт разработки в соответствии с предложенным подходом. В нашей практике есть конкретные подтверждения: например, когда весной 2020 года вдруг (совершенно неожиданно) началась пандемия, в одной из сопровождаемых нами систем понадобилось обрабатывать новые виды объектов, связанные с ней (тесты, самоизоляцию и т.д.). Благодаря архитектуре системы удалось вывести структуру данных и логику обработки таких объектов в продуктив буквально за пару недель, и затем неоднократно изменять вслед за вводом/отменой различных противоэпидемических мер. Если бы у нас был классический цикл разработки, так быстро мы бы это не сделали.
Прежде всего - отсутствием привязки к конкретной платформе разработки ПО, возможность использовать любые языки и среды программирования.
Кроме того, ни в SAP, ни в Dynamics, ни в Access, насколько мне известно, нет тех возможностей, которые перечислены в статье: мульти-модельное хранение данных, ведение истории/версионность модели и данных (имеется в виду возможность одновременно работать с несколькими версиями модели и данных, а не переключаться между ними), возможность управления моделью данных со стороны программных компонентов, уведомление компонентов об изменении модели данных во время исполнения. Хранение логики исполнения вне кода в перечисленных вами системах в каком-то виде присутствует, но в весьма ограниченном объеме (программирование на встроенном языке нельзя считать переносом логики из кода).
С ограничениями по железу мы при использовании такого подхода не сталкивались: скажем, ORM или известные "большие платформы" гораздо хуже влияют на производительность.
А в части сложных навыков соглашусь с вами: требования к аналитикам растут, в процессе создания системы приходится гораздо больше думать, чем при привычной разработке. Это ограничение.
Но и подход мы рекомендуем для разработки не всех систем, а только таких, которые работают с очень сложной и изменчивой структурой данных; их создание в любом случае требует больших ресурсов, но при классическом подходе тут есть большие шансы вообще зайти в тупик. Приходилось видеть не одну автоматизированную систему, фактически заброшенную из-за невозможности оперативно вносить в нее требуемые изменения, хотя на разработку были потрачены огромные суммы. В таких случаях построение системы вокруг модели данных однозначно себя оправдывает.
>Интересующие фрагменты модели определяем в зависимости от задачи.
мне скорее технически было интересно. вот как в модели на примере Fuseki вы можете понять, что вот эта часть — то что относится к данной установке? На основании чего?
Каждый объект в онтологической модели имеет идентификатор, записанный в форме URI. Например, наша установка может иметь такой URI: zavod.com/model/Unit1 (на самом деле URI может быть совершенно любой, он не несет смысловой нагрузки и не обязан дереференсироваться).
Соответственно, все триплеты, первым элементом которых является этот URI, сообщают нам что-то о свойствах и связях этой установки. Пройдя на какую-то глубину по связям, мы можем получить и все связанные с ней объекты, например — описание частей установки, фаз ее жизненного цикла и т.д.
>нет ли уже такого в модели
В реальности эта задача — для хомо сапиенса, а ему свойственно ошибаться. Вы спокойно можете иметь два атрибута, похожих по описанию, и не сможете просто определить, это одно и тоже, или же нет. Ну т.е. rdfs:comment на мой взгляд тут мало поможет. Вы исходите из того, что над задачей работают скажем два аналитика, причем они оба из одного проекта?
Часто над моделью работает более двух аналитиков, причем из разных команд — например, наши сотрудники и персонал заказчика. Тут помогает обычная дисциплина, четкое следование методологии, а также механизмы аудита — отслеживание уже внесенных в модель изменений. Проблемы случаются, но не так уж часто.
Еще помогают обсуждения изменений в модели и семинары, предназначенные для того, чтобы все аналитики представляли себе общую структуру модели.
Интересующие фрагменты модели определяем в зависимости от задачи. Например, если нам нужно решить задачу мониторинга состояния промышленной установки — в модель должна попасть та информация, которую ответственные работники предприятия используют для принятия решений о действиях, которые нужно выполнить в зависимости от тех или иных ситуаций, возникающих в работе установки. Причем желательно моделировать именно представления этих работников (за исключением очевидно неверных), а не пытаться смоделировать «объективную реальность», которой нет.
При совместной работе над моделью, действительно, возникают недоразумения. Прежде всего, мы заставляем аналитиков перед созданием нового класса или свойства обязательно проверять, нет ли уже такого в модели. Для описания точного смысла классов и свойств используются аннотационные свойства, такие как rdfs:comment, rdfs:isDefinedBy и другие, а также документация на модель. Можно использовать процедуру одобрения изменений в модель, такой программный инструмент у нас тоже есть: один аналитик предлагает, другой подтверждает.
Если дублирующий по смыслу атрибут появился, выполняется рефакторинг: все ссылки на ошибочно введенный атрибут заменяются на тот, который должен был быть использован. В графовой СУБД это очень просто сделать, в случае с мульти-модельным хранилищем сложнее, но с помощью созданных для этого инструментов — можно.
Вопросы обозримости, понимаемости и управляемости модели очень важны и сложны.
Мы практически никогда не визуализируем всю модель на одной диаграмме, только по кусочкам.
Если обращаться к методологии «сборки» онтологии под конкретные задачи, то мы используем следующие принципы:
берем за основу онтологию верхнего уровня, например BFO (Basic Formal Ontology);
берем готовые фрагменты из подходящих стандартных и отраслевых онтологий, таких как FOAF, Organization, SOSA/SSN и др.;
Что касается инструментов — мы используем свой редактор, работающий с подмножеством OWL, которое мы считаем достаточным для создания корпоративных моделей. Физически модель располагается в хранилище триплетов RDF, например Apache Fuseki. Программно мы с ней работаем через собственную платформу-прослойку. Для визуализации используем сторонние инструменты, от WebVOWL для непосредственной визуализации графа до yEd Graph Editor для построения концептуальных диаграмм.
Я бы не стал писать эту статью, если бы все это было только идеями. Конкретные примеры реализации дата-центрического подхода есть и в нашей практике, и у других компаний. Поскольку хабр запрещает рекламу, я здесь о них не пишу, но найти, как мне кажется, несложно (или пишите в личку).
Проблемы с доступом к данным вендорских приложений, или, еще лучше, самописных приложений заказчика — возникают, но решаются. Часто удается получить прямой доступ к СУБД, иногда работаем через предоставляемые приложениями веб-сервисы.
Во множестве API я не перечислил менеджеры очередей, но в нашей платформе есть поддержка Kafka и RabbitMQ.
Что касается объема данных — есть примеры реализации приложений, обрабатывающих событийную информацию, в том числе работающих с временными рядами показаний различных датчиков. Этих данных, действительно, очень много, они хранятся в БДРВ (база данных реального времени), которая может находиться как под управлением дата-центрической платформы, так и вне ее — с доступом в режиме логической витрины данных. В ответе на следующий комментарий я написал о том, что платформа физически хранит данные в хранилище, наиболее подходящем для данных того или иного типа. Избыточная нагрузка, создаваемая самой платформой при доступе к таким данным, невелика и не увеличивает радикально требования к оборудованию для размещения системы.
Зато появляется возможность легко построить бизнес-приложение под конкретную задачу, не думая о том, как собрать необходимые данные из десятков систем. Например, для мониторинга состояния промышленной установки кроме показаний датчиков нужны сведения о ремонтах и техобслуживании, нарядах на выполнение работ, персонале и его допусках, о конструкции установки — на обычном предприятии все эти данные находятся в разных бизнес-приложениях, и их интеграция является не тривиальной задачей.
В нашем же случае все это на себя берет платформа. Пусть на первом этапе данные продолжают находиться внутри старых бизнес-приложений, важно то, что для нового дата-центричного бизнес-приложения они представлены как единый граф. В результате написание приложения мониторинга состояния промышленной установки сводится к задаче создания фронт-энда, который будет отображать уже готовые данные.
Как раз для этого нужна виртуализация данных, упомянутая в статье. Корпоративный граф знаний в нашем понимании - это не просто слепок информации из корпоративных приложений. Это виртуальная конструкция, которая формируется по частям "на лету" во время выполнения запросов.
Чтобы это воплотить в реальности, мы делаем следующее:
создаем онтологическую модель предметной области, в которой описаны классы и атрибуты: сотрудник, объект, согласование доступа и др.
создаем адаптеры для доступа к данным корпоративных систем с помощью веб-сервисов на их стороне, или прямого доступа к их СУБД на чтение
создаем в онтологии правила сопоставления элементов модели предметной области элементам структуры данных корпоративных систем: список актуальных сотрудников находится в таком-то справочнике системы кадрового учета, сведения о маршрутах согласования - в таком-то виде в СЭД, и так далее
платформа виртуализации данных умеет принимать SPARQL-запросы в терминах модели предметной области (их она получает в результате преобразования вопросов пользователей), с помощью правил мэппинга извлекать на лету данные из систем-источников, строить временный граф, необходимый для ответа на запрос, и формировать ответ.
Благодаря такому подходу информация в корпоративном графе знаний всегда актуальна.
Возможность внести такое изменение только средствами моделирования зависит от того, подумали ли об этом при проектировании системы. Напомню, я не говорил в статье о том, что код полностью заменяется на модель - заменяется в некоторой части.
Если при проектировании подумали о том, что могут существовать перевозчики с закрытым алгоритмом расчета, то в модели должна быть описана сущность "внешний веб-сервис". Здесь уже стандартными спецификациями не обойтись. Для каждого сервиса формально описываются параметры и возвращаемое значение - что-то вроде SHACL Function, только для самого расчета вместо SPARQL-запроса нужно будет делать вызов внешнего сервиса.
К каждому перевозчику в модели привязываем метод расчета стоимости - это может быть SHACL Rule / Function или конкретный "внешний веб-сервис". Алгоритм выбора перевозчика для конкретного заказа, вполне вероятно, останется в коде и будет заключаться в асинхронном запуске расчета стоимости для всех перевозчиков согласно определенным в модели алгоритмам.
Если при проектировании о таком варианте не подумали, значит предстоит рефакторинг кода и модели.
Да, это похожий пример. И пример со SPARQL был бы валиден, у нас для таких есть конструктор.
Приведенная запись - один из вариантов сериализации онтологии. Есть и другие варианты, например в RDF/XML или OWL/XML. Все они при импорте в графовую СУБД дают один и тот же набор триплетов, и при просмотре через редактор выглядят одинаковым образом.
Вы можете зарегистрироваться на https://webprotege.stanford.edu или скачать десктопную версию Protege, загрузить туда этот фрагмент и посмотреть, как он будет выглядеть в редакторе. Увидите иерархию классов, среди которых будут классы NodeShape, RectangleShape, TripleRule и т.д., и индивидуальные объекты этих классов, представляющие конкретное правило.
Можно описать как SHACL Rule, см. спецификацию https://www.w3.org/TR/shacl-af/
Редактируется с помощью визуального конструктора формул и правил, если он есть в составе платформы, на которой ведется разработка (таких платформ существует несколько), или путем ручного создания элементов онтологии. Можно хоть в Protege создать, при желании - это базовый open source редактор онтологий.
Тут, видимо, можно долго спорить о терминологии "программисты"/"аналитики". Также понятно, что хочется обсуждаемое явление свести к тому, что уже известно. Хотя лично я не могу называть программистами людей, которые работают только с редактором онтологии и не написали за свою жизнь ни строчки программного кода.
Я понимаю, что одной статьей сложно убедить всех в том, что то, что толком не получилось у Low code платформ, можно сделать другим способом, не создавая очередного внутриплатформенного языка программирования (онтологическая модель - это не код даже в том смысле, в котором им является язык 1С).
Все, на что я надеюсь - что кто-то из читателей заинтересуется онтологическим моделированием, почитает про него и подумает над тем, как можно применять такие модели в программных продуктах.
Пример про несколько версий данных: пусть у нас есть справочник тарифов, с 01.01.2022 тарифы должны измениться. Такое изменение планируется заранее. В системе должны быть программно доступны и старая, и новая версия тарифов. Алгоритмы биллинга должны ночью на 1 января автоматически перейти на расчет по новым тарифам. Поскольку система хранит данные "в 4D", в ней одновременно существуют и старые тарифы, и новые. При запросе к API системы клиент может указать метку времени и получить тарифы, актуальные на это время. Если метку не указать, то вернутся значения, актуальные на текущее время - это обеспечит автоматическое переключение на новые тарифы.
Про историю модели: клиент при работе через API может явно указать, что хочет использовать не текущую версию модели, а версию, актуальную на заданное им время. При этом сами данные одни и те же. В таком случае, да, может возникнуть ситуация, что в одной версии модели какой-то атрибут не обязателен, а в другой обязателен.
Не знаю какая тут политика по рекламе в комментариях, поэтому ответил в личку. $hyoo_rdf не видел, посмотрю, спасибо.
То, что вы пишете, справедливо для Low code платформ. Выше в обсуждении был вопрос, чем наш подход от них отличается, вот ответ: https://habr.com/ru/post/576304/#comment_23447646
Про квалификацию добавлю, что специальность "онтолог" набирает популярность. Поскольку методы онтологического моделирования описаны спецификациями W3C и позволяют моделировать что угодно, скиллы обучившегося им человека не привязан к платформе, на которой он работает в компании X.
Модель - это набор триплетов в графовой базе данных. Есть транзакции, которые изменяют состояние этой базы. Как и в обычной базе, транзакции можно записать в журнал и получить возможность "бегать" вперед-назад по состояниям базы. Мы с графом работаем не напрямую, а через платформу, которая обеспечивает такую возможность (получить состояние модели на любой момент времени).
Чтобы привести прод в состояние, в котором находится staging, надо применить на нем некий набор транзакций. У нас этот набор формируется автоматически с помощью механизма распространения изменений по подписке через менеджер очередей. То есть в условной очереди Kafka или RabbitMQ копится набор пакетов с транзакциями, и в нужный момент мы перекидываем их в другую очередь, откуда их заберет система на проде и обновит свою модель до очередного состояния.
Совместная работа с моделью происходит через веб-приложение, редактор онтологий. Редактор тоже работает с графом через платформу, соответственно все выполняемые с его помощью действия попадают в журнал транзакций.
Все тем же: методы/процедуры/обработчики создаются в программном коде, а правила создаются в онтологической модели. В нашем случае они физически лежат в той же графовой базе (или в других базах, которые на уровне API выглядят как графовая, но это уже детали). Лежат в виде точно таких же триплетов (элементарная единица информации в графовой СУБД), что и описание структуры данных, и сами данные. Технологически все это вместе образует единое и неразрывное структурированное описание знаний об автоматизируемой предметной области, корпоративный граф знаний (см. Enterprise knowledge graph).
Эта технологическая неразрывность означает, что описание правил редактируется теми же инструментами и людьми, что и описание структуры данных, и сами данные (по крайней мере в части справочных данных, с оперативными данными работают пользователи через свои фронт-энды, но и аналитикам они доступны через универсальные инструменты).
По просьбе одного из читателей, с кем переписывались в личке, привожу пример алгоритма, работающего с моделью.
Пусть в онтологии описаны некие структурные подразделения или организации, сотрудникам которых доступны некоторые операции с объектами определенных классов (типов) в зависимости от их функциональной роли. В онтологии формализованы правила, каждое из которых представляет собой связку объектов:
[ организация, роль пользователей, класс модели предметной области, операция ]
например:
[ Департамент маркетинга, Ведущий специалист, Клиент, Просмотр ]
[ Департамент маркетинга, Ведущий специалист, Потенциальный клиент, Создание ]
Организационные единицы и классы модели предметной области образуют иерархии, т.е. Департамент маркетинга может содержать вложенные орг. единицы (отделы, группы и т.д.), класс Клиент также может содержать подклассы, например Потенциальный клиент/Активный клиент или Юр. лицо/Физ. лицо.
Пусть пользователь работает со списком клиентов. Системе нужно определить,какие операции он сможет выполнить с каждым из них. Алгоритм будет таким:
1) Построить список всех родителей той орг. единицы, к которой относится пользователь (пройти вверх по иерархии орг. единиц)
2) Построить список всех родителей того класса(-ов), к которому относится проверяемый объект
3) Найти правила, в которых "организация" равна одной из полученных орг. единиц, "класс" равен одному из полученных классов, "роль" равна роли текущего пользователя. Ранжировать правила по степени спецфичности, т.е. правила, определенные для потомков, переопределяют правила, определенные для родителей.
4) По полученному списку правил составить список операций, доступных пользователю.
Подобным образом формализуются и другие правила: перехода процесса между стадиями, видимости свойств объекта разным пользователям, формирования карточки объекта и т.д. При появлении в системе нового класса объектов достаточно создать для него набор правил, и система сможет его обрабатывать.
Это - один из главных моментов, но и в остальном полностью согласен.
Да, добавляется проблема ведения версий модели и - при существенном изменении модели - деплоя модели одновременно с кодом, который готов с ней работать. Особенно печально, если на продуктиве нельзя заменить модель целиком - например потому, что заказчик со своей стороны сам в ней что-то редактирует. Мы к таким операциям приспособились с помощью а) механизма версионирования модели в платформе, б) механизма подписки на изменения в модели - с его помощью можно на сервере разработки формировать лог транзакций, которые меняют модель, и затем применять их на тесте и проде.
Мы при найме разработчиков даже ничего не говорим про иную модель) Уже в процессе работы плавно вводим в курс дела.
Тут, наверное, могут быть разные мнения. Для меня программирование - это написание кода, а манипуляции с элементами онтологической модели - не программирование. Допускаю, что можно считать иначе.
Да нет, почему. У нас в компании программисты и аналитики - разные люди с разной квалификацией, я их не путаю) И зарплаты у них разные.
Разумеется, я и не говорю ничего про другие команды. Я привел цикл наблюдений: у нас получилось вот так, а у отдельных других известных мне команд не получилось при другом подходе. Никаких обобщений)
Можно запрограммировать (точнее, формально описать в онтологии) новый процесс, можно модифицировать существующий.
Это хороший вопрос: в разных компаниях под аналитиками понимают разное. У нас аналитики - это прежде всего те, кто работает с онтологической моделью. Они описывают структуру данных и способы их обработки, часто - в виде формальных правил в онтологии.
Я всего лишь обобщаю наш собственный опыт разработки в соответствии с предложенным подходом. В нашей практике есть конкретные подтверждения: например, когда весной 2020 года вдруг (совершенно неожиданно) началась пандемия, в одной из сопровождаемых нами систем понадобилось обрабатывать новые виды объектов, связанные с ней (тесты, самоизоляцию и т.д.). Благодаря архитектуре системы удалось вывести структуру данных и логику обработки таких объектов в продуктив буквально за пару недель, и затем неоднократно изменять вслед за вводом/отменой различных противоэпидемических мер. Если бы у нас был классический цикл разработки, так быстро мы бы это не сделали.
Прежде всего - отсутствием привязки к конкретной платформе разработки ПО, возможность использовать любые языки и среды программирования.
Кроме того, ни в SAP, ни в Dynamics, ни в Access, насколько мне известно, нет тех возможностей, которые перечислены в статье: мульти-модельное хранение данных, ведение истории/версионность модели и данных (имеется в виду возможность одновременно работать с несколькими версиями модели и данных, а не переключаться между ними), возможность управления моделью данных со стороны программных компонентов, уведомление компонентов об изменении модели данных во время исполнения. Хранение логики исполнения вне кода в перечисленных вами системах в каком-то виде присутствует, но в весьма ограниченном объеме (программирование на встроенном языке нельзя считать переносом логики из кода).
С ограничениями по железу мы при использовании такого подхода не сталкивались: скажем, ORM или известные "большие платформы" гораздо хуже влияют на производительность.
А в части сложных навыков соглашусь с вами: требования к аналитикам растут, в процессе создания системы приходится гораздо больше думать, чем при привычной разработке. Это ограничение.
Но и подход мы рекомендуем для разработки не всех систем, а только таких, которые работают с очень сложной и изменчивой структурой данных; их создание в любом случае требует больших ресурсов, но при классическом подходе тут есть большие шансы вообще зайти в тупик. Приходилось видеть не одну автоматизированную систему, фактически заброшенную из-за невозможности оперативно вносить в нее требуемые изменения, хотя на разработку были потрачены огромные суммы. В таких случаях построение системы вокруг модели данных однозначно себя оправдывает.
Каждый объект в онтологической модели имеет идентификатор, записанный в форме URI. Например, наша установка может иметь такой URI: zavod.com/model/Unit1 (на самом деле URI может быть совершенно любой, он не несет смысловой нагрузки и не обязан дереференсироваться).
Соответственно, все триплеты, первым элементом которых является этот URI, сообщают нам что-то о свойствах и связях этой установки. Пройдя на какую-то глубину по связям, мы можем получить и все связанные с ней объекты, например — описание частей установки, фаз ее жизненного цикла и т.д.
Часто над моделью работает более двух аналитиков, причем из разных команд — например, наши сотрудники и персонал заказчика. Тут помогает обычная дисциплина, четкое следование методологии, а также механизмы аудита — отслеживание уже внесенных в модель изменений. Проблемы случаются, но не так уж часто.
Еще помогают обсуждения изменений в модели и семинары, предназначенные для того, чтобы все аналитики представляли себе общую структуру модели.
При совместной работе над моделью, действительно, возникают недоразумения. Прежде всего, мы заставляем аналитиков перед созданием нового класса или свойства обязательно проверять, нет ли уже такого в модели. Для описания точного смысла классов и свойств используются аннотационные свойства, такие как rdfs:comment, rdfs:isDefinedBy и другие, а также документация на модель. Можно использовать процедуру одобрения изменений в модель, такой программный инструмент у нас тоже есть: один аналитик предлагает, другой подтверждает.
Если дублирующий по смыслу атрибут появился, выполняется рефакторинг: все ссылки на ошибочно введенный атрибут заменяются на тот, который должен был быть использован. В графовой СУБД это очень просто сделать, в случае с мульти-модельным хранилищем сложнее, но с помощью созданных для этого инструментов — можно.
Мы практически никогда не визуализируем всю модель на одной диаграмме, только по кусочкам.
Если обращаться к методологии «сборки» онтологии под конкретные задачи, то мы используем следующие принципы:
Конечно, это всегда очень творческий процесс, одну и ту же предметную область можно смоделировать множеством разных способов. Некоторые вопросы методологии моделирования мы обсудили в нашей книжке «Онтологическое моделирование предприятий: методы и технологии».
Что касается инструментов — мы используем свой редактор, работающий с подмножеством OWL, которое мы считаем достаточным для создания корпоративных моделей. Физически модель располагается в хранилище триплетов RDF, например Apache Fuseki. Программно мы с ней работаем через собственную платформу-прослойку. Для визуализации используем сторонние инструменты, от WebVOWL для непосредственной визуализации графа до yEd Graph Editor для построения концептуальных диаграмм.
Проблемы с доступом к данным вендорских приложений, или, еще лучше, самописных приложений заказчика — возникают, но решаются. Часто удается получить прямой доступ к СУБД, иногда работаем через предоставляемые приложениями веб-сервисы.
Во множестве API я не перечислил менеджеры очередей, но в нашей платформе есть поддержка Kafka и RabbitMQ.
Что касается объема данных — есть примеры реализации приложений, обрабатывающих событийную информацию, в том числе работающих с временными рядами показаний различных датчиков. Этих данных, действительно, очень много, они хранятся в БДРВ (база данных реального времени), которая может находиться как под управлением дата-центрической платформы, так и вне ее — с доступом в режиме логической витрины данных. В ответе на следующий комментарий я написал о том, что платформа физически хранит данные в хранилище, наиболее подходящем для данных того или иного типа. Избыточная нагрузка, создаваемая самой платформой при доступе к таким данным, невелика и не увеличивает радикально требования к оборудованию для размещения системы.
Зато появляется возможность легко построить бизнес-приложение под конкретную задачу, не думая о том, как собрать необходимые данные из десятков систем. Например, для мониторинга состояния промышленной установки кроме показаний датчиков нужны сведения о ремонтах и техобслуживании, нарядах на выполнение работ, персонале и его допусках, о конструкции установки — на обычном предприятии все эти данные находятся в разных бизнес-приложениях, и их интеграция является не тривиальной задачей.
В нашем же случае все это на себя берет платформа. Пусть на первом этапе данные продолжают находиться внутри старых бизнес-приложений, важно то, что для нового дата-центричного бизнес-приложения они представлены как единый граф. В результате написание приложения мониторинга состояния промышленной установки сводится к задаче создания фронт-энда, который будет отображать уже готовые данные.