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
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 //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 :
Mentionné :
Non-traité :
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 :
Désormais accepté par communautés des bib. et des vendeurs.
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 :
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…
LSP :
Unifie leur gestion : des ensembles, workflows communs. Devrait inclure à l'avenir les archives, archives institutionnelles, gestion des données.
Support de plusieurs formats : MARC, Dublin Core, standards XML. Linked data, BIBFRAME ne sont pas encore implémentées…
Achat, abonnement, licence, dans le même logiciel. À la différence des ILS.
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.
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 ?
?
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é ?].
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.
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. :
Bénéfices dans domaine bib. :
Du point de vue des bib. elles-mêmes :
Du point de vue de bib. la différence entre SaaS ou multi-tenant est subtile :
Mais au fond, peut de différences entre SaaS et mt, moins qu'entre cloud et selfhosted.
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.
? programmation objet ? Développement par modules ? Méthodes agile ? → services-oriented approach…
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.
Avec :
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.
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.
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é.
Beta testers, early adopters… ? A chacun sa prise de risque.
Évaluer la maturité d'un produit :
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…].
voir : timeline sur librarytechnology.org.
Comment peut-on dev un truc aussi complexe qu'un LSP (est-ce vraiment aussi complexe ?) ? Dépend de plusieurs facteurs :
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.