Недавно пришлось разбираться с одним, довольно старым приложением класса Enterprise Content Management. Возможно, что его следовало бы скорее отнести к классу систем Web Content Management, но учитывая, что использовалось оно внутри компании и пользователи считали, что хранят в нем документы, будем считать, что это ECM. Тем более что в этой системе отсутствовал традиционный функционал WCM такой как шаблоны отображения, расширения и т.п. Про теги и таксономии я и не говорю. В общем, система и система. Можно в неё файл приаттачить, а можно в визивиг редакторе web-страничку нарисовать, а затем, используя функцию поиска, что-нибудь в этой системе найти. Чем на протяжении нескольких лет и занимались редакторы и читатели контента соответственно.
Все было хорошо, пока система не стала искать документы слишком долго. Впрочем, это вполне характерно для такого класса систем. Естественно, были проведены некоторые упражнения по исправлению данной ситуации посредством переезда на новое железо, но через какое-то время и нового железа перестало хватать и проблемой пришлось заняться всерьез. Обычно, в таких случаях находится эксперт, который глубокомысленно заявляет, что проблема в архитектуре. И как только прозвучит эта фраза, сразу же зовут архитектора и говорят, что у него проблема. Конечно, архитектура системы и правда не внушала оптимизма, но настоящий культурный шок мы испытали, посмотрев на данные внутри системы. Дело в том, что большая часть этих данных была структурирована. Не частично структурирована, а структурирована полностью. Одни web-странички представляли из себя HTML-таблицы с описанием объектов и набора параметров в виде строки, другие списки свойств в формате «ключ-значение» в виде тех же HTML-таблиц. Были, правда и экранные формы, включающие несколько закладок, но на вопрос для чего это сделано кто-то мне ответил, что закладки нужны для больших документов, которые не помещаются на один экран, чтоб их было быстрее листать. Разумеется, вопрос известно ли пользователям назначение кнопок PgUp и PgDn я счел задавать неуместным. Одним словом, на протяжении многих лет пользователи вбивали в систему вполне структурированную информацию в виде HTML страниц или в разнообразных офисных форматах. Естественно, в какой-то момент искаться информация во всем этом массиве данных стала медленно. Ситуация существенно ухудшилась после реализации в системе невинной просьбы пользователей о реализации предиктивного поиска.
На самом деле, ситуация довольно типичная. Никто не будет структурировать информацию по собственной воле. Многолетний опыт создания документов в редакторе MS Word формирует соответствующий user experience. А бизнес-приложения, с драконовскими требованиями по обязательному заполнению всех полей в экранной форме отталкивают пользователей (Вспомните сколько раз даже на интернет ресурсах от вас требовали ввести ZIP code ). Тем более, что внесение даже небольших изменений в экранную форму и структуру данных, потребует привлечения программиста и может оказаться не быстрым и не бесплатным. Вот люди и создают «контент» из структурированных данных, а некоторые айтишники их в этом поддерживают. Тезис о том, что 80% корпоративной информации это неструктурированные данные известен практически всем.
О том, что это не так я уже писал в заметке Существуют ли непредсказуемые бизнес-процессы и неструктурированные данные? Мысль о том, что ECM позволяет связать с друг другом различные образы одного и того же объекта, например скан-копию документа с записью о нем в учетной системе, так же достаточно очевидна.
Но, видимо, как-то не так мы рассказываем все это нашим пользователям