От объекта к системе

Глава 18. От модели данных к инженерной платформе

18.1. Здание, которое стоит на песке

Представим архитектора, который проектирует здание. Он выбирает фасад. Выбирает материалы отделки. Выбирает цвет стен. Выбирает форму окон. Всё красиво. Всё современно. Всё соответствует последним тенденциям.

Но фундамент не заложен. Или заложен неправильно. Грунт не исследован. Нагрузка не рассчитана. Несущие конструкции не определены.

Через пять лет здание начинает трескаться. Через десять — требует капитального ремонта. Через двадцать — сносится.

Не потому, что фасад был плох. А потому, что фундамент был слаб.

Информационная система устроена так же.

Технологии — это инструменты реализации. База данных, язык программирования, протокол взаимодействия, интерфейс — всё это важно. Но они не определяют, какие объекты существуют в системе и какой смысл имеют хранимые данные.

Модель данных — это фундамент.

Если фундамент неправилен, никакая технология не исправит модель. Можно заменить базу данных. Переписать сервисы. Изменить интерфейс. Перейти на другой язык программирования. Но если система продолжает хранить неправильные объекты и неправильные связи между ними, проблема остаётся.

18.2. Что меняется, а что остаётся

Рассмотрим инженерную платформу, которая существует двадцать лет.

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

Но сами инженерные объекты не исчезают вместе с технологиями.

Изделие остаётся изделием. Его описание остаётся описанием. Экземпляр остаётся конкретным экземпляром. Документ остаётся документом. Связь между объектами сохраняет свой смысл.

Меняется способ хранения и обработки информации. Не сама инженерная реальность.

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

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

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

18.3. Модель данных как архитектурный документ

В традиционном понимании архитектура системы описывается диаграммами сервисов, схемами взаимодействия, спецификациями API и инфраструктурными решениями.

Это важные документы. Но они описывают реализацию.

Модель данных отвечает на другой вопрос: что система считает существующим?

Если в модели есть объект изделия, система может независимо хранить его описание.

Если описание имеет собственные версии, изменение описания не обязано менять сам объект.

Если экземпляр является самостоятельным объектом, система может отличать тип изделия от конкретного изготовленного изделия.

Если связь является самостоятельной сущностью, она может иметь собственные свойства, историю и правила изменения.

Если разные области знания представлены разными сущностями, архитектура может разделить ответственность между соответствующими сервисами.

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

Модель данных сначала отвечает на вопрос, что именно система должна реализовать.

18.4. Модель определяет границы ответственности

В предыдущих главах мы пришли к тому, что один объект может иметь несколько независимых описаний.

Конструктор знает конструкцию изделия. Технолог знает способ его изготовления. Производство знает конкретный производственный процесс. Эксплуатация знает состояние конкретного экземпляра.

Ни одна из этих областей не должна владеть всем объектом целиком.

Объект один. Знаний о нём много.

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

Например:

                     KObject
                        │
          ┌─────────────┼─────────────┐
          │             │             │
       Design       Technology    Manufacturing
       Service        Service        Service
          │             │             │
      Definition     Definition    Definition
      Revision       Revision      Revision

Сервисы управляют разными аспектами одного объекта. Объект при этом не принадлежит одному из них.

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

18.5. Единый объект — разные области знания

Рассмотрим насос Н1.

Конструкторское подразделение создаёт его конструктивное описание. Технологическое подразделение создаёт технологическое описание. Производство фиксирует сведения о конкретном изготовленном экземпляре. Эксплуатационная служба фиксирует сведения о состоянии этого экземпляра.

Все эти сведения относятся к одному объекту или к связанным с ним объектам. Но они не являются одним и тем же знанием.

Если система объединяет их в одну сущность, любое изменение начинает затрагивать всё сразу.

Изменение конструкции становится изменением технологии. Изменение технологии становится изменением производственных данных. Изменение состояния экземпляра начинает выглядеть как изменение самого изделия.

Модель перестаёт различать предметы, которые в реальном мире различны.

Если же модель разделяет эти сущности, архитектура получает естественные границы.

Конструктор изменяет конструктивное описание. Технолог изменяет технологическое описание. Производство работает со своими данными. Эксплуатация работает с данными конкретного экземпляра.

Они могут взаимодействовать, но не обязаны владеть одним и тем же набором данных.

18.6. Почему неправильная модель не исправляется технологией

Предположим, система построена на неправильной модели.

Например, объект изделия не отделён от его описания.

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

Но объект по-прежнему не отделён от описания.

Технология изменилась. Модель — нет.

Через несколько лет возникает та же проблема. Пользователи снова начинают хранить часть информации вне системы. Система становится технически современной, но концептуально остаётся той же.

Это объясняет важное различие: технологическая модернизация не является исправлением модели данных.

Чтобы исправить модель, необходимо изменить представление системы о том, какие объекты существуют и как они связаны.

18.7. Что происходит с данными

Когда модель данных не соответствует инженерной практике, пользователи начинают обходить систему.

Формально центральная система существует. Фактически данные начинают жить в нескольких мирах. Через несколько лет никто точно не знает, какой источник является актуальным. Данные расходятся. Целостность теряется.

Это уже не просто техническая проблема. Система хранит одну модель мира. Пользователи работают с другой. Эти две модели перестают совпадать.

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

18.8. Почему это не вопрос интерфейса

На первый взгляд может показаться, что проблема в интерфейсе.

Сделать более удобные экраны. Добавить подсказки. Упростить навигацию. Добавить ещё один workflow.

Но интерфейс является внешним слоем системы. Он показывает то, что содержит модель.

Если модель не содержит объекта изделия, интерфейс не может его показать.

Если модель не различает изменение описания и изменение объекта, интерфейс не может устранить это различие.

Если модель не содержит конкретного экземпляра как самостоятельного объекта, интерфейс не сможет сделать его самостоятельным объектом только за счёт удобной формы.

Интерфейс может скрыть проблему. Но не решить её.

18.9. Как строится платформа

Отсюда следует последовательность, которая кажется очевидной, но на практике часто нарушается.

Сначала определяется модель данных. Какие объекты существуют? Как они связаны? Какие сущности являются самостоятельными? Что изменяется, а что остаётся тем же объектом? Какие правила определяют допустимые состояния?

После этого модель проверяется на реальных инженерных сценариях. Конструктор создаёт изделие. Создаёт его описание. Изменяет описание. Технолог создаёт собственное описание. Производство выпускает конкретный экземпляр. Эксплуатация изменяет состояние экземпляра. Изделие включается в состав другого изделия. Документ описывает объект. Изменение проходит согласование и утверждение.

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

Это не удобно. Это не быстро. Но это правильная последовательность.

Сначала модель. Потом архитектура. Потом технологии.

18.10. Правильная последовательность требует дисциплины

Проблема технологического подхода в том, что технология видна сразу. Все эти решения дают ощущение движения.

Но они не отвечают на главный вопрос: что именно система должна считать существующим?

Если этот вопрос не решён, команда начинает компенсировать отсутствие модели техническими механизмами. Система растёт. Но её внутренняя семантика становится всё менее определённой.

Правильная последовательность требует обратного подхода.

Сначала модель. Потом всё остальное.

Это не гарантирует идеальную систему. Но это позволяет проверять архитектуру относительно явно определённой модели мира.

18.11. Граница: модель определяет границы, но не реализацию

Было бы неверно утверждать, что модель данных определяет всё.

Она определяет:

• какие объекты существуют;
• как они связаны;
• кто за них отвечает;
• где проходят границы ответственности.

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

Эти решения важны. Но они вторичны. Они определяют, как реализована граница, а не где эта граница проходит.

Хорошая модель данных может быть реализована на разных технологиях.

Плохая модель данных не исправляется никакой технологией.

18.12. Что говорят стандарты

Международные стандарты управления конфигурацией последовательно показывают, что информационная модель должна рассматриваться независимо от конкретного инструмента её реализации.

ANSI/EIA-649-D «Configuration Management Standard» устанавливает требования к управлению конфигурационными данными на протяжении жизненного цикла конфигурационной единицы. Это принципиально: система управления конфигурацией должна быть рассчитана на долгосрочную работу с данными, а не только на возможности конкретного инструмента.

NASA Systems Engineering Handbook рассматривает информационную архитектуру управления конфигурацией как отдельный уровень, который должен быть определён относительно данных управления конфигурацией, а не относительно возможностей конкретного программного продукта.

MIL-HDBK-61A также рассматривает модель данных управления конфигурацией как основу системы и подчёркивает необходимость отделять её от конкретных инструментов реализации.

Эти документы не говорят, что существует единственная архитектура PLM.

Они устанавливают более фундаментальное требование: система должна сохранять управляемый смысл конфигурационных данных независимо от конкретного инструмента.

18.13. ISO 10303-239

Тот же принцип виден в ISO 10303-239, Product Life Cycle Support.

Стандарт разделяет сущности, связанные с самим изделием, его определением и контекстом определения.

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

Модель не обязана копировать PLCS.

Но сам факт такого разделения показывает: международная практика не сводит всё инженерное знание к одной записи изделия.

18.14. NPDM

Аналогичный принцип используется в NATO Product Data Model.

NPDM разделяет product и информацию, связанную с его определением и характеристиками.

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

Это не означает, что Constructum является реализацией NPDM или ISO 10303-239.

Это означает, что выбранное в книге разделение имеет международные архитектурные аналоги.

18.15. Как это закреплено в ЕСКД

Отечественная инженерная практика выражает тот же принцип через систему стандартов.

ГОСТ Р 2.101-2023 определяет, что является изделием. Это определение не зависит от программного обеспечения.

ГОСТ 2.113-75 определяет исполнение как конструктивную разновидность изделия. Это понятие не зависит от базы данных или интерфейса.

ГОСТ Р 2.503-2023 определяет правила внесения изменений. Сам процесс изменения не зависит от конкретной программной реализации.

ГОСТ Р 2.052-2024 и ГОСТ Р 2.053-2023 описывают электронную модель изделия и электронную структуру изделия как отдельные инженерные понятия.

Следовательно, инженерные стандарты определяют смысл объектов и процессов, но не предписывают конкретную программную реализацию.

Именно здесь возникает пространство для архитектуры информационной системы.

18.16. Модель не является программой

Это различие важно зафиксировать.

Модель данных не является программой. Она не является базой данных. Она не является API. Она не является микросервисом. Она не является интерфейсом.

Модель определяет, что эти технические компоненты должны представлять.

Можно построить несколько разных программных систем на одной модели. Если смысл модели сохранён, данные продолжают означать то же самое.

И наоборот: две системы могут использовать одинаковую базу данных, одинаковый язык программирования и одинаковые протоколы, но иметь совершенно разные модели мира.

Технологии одинаковы. Системы — разные.

18.17. Связь с предыдущими главами

Глава 13 установила: модель данных определяет архитектуру системы.

Глава 16 установила: различие между PLM находится в исходном вопросе. Одна система спрашивает: как управлять состояниями? Другая спрашивает: что существует?

Глава 17 установила: если модель не соответствует практике, пользователи обходят систему.

Глава 18 добавляет: модель данных является фундаментом платформы. Технологии являются инструментами. Фундамент живёт дольше инструментов.

Вместе эти главы формируют последовательную картину. Сначала определяется, что является объектом. Затем определяется, что является его описанием. Затем определяется, что изменяется, а что остаётся тем же объектом. Затем определяется, как эти понятия должны быть представлены в системе.

И только после этого возникает вопрос о технологии.

18.18. Главный вывод

Цифровая инженерная платформа начинается не с технологий. Не с микросервисов. Не с базы данных. Не с интерфейса.

Она начинается с модели данных.

С ответа на вопрос: какие объекты существуют в реальном мире и как они связаны?

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

Если модель правильная, технологии становятся инструментами. Их можно менять. Обновлять. Заменять.

Модель остаётся. Данные сохраняют смысл. Платформа может жить десятилетиями.

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

Платформа не живёт. Она выживает.

Поэтому инженерная платформа должна строиться от модели мира, а не от технологии.

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

Именно поэтому модель данных является фундаментом платформы.

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

В следующей главе: всё является объектом. Пользователь, документ, revision, исполнение, экземпляр, проект, группа, связь — все они являются объектами. И благодаря этому вся система начинает работать одинаково.

Примечания к главе 18

Источники:

• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019.
• NASA/SP-2016-610, Rev. 2, NASA Systems Engineering Handbook, NASA, 2016.
• MIL-HDBK-61A, Configuration Management Guidance, U.S. Department of Defense, 2001.
• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• NATO CALS Office, NPDM Version 4.10 — NATO Product Data Model, STANAG 4613 / ALP-14.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ 2.113-75. Единая система конструкторской документации. Групповые и базовые конструкторские документы.
• ГОСТ Р 2.503-2023. Единая система конструкторской документации. Правила внесения изменений.
• ГОСТ Р 2.052-2024. Единая система конструкторской документации. Электронная модель изделия. Общие положения.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ Р 2.051-2023. Единая система конструкторской документации. Электронная конструкторская документация. Основные положения.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.

Типы доказательств: