Брюс Силвер
президент Ассоциации Брюса Силвера. С ним можно связаться по e-mail: bruce@brsilver.com

Можно ли управлять документами с таким же уровнем автоматизации и легкостью, как это происходит с управлением данными? Оправдывает ли себя структурированный подход? Заглянем в будущее управления контентом.

Еще недавно информацию удавалось легко и четко разделить на данные и контент. Данные - это "структурированная" информация, хранящаяся в реляционных базах данных, OLTP-системах и других иерархических решениях. Контент был "неструктурирован" и состоял... ну, в общем, в эту категорию попадала вся остальная информация. Данные обеспечивали нормальную работу компании, поэтому базы данных стали стратегической составляющей корпоративной ИТ-инфраструктуры. Все остальное - по крайней мере часть, поддающаяся управлению, - размещалось в специализированных хранилищах, развертываемых на уровне отделов и получивших название системы управления контентом.

Сегодня компании стремятся обеспечить согласование и синхронизацию всех печатных и Web-документов, бизнес-контекста отношений внутри компании, с партнерами и клиентами, а также синхронизацию между географически распределенными филиалами (а значит, согласование документации на различных языках). Иначе говоря, они стремятся управлять контентом практически как данными. Это означает, что контент должен обеспечивать беспроблемное повторное использование, динамический поиск и перестройку в соответствии с нестандартными требованиями и преобразование в любой формат представления, а также поддаваться "обработке" прикладным ПО. Осознанно или нет, но компании стремятся к контенту, выраженному и управляемому как XML.

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

Границы размываются

Несмотря на несколько волн консолидации в ИТ-отрасли управление контентом так и осталось стоять особняком, отдельно от управления данными, отвергая все попытки ведущих производителей СУБД включить контент в базы данных. А причина в том, что между данными и контентом существуют фундаментальные различия. Данные структурированы и "самоописательны" (у записей и полей есть четко определенные названия, типы и связи), и поэтому легко поддаются машинной обработке. Универсальный язык SQL позволяет запрашивать данные и получать результат с любым уровнем детализации - от целой таблицы до отдельного поля. Визуальное представление данных в виде таблиц в отчетах, диаграмм и прочего остаются задачей приложения, мало связанной с самими данными. Данные - это информация в чистом виде.

С другой стороны, в контенте нет четкого деления между текстовой информацией и форматом представления, определенным приложениями, такими как Microsoft Word, Adobe Acrobat или HTML-редакторы. Объекты контента - это информационные представления, оптимизированные для человеческого (а не машинного) восприятия и обработки. Единицей поиска является документ или файл. При поиске контента даже по таким крошечным фрагментам информации, как отдельное слово или символ, вы получаете список документов, а не фрагментов.

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

Так в чем же загвоздка? По сравнению с данными контент обладает рядом недостатков: его сложно использовать повторно, процедура поиска очень громоздка, и вообще он мало поддается автоматизированной обработке. Чтобы пересобрать фрагменты контента в соответствии с новым "контекстом" (например, используя в качестве источника разные документы - от финансовых отчетов до пресс-релизов), придется выбрать все фрагменты из соответствующих исходных документов, собрать их и переформатировать. Поскольку контент управляется на уровне документов и неразрывно связан с форматом представления, значительная часть обработки контента выполняется вручную и малоэффективна.

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

Вы удивитесь, но есть универсальный ответ на этот вопрос - XML.

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

Простого именования элементов информации в документах недостаточно. XML позволяет обращаться к контенту на уровне элементов - вплоть до отдельного слова или числа, а не только на уровне целых документов. Например, заголовок документа может идентифицироваться XML-тэгом в самом контенте. В отличие от неструктурированного контента XML-запросы органично сочетают текстовый поиск и строгость SQL. Более того, XML избавляет от необходимости поддерживать популярные сегодня в системах управления контентом частные механизмы поиска - в XML-запросах используются стандартные языки, в том числе XPATH, XSLT и XQUERY. Способна ли ваша система управления контентом найти все документы, принадлежащие перу Джона Доу, изданные между 2002 и 2004 г., содержащие слово "XML" в первом абзаце, и вернуть только первые абзацы? При наличии XML-контента задача упрощается донельзя, потому как поиск с подобной степенью детализации поддерживают XPATH и XQUERY.

Структура XML-документа - имена, разрешенный порядок и тип данных элементов, выделенных тэгами, - определена в отдельном документе. Эта схема или определение DTD (Document Type Definition) представляет собой стандартный шаблон для данного типа документов. В нем могут быть карты преобразования (тоже на стандартном языке XSLT) для автоматического преобразования XML в любой другой формат представления - HTML, Word, PDF и т. п. В отличие от обычного контента, в котором текстовую информацию приходится извлекать из Word, PDF и других прикладных форматов, XML-контент представляет собой чистый текст. Все форматы представления получаются из единого XML-источника путем применения нужной XSLT-таблицы стилей.

Новая экономика на основе XML-контента

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

1. XML позволяет повторно использовать контент. Присущая XML модульность и структура делают его особо ценным, когда требуется повторное использование. В отличие от более ранних технологий структуризации контента на основе SGML (Standard Generalized Markup Language), XML широко поддерживается производителями господствующих платформ, приложений и инструментов. XML-контент можно создавать в приложениях Microsoft Office, просматривать в Web-браузере (при наличии таблицы стилей) и преобразовывать в формат любого сервера приложений или основных СУБД.

Возможность повторно использовать контент единственного источника позволяет значительно сокращать издержки и производственные циклы. Причем речь идет не только о множестве каналов поставки информации, в числе которых Web, печать и радио, но и о множестве бизнес-контекстов: это предложения, контракты, спецификации и пресс-релизы. XML идеально подходит для такого контента, как инструкции и руководства, которые требуют перевода на многие языки. Если меняются отдельные элементы или подразделы XML-инструкции, достаточно перевести только обновленные компоненты и повторно собрать документ, не создавая его с нуля. XML-технология позволила компании Siemens Building Technologies Siemens увеличить производство специализированных технических документов на 40%, снизив при этом производственные издержки на 30% (см. врезку). Специалисты исследовательско-консалтинговой компании Common Sense Advisory утверждают, что повторное использование контента позволяет уменьшить объем переводов на 70% и сократить время вывода продукта на рынок.

2. Максимизация ценности активов. Одно время "многоканальная поставка" означала просто синхронизацию информации среди различных форматов носителей, но сегодня это может также означать модификацию в соответствии с потребностями целевой аудитории. Для владельцев контента XML означает простоту и легкость сбора и повторного использования информации, а также специализированное создание новых форм контента для получения дополнительного дохода. Так, научно-техническое издательство Elsevier Science использует специализированный сервер XML-контента для агрегирования и реформатирования частного контента в зависимости от целевой аудитории и требуемых форм поставки.

3. Контент поддается машинной обработке. Контент, получивший вполне определенную структуру, может обрабатываться не только человеком, но и компьютером. Таким образом, ручные операции можно автоматизировать. Информация уровня отдельных элементов может извлекаться из отчетов, проверяться на соответствие бизнес-правилам, агрегироваться, использоваться для создания диаграмм и автоматически пересобираться - точно так же как данные. Ключ к успеху - доступ с высокой степенью детализации.

4. Соответствие требованиям регулирующих органов. Побочный результат всех описанных выше преимуществ заключается в том, что XML все чаще упоминается в отраслевых стандартах и требованиях государственных регулирующих органов. За примерами далеко ходить не надо: специализированные XML-словари, такие как XML Business Reporting Language (XBRL) для финансовой отрасли, модернизированная программа eFile налоговой службы США для представления налоговых деклараций в формате XML и стандарт Clinical Document Architecture (CDA) института HL7. Американское управление по контролю продуктов и лекарств (FDA) находится в процессе принятия Structured Product Labeling (SPL), основанного на CDA стандарта описания лекарств.

XML и системы управления контентом

Позволят ли XML-контенту все перечисленные преимущества получить повсеместное распространение и революционизировать инфраструктуру управления контентом? На это потребуется время.

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

Вторая загвоздка в том, что формат XML плохо подходит для написания контента. Чтобы добиться повторного использования контента, компаниям, первым перешедшим на XML, пришлось переключиться на специализированные средства создания XML.

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

В мире управления Web-контентом хорошо известна возможность "автоматической разметки тэгами" документов Microsoft Office и HTML на основании стилевой разметки заголовков и с использованием эвристических методов, то есть скрытое превращение обычного контента в XML. Эта возможность позволила бы поставщикам решений по управлению контентом решить эту проблему... если бы они действительно хотели ускорить XML-революцию. Но они не хотят.

По большей части поставщики решений по управлению контентом рассматривают XML как еще один специальный тип контента, мало чем отличающийся от электронной почты, Web-контента или мультимедиа, который надо обрабатывать в соответствии с нуждами определенного прикладного сегмента, и не считают XML фундаментальной революцией в области контента. Точно так же начинающие поставщики серверов XML-контента, не переставая прославлять возможности доступных в современном XML-хранилище динамических запросов и повторной сборки, какое-то время, по-видимому, будут довольствоваться ростом сегмента динамической публикации. Они пока не готовы или не достигли достаточного размера, чтобы "по-крупному" заняться всем разнообразием корпоративного управления контентом.

***

Так все-таки: в более далекой перспективе управление контентом почти как данными будет узкоспециализированным или широкомасштабным требованием? Не забывайте, что технология управления контентом не родилась в рутине офисной работы, а "спустилась" из масштабных вертикальных приложений, таких как система подачи данных о новых медикаментах в FDA. В подобных приложениях целые отрасли быстро принимали стандарты, предоставленные поставщиками решений для управления контентом, из-за чего и возникли современные гранды этого рынка.

Позволят ли XML его преимущества, в числе которых повторное использование, автоматизация и соответствие стандартам, стать общепринятой формой представления исходного контента? Сейчас ведется активная работа над XML-решениями для финансов, фармацевтики и других отраслей, но на то, чтобы технология вышла из тени узкоспециализированного применения, могут потребоваться годы. "Если спросить обычных, нетехнических фармацевтов, что они используют для создания XML-документов, они посмотрят на вас непонимающими глазами", - говорит консультант по фармацевтической отрасли Гарри Фишер. По его мнению, в рамках всей отрасли консенсус относительно того, как должен выглядеть набор приложений для управления XML-контентом, будет достигнут не ранее чем через пять лет, "но пока никто не знает, как это все будет выглядеть".

65 тыс. способов повторного использования контента

Как и другие производители, Siemens Building Technologies предлагает тысячи печатных и онлайновых документов, которые помогают служащим, партнерам по бизнесу и клиентам устанавливать, эксплуатировать, обслуживать и устранять неполадки продуктов компании (системы централизованного управления и контроля отопления, кондиционирования, противопожарной безопасности и т.д.). Оборудование Siemens способно взаимодействовать с тысячами типов и наименований климатических систем и систем безопасности, поэтому документация должна описывать тысячи возможных комбинаций оборудования и программных драйверов.

До принятия компонентного подхода к публикации, основанного на XML, отдел интеграционных решений компании с трудом справлялся со своевременным выпуском менее 200 документов по поддержке в год, используя Microsoft Word в качестве основного инструмента создания документации. В отсутствие компонентноориентированного подхода контент практически не использовался повторно, не говоря уже о жуткой его несогласованности.

"В нашем отделе несколько отдельных групп, в каждой из которых разрабатывают контент так, как считают нужным, - говорит менеджер проекта Кристин Роделл. - А в отделе обучения жаловались на то, что в наших документах много противоречий. В одном комплекте документов был раздел по, скажем, установке драйверов для оборудования стороннего поставщика, а в другом комплекте он мог просто отсутствовать. Пользователи недоумевали: установка не нужна, или авторы забыли дописать соответствующий раздел?"

Но важнее то, что "бутылочное горлышко" производства контента ограничивало число систем, которые компания могла поддерживать, а это, в свою очередь, ограничивало возможности сбыта. На момент развертывания отдела в октябре 2002 года в нем внедрили Epic Editor, среду написания XML-котента от компании ArborText, и средство управления контентом Documentum (теперь EMC Documentum), но, как признается Роделл, способ развертывания систем был "далек от совершенства".

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

Число выпускаемых документов устойчиво росло, увеличившись почти в четыре раза - до 722 единиц, выпущенных или обновленных в прошлом году. И это притом, что состав основной группы писателей сократился (за счет "естественной убыли") с шести сотрудников на полной ставке в 2001 до эффективной занятости 3,75 "полных ставок" в 2004 году. Чтобы гарантировать согласованность документации, в группе Роделл создали 19 базовых XML-шаблонов, на основании которых создавались все документы. Еще интереснее другое - в отделе обнаружили, что подобные перемены позволили повторно использовать 3500 "кусочков" контента (описаний продуктов, спецификаций изделий других производителей и графических элементов) в, по крайней мере, 65 тыс. мест. Теперь при создании или обновлении одного-единственного элемента контента автоматически обновляются в среднем более 18 экземпляров этого элемента в документах самых различных типов.

Роделл отказывается озвучить расходы Siemens на этот проект, но говорит: "Я уверена, что мы с лихвой окупили затраты, потому что теперь точно знаем, сколько времени сотрудники тратят на каждый проект. (А ведь их время оплачивается по ставке 85 долл. в час. - Прим. автора.) Мы сократили затраты рабочего времени и улучшили согласованность, а если мы можем сделать больше за меньшее время, значит, мы в состоянии продать больше наших продуктов".