====== Library Technology Reports : Library Services Platform ====== ===== Référence ===== BREEDING, Marshall, 2015. Library Services Platforms: A Maturing Genre of Products. //Library Technology Reports//. 5 juin 2015. Vol. 51, n° 4, pp. 38. Disponible à l'URL suivante : http://search.ebscohost.com/login.aspx?direct=true&db=lih&AN=110072912&site=ehost-live {{:lectures:ltr-library-service-platforms.pdf|PDF}} - [[https://www.zotero.org/igor.m/items/itemKey/8KQDXEJU|Zotero]] ===== Notes ===== ==== Introduction ==== LSP = dernière vague de systèmes automatiques pour bib. Très différents de ce qui a existé. But du rapport : permettre de comprendre LSP. LSP n'a pas encore remplacé ILS. Besoin de données pour décider si ILS ou LSP. Rapport ne fais pas de recommandations pour les produits présentés, vision neutre. Description générale et données empiriques sur nombre et types de bib. sur LSP. **Source** : stats, graph. proposés par vendeurs, libraries.org, le [[http://librarytechnology.org/perceptions/2014/|//Library Automation Perceptions Survey// de 2014]]. Donne des descr. gen. des produits, pas détail des caractérisitques, fonctionnalités. Champ : les solutions les plus utilisées en Amérique du Nord : * OCLC WorldShare Management Services * Ex Libris Alma * Innovative Interface Sierra * ProQuest Intota * Kuali OLE Mentionné : * SirsiDynix BLUEcloud Suite Non-traité : * Spydus 9 de Civica, pas présent aux USA, pourtant peut être pertinent. === Qu'est-ce qu'un LSP ? === Diffère substanc.mnt des ILS, qui ne répondent plus aux besoins. LSP = catégorie qui contient des solutions corresondant à différentes caractérisitiques (concept, technique, fonction). Pas de def. univoque, fermée. //Ressource management system// = tout produit majeur utilisé par une bib. pour gérer tout ou partie de ses collections. Inclut : LSP, ILS, //digital collections management system//, etc. Proposition de def. en 2011, par l'auteur : spécifique aux bib., permet aux bib. de //produire// ses services, à l'interne comme à l'externe, via l'outil ou via des services Web. Puis ajoute : répond aux changmts fondamentaux ds domaine bib. → contenu numérique. Se sépare de l'époque où les modèles d'automatisation étaient centrés sur l'imprimé (ILS). Jusqu'ici, on ajoute des modules à l'ILS : //link resolvers//, bibliothèques numériques, systèmes de gestions des actifs numériques, archives institutionnelles... But des new produits : plateforme qui intègre le tout. Besoin d'avoir une def. neutre → LSP. Chaque vendeur proposait sa def. pour son produit : * //Unified Resource Management// par Ex Libris * //Web-Scale Management Service// par OCLC Désormais accepté par communautés des bib. et des vendeurs. === Perspective historique : consolidation des fonctionnalités === Mission des bib. constante : dev les collections en fonction des intérêts des communautés d'utilisateurs, et y donner accès. Par contre, les collections ont changé de nature, format, méthode de stockage, d'accès... À chaque changement, les bib. ont développé les outils et tech. dont elles avaient besoin pr remplir mission. [histoire des tech. bib.] Informatisation : améliore gestion (circulation, catalogage, acquisitions) et accès. Unification des divers programmes → ILS, basés sur une DB centralisée. Développement a suivi les tech. dispo : //mainframe//, client-serveur, //cloud// et techno Web. Tendance constante vers la consolidation, unification dans 1 solution, //integrated or unified platforms//. 70s : ILS résultat de cette unification (circulation, acquisition...). Augm. de la doc numérique : besoin de nouveaux outils pour acquisition, gestion, accès du numérique. Début 21e, nouvelle période de fragmentation des outils pour le numérique : * ILS pour l'imprimé, rôle de moins en moins central * OpenURL link resolvers, début 2000s, aide les bib. pour une solution gérable pour lier les citations (ou référence) au full text → le rendre accessible aux utilisateurs. Offre un lien, selon le contexte, vers le full-text sur le serveur de l'éditeur auquel la bib. est abonné. Résolvait problème des liens en dur, impossible à maintenir, à cause trop grande masse des ressources électroniques et leur évolution. * KB : DB qui décrit le contenu des bouquets auxquels la bib. est abonnée. Liste actualisée de chaque revue électronique contenue dans les bdd, les années couvertes (embargo ou pas...), la syntaxe nécessaire pour faire un lien vers l'article individuel, et autres. Support le protocol OpenURL. KB décrit l'ensemble du contenu potentiellement accessible, le link resolver permet de savoir si on y accède et y donne accès. * liste AtoZ * //Electronic resource management system// : acquisition, description, gestion des bdd, revues électroniques, bouquets. Se base sur une KB. * archives institutionnelles, ou collections numérisées * plateformes d'archivage à long terme de contenu numériques. LSP → consolidation de plusieurs catégories de fonctionnalités. [ah ?]. Vont remplacer plusieurs produits, y compris ILS, gestion des ressources électroniques, KB. Peut-être aussi //link resolver//, en lien avec //discovery//. LSP ne suffit pas, aussi //discovery//, même si souvent intégrés dans la même offre. Pas de plateforme de publication, archives institutionnelle, gestion des données, actifs numériques... Garder en tête l'élargissement des fonctions lors de la comparaison des coûts : ILS + gestion des ressources électroniques + //link resolver// + infrastructure, ressources humaines... === Définition et caratéristiques === LSP : * permet bib de //acquérir// + //gérer// ses collections * quel que soit le format, au moins des contenu physiques et numériques * différents processus d'acquisition : achat, abonnements, licences, OA * gestion des différents schémas de métadonnées nécessaires pour chaque format * famille MARC * dublin core * ~ //discovery// ou connexion vers un //discovery//, grâce aux APIs * **cloud multi-tenant** * client Web, pour l'admin comme pour utilisateur final * KB === Caractéristiques fonctionnelles === == Gestion des formats imprimés et électroniques de contenus == Unifie leur gestion : des ensembles, //workflows// communs. Devrait inclure à l'avenir les archives, archives institutionnelles, gestion des données. == Remplacement des différents outils == == Gestion étendue des métadonnées == Support de plusieurs formats : MARC, Dublin Core, standards XML. Linked data, BIBFRAME ne sont pas encore implémentées... == Workflows d'acquisition == Achat, abonnement, licence, dans le même logiciel. À la différence des ILS. == KB == Le fournisseur construit la KB à la place des bib : c'est un dépôt de métadonnées inclus. KB à la fois des contenu imprimés et numériques. Donc une KB qui dépasse de loin les collections possédées par la bibliothèque. == Stats == Promesses de meilleures stats. Parce que le fournisseur dispose de plus de données... et ? Il les donne ? Il les vends ? Comme les éditeurs commerciaux ? == Organisation conceptuelle == ? == Discovery == S'y intègre. LSP ne proposent pas d'interface de recherche. OPAC était intégré à ILS. //Discovery// considéré comme produit différent du LSP. Pour un LSP, la notion d'OPAC ne s'applique pas, plutôt via APIs. [Quelle qualité ?]. === Caractéristiques techniques === == Au delà de l'architecture client - serveur == Passage de l'architecture client lourd / serveur à client léger (navigateur) / serveur. Éviter d'installer et de mettre à jour un client lourd. [À la place, on utilise une sorte de client universel : le navigateur, avec ses propres limites (conf., mises à jour, plugins...)] Chaque institution installait son logiciel sur ses serveurs, avec ses DB. L'utilisateur final passait via un client qui produisait l'interface utilisateur. == Plateformes multi-tenant == 1 instance → plusieurs users. TT le monde utilise la même version. Permet d'envisager l'ensemble des données comme un tout, de séparer des parties, d'en partager d'autres entre users. Distribution globale, bascule et redondance sur différents datacenters, sur différents continents. Existe avant LSP dans domaine des bib. : * [[https://www.worldcat.org/|worldcat.org]] * les logiciels de gestion de contenu numérique * //discovery// : Summon, EBSCO Discovery Service, Primo Central * différents logiciels de bib : * [[https://www.biblionix.com/products/apollo/|Apollo de Bblionix]] * [[http://www.proquest.com/products-services/360-Core.html|360]] de ProQuest * EBSCO A-Z, LinkSource, etc. * LSP : Alma, WorldShare Management Services, Intota Bénéfices dans domaine bib. : * coût marginal d'un nouveau client pour le fournisseur * maintenance faite une fois, appliquée globalement * économie en pers. pour le fournisseur... * simplification du déployement des patchs, pour le fournisseur... * évolutions, mise à jour facilitée * possibilité d'activer optionnellement des feats en tests, avant mise en prod. Du point de vue des bib. elles-mêmes : * la tech. est gérée par le fournisseur, allège la tâche du pers. de la bib. * carrément pas besoin de personnel technique, pas d'adminsys. * parfois besoin d'un bibsys, pour institution de grande taille pour config., chargement des données, interactions avec le système local. Du point de vue de bib. la différence entre SaaS ou multi-tenant est subtile : * multi-tenant peut proposer des fonctions intégrées comme KB [pourquoi particulièrement les multi-tenant ?] * mt offre un processus de conf. de plus haut niveau [?] * scalability... Mais au fond, peut de différences entre SaaS et mt, moins qu'entre cloud et selfhosted. == Interfaces Web == Interfaces Web != pas de logiciels en local sur les serveurs ou desktop... sauf un navigateur, ok. Pas de mise à jour du client, ni des serveurs locaux. == Architecture orientée architecture == ? programmation objet ? Développement par modules ? Méthodes agile ? → //services-oriented approach//... == APIs : extension et interopérabilité == Réutilisation des données dans d'autres services (stats, analyse, ...) ou gestion des données (modif globales, autres tâches pas prévues nativement dans l'outil). Gestion des droits et accès aux APIs. [bah, oui]. Doit être bien documenté. L'APIs et les développements. == Interopérabilité == Avec : * ERP * système de la compta * gestion des dossiers étudiants * LMS Le tout avec APIs. Le LIS qu'une partie du système d'information de l'institution. Le LIS utilise les données d'autres partie du SI : dossiers étudiants, RH. Acquisition et compta. == Modèle de l'abonnement == Du modèle de licence au modèle de l'abonnement. SaaS : abonnement mensuel en rapport avec la taille et la complexité de l'orga. 1re année plus chère : migration et paramétrage. Abo + chère que licence, mais il faut ajouter infra + RH. === Un groupe de produits en évolution === LSP ne sont plus des //next-gen sys// mais produits bien établis, implémentés dans des 100n de bibs. A commencé en 2009. Début des implémentations en 2010. Fin 2014, presque 1000 bibs y ont migré. == Dans le cycle d'adoption == * Alma et WS en prod depuis 2012, ont bcp progressé. * KualiOLE : en prod dans 2 bib., gère seulement l'imprimé, prochaine version en prod début 2015 (annoncé à l'époque). * Intota : pas terminé, seulement le numérique. * Sierra : mix LSP et ILS, sorti en 2012, ~500 bib. en prod. Beta testers, early adopters... ? A chacun sa prise de risque. == Du dev à l'implémentation == Évaluer la maturité d'un produit : * Fin du dev initial. Pas encore complet, mais au moins un niv. de complétude satisfaisant... * Première phase de production. Au moins implémenté par qlqes bib. même petites, ont laché l'ancien système. * Déployement en masse. Plusieurs centaines de bib. en prod. Produits en constante évolution, déjà le cas des ILS. mt → évolution graduelle, plutôt qu'en "palliers" dans architecture client-serveur. [ne dépend pas forcément de l'architecture...]. == Sources pour évaluer implémentation et réception == * //Library Systems Report// * //libraries.org//, les //Library Technology Guides// * //Library automation Perceptions Survey// [voir: [[http://librarytechnology.org/perceptions/2014/|2015]] == Des timeline différenciées == voir : [[http://librarytechnology.org/chron/libraryservicesplatforms.pl|timeline]] sur librarytechnology.org. == Stratégies de dev : Greenfield VS Brownfield == Comment peut-on dev un truc aussi complexe qu'un LSP (est-ce vraiment aussi complexe ?) ? Dépend de plusieurs facteurs : * Taille de l'orga qui dev * nbr de dev La diff entre brown et greenfield, c'est si le dev reprend des compsants déjà existants. Du job déjà fait, mais des contraintes. Brownfield avance plus vite, mais moins innovant, puisque reprise d'éléments existants. WS : greenfield. S'appuie sur le contenu de WC. + WorlCat Local comme //discovery//, puis WorlCat Discovery Service. Alma : greenfield. Ne reprend pas travail existant de Voyager, Aleph, SFX... Reprise de la KB, mais pas le code. + Primo et Primo Central. Primo a aussi été un //greenfield project//. Kuali OLE : approche hybride. La partie bib. est complètement nouvelle, mais reprend les parties de Kuali Rice et Kuali Financial System, qui n'est pas prévu pour du mt, mais KualiCo redéveloppe cette partie. Intota : s'appuie sur l'existant plus dev de nouveau code. Continue le dev des produits de Serials, récent dans le domaine, donc tout en mt. Intota comprend 360 Link, un module des gestion des ressources numériques. Sierra : s'appuie sur Millenium + nouvelle tech. Développement plus rapide. SirsiDynix : hybrid. Son //BLUEcloud suite// peut être considéré comme LSP. Déployé en mt, gestion du numérique et de l'imprimé, interfaces Web. Repose sur le ILS de SirsiDynix : Symphony ou Horizon.