ИТ-архитектура библиотеки

Усложняющиеся требования к библиотекам изменили подход к выделению программных подсистем, связей и принципов взаимодействия ПО для библиотеки.

Рассмотрим пример архитектуры и причины возникновения отдельных подсистем, чтобы было понятно откуда берётся отдельная подсистема, что и почему надо выносить из АБИС.

Почему нельзя всё сделать в одной АБИС[править]

Многие пытаются удержать абсолютно всё в рамках единой информационной системы автоматизации библиотеки (АБИС). Теоретически действительно можно построить систему "решающую все проблемы" и замыкающую всё на себя.

Плюсы полностью централизованной единой системы понятны:

нет дублирования данных;
единую систему проще администрировать и анализировать;
единые правила и единственная система которой надо обучить персонал;
меньше систем - меньше вероятность поломок;
данные в консистентном (не противоречивом) состоянии;
дешевле в эксплуатации.

Минусы:

если система ломается, встаёт абсолютно всё;
значит ломаться нельзя, значит опасно обновляться и стабильность оказывается весомей обновлений и нового функционала;
существующие АБИС предлагают решения не соответствующие современным требованиям к работе ПО и не оправдывают ожиданий пользователей;
универсальные системы обычно хуже узкоспециализированных, а по факту АБИС, являясь универсальной системой, будет пытаться делать всё что связано с контентом, обслуживанием и т.п.;
в реальности АБИС на сегодня многого не умеют да и в ситуации постоянных изменений не всегда легко угадать что надо уметь, а что нет.

Опыт показывает, что вместо упихивания всего в АБИС, лучше иметь параллельно несколько слабосвязанных систем, каждая из которых будет уметь решать свою узкую задачу.

Компоненты современной библиотеки[править]

АБИС (печатная книговыдача и автоматизация процессов связанных с печатной книгой + RFID);
электронная библиотека или несколько узкоспециализированных электронных библиотек и архивов;
внешние подписные сервисы (ЭБС, ЛитРес, WoS...);
официальный внешний сайт;
сайт корпоративный (база знаний и т.п. информация для внутреннего использования библиотекой);
поиск;
иные внешние сервисы (энциклопедия и т.п.);
аутентификация пользователей;
VPN или проксирование;
разрешитель ссылок (link resolver).

Многокомпонентность нужна потому, что есть отдельное ПО созданное именно для указанных целей и реализующие свой функционал лучше встроенного в АБИС.

АБИС[править]

Задача АБИС - взять на себя те задачи, которые она делает лучше всего: работа с печатным фондом.

Электронная библиотека[править]

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

Внешние сервисы[править]

Библиотека оформляет подписки на сервисы и определённым образом от них зависит. Сервисы появляются новые и исключаются из подписки, даются в демо-доступ и т.п.

Сервисов много и они динамичны. Этим они отличаются от других систем библиотеки. Библиотека легко подписывается на сервисы и с некоторыми оговорками легко может отписаться.

Официальный сайт[править]

Обычно официальный сайт нет нужды куда-либо интегрировать, кроме аутентификации, но бывает ПО для АБИС и ЭБ работающие, в виде модулей к известным CMS и официальный сайт можно делать там же, где у вас такое библиотечное ПО установлено.

Примеры ПО на CMS: ELiS (Drupal), J-ИРБИС (Joomla!), НЭБ (Битрикс).

Корпоративный сайт[править]

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

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

Управление проектами также должно где-то жить.

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

Поиск[править]

Упомянутые выше подсистемы независимы и с собой не общаются. Но на самом деле есть задача, требующая их объединения: поиск по всем ресурсам библиотеки.

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

Почему поиск отдельно, а не в АБИС? Внешние ресурсы очень динамичны и они то появляются в больших количествах, то исчезают. Если всё это загрузить в АБИС, то чтобы не происходило удвоение записей, предполагается слияние уже известных MARC-записей с импортируемыми. Проблема в том, что делать, когда аренда сервиса заканчивается и записи надо удалить (а они уже влиты и слиты с существующими).

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

Иные внешние сервисы[править]

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

Все варианты сложно перечислить и одни будут возникать, а другие исчезать.

Аутентификация пользователя[править]

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

VPN или проксирование[править]

Часть подписных сервисов до сих пор авторизуют пользователей только по IP-адресу организации и для доступа из интернета необходимо выполнить запросы пользователя через сеть организации.

Есть разные способы как это сделать, от проксирования с помощью авторизующего прокси-сервера и до поднятия VPN.

Разрешитель ссылок[править]

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

См. подробности про OpenURL. Системы на подобие DOI тоже когда-то начинались с похожей задачи, но решаемой глобально, а не в рамках организации.

Выводы[править]

Создание качественных сервисов требует от библиотеки внедрение большого количества разнообразного ПО.

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

С помощью АБИС затруднительно реализовать всё это, особенно с помощью АБИС созданных не для решения упомянутых задач, а в первую очередь для автоматизации процессов выдачи и обработки книг. Поэтому встречающаяся практика "впихать невпихуемое" в АБИС нельзя стратегически признать удачной.

Движение направлено в сторону усложнения всего и вся с одновременным ростом разнообразия внедряемых систем. Развитие библиотечных сервисов надо вести исходя из усложнения систем и роста требований к квалификации сотрудников.

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

СКУД, видеонаблюдение, мониторинг, резервирование - это тоже есть, но не включено в обсуждение как ПО не являющееся библиотечным.

Примеры использования[править]

КФУ[править]

Казанский федеральный университет.

У него ядром является поиск VuFind. Изображён в центре схемы.

https://kpfu.ru/library/uchebno-metodicheskie-resursy

В качестве хранилища DSpace http://dspace.kpfu.ru/

Всё ПО с открытым кодом.

В качестве ограничений - нет навигатора.

МГУ[править]

Издательства при МГУ как пример, когда (при)вузовский издатель существенно качественнее предлагает решения, чем библиотека:

Имеется сайт-навигатор по ресурсам, сами ресурсы могут находиться в другом месте, т.е. не является даже ЭБ, неся сходный функционал:

http://msupress.com/

Есть ещё одно издательство в (при?) МГУ: http://kdu.ru/

Владеет установленной у многих ЭБС БиблиоТех.

Поддерживает ЭБ: http://kdu.ru/biblioteka

Для сравнения не в пользу библиотеки, научная библиотека МГУ:

http://nbmgu.ru/catalogs/elcats/full/

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

ТГУ[править]

Томский государственный университет использует Vital для хранения электронного контента.

http://vital.lib.tsu.ru/vital/access/manager/Index

Vital создан создателями АБИС Virtua - конкурента АБИС Aleph.

Пример, что не всегда следует выбирать продукты, приближённые к АБИС.

ТПУ[править]

Томский политехнический университет

ЭБ построена на ПО собственной разработки и являет собой поиск со ссылками на тексты: http://catalog.lib.tpu.ru/ec/simple

Думаю, это еще один способ убедиться, что поисковый интерфейс не оптимален для ЭБ.

В этот же поиск сведен и каталог: http://catalog.lib.tpu.ru/

Есть веб-прокси: http://ezproxy.ha.tpu.ru:2048/login

НГТУ[править]

Новосибирский гос. тех. университет.

ЭБС: https://elibrary.nstu.ru/ - похоже на собственную разработку.

Примечателен использованием единой аутентификации: для скачивания файла вас заставят пройти аутентификацию на отдельном сервере (см. схему): https://login.nstu.ru/ssoservice/XUI/

Каталог на Virtua: http://virtua.library.nstu.ru