Время понимать

В статьях, посвященных применению XML в конкретных приложениях, одинаковое понимание, одинаковая трактовка информации разными субъектами (людьми и компьютерами) называется важнейшим условием успеха. А наибольшим риском — то, что это условие может и не быть достигнуто. Попробуем хотя бы частично ответить на вопросы: какова оценка этого риска? каковы его корни? есть ли российская специфика? каков должен быть план действий?

Евгений Захарович Зиндер — директор аналитического и конструкторского бюро «Группа 24», шеф-консультант журнала «Директору информационной службы». Ему можно написать по адресу: ezinder@osp.ru

Обратите также внимание еще на одно «знаковое» явление: компании стали сообщать о наличии в своих штатах новых специалистов — онтологов. Вы могли прочесть (Ив Энштейн, «Роль слова в электронной коммерции», Computerworld Россия № 22 за 2000 год), что их имеют и всемирно известная Yahoo!, и менее знакомая Requisit Technology. Онтология раньше считалась чисто академической дисциплиной, а теперь онтологи работают над построением систем понятий, описывающих нужную предметную область, то есть над построением понятийных моделей. Эти модели создают основу для того, чтобы, например, в системах B2C и B2B обменивающиеся информацией стороны могли правильно понимать друг друга.

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

Понятийные модели

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

Для содержательной обработки сообщений в человеко-машинных системах понятия должны быть описаны на более формальном уровне. Вот три способа формализации.

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

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

Третий способ объединяет все возможности первых двух.

Заметим, что выбор конкретного формального языка во многих отношениях является вторичным.

Из личного опыта

Со второй половины 80-х годов мне с коллегами неоднократно приходилось разрабатывать компоненты понятийных моделей — как для деловых систем, так и в исследовательских целях. Применялись различные «носители» моделей — от баз языка Prolog до таблиц Excel. Все это использовалось для решения самых разных задач — от обнаружения смысловых коллизий в требованиях пользователей к интегрированной базе данных до создания разделов корпоративного тезауруса, который должен был бы играть объединяющую роль для сотрудников большой организации.

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

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

Опыт исследователей

Все эти годы понятийными моделями занимались многие исследователи. Какие же успехи в их применении достигнуты, например, в научной и конструкторской деятельности? И как они соотносятся со стандартизацией словарей для XML-систем?

Обратимся к системе Ontolingua, разработанной в начале 90-х годов в Стэнфордском университете. В этой системе понятийная модель представляется в виде «онтологии», здесь под этим словом понимается (упрощенно) набор декларативных описаний связанных понятий на формальном языке. Каждое заинтересованное сообщество профессионалов строит свою онтологию и помещает ее на Ontology Server (www-ksl-svc.stanford.edu) для общего использования в WWW. (Подробности см. на www.ksl.stanford.edu. Есть публикации наших авторов по данной теме, см. статью Е. М. Бенеаминова и Д. М. Болдиной в журнале НТИ за этот год, издательство ВИНИТИ.) К самым серьезным проектам, ведущимся на основе онтологий, причисляют: CommerseNet, The Enterprise Project, The InterMed Project, The Trial Bank, Accounting Information System и другие. Из названий видно, что темы проектов прямо соотносятся с задачами предприятий.

Возникает вопрос: если на основе этой системы отработаны технология, конкретные представления декларативных знаний (словари XML являются их аналогом) и их интерпретации в интересах задач разных пользователей, если эти работы начались задолго до появления XML, то почему не произошло более широкое если не распространение Ontolingua, то хотя бы применение уже отлаженных и отработанных понятийных моделей?

Конечно, имеет значение, что язык Ontolingua на уровне непосредственного представления по своему синтаксису сложен для таких специалистов, как бизнес-аналитик или «онтолог«. Но, казалось бы, можно рассчитывать на обычный прием: создание графических оболочек этого языка и их применение для составления онтологий и их отладки! Конечно, система Ontolingua в первую очередь рассчитана на научных сотрудников. Но не зря на ней выполняются очень приземленные проекты бизнес-характера (см. выше). И по всей видимости, она изначально и лучше приспособлена для обсуждаемых целей, чем XML. Очевидно, дело еще и в чем-то другом. На мой взгляд, это другое — сложность самих моделей и вообще фактор сложности как таковой.

Что изменилось с появлением XML?

Признано, что широкое распространение сначала HTML, а затем XML обусловлено их простотой.

Простота — великое дело, ведь люди постоянно наталкиваются на преграду сложности. Во всех областях существует разрыв между высокой степенью сложности многих проблем и объективно скромной способностью людей преодолевать высокую сложность. Причем в больших системах эту преграду создает уже только количественная (число элементов и их разнообразие) и структурная (взаимосвязи элементов) сложность. А если к этому добавить сложность логических зависимостей и изменчивость модели!

Теперь учтем, что на HTML до сих пор описывались достаточно простые модели документов, Web-страничек, электронных сообщений. А понятийные модели для XML (описания метаданных — словари, DTD) начали строиться совсем недавно.

Думаю, что XML очень прост только до тех пор, пока с его помощью решаются простые задачи. А точнее — простые куски очень сложных задач. Их потенциальная сложность определяется:

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

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

Поэтому успех XML на первом этапе объясняется появлением для широкой массы разработчиков новых возможностей быстро расширить «зону охвата» средствами своих страничек, баз и XML-серверов. Предлагаемые на этом этапе словари не очень велики и не интегрированы, решаемые с помощью XML задачи достаточно просты. Это — своего рода очередной успех «лоскутного» подхода при появлении более удобного инструмента разработки. Правда, теперь этот подход проник в область совместной деятельности многих предприятий.

Продолжение следует

На втором этапе (почти все говорят о том, что он наступит через два-три года) участники процесса вплотную приблизятся к «ватной стене» фактора сложности. Он проявится в том, что:

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

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

В связи с этим вспомним проекты реинжиниринга бизнес-процессов, основанные на значительном обновлении способов работы, включая взаимодействия с партнерами. Такие периодические обновления (а необходимость в них не исчезнет) будут неизбежно затруднены при строгом следовании стандартам словарей XML. И наоборот, при выполнении BPR-проекта интерпретация элементов «код детали» или «категория заказа» на предприятии может меняться вне зависимости от того, что содержит по этому поводу стандартный XML-словарь.

Я специально ограничиваю рассмотрение и не говорю, например, про особые сложности межотраслевых и междисциплинарных связей. Но надо упомянуть дополнительные смысловые коллизии, которые появляются при сравнении, казалось бы, одних и тех же понятий, но представленных терминами разных естественных языков. Вот чисто символический пример: сравните объемы понятий бизнес (российский) и business (американский). Что уж говорить про одноименные понятия, объем и вся трактовка которых зависит от особенностей местного законодательства (например, налогового)! Так что прямое использование «американских» DTD будет нести не только пользу, но и много скрытых угроз.

Линия поведения

Что же делать — ждать у моря погоды? Конечно, нет. Просто предстоящие трудности надо знать, и, хладнокровно их учитывая, приступать к составлению, покупке (получению) и изучению понятийных моделей для своего предприятия, шаг за шагом осваивая новые области и разделы.

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

1) Начинайте формировать понятийную модель для своего предприятия, максимально близкую к наиболее подходящим вам общим моделям (обращаясь, например, к результатам RosettaNet, но не забывая сказанное выше про «национальные особенности DTD»). Используйте для этой работы не только программистов, но и технологов-постановщиков, бизнес-аналитиков, лингвистов и даже «онтологов».

2) Вместе с тем вовсе не нужно связывать составление такой модели только с XML-проектом. Если вы используете FTP-обмены, если вы хотите «просто навести элементарный порядок» внутри предприятия (в головах, в автоматизированной системе, в бумажных документах), составьте понятийную модель терминов в виде традиционного толкового словаря своей организации или «корпоративного глоссария», как теперь часто говорят. В полном объеме такой глоссарий велик, поэтому начните с того раздела, который окажется наиболее необходим для использования (как основа для НСИ, для подсказок оперативной помощи в системе или даже для составления должностных инструкций).

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

4) Учтите, что пункты 2 и 3 в равной мере относятся и к словарям XML, и к ведению баз данных, и к организации EDI-обменов, недаром качественное управление проектом создания системы требует с первых его шагов составления глоссария проекта (а многие ли из нас делают это всерьез?!). Ориентируйтесь на то, что именно понятийная модель является тем минимальным интегрирующим слоем, который необходим для соединения отдельных компьютерных «островков» в систему предприятия.

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

6) Переходите к составлению минимальных по объему понятийных моделей, общих для вашего предприятия и предприятий-партнеров, но только в той части, которая нужна в актуальных сегодня задачах, решаемых в интересах совместной деятельности (будь то старая кооперация предприятий, новомодная B2B или что-то существующее под другой кличкой). Для того чтобы лоскутность такой деятельности была под контролем, используйте рекомендацию № 1. Берите на себя инициативу составления такой модели, но вовлекайте в работу и партнеров, используйте их опыт и наработки. Успех здесь может быть только общим.

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