Quand utiliser SharePoint ?

SharePoint est avant-tout un outil de gestion (publication, échanges) de contenus.
Ces contenus sont des documents, des pages ou bien des données (non structurés, semi-structurés, structurés).
La technologie SharePoint est adapté à des projets de différentes natures mais principalement autour de :

  • Sites Web qui nécessitent
    • Gestion de contenus
    • Notion de composition des IHM (Web Parts)
  • Projets collaboratifs
    • Saisie de contenus structurés (formats XML)
    • Echanges, transferts de documents (non structurés, fichiers plats, bureautique)

Par ailleurs, la technologie SharePoint apporte une souplesse à l'utilisateur que ce soit concernant la forme et le fond. En effet, il est possible de configurer ces écrans (Apparition de telle ou telle module / WebPart, ou bien ajoût d'un fonctionnalité (Feature) dans un menu. Mais SharePoint laisse aussi la possibilité à l'utilisateur de créer ses propres modèles de données auxquel il associera des formulaires de saisie.

Aussi, les projets destinés à être gérés directement par les utilisateurs pour répondre à des contraintes de temps ou bien de flexibilité (difficile d'écrire des spécifications, les besoins de données à saisir évoluent, nécessité d'être réactif pour gérer des situations de crise dans la constitution d'un groupe de travail).

Résumons :

  1. Toutes les applications métier ne sont pas candidates à rentrée dans une filière de développement basée sur SharePoint
  2. Voici quelques critères qui permettent d’orienter votre choix de technologies : qui est maître de l’application (pilotée par l’utilisateur ou les études) ? quel est le niveau d’interaction avec le SI (cohérence des données, dictionnaires, règles métiers) ? quelle est la nature des contenus saisis (Documents, Semi-Structurés, Structurés) ? quel est le besoin de composition et de personnalisation des écrans (WebParts, Portail...) ?

Au-delà de ces critères, rappelons quelques évidences :

  • Mon développement SharePoint se résume à une énorme WebPart que je développe sous VS ! Dans ce cas, attention, il semble que vous soyez en train de réaliser un application Web : on bien changer votre fusil d'épaule en utilisant la technologie ASP.Net
  • La grande partie des données saisies doivent être intégrées au SI et les règles métier doivent systématiquement être déroulées dans le processus de saisie (cad, jusqu'aux écrans utilisateurs). Attention, vous semblez être dans un développement traditionnel, vous devez vous poser la question de l'adéquation de SharePoint pour votre projet ! Comment en êtes vous arrivé là ? Est-ce le besoin de composition de l'interface graphique utilisateur (Portail) ? Les moteur de WebParts d'ASP.Net et de WSS sont certainement suffisants dans ce cas. Est-ce le fait que vous devez interagir avec des documents ? Vous avez alors différentes options : utiliser la GED SharePoint depuis un développement .Net ou WSS, ou bien utiliser des connecteurs BizTalk.


Comment structurer le choix de telle ou telle technologie pour mes développements ?

Le succès de SharePoint est lié au fait que les problématiques liées aux Sites Web et au collaboratif sont en général mal gérées par les filières de développement traditionnelles. Par traditionnel, on entend des développements Web ou Desktop en frontal de bases de données relationnelles et/ou de mainframe.
Dès lors, il est important de définir de façon précise la place de SharePoint dans son organisation vis-à-vis des développements traditionnels.

En premier lieu, il s'agit d'intégrer SharePoint dans les filières de développement existantes.
Selon les entreprises, on distingue différents modèles d'organisation :

  • Organisation par pôle de compétences (Web, Client/Serveur, EAI/ETL,…)
  • Organisation par environnement (Visual Studio/.Net, Eclipse/Java, PacBase/Cobol...)
  • Organisation par type de développement (Internet, Bureautique, Métier)

Dans tous les cas, l'arrivée de SharePoint dans le paysage nécessite de définir le spectre des projets SharePoint en regard des développements traditionnels :

  • Doit-on remplacer une filière existante pour ses gains en productivité ?C'est le cas de développement de sites Web historiquement réalisés en spécifique .Net ou J2EE)
  • Doit-on compléter une filière de développement existante pour gérer les aspects collaboratifs ou gestion de contenus ? Auquel cas, on s'intéressera surtout aux possibilités d'intégration de SharePoint (Requêtage, connecteurs, interopérabilité)
  • Ou bien doit-on créer une nouveau filière de développement ? Correspond à des organisations qui ne couvraient pas les projets de type Web ou collaboratifs (historiquement sous-traités) et qui découvre soudainement la valeur ajoutée des ces développements pour les utilisateurs

Dans un second temps, il s'agit de cadrer :

  • Formaliser le cadre d'utilisation de la technologie (Inscrire les critères de choix évoqués précédemment dans la méthodologie projet interne de l'entreprise)
  • Cadrer les projets SharePoint (mixte d'intégration et de développement)
    • Ce blog décrit à merveill les phénomènes que vous souhaiterez certainement éviter
  • Organiser la production (Gestion des infrastructures (mutualiser, sauvegarder, provisionner..) , définir des rôles, assurer le support de 1er et 2nd niveau…)

Si l'on cherchait à dresser la liste des préoccupations de la Gouvernance SharePoint, on trouverait notamment :

  • Un plan de communication et offre de services
  • Des fermes de serveurs consolidée et supervisé
  • La Cohérence, les Standards, la Charte, et les Politiques d’utilisation
  • La structure des équipes : rôles et responsabilités
  • Les politiques de sécurité, de gestion de l’information
  • La pertinence de la recherche centralisée et interface de navigation
  • La formation et support à la demande
  • Les procédures et documentation des processus
  • L'évaluation des risques

Cette problématique est régroupée sous le terme Gouvernance SharePoint. Le site TechNet possède une rubrique dédiée Governance Information for SharePoint Serveur 2007 qui présente notamment :

SharePoint Governance Model

SharePoint Information Architecture

Enfin, il y a fort à parier que vous voudrez outiller SharePoint pour respecter ces règles de gouvernance. Quelques outils sont disponibles sur le site CodePlex SharePoint Governance & Manageability.

Comment intégrer les données gérées par SharePoint à mon système d'informations ?

Les données gérées par SharePoint sont tantôt dénuées d'intérêt pour le SI, tantôt très importantes, c'est le cas par exemple, d'un catalogue produit partagés entre les collaborateurs d'une équipe R&D dans un groupe industriel par exemple. SharePoint dans ce cas présente l'avantage d'apporter de la flexibilité à la saisie des informations, de facilité leur partage, et de permettre de définir des circuits de validation de ces informations.
Rapidement, les équipes Etudes vont souhaiter consolider ces données avec celles contenus dans le SI.
Nous sommes face à une problématique de rapprochement et/ou de consolidation de données (problématique abordée d'une façon plus large par le Master Data Management - MDM).

Dès lors, il est possible de ré-intégrer toute ou partie des contenus déversés dans SharePoint vers le SI (et vice versa, le SI peut être visible dans SharePoint) via plusieurs procédés :

  • ETL
    • En travaillant à partir des contenus (artefacts) générés par SharePoint
    • L'objectif est d'intégrer les contenus et données visibles e l'extérieur
    • SSIS - SQL Serveur Integration Services est un excellent candidat dans ce cas
  • EAI
    • En interrogeant SharePoint via des Services (SOAP, RPC, API du SDK)
    • L'objectif ici est de requêter pour récupérer et intégrer des contenus et des données
    • BizTalk Serveur apporte plusieurs réponses ici
      • via ses connecteurs et ses capacités de traitements par lots le cas échéant,
      • Les données brutes peuvent être enrichies, corrigés, supprimées lors d'une orchestration
      • ainsi que la possibilité de ré-injecter ses données dans le SI via une multitude de connecteurs (SGBDR, ERP, MainFrame et autres protocoles)
  • DataWareHousse
    • Il s'agit ici de donner de la visibilité des données du SI vers toute la gamme de produits Office, une sorte de dataware house connecté à la suite Office
    • Le Business Data Catalog qui vient avec MOSS est une solution clé en main
  • Développements sur mesure
    • Ces traitements sont déclenchés sur des évènements, lors de l'exécution de workflow ou bien à la génération de pages
    • .Net et Visual Studio sont vos alliers dans ce cas


Comment en est-on arrivé là ?

Un même constat en entreprises et chez les intégrateurs : pourquoi une telle déferlante SharePoint ?
Est-ce le fait d'un push commercial Microsoft ? Certainement, mais pas seulement.
Il s'agit tout simplement du phénomène de la fenêtre d'opportunité (Maturité d'un marché et disponibilité d'un produit ad-hoc sur une même fenêtre temporelle) :

  • SharePoint arrive sur un marché mal adressé par la concurrence
  • De plus SharePoint répond au besoin
    • de façon évolutive (par les aspects programmatiques / ouverture)
    • et exhaustive (grâce à la gamme MOSS - Live Communication - Gestion de la performance avec Performance Serveur)