ttfna в треде http://ailev.livejournal.com/965124.html?thread=9717252#t9717252 к моему постингу про четыре поколения перехода от документ-центричности к датацентричности. Получилось много, и в коммент не поместилось. Собственно, я всё это уже в разное время у себя в ЖЖ писал -- разве что разноски по поколениям не делал.1. Многие современные как гибридные, так и датацентричные PLM (системы product lifecycle management) используют всё то же самое, что ECM (enterprise content management), по факту используемые в крутой документоцентрике -- наличие "объектов" в них не является критерием отличия. Я бы сравнивал современные ECM с более ранними PDM (product data management) системами, где самое важное было как-то управляться с многочисленными файлами разной природы -- понимая при этом, что физическое представление "файла" не так важно, как его "объектная" сущность и поэтому собственно работа ведется с "карточками" этих файлов -- а сами эти карточки вполне себе "объекты".
2. Как в ECM и PDM, любые современные PLM имеют какой-нибудь item с атрибутами и associations/relations этих items в основе, поддерживающая наследование и прочие прелести объект-атрибутной модели. Никакой предметной области нет, кроме просто развитой работы с данными. Эта объект-атрибутная модель опирается на какую-нибудь реляционку под ними -- все они "нашлёпки" над каким-нибудь Ораклом.
3. Но далее в PLM уже над items строится некоторая (у кого более богатая, у кого менее богатая) онтология, которая подразумевает мэппинг структур данных на объекты реального мира: фишка не в том, что довольно быстро в этой модели мира мы выходим на "оборудование", важное для PLM, а в том, что сама эта модель мира начинается с thing (почувствуйте разницу с item!) и принципиально расширяема в этой описывающей мир, а не описывающей структуры данных части -- причем "из коробки". В отличие от ECM настройка на предметную область производится не только разработчиками "плагинов" (это тоже есть), но и предварительно в PLM существует уже некоторая связная модель инженерного мира.
4. В этих PLM опять же "из коробки" даны слитые воедино модели данных/онтологии разнопредментых authoring tools, это нормальный стиль. Эти разные модели данных принципиально сливаются в одну модель данных, что гарантируется общей онтологией, а не общей схемой данных из items и relations.
5. Эта архитектура была выработана после того, как выяснилось, что работа с plugins как в ECM (это было в ходе разработки стандарта STEP, закончившейся не "единым языком инжиниринга", как предполагалось, а кучей application protocols для разных предметных областей) не гарантирует, что модели данных всех эти plugins сольются в одно красивое целое -- если при этом не основывать все эти предметные модели данных на беспредметной общемировой (еще раз повторюсь: "беспредметная модель данных" моделирует мир -- вещи, время, пространство, отношения, свойства, атомы, молекулы, живое-неживое и т.д., что нельзя путать с абсолютно другой природы айтемами, записями, атрибутами, объектами и прочими формализмами данных).
6. Конечно, уже начинаются интересные примеры, как из разных ECM пытаются делать PLM: для этого берут огромного размера рашпиль и доводят более-менее удачную ECM до состояния PLM -- например, это произошло с MatrixOne и Enterprise Bridge после их приобретения разработчиками САПР. Но это переход в уже другой класс систем, и фишка в существенной доработке модели данных -- т.е. огромный объем программирования как раз в терминах этих айтемов и записей, но этот объем программирования выполняется еще до всяких там "плагинов", как раз для того, чтобы потом данные самых разных заранее даже неизвестных еще плагинов слились в одну информационную модель. Это совсем другой стиль, нежели обычная работа с плагинами в ECM.
7. Именно необходимость объединять данные разных предметных областей и authoring tools ставит запрет на использование объект-атрибутной модели: что для одного authoring tool объект, для другого authoring tool атрибут. Отсюда и переход к факт-ориентированной модели, в которой все те же фрагменты мира выражаются в формализме классов (теории множеств), а не в субстанциональной аристотелевской парадигме объектов-свойств.
8. Люди из мира PLM, естественно, знают про происходящее в мире ECM, идиотов-то сейчас нет. Другое дело, что они когда-то сами таким занимались -- но ввиду много бОльшей сложности их задач они пошли дальше.
9. Масла в огонь подливает то, что ECM и связанный с ними MDM обычно внутрикорпоративны, а вот для PLM обычно данные и справочные данные должны быть отраслевыми -- проекты выходят далеко за границы любой инжиниринговой компании, и с самого начала архитектура и способы работы должны поддерживать работу комьюнити. Именно поэтому ISO 15926 сразу подразумевает для интеграции данных использование федерации библиотек справочных данных, а не "корпоративное решение MDM".
10. Файл, конечно, не эпицентр современных ECM -- но так уж получается. То есть потенциально современные ECM могут быть использованы не как средства второго поколения (где главное -- это обеспечивать ссылки на файлы из паутины классификаторов), а средства третьего поколения (где главное -- это поддержание модели предметной области, из которой уже и идут ссылки на "первичку"). Но модели предметной области, где задействованы ECM получаются жидковаты. Мы в 1998 году затеяли разработку онтологического движка Communiware, это как раз была попытка сделать ECM с отрывом от файлов -- ибо мы целились на рынок интернетов и интранетов, где важны были не столько файлы, сколько статьи, постинги, комментарии, рубрики и прочие нехитрые предметные сущности. Мы сделали онтологический движок, и на нём нехитрую обобщенную модель того самого веб-контента. На этой совсем нехитрой модели всё и закончилось, ибо при выходе на хитрые модели потребовалось бы принимать абсолютно другие архитектурные и онтологические решения. На этом же заканчивается сейчас "семантик веб": множество нехитрых онтологических моделей отнюдь не слипаются в полноценную хитрую модель куска реальности. Финансовые модели мира -- при всём к ним уважении -- оказываются много менее хитрыми, нежели модели продукции, достаточные инженерам для производства. Инженерам потребовалось двадцать лет для осознания этого факта неслипания их моделей данных в ходе работы разных консорциумов и групп по стандартизации (прежде всего -- консорциума EPISTLE) и необходимости поэтому использования какой-то общей верхнеуровневой онтологии для разных authoring tools.
11. Итого: ECM обычно относятся ко второму поколению крутой датацентрики, ибо несмотря на всю их пригодность к вышиванию на них крестиком сложных моделей данных никто этого не делает. PLM как раз "из коробки" содержат весьма сложные схемы данных инжиниринга, и поэтому относятся к третьему (гибридному) и четвертому (датацентрическому) поколениям.
12. Я ожидаю, что пятое поколение -- это будет про федерацию датацентричных систем.