Gouvernance : Comment s'organiser face à la percée de SharePoint en entreprise
Par Stève SFARTZ le vendredi 28 septembre 2007, 11:31 - Architecture - Lien permanent
ArchiMS Gouvernance Infrastructure Suite à la montée en puissance de la gamme SharePoint en Entreprise, Architectes et Chefs de projet s'interrogent de façon légitime concernant l'attiude et l'organisation à adopter face à SharePoint, à savoir :
- Quand utiliser la technologie en regard des développements traditionnels (au sens transactionnel) ?
- Comment structurer lses projets SharePoint (Développement, Infrastructure, gestion des informations) ?
- Ces problématiques concernent la Gouvernance SharePoint, faisons un tour d'horizon du sujet...
Lire la suite là : Gouvernance : Comment s'organiser face à la percée de SharePoint en entreprise - "Think Big" ... mais pas trop !
--
P. Erol GIRAUDY
Président du Club MOSS 2007 et MUG.
Vice-Président Club UGO2007
http://clubmoss2007.org/
http://www.mugfrance.fr/
http://www.viadeo.com/fr/profile/pierreerol.giraudy
Par Stève SFARTZ le vendredi 28 septembre 2007, 11:31 - Architecture - Lien permanent
ArchiMS Gouvernance Infrastructure Suite à la montée en puissance de la gamme SharePoint en Entreprise, Architectes et Chefs de projet s'interrogent de façon légitime concernant l'attiude et l'organisation à adopter face à SharePoint, à savoir :
- Quand utiliser la technologie en regard des développements traditionnels (au sens transactionnel) ?
- Comment structurer lses projets SharePoint (Développement, Infrastructure, gestion des informations) ?
- Ces problématiques concernent la Gouvernance SharePoint, faisons un tour d'horizon du sujet...
Lire la suite là : Gouvernance : Comment s'organiser face à la percée de SharePoint en entreprise - "Think Big" ... mais pas trop !
--
P. Erol GIRAUDY
Président du Club MOSS 2007 et MUG.
Vice-Président Club UGO2007
http://clubmoss2007.org/
http://www.mugfrance.fr/
http://www.viadeo.com/fr/profile/pierreerol.giraudy
1 commentaire:
Gouvernance : Comment s'organiser face à la percée de SharePoint en entreprise
Par Stève SFARTZ le vendredi 28 septembre 2007, 11:31 - Architecture - Lien permanent
ArchiMS Gouvernance Infrastructure Suite à la montée en puissance de la gamme SharePoint en Entreprise, Architectes et Chefs de projet s'interrogent de façon légitime concernant l'attiude et l'organisation à adopter face à SharePoint, à savoir :
Quand utiliser la technologie en regard des développements traditionnels (au sens transactionnel) ?
Comment structurer lses projets SharePoint (Développement, Infrastructure, gestion des informations) ?
Ces problématiques concernent la Gouvernance SharePoint, faisons un tour d'horizon du sujet...
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 :
Toutes les applications métier ne sont pas candidates à rentrée dans une filière de développement basée sur SharePoint
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 :
Comment mettre en place une gouvernance SharePoint ?
Un exemple de plan de gouvernance
Comment structurer et gérer l' information (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)
Enregistrer un commentaire