Датацентричность и моделе-ориентированность
Слова "датацентричность" и "моделе-ориентированность" сегодня уже что-то вроде привычных техно-заклинаний. Все хотят "датацентричности" и "моделе-ориентированности" (нет, я не против -- это хорошо, что хотят!), но не очень-то понимают, что это конкретно в их ситуации значит, и какие именно выгоды будут получены. В итоге в презентациях и технических заданиях появляются слова "датацентричность" и "моделеориентированность", но много реже датацентричность и моделе-ориентированность проявляются в реальных системах.
Слова "датацентричность" и "моделе-ориентированность" обычно произносятся не сами по себе, а как основная характеристика или принцип построения архитектуры корпоративной или инженерной информационной системы. Тем самым это характеристики того, функция (назначение, поведение) системы в надсистеме реализуется конструкцией целевой системы. Оставим пока в стороне длинную дискуссию про структуру, механизм, конструкцию, процесс, материал и всё прочие возможные различения в том, что реализует функцию и я назвал пока просто "конструкцией". Можно обсуждать и проще: функция -- это "система как чёрный ящик", а всё остальное -- "белый ящик". Датацентричность и моделеориентированность -- это, конечно, про белый ящик. Но так же, как реализация функции "землеройное устройство" зависит от выбранного пути конструкторского решения (лопата или экскаватор), которое в свою очередь переопределяет функцию (у лопаты и экскаватора де-факто получаются разные функции), так и датацентричность и моделеориентированность относятся к таким архитектурным принципам/характеристикам, которые переопределяют функции систем с принципами/характеристиками документо-центричности и документо-ориентированности.
"Датацентрическая архитектура" (data-centric architecture), противопоставляемая "документо-центричной архитектуре" -- это указание на то, что система строится на основе приоритета разбирательства с данными, и подчиненной роли информационных объектов (различение информации, данных и информационных объектов -- http://ailev.livejournal.com/908102.html). В датацентрических архитектурах обсуждаются учётные проблемы (раскладка "оригинальных" данных по информационным объектам, находящимся под разным администрированием, а также проблемы, возникающие при управлении конфигурацией данных -- трассировка изменений в данных к изменениям в информационных объектах).
"Моделе-ориентированная архитектура" (model-based architecture) в противопоставление "документо-ориентированной" -- это указание на то, что функция информационной системы реализуется на основе понимания моделей как данных (т.е. абстрактных сущностей), а не на основе поддержки только отображающих эти модели конкретных документов (информационных объектов). В моделеориентированных архитектурах обсуждается полнота отражения информации об объекте в данных (так, 3D информация плохо представима в растровых форматах, хотя именно растровые форматы удобны для их презентации на дисплеях и бумаге).
Конечно, два предыдущих абзаца определений сами по себе совершенно непонятны и недостаточны. Эта непонятность, увы, не только в их краткости, но и в предполагаемой этими формулировками смене мыслительных парадигм:
-- в датацентричности это учётная парадигма (см. также "вопрошание об учёте", http://ailev.livejournal.com/593013.html), меняющая собой парадигму документирования. Учёт подразумевает позицию регистратора данных, полномочия по регистрации данных, реестры, формирование выписок и т.д.. Документирование всего этого не предусматривает, там просто составляются и передаются документы -- информационные объекты. Переход от "банков документов" к "базам данных" как раз представляет собой сдвиг в сторону датацентричности. Датацентричность -- это даталогическое обсуждение, где важны данные сами по себе (их сбор, хранение, маршрутизация заинтересованным сторонам и т.д.). Содержание данных в датацентричности обсуждается только по сопричастности.
-- в моделе-ориентированности это знаниевая парадигма (аккуратное представление информации данными, отображение возможно только после специальной обработки этих данных для целей представления человеку) против парадигмы документа-как-изображения-для-человека. Подробное разбирательство с моделями данных (например, отдельное хранение имени, отчества и фамилии в базе данных; хранение аннотированных разнообразными атрибутами 3D параметрических моделей в САПР вместо хранения растровых или даже векторных "картинок") представляет собой сдвиг в сторону моделеориентированности. В моделе-ориентированности обсуждение инфологическое: обсуждается адекватность представления информации в данных, но вопросы самих учёта самих данных (сбора, хранения, маршрутизации и т.д.) обсуждаются только по сопричастности.
Путаница появляется в том числе и оттого, что как датацентричность, так и моделе-ориентированность связаны с различными группами описания работы с данными (датацентричность -- как данные раскладываются по информационным объектам, т.е. носителям данных; моделецентричность -- какие именно данные доступны для учёта). И оба этих аспекта (знаний и учёта) противопоставляются простейшим формам работы с документами (где учитываются сами документы, а не данные в них; документы предназначены только для предъявления человеку, поэтому не содержат машинно-читаемых знаний). Важно учитывать оба сдвига парадигмы (учётный/даталогический и знаниевый/инфологический), а не только один. Так, переход к структурированным документам -- это только половина дела. Переход к навороченным (на сегодня чаще всего -- уже объект-ориентированным, а не реляционным) базам данных -- это тоже половина дела.
Вот примеры проблем, которые решаются в рамках перехода к датацентричности:
-- как передать оригинал модели? Так, при проектировании в SP3D содержится полная 3D модель (но только в последней версии!), в SPF уже передаётся неполная модель (.vue файл) и информация о версии модели имеется не для 3D модели, а только для "модели для просмотра". В архив же уходят не модели, а полученные из модели двумерные чертежи. В ситуациях передачи модели другим проектировщикам, восстановление истории (в том числе откаты к предыдущим версиям, или восстановление конфигурации), работа с вариантами дизайна и т.д. возникают огромные проблемы. Нет проблем с учётом в части архивного хранения "выписок из модели" (полученных двумя разными огрублениями -- переход от полного 3D представления к просмотровому .vue, и параллельно вывод в архивные чертежи), но ничего содержательного без перехода к датацентричности (т.е. решения вопроса об учёте оригинальной модели системы в SP3D, а не разных выписок из этой модели в других информационных системах) с этими документами делать нельзя. Есть также проблема с "утверждениями": утверждается "фотография" (выписка), а не то, с чего сделана фотография (исходная база данных) -- но утвержденная фотография оказывается главней оригинала, который никем не утверждается и продолжает оставаться "рабочим"! Если возникает проблема "объекту нужно сбрить усы", то нельзя гарантировать, что вместо сбривания усов не будет подретуширована фотография (т.е. данные исходной базы и утвержденных выписок из неё совпадут).
-- data handover со стадии на стадию. Ежели передавать документы, то совершенно непонятно, как работать с изменениями: в документах коллизии не проверишь. Ежели базу данных, то какую из многочисленных?
-- нужно ли "физически" собирать все данные разных САПР в какой-то одной PLM для поиска коллизий, или возможно организовать распределенную разработку? Какова архитектура информационной системы разработки, обеспечивающей принципиальный (логический, абстрактный) сбор правильной конфигурации системы для поиска коллизий или в виде проектного базиса?
-- практика управления информацией в ISO 15288 обеспечивает, чтобы данные были доступны тем заинтересованным сторонам, которым они нужны, и тогда, когда они нужны. Как это обеспечить технологически, ежели эти данные уже где-то находятся, а все информационные системы в предприятии находятся под разным администрированием?
Итого: датацентричность нужна, чтобы обеспечить управление конфигурацией информационной модели сложного технического объекта, а также управление информацией. Нет датацентричности -- нельзя быть уверенным в правильности конфигурации общей информационной модели инженерного объекта и возможности получить даже имеющуюся информацию для ее машинной обработки или другого использования.
Вот примеры проблем, которые решаются в рамках перехода к моделе-ориентированности:
-- действительно ли нужно использовать просмотровые форматы в PLM, или нужно передавать оригинальные модели с сохранением всей информации?
-- совместимы ли используемые модели данных (интеграция данных разных САПР) при попытках собрать общую непротиворечивую модель инженерного объекта?
-- можем ли мы обеспечить "подъем в цифру" бумажных чертежей? При этом речь идет не о сканировании (это бы обсуждалось как маленький шажок к датацентричности, смена вида носителя для "картинки" с бумаги на растровый файл), а "распознавании" -- то есть представление в виде атрибутированной 3D-модели с привязкой к другим моделям (например, P&ID).
-- какие виды коллизий мы можем проверить, имея тот или иной вид данных? Какие данные нужно собрать и хранить, как обеспечить связанность этих данных между собой, чтобы проверка коллизий была возможна?
-- какие виды моделей (технологические/процессные -- P&ID, 3D, финансовые, графики работ, органиграммы и т.д.) должны быть разработаны в инженерном проекте, и какие должны быть модели данных (метамодели) этих моделей?
-- какое программное обеспечение должно быть выбрано, чтобы поддержать работу с необходимыми моделями (например, САПР должен поддерживать 3D моделирование, а не 2D).
-- какое имитационное моделирование можно выполнить с использованием данных модели? Какие программы имитационного моделирования (коды) поймут данные модели?
Итого: моделецентричность нужна, чтобы как можно более аккуратно представить инженерный объект в компьютере, получить его точную модель. И на этой модели можно проверить коллизии, использовать данные этой модели для порождающего проектирования. Нет моделецентричности -- и компьютер будет бесполезен для обработки инженерной информации, придётся полагаться только на голову -- и мириться при этом с неизбежными ошибками и низкой производительностью умственного труда.
А теперь повторюсь: это два парадигмальных сдвига. Так что не думайте, что быстро разберётесь, даже если всё написанное тут кажется очевидным и понятным. Но и не надейтесь, что эти проблемы обойдут стороной: датацентричность и моделе-ориентированность представляют сейчас основной архитектурный тренд в инженерных и корпоративных информационных системах, и с этим неминуемо придётся разбираться.
Слова "датацентричность" и "моделе-ориентированность" обычно произносятся не сами по себе, а как основная характеристика или принцип построения архитектуры корпоративной или инженерной информационной системы. Тем самым это характеристики того, функция (назначение, поведение) системы в надсистеме реализуется конструкцией целевой системы. Оставим пока в стороне длинную дискуссию про структуру, механизм, конструкцию, процесс, материал и всё прочие возможные различения в том, что реализует функцию и я назвал пока просто "конструкцией". Можно обсуждать и проще: функция -- это "система как чёрный ящик", а всё остальное -- "белый ящик". Датацентричность и моделеориентированность -- это, конечно, про белый ящик. Но так же, как реализация функции "землеройное устройство" зависит от выбранного пути конструкторского решения (лопата или экскаватор), которое в свою очередь переопределяет функцию (у лопаты и экскаватора де-факто получаются разные функции), так и датацентричность и моделеориентированность относятся к таким архитектурным принципам/характеристикам, которые переопределяют функции систем с принципами/характеристиками документо-центричности и документо-ориентированности.
"Датацентрическая архитектура" (data-centric architecture), противопоставляемая "документо-центричной архитектуре" -- это указание на то, что система строится на основе приоритета разбирательства с данными, и подчиненной роли информационных объектов (различение информации, данных и информационных объектов -- http://ailev.livejournal.com/908102.html). В датацентрических архитектурах обсуждаются учётные проблемы (раскладка "оригинальных" данных по информационным объектам, находящимся под разным администрированием, а также проблемы, возникающие при управлении конфигурацией данных -- трассировка изменений в данных к изменениям в информационных объектах).
"Моделе-ориентированная архитектура" (model-based architecture) в противопоставление "документо-ориентированной" -- это указание на то, что функция информационной системы реализуется на основе понимания моделей как данных (т.е. абстрактных сущностей), а не на основе поддержки только отображающих эти модели конкретных документов (информационных объектов). В моделеориентированных архитектурах обсуждается полнота отражения информации об объекте в данных (так, 3D информация плохо представима в растровых форматах, хотя именно растровые форматы удобны для их презентации на дисплеях и бумаге).
Конечно, два предыдущих абзаца определений сами по себе совершенно непонятны и недостаточны. Эта непонятность, увы, не только в их краткости, но и в предполагаемой этими формулировками смене мыслительных парадигм:
-- в датацентричности это учётная парадигма (см. также "вопрошание об учёте", http://ailev.livejournal.com/593013.html), меняющая собой парадигму документирования. Учёт подразумевает позицию регистратора данных, полномочия по регистрации данных, реестры, формирование выписок и т.д.. Документирование всего этого не предусматривает, там просто составляются и передаются документы -- информационные объекты. Переход от "банков документов" к "базам данных" как раз представляет собой сдвиг в сторону датацентричности. Датацентричность -- это даталогическое обсуждение, где важны данные сами по себе (их сбор, хранение, маршрутизация заинтересованным сторонам и т.д.). Содержание данных в датацентричности обсуждается только по сопричастности.
-- в моделе-ориентированности это знаниевая парадигма (аккуратное представление информации данными, отображение возможно только после специальной обработки этих данных для целей представления человеку) против парадигмы документа-как-изображения-для-человека. Подробное разбирательство с моделями данных (например, отдельное хранение имени, отчества и фамилии в базе данных; хранение аннотированных разнообразными атрибутами 3D параметрических моделей в САПР вместо хранения растровых или даже векторных "картинок") представляет собой сдвиг в сторону моделеориентированности. В моделе-ориентированности обсуждение инфологическое: обсуждается адекватность представления информации в данных, но вопросы самих учёта самих данных (сбора, хранения, маршрутизации и т.д.) обсуждаются только по сопричастности.
Путаница появляется в том числе и оттого, что как датацентричность, так и моделе-ориентированность связаны с различными группами описания работы с данными (датацентричность -- как данные раскладываются по информационным объектам, т.е. носителям данных; моделецентричность -- какие именно данные доступны для учёта). И оба этих аспекта (знаний и учёта) противопоставляются простейшим формам работы с документами (где учитываются сами документы, а не данные в них; документы предназначены только для предъявления человеку, поэтому не содержат машинно-читаемых знаний). Важно учитывать оба сдвига парадигмы (учётный/даталогический и знаниевый/инфологический), а не только один. Так, переход к структурированным документам -- это только половина дела. Переход к навороченным (на сегодня чаще всего -- уже объект-ориентированным, а не реляционным) базам данных -- это тоже половина дела.
Вот примеры проблем, которые решаются в рамках перехода к датацентричности:
-- как передать оригинал модели? Так, при проектировании в SP3D содержится полная 3D модель (но только в последней версии!), в SPF уже передаётся неполная модель (.vue файл) и информация о версии модели имеется не для 3D модели, а только для "модели для просмотра". В архив же уходят не модели, а полученные из модели двумерные чертежи. В ситуациях передачи модели другим проектировщикам, восстановление истории (в том числе откаты к предыдущим версиям, или восстановление конфигурации), работа с вариантами дизайна и т.д. возникают огромные проблемы. Нет проблем с учётом в части архивного хранения "выписок из модели" (полученных двумя разными огрублениями -- переход от полного 3D представления к просмотровому .vue, и параллельно вывод в архивные чертежи), но ничего содержательного без перехода к датацентричности (т.е. решения вопроса об учёте оригинальной модели системы в SP3D, а не разных выписок из этой модели в других информационных системах) с этими документами делать нельзя. Есть также проблема с "утверждениями": утверждается "фотография" (выписка), а не то, с чего сделана фотография (исходная база данных) -- но утвержденная фотография оказывается главней оригинала, который никем не утверждается и продолжает оставаться "рабочим"! Если возникает проблема "объекту нужно сбрить усы", то нельзя гарантировать, что вместо сбривания усов не будет подретуширована фотография (т.е. данные исходной базы и утвержденных выписок из неё совпадут).
-- data handover со стадии на стадию. Ежели передавать документы, то совершенно непонятно, как работать с изменениями: в документах коллизии не проверишь. Ежели базу данных, то какую из многочисленных?
-- нужно ли "физически" собирать все данные разных САПР в какой-то одной PLM для поиска коллизий, или возможно организовать распределенную разработку? Какова архитектура информационной системы разработки, обеспечивающей принципиальный (логический, абстрактный) сбор правильной конфигурации системы для поиска коллизий или в виде проектного базиса?
-- практика управления информацией в ISO 15288 обеспечивает, чтобы данные были доступны тем заинтересованным сторонам, которым они нужны, и тогда, когда они нужны. Как это обеспечить технологически, ежели эти данные уже где-то находятся, а все информационные системы в предприятии находятся под разным администрированием?
Итого: датацентричность нужна, чтобы обеспечить управление конфигурацией информационной модели сложного технического объекта, а также управление информацией. Нет датацентричности -- нельзя быть уверенным в правильности конфигурации общей информационной модели инженерного объекта и возможности получить даже имеющуюся информацию для ее машинной обработки или другого использования.
Вот примеры проблем, которые решаются в рамках перехода к моделе-ориентированности:
-- действительно ли нужно использовать просмотровые форматы в PLM, или нужно передавать оригинальные модели с сохранением всей информации?
-- совместимы ли используемые модели данных (интеграция данных разных САПР) при попытках собрать общую непротиворечивую модель инженерного объекта?
-- можем ли мы обеспечить "подъем в цифру" бумажных чертежей? При этом речь идет не о сканировании (это бы обсуждалось как маленький шажок к датацентричности, смена вида носителя для "картинки" с бумаги на растровый файл), а "распознавании" -- то есть представление в виде атрибутированной 3D-модели с привязкой к другим моделям (например, P&ID).
-- какие виды коллизий мы можем проверить, имея тот или иной вид данных? Какие данные нужно собрать и хранить, как обеспечить связанность этих данных между собой, чтобы проверка коллизий была возможна?
-- какие виды моделей (технологические/процессные -- P&ID, 3D, финансовые, графики работ, органиграммы и т.д.) должны быть разработаны в инженерном проекте, и какие должны быть модели данных (метамодели) этих моделей?
-- какое программное обеспечение должно быть выбрано, чтобы поддержать работу с необходимыми моделями (например, САПР должен поддерживать 3D моделирование, а не 2D).
-- какое имитационное моделирование можно выполнить с использованием данных модели? Какие программы имитационного моделирования (коды) поймут данные модели?
Итого: моделецентричность нужна, чтобы как можно более аккуратно представить инженерный объект в компьютере, получить его точную модель. И на этой модели можно проверить коллизии, использовать данные этой модели для порождающего проектирования. Нет моделецентричности -- и компьютер будет бесполезен для обработки инженерной информации, придётся полагаться только на голову -- и мириться при этом с неизбежными ошибками и низкой производительностью умственного труда.
А теперь повторюсь: это два парадигмальных сдвига. Так что не думайте, что быстро разберётесь, даже если всё написанное тут кажется очевидным и понятным. Но и не надейтесь, что эти проблемы обойдут стороной: датацентричность и моделе-ориентированность представляют сейчас основной архитектурный тренд в инженерных и корпоративных информационных системах, и с этим неминуемо придётся разбираться.