CMIS: управление контентом как сервис

ервые системы управления контентом предприятия (Enterprise Content Management, ECM) были нацелены на решение сложных проблем бизнеса с помощью сложных решений, но не предлагали пользователям универсальных инструментов для эффективного управления их контентом. Однако нигде необходимость интеграции данных не очевидна. Управление поиском подобий, стандартизация метаданных и рабочих потоков, безопасность и сохранность данных — вот краткий перечень областей, в которых предприятия на техническом уровне стремились связать управление контентом с бизнес-процессами.

Интеграция систем управления контентом

Появление любой новой категории ИТ-решений обычно связано с объявлением привлекательного для бизнеса функционала и обсуждением первых проектов. Однако жизнь затем неизбежно ставит новые сложные задачи. Особенно это болезненно для решений, претендующих на консолидацию разрозненных информационных ресурсов, доступных для повторного многократного использования всеми сотрудниками предприятия. Более того, инструментарий управления контентом характеризуется углубленной специализацией — управление документами (Document Management, DM), управление документами строгой отчетности (Records Management, RM), управление Web-контентом (Web Content Management, WCM), управление мультимедийным контентом (Digital Asset Management, DAM), контроль за соблюдением авторских прав (Digital Rights Management, DRM) и т.д. Напомним, что система документооборота обеспечивает коллективную работу с документами, часть из которых может попасть в другую категорию, став документами строгой отчетности, необходимыми для предоставления внешним организациям (налоговой инспекции, судебным органам, проверяющим инстанциям и т.п.). Для хранения и отслеживания жизненного цикла документов строгой отчетности требуется система, отличная от системы документооборота. Далеко не все производители предлагают полную номенклатуру такой функциональности, поэтому проблема интеграции (рис. 1) стоит как нельзя остро.

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

Внешняя интеграция

Интеграция с системами ERP/CRM

Многие производители систем ECM сосредоточили свое внимание на интеграции в рамках решений ERP/CRM, осознав, что их клиенты уже заняты интеграцией своих Web-приложений, обслуживающих заказы внешних покупателей, с внутренними приложениями, ответственными за инвентаризацию и платежи. Поэтому поставка интегрированных решений в составе систем Siebel, PeopleSoft и SAP выглядела вполне логичной и оказалась прибыльной. Однако такая интеграция оставила в стороне ключевой вопрос — как потребителям интегрировать системы ECM и ERP/CRM? Одни компании были озабочены проблемами выявления, анализа и прогнозирования предпочтений покупателей, что требовало интеграции Web-каталогов продуктов с CRM. Других волновала проблема ведения контрактов, что неминуемо приводило к интеграции документооборота и ERP. Таким образом, на плечах ИТ-специалистов предприятий и системных интеграторов по-прежнему лежит тяжелым грузом проблема интеграции.

Интеграция с инструментарием коллективной работы

Не менее важным, чем структурированный контент в ERP/CRM, потребители сегодня считают и неструктурированный контент, сосредоточенный в электронной почте и рабочих документах произвольного формата. Действительно, важный бизнес-контент, как правило, зарождается в инструментах обеспечения коллективной работы, а сохраняется в ECM. Любая инициатива компании начинается с письма по электронной почте, которое сразу может превратиться в документ строгой отчетности. Справочные материалы какого-либо сотрудника, родившиеся в виде некоего документа на диске его ноутбука, позднее попадают на хранение в корпоративную сеть и в систему документооборота. Производители в поисках полезных, но простых интеграционных решений не упустили возможности предложить интеграцию инструментов коллективной работы с системами ECM. И снова интеграция оказалась более жесткой, чем ожидалось. Поэтому, к примеру, в компаниях Documentum и Interwoven так заинтересованы в упрощенных технологиях «управления контентом для масс» (basic content services — «базовые контент-сервисы»). Даже корпорация Microsoft, чей вклад в разработку инструментария коллективной работы очевиден, не смогла пока занять достойное место на рынке ECM. И, как следствие, вновь поглощения  — Documentum приобретает eRoom, Microsoft поглощает nCompass; однако, это, как уже говорилось, не может дать немедленного эффекта.

Интеграция инфраструктуры

Успехи интеграции ECM-приложений с инфраструктурными программными компонентами обычно не сопровождаются рекламной шумихой, но от этого не становятся менее важными. Осмысленная интеграция ECM с чем бы то ни было должна начинаться именно с этого. Наиболее успешными точками интеграции здесь являются безопасность и управление правами доступа. Приложения ECM, на скорую руку интегрированные с каталогом Microsoft Active Directory, использующим сервис LDAP, могут привести в тупик, если попытаться усложнить политику управления доступом с использованием такого инструмента, как eTrust SiteMinder.

Интеграция на уровне платформы может оказаться не менее важной. Например, почти все реализации ECM содержат базу данных, и производители ECM, не обладающие собственными СУБД, вынуждены искать баланс между поддержкой достаточно большого числа форматов, но не столь большого, чтобы обременять себя тестированием всех новых приложений и сертификацией относительно всех этих баз данных. Кроме того, эти сертификаты мало что значат для работы приложений, когда используются такие развитые дополнения СУБД, как, например, Oracle Real Access Clusters.

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

Интеграция порталов

Порталы остаются последней надеждой в осуществлении простой интеграции разных систем, включая и ECM-приложения. Если весь интересующий сотрудника контент не может быть представлен на единственной Web-странице, то чем тогда может помочь интеграция?

Системы управления Web-контентом разрабатываются для генерации контента внутри порталов, которые, однако, испытывают те же проблемы (динамическая сборка, кэширование контента, его безопасность и т.п.), что и другие разновидности Web-присутствия. Более того, ценность контента определяет его привлекательность для потребителя. Если система ECM не может предоставлять нужный контент, то не пройдет фундаментального тестирования. Вместе с тем, порталы не должны быть простой мозаикой из несвязанного контента: именно интеграция контента делает их привлекательными, а интеграция приложений — полезными. Поскольку пользователи все больше тяготеют к выполнению на портале все большего числа приложений, то приложения эти, включая ECM, вынуждены исполняться на самом портале. Скажем, если страховой агент может создавать новую запись страхователя в портале, то почему бы не позволить этому агенту загружать документы непосредственно в систему документооборота?

Интеграция со средствами поддержки соответствия нормативным актам

Соблюдение требований нормативно-правовым актам стало важным для всего мира ИТ, и ECM не исключение. И здесь также интеграция важнее любых функциональных «наворотов». Так, «электронное обнаружение» (e-discovery) — то есть выявление и сбор контента, требующего юридического одобрения или предъявления исков — практически всегда выливается в проблему интеграции. Юридически значимый контент может находиться: в системе управления Web-контентом (как была представлена компания в конкретный день); в рабочем потоке (кто одобрил Web-контент для опубликования); в электронной почте (как проходило внутреннее согласование конкретного экземпляра контента) и т.д.

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

Стандарт CMIS

В сентябре 2008 года корпорации EMC, IBM и Microsoft объявили о начале совместного проекта по разработке спецификаций Content Management Interoperability Services (CMIS) на интерфейс Web-сервисов, призванных обеспечить взаимодействие между системами ECM. К этому трио для участия в разработке спецификаций присоединились компании Alfresco, Open Text, Oracle и SAP. В качестве главной цели было заявлено снижение затрат на создание среды управления контентом предприятия на базе нескольких репозиториев от разных производителей. Эти спецификации призваны также помочь независимым разработчикам при создании приложений, способных работать с несколькими системами управления контентом. Все названные компании подтвердили возможность взаимодействия их продуктов в рамках предложенного проекта спецификаций и приняли решение направить согласованный проект на одобрение в OASIS (Organization for the Advancement of Structured Information Standards).

Цели нового стандарта таковы:

• обеспечение работы новых приложений с имеющимися репозиториями и накопленным в них контентом;
• обеспечение независимого управления контентом разных репозиториев с помощью Web-сервисов;
• обеспечение общих Web-сервисов и интерфейсов Web 2.0 для упрощения разработки новых приложений;
• создание платформы, независимой от языковой принадлежности контента;
• поддержка разработки композитных приложений и «коллажей», то есть нового контента, составленного из контента нескольких источников и выглядящий как единое целое.

Общий замысел CMIS иллюстрирует рис. 2. Приложение Interoperable Content Application, взаимодействующее с контентом из разных репозиториев, может размещаться на любой платформе и осуществлять это взаимодействие с помощью сервисного интерфейса и специальной надстройки (CMIS Implementation), которая делается каждым участником CMIS для своих репозиториев самостоятельно.

Стандарт интересен в первую очередь крупным предприятиям, которые уже обзавелись несколькими репозиториями от разных производителей. Но если предположить, что репозитории разных организаций будут открыты для вашего приложения, то у вас появляются совершенно новые привлекательные для бизнеса возможности. Фактически это означает создание виртуальных хранилищ данных, а приложение может составить композитный документ, как результат поиска в нескольких репозиториях. Именно полноценный документ, а не ссылки на первоисточники. При этом нет необходимости отвлекаться на выполнение трудоемких процедур создания мастер-данных: этим может заниматься специализированная организация — владелец репозитория. В стандарте не говорится о том, что все репозитории должны принадлежать одной организации, отмечается лишь, что процедуры обслуживания репозитория каждого производителя остаются неизменными или изменяются каждым производителем с учетом наличия CMIS Implementation. Это позволит упростить и ускорить решение задач бизнес-анализа, но хотя стандарт и не решает всех проблем интеграции, он способен упростить ситуацию. С этой точки зрения стандарт может заинтересовать многие компании. Стандарт не предполагает «ломки старого» — существующие репозитории с их инфраструктурой управления накопленными данными остаются неизменными, а «аллергическая» реакция интерфейсов Java и Microsoft .Net устраняется с помощью надстроек CMIS Implementation.

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

Модель данных стандарта CMIS и сервисы не зависят от протокола, который используется для запуска сервиса. В настоящий момент поддерживаются протоколы как на базе SOAP, так и на базе REST. Впоследствии в стандарт могут быть включены и другие протоколы.

Споры вокруг пристрастия тому или иному стандарту программирования давно стали похож на споры тупо- и остроконечников. Основные производители решений для репозиториев это прекрасно понимают. Понятно также, что производителям репозиториев хочется «построить» всех независимых производителей программного обеспечения, ограничив их возможности базовыми сервисами репозиториев, которые любой из них должен предоставлять программисту. Поставит ли это ограничение производителя репозитория в привилегированное положение по сравнению с независимыми разработчиками? Возможно. Все зависит от перечня базовых сервисов и типов объектов. CMIS предполагает наличие сервисов, которые позволяют:

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

CMIS определяет четыре базовых типа объектов, которые могут присутствовать в любых репозиториях, хотя сами репозитории могут определять дополнительные типы объектов. Любой тип определяет схему свойств, которая назначается или предъявляется каждым конкретным объектом. Документы представляют собой индивидуальные экземпляры контента в репозитории, любой документ может включать или не включать в себя один поток контента. Папки представляют собой организационные контейнеры, в которых могут храниться документы или другие папки. Отношения — это связи между двумя объектами (документы или папки) в конкретном репозитории. Политики представляют собой наборы административных правил, которые могут быть применены к объектам.

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

Что будет в стандарте

Для отработки текста стандарта в OASIS создан технический комитет, который должен подготовить предложения по составу, назначению и содержанию проекта, взяв за основу текст, опубликованный корпорациями EMC, IBM и Microsoft 10 сентября 2008 года. Первоначальный набор решений охватит: приложения для коллективной работы с контентом; порталы, использующие репозитории управления контентом; коллажи; поиск в репозитории контента.

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

Чего в стандарте не будет

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

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

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

***

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