Note - Cet article a été sélectionné pour publication dans le blogue des MVP de Microsoft en décembre 2011.
Introduction
Un des sujets les plus discutés dans la communauté SharePoint est certainement le concept d'architecture d'information. Une simple recherche via Bing en utilisant l'expression "SharePoint information architecture" nous retourne plus de 3.4 millions de résultats. Il a été démontré maintes et maintes fois qu'une architecture d'information inappropriée, ou même l'absence d'architecture d'information, est l'une des causes principales d'échecs dans les projets et implantations SharePoint. Cet article propose une approche d'architecture d'information dans un contexte SharePoint qui est basée sur l'utilisation des cartes heuristiques, mieux connues sous le nom de mind maps. Pour cet article, j'utilise l'outil XMind mais tout outil peut faire l'affaire; l'idée principale étant de considérer l'approche et non pas l'outil en soi.
Profil de compétences de l'architecte d'information
Afin de maximiser ses chances de succès, l'architecte d'information devrait posséder les compétences suivantes :
- Sens politique et Négociation– Étant donné que l'architecture d'information prend parfois une tournure politique, l'architecte d'information doit être en mesure de négocier et d'agir en médiateur entre les divers représentants impliqués autant au niveau technique qu'au niveau affaires
- Habiletés analytiques et techniques – Afin de s'assurer que les divers besoins sont adéquatement supportés par les bons artefacts SharePoint, l'architecte d'information doit comprendre les implications fonctionnelles et techniques de chaque option et être en mesure d'expliquer les choix proposés
- Communicateur et facilitateur – Ces habiletés sont essentielles durant la phase de collecte des besoins. L'architecte d'information doit être en mesure d'influencer les autres, de gagner leur confiance, de remettre en question les besoins d'une façon positive et surtout de maîtriser l'art du compromis
Même si l'architecte d'information est celui qui gère le processus d'architecture d'information et qui est responsable de produire l'architecture d'information, cette activité est d'abord et avant tout un effort de collaboration entre les divers intervenants : l'architecte d'information, l'architecte SharePoint, un ou plusieurs ressources expertes (SME) et un ou des représentants des unités d'affaires impliquées.
Zones de l'Architecture d'Information
La majorité des pratiques actuelles en architecture d'information dans un contexte SharePoint sont ciblées vers les éléments physiques tels la structure du site, la navigation et le design graphique. Cependant, d'autres zones clés sont souvent négligées mais elles sont essentielles pour permettre une implantation flexible et gérable. Une architecture d'information complète devrait donc couvrir les zones d'architecture d'information suivantes :
- Gouvernance
- Collecte des besoins
- Hiérarchie du contenu
- Conteneurs SharePoint
- Design visuel
En fonction de la portée et de l'étendue de la solution ciblée, il est possible que certaines de ces zones ne soient pas nécessaires ou que leur niveau de détails soit limité. Pour chaque zone de l'architecture d'information, nous indiquons les intervenants ainsi que les éléments qui doivent être couverts, tel qu'illustré dans la figure suivante.
Figure 1 – Vue globale – Zones de l'architecture d'information
Comme on peut le voir dans cette carte heuristique, chaque zone de l'architecture d'information dispose de sa propre carte heuristique à l'intérieur d'une carte globale. On peut aussi créer des liens entre des items spécifiques et leurs définitions à l'intérieur d'une carte. Les figures qui suivent vont illustrer le contenu des cartes de certaines zones de l'architecture d'information.
Gouvernance – Il est important de comprendre qu'il y aura plusieurs plans de gouvernance en fonction de la portée et de l'étendue de la solution ciblée. On retrouve habituellement les plans de gouvernance suivants: Collaboration, Gestion de documents, Formation, Infrastructure, Personnalisation, Réseau social et Stratégie. Un bon point de part pour un plan de gouvernance se trouve sur TechNet via ce lien.
Collecte des besoins – C'est la zone d'architecture la plus importante de toute implantation; les besoins doivent être remis en questions pour s'assurer que les bons artéfacts seront utilisés. Par exemple, il faut que l'architecte d'information soit en mesure d'expliquer la différence entre un blogue et un wiki. Il peut être utile à ce stade de construire quelques prototypes pour solidifier et confirmer la compréhension et les besoins. Plusieurs techniques peuvent être utilisées pour faciliter la collecte de besoins. Les cartes heuristiques sont l'une de ces techniques et la technique nommée card sorting peut être aussi très utile pour le volet de taxonomie et de classification de l'information.
Hiérarchie SharePoint– Cette zone est liée à l'architecture de la ferme et couvre les artéfacts SharePoint tels les Applications Web, les Collections de Sites, les Applications de Services, les Serveurs, les Bases de Données, les zones, etc. ainsi que tout élément de configuration lié à ces artéfacts. On complète habituellement cette zone lorsque tous les besoins ont été collectés, analysés et liés aux divers artéfacts SharePoint. Dans d'autres cas, il se peut que ce travail soit déjà réalisé; l'architecte d'information doit alors en connaître les détails.
Figure 2 – Carte – Hiérarchie SharePoint
Structure des contenants SharePoint – En se basant sur les besoins, les meilleures pratiques et les capacités organisationnelles, nous pouvons maintenant définir les types de contenant SharePoint (sites, bibliothèques, listes, web parts, flux de travail, types de contenus, etc.) qui sont nécessaires. On peut aussi bâtir des modèles et gabarits de ces contenants pour assurer une certaine consistance au niveau de l'utilisation, promouvoir la réutilisation et augmenter le niveau d'usabilité de la solution.
Figure 3 – Carte – Contenants SharePoint
Design Visuel – Cette zone vise à s'assurer que la navigation et l'habillage graphique sont couverts adéquatement. Cela inclut donc les thèmes, les éléments ASP comme les pages layout, les master pages, le CSS, etc. Pour faciliter le travail au niveau du prototypage initial d'une solution, il existe un outil Web gratuit nommé Intranet Modeler qui permet de bâtir rapidement et de démontrer un prototype de solution dans une enveloppe visuelle SharePoint 2010.
Un Exemple
Cet exemple montre un sous-ensemble d'une architecture d'information pour une solution simple. Le but de cette solution est d'offrir un environnement collaboratif avec quelques fonctionnalités de gestion documentaire. Une des contraintes est l'utilisation de WSS 3.0 comme plateforme technologique. Étant donné la portée limitée de cette solution, il n'a donc pas été nécessaire de compléter chaque zone de l'architecture d'information; les zones suivantes ont été réalisées : Hiérarchie SharePoint (partielle car la ferme existait déjà), Contenants SharePoint et Gouvernance. La figure suivante présente le résultat du travail pour la zone Contenants SharePoint. Un code de couleurs et des marqueurs ont été utilisé pour classifier les différents artéfacts SharePoint.
Figure 4 – Carte – Contenants SharePoint pour une solution de collaboration
En regardant cette carte, on peut déjà constater que :
Nous avons besoins de cinq (5) bibliothèques de documents. Quelques-unes sont basées les modèles standards de SharePoint et d'autres seront livrées comme gabarits personnalisés :
- Documents de Travail (Working Documents) – Une bibliothèque personnalisée pour gérer les versions initiales et les versions de travail de tout type de document
- Reference– Une bibliothèque personnalisée pour gérer les documents de référence qui proviennent de l'extérieur de l'organisation
- Communications – Une bibliothèque personnalisée pour gérer les éléments de communication comme les présentations, les mémos et notes internes, etc.
- Galerie (Gallery) – Une bibliothèque standard de type Images pour gérer les images utilisées dans le site et les sous-sites.
- Scripts – Une bibliothèque standard de documents pour gérer les scripts et autres éléments (fichiers JS, etc.) qui sont utilisés dans le site et les sous-sites
Nous avons besoin de trois(3) listes:
- Taxonomie (Taxonomy) – Une liste personnalisée qui contient les termes clés de notre taxonomie ainsi que la définition de chaque terme. La liste n'a donc que deux colonnes (Titre, Description)
- Nos Nouvelles (Our News) - Une liste base sur le modèle de liste Annonces du groupe
- Évènements (Events) – Une liste de type Calendrier pour gérer les évènements du groupe
Nous avons besoin de cinq (5) sites::
- Centre de Gouvernance (Governance Center) – Ce site d'équipe sera utilise pour les equips de gouvernance afin de gérer et publier les livrables (plans de gouvernance); ce site peut aussi être utilisé comme un site global de référence pour le volet SharePoint dans votre organisation
- CollaPedia – A site Wiki de base (ou une bibliothèque de pages Wiki avec Foundation) qui agit comme un Wikipedia interne avec une emphase forte sur la collaboration
- Le Collaborateur (The Collaborator) – Un site de type Blogue pour publier divers articles sur la collaboration afin de promouvoir le partage et les discussions
- Site Départemental (Departmental Site)– Un site d'équipe destiné aux unités d'affaires et aux départements de l'organisation; ce site doit être personnalisé en le construisant avec certains éléments réutilisables (bibliothèques de documents, listes)
- Site de projet (Project Site) – A site d'équipe de base destine aux équipes de projets; ce site doit être personnalisé en le construisant avec certains éléments réutilisables (bibliothèques de documents, listes, etc.)
- Nous avons besoin d'une (1) Web Part nommé Administration du Site (Site Administration). On utilise une Web Part de type Éditeur de contenu pour publier en page d'accueil, les coordonnées (nom, hyperlien de type mailto, etc.) des propriétaires du site.
Nos bibliothèques personnalisées sont détaillées dans une carte liée qui décrit les types de contenus requis tel que démontré dans cette figure.
Figure 5 – Carte – Types de Contenu
On utilise une carte spécifique pour définir nos types de contenu. On voit ici qu'il y a un type de contenu de base nommé Document-Base et que tous les autres types de contenu document héritent de ce type maître. Nous avons aussi créé un type de contenu Contacts qui représente en fait une version allégée du type de contenu standard de SharePoint. On voit aussi qu'à l'intérieur de nos types de contenu, nous avons certaines colonnes de site qui sont décrites dans une carte liée.
Figure 6 – Carte – Colonnes de site
Cette carte montre les diverses colonnes de site requises pour supporter notre architecture d'information. On y détaille aussi les domaines de valeur ainsi que la valeur par défaut qui est visible en gras.
Finalement, nous avons aussi une carte spécifique qui nous montre les modèles de site requis pour supporter notre architecture d'information.
Figure 7 – Carte – Modèles de Site
On constate que nous réutilisons tous les artefacts définis précédemment. Cela permet une consistance au niveau de l'utilisation et favorise grandement la réutilisation. Dans certains outils de cartes heuristiques, on peut utiliser la section Notes de chaque élément pour définir plus précisément ces éléments. L'ensemble des cartes peut alors servir à démarrer l'approvisionnement des artéfacts communs tels les gabarits et les éléments globaux. En utilisant la carte de la zone Design visuel, on peut aussi débuter la structure du site.
Conclusion
Étant donné qu'un outil de cartes heuristiques nous permet de créer des relations entre divers concepts, l'architecte d'information peut donc facilement:
- Collecter et classifier les besoins d'affaires
- Démarrer la définition de l'architecture de la ferme
- Identifier rapidement les éléments communs tels les types de contenu, les gabarits (listes, sites, bibliothèques, etc.)
- Prototyper rapidement certains des artéfacts pour solidifier et confirmer les besoins d'affaires
- Démarrer le processus de documentation de l'architecture d'information via les facilités d'exportation des outils (création de documents PPT, PDF ou Word)
J'espère que serez en mesure d'utiliser certains des concepts présentés ici dans votre prochaine architecture d'information. Le message clé ici est de démontrer que l'utilisation d'outil de cartes heuristiques peut vraiment aider l'architecte d'information à livrer une solution SharePoint solide et viable.