Information Architecture in a SharePoint Context | Architecture d’Information dans un contexte SharePoint

Editor's Note: The following MVP Monday post is by French-Canadian SharePoint Server MVP Alain Lord and is available in both English and French.

Introduction

One of the most discussed topics in SharePoint community is certainly the concept of information architecture. A simple search request in Bing with “SharePoint information architecture” gives us more than 3.4 million hits. It has been demonstrated over and over that the lack of proper information architecture is one of the main failure causes in SharePoint deployment. This article will propose an information architecture approach in a SharePoint context by using mind maps. For this article, the XMind tool has been used but any mind map tool can be used. The idea is to focus on the approach used instead of the tool itself.

Information Architect competency profile

In order to be successful, an information architect must possess the following competencies:

• Negotiation – Political skills – Given that the information architecture may have some political aspects, the information architect must be able to negotiate and acts as a mediator between the various stakeholders
• Analytical and Technical skills – In order to ensure that the various needs are properly fulfilled by the appropriate SharePoint artefacts, the information architect must understand the technical implications of each option
• Communicator and Facilitator – These skills are essential especially during the requirements gathering activities. The information architect should be able to influence others, win their confidence, challenge the requirements in a positive way and master the art of compromise

Even if the information architect is the lead of the Information Architecture process and responsible for the final delivery of the Information Architecture, this activity is first and foremost a collaborative effort between various stakeholders:  Information Architect, SharePoint Architect, one or more Subject Matter Experts (SME) and Business Units representatives.

Information Architecture Areas

Most of the current information architecture practices are targeted at site structure, site navigation and labelling. However, other key areas are often neglected but they are essential to ensure a manageable implementation. A complete Information Architecture should cover these Information Areas (IA) as shown in the next figure:

• Governance
• Requirements Gathering
• SharePoint Containment
• SharePoint Containers
• Visual Design

Based on the scope and the extent of the target solution, it is possible that some areas may not be required and/or their level of details will not be the same. For each Information Architecture area, we indicate the stakeholders and the elements that will be covered in each area.

Figure 1 – Global view of Information Architecture

As you can see in this map, each Information Architecture area has its own map within a global IA workbook. We can also link specific items to their definition within the workbook. The next set of figures will show some of the key Information Areas maps.

Governance – It is important to understand that there will be several governance plans based on the scope and the nature of the implementation. We usually have these governance plans:  Collaboration, Document management, Training, Infrastructure, Customization, Social Networking and Strategy. A good starting point for a governance plan can be found here at TechNet site.

Requirements Gathering – This is the key area of every implementation; the requirements must be challenged to ensure that the proper artefacts will be used. We can also build some prototypes to help us during the requirements gathering activity. Several techniques can be used to gather these requirements. Mind map is a good approach and card sorting technique can also be useful especially for the taxonomy and classification aspects.

SharePoint Containment – This area is related to the farm architecture and covers core SharePoint artefacts such as Web Application, Site Collection, Service Applications, Servers, Database, Managed Paths, Zones and the entire required configuration for these items. This area is usually completed once the requirements has been captured, analyzed and properly mapped to SharePoint artefacts. It is possible that this zone is already developed; in this situation, the information architect must know the details of the implementation.

Figure 2 – SharePoint Containment map

SharePoint Containers – Based on the requirements, best practices and your organization capabilities, we can now determine the type of containers (sites, libraries, lists, web parts, workflows, etc.) and build templates for some of these containers to ensure consistency, promote reusability and ease usability across the whole solution.

Figure 3 – SharePoint Containers map

Visual Design – This area aimed to ensure that navigation and branding are properly covered. It covers themes, branding, page layouts, master pages, CSS, etc. In order to assist you in your prototyping phase, there is a free web-based tool called Intranet Modeler. This tool allows you to quickly build and show a prototype based on the initial requirements.

An Example

This example shows a subset of Information Architecture areas for a simple solution. The main goal of this solution is to provide a collaborative environment with some basic document management facilities. One of the constraints is the use of SharePoint WSS 3.0 as the technology platform. Given the limited scope of this solution, it was not required to complete every IA areas; the following IA areas performed are: SharePoint Containment, SharePoint Containers and Governance. For this article, we show the SharePoint Containers map. Color code and markers are used to show the various SharePoint artefacts.

Figure 4 – SharePoint Containers map

By looking at this mind map, we can already see that:

• We need five (5) document libraries. Some of them are standard and others will be delivered as templates:
• Working Documents – A custom document library to manage all the work-in-progress documents
• Reference – A custom document library to manage reference documents
• Communications – A custom document library to manage communications items such as presentation, memos, internal notes, etc.
• Gallery – The standard Picture library to support images used within the site and sub-sites
• Scripts – A standard document library to manage the various scripts used in other parts of the site and sub-sites.
• We need three (3) lists templates:
• Taxonomy – A custom list that will contain the key terms of our taxonomy and their definition
• Our News  - A basic Announcement list for group news
• Events – A basic calendar for the group event
• We need five (5) sites templates:
• Governance Center – This team site will be used by the governance teams to publish their deliverables (governance plans) and can also act as a reference site for your global SharePoint implementation
• CollaPedia – A basic Wiki site (or wiki pages library with Foundation) that act as your internal Wikipedia with a strong emphasis on collaboration
• The Collaborator – A blog site to post various articles about collaboration and to promote discussions and sharing
• Departmental Site– A basic team site targeted at business units and departments; it is pre-populated with the document libraries and lists templates
• Project Site – A basic team site targeted at projects; it is pre-populated with the document libraries and lists template
• We need one (1) web part named Site Administration. This is a basic CEWP used to publish the name of the site owner and site co-owner with mailto hyperlinks on the home page of every single site.

Our custom libraries are further detailed in a linked map describing our required content types as shown below.

Figure 5 – Content Types mind map

This mind map is used to define our content types. We can see that we have a basic Document content type and that other document content types inherit this basic content type. We have also created a Contacts content type with minimal contact information. Some of the key columns are described within another linked map as shown below.

Figure 6 – Site Columns mind map

This map shows the various site columns required to support our information architecture. We can also list the value set and the default value is shown in bold.

Finally, we also have a specific map to show the required site templates as shown below.

Figure 7 – Site templates mind map

As you can see, we are reusing all the artefacts that have been previously defined. This ensures consistency, promote reusability and increase the usability of the implementation. If we have fulfilled the notes section of every item, the map can also be used to start the provisioning of the common artefacts such as templates and the global elements such as site columns. By using the Visual Design map, we can then provision the complete site structure.

Conclusion

Given that a mind map tool allows us to create relationships between various concepts, the SharePoint information architect can easily:

• Collect and classify the business needs
• Start the definition of the farm architecture
• Identify potential common elements such as content types, managed terms, templates (sites, lists, libraries)
• Prototype some of the artefacts to ensure that business needs are properly met
• Start the documentation process of the information architecture through the export function of the mind map tool that allows the creation of document such as PDF or Word

I hope that you will be able to use some of these concepts in your next Information Architecture exercise. The key message here is to show that the use of a mind map tool can really help you to build a global Information Architecture that will help you to deliver a solid and viable SharePoint solution.

Original Version in French 

Architecture d’Information dans un contexte SharePoint

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.

Author’s Bio

Alain Lord is a Most Valuable Professional (MVP) for SharePoint Server since 2009 and the lead of the Groupe d’Usagers SharePoint Québec, a French-Canadian community of users, developers, architects and managers who share their experience with SharePoint technology within the province of Québec.  He is also on the board of directors for the SharePoint Summit event. He provides community content mostly through the Groupe d’Usagers SharePoint Québec blog  and through their LinkedIn group site. He is an enterprise architect in a large financial company where he leads the various initiatives revolving around collaboration and enterprise content management. His Twitter account is: @djlordee

Biographie

Alain Lord est MVP) SharePoint Server depuis 2009 et aussi président et membre fondateur du Groupe d’Usagers SharePoint Québec, une communauté québécoise d’utilisateurs, de développeurs, d’architectes et de gestionnaires qui partagent leurs expériences avec la technologie SharePoint.  Il est aussi sur le comité de direction de l’évènement annuel SharePoint Summit. Il publie du contenu pour la communauté principalement sur le blogue du Groupe d’Usagers SharePoint Québec ainsi que sur le site LinkedIn du groupe. Il est architecte TI dans une grande organisation financière où il réalise des initiatives axées principalement sur la collaboration et la gestion de contenu d’entreprise. Vous pouvez le rejoindre via Twitter : @djlordee

MVP Mondays

The MVP Monday Series is created by Melissa Travers. In this series we work to provide readers with a guest post from an MVP every Monday. Melissa is a Community Program Manager for Dynamics, Excel, Office 365, Platforms and SharePoint in the United States. She has been working with MVPs since her early days as Microsoft Exchange Support Engineer when MVPs would answer all the questions in the old newsgroups before she could get to them