Excellente session sur les services et la topologie.
Vous savez maintenant que le SSP n’est plus et que tous les services qui font SP 2010 sont indépendants et peuvent être installés partout.
Ce partout peut être une ferme de services (ca me plait beaucoup cette idée…), autant de servers qu’il n’y a de services, etc…
Il était donc particulièrement interessant d’aller voir ce que MS allait nous proposer comme topologie puisque tout est à réinventer.
Ainsi, pour une petite ferme, voila la solution proposée:
C’est donc surtout quand on voit la topologie physique qu’on se rend compte qu’il s’agit bien d’une petite ferme.
Au niveau des points marquants:
- il s’agit d’une seule ferme
- la configuration est principalement par défaut
- il y a combinaison de servers applicatifs et de webfrontend servers
- la gestion de la croissance se fait de deux façons:
- ajout dans les collections de sites
- ajout de server(s)
Pour une ferme moyenne, les choses deviennent un peu plus sérieuses:
On voit maintenant qu’il y a un peu plus de hardware. On voit aussi qu’il est aisé de répartir les différents services sur différents servers.
Les faits marquants sont:
- ferme simple
- avec isolation des pools applicatifs
- il y a plusieurs servers de services
- il y a plusieurs groupes proxy
- les servers ont des rôles distincts
- La gestion de la croissance se fait:
- par ajout de nouvelles webapps, de nouvelles collections de sites
- par ajout de servers FrontEnd ou de servers applicatifs
- en considérant de splitter la ferme en plusieurs fermes…
Dans le cas de la grande ferme, on est alors confronté à la ferme de services, dont je vous ai déjà dit que j’aimais beaucoup l’idée, et je vais m’en expliquer.
On est maintenant dans du lourd. Fini la notion de grande ferme, voir deux ou trois fermes. Nous avons ici une ferme de services, une ferme de publication, une ferme de MySites, une ferme collaborative….
Bien sûr, bonjour les licences mais en contrepartie, quel plaisir pour la gestion, que ce soit en fail over, en montée de charge, cette topologie est la topo revée de chaque IT Pro qui aime SharePoint :)
Les points marquants sont:
- Les services d’entreprises sont gerés par l’IT de façon centralisée
- la geo distribution peut se faire via des fermes multiples de services
- La gestion de la croissance se fait:
- par l’ajout de FrontEnd servers et de servers applicatifs
- une nouvelle BU peut s’ajouter de différentes façons:
- nouvelle ferme
- nouvelle collection de sites dans les fermes existantes
- nouvelles webapps dans les fermes existantes
- Ne pas perdre de vue le Disaster and Recovery Plan, qui sera forcément plus lourd.
On voit donc, ici, qu’avec une ferme de services, on va pouvoir partager ces services entre différentes fermes, qui font des choses tout à fait différentes. Cette ferme de services sera forcément gérée, vu la complexité et la taille, par l’IT et non pas par des users, fussent-ils power…
Beaucoup de souplesse dans cette construction… j’adore.
Christian
Je suis en effet bien arrivé à Las Vegas pour la Conférence. Bon, avec un jour de retard mais cela commence à être une habitude, je m’y fais donc.
Je profite de l’occasion pour remercier Bill et Redo, mes patrons, de m’avoir donné l’occasion de venir à Vegas pour cette conférence, en compagnie de Renaud. Ca fait beaucoup de sous que nous avons essayé de dépenser à bon escient :)
J’ai préféré consacrer mon temps à choisir puis suivre les sessions plutôt que de blogguer pendant les sessions.
Je n’ai pas l’habilité de mon collégue Renaud qui fait admirablement bien les deux en même temps. Moi, j’en perds la moitié pendant que j’écris l’autre :)
Or donc, cette conférence est un succès de foule, plus de 7.400 participants, jamais égalé… Un buzz d’enfer et une version qui promet beaucoup à défaut d’en montrer autant.
En effet, certaines sessions se passent plus ou moins bien, en fonction des bugs encore présents, mais comme il s’agit d’une pré-beta, il serait bien mal venu de se plaindre.
J’ai donc, fidèle à moi-même, suivi les sessions IT Pro, laissant les dev à Renaud et je vais vous en faire rapport, en tout cas des sessions les plus importantes à mes yeux.
A tout de suite donc…
Vous connaissiez déjà Wygwam sous l’angle de l’expertise technologique ainsi que sur nos implications communautaires.
Aujourd’hui, Wygwam ouvre un tout nouveau pôle FORMATION.
En partenariat mondial avec la société Combined Knowledge (www.combined-knowledge.com) Wygwam vous délivrera, en Français, les formations SharePoint de Combined Knowledge.
C’est donc l’expérience technologique de Wygwam, combinée avec l’expérience pédagogique de Combined Knowledge que nous 
vous délivrons dans ces formations exceptionnelles.
Première formation
Pour fêter l’événement, nous avons le plaisir de vous inviter à notre première formation officielle pour utilisateurs finaux « Formation utilisateur SharePoint : Produire, collaborer et gérer les sites »
Elle se déroulera du 21 au 24 septembre prochain à l’hôtel Mercure Lille Métropole à Marcq en Baroeul.
Pour plus d’informations, pour connaître le programme détaillé et découvrir nos conditions « Première », rendez-vous sur notre site.
Pensez Wygwam
Dès à présent, pour vos formations SharePoint, pensez Wygwam !
Christian
Et pas tout seul, Renaud aka TheMit sera également de la partie.
Ceci promet une belle série de posts en perspective car, bien entendu, nous allons essayer de vous faire participer en direct à l’évènement.
Il n’est pas encore trop tard pour s’inscrire, j’ai trouvé, grâce à un collègue SharePointeur, un hôtel assez génial: Le Luxor.
Bon marché (quand je dis bon marché, ca veut vraiment dire bon marché puisque la nuit coûte moins de 50 $) , à côté du Mandalay Bay, qui héberge la Conférence, et à proximité immédiate de l’aéroport (pour éviter les frais de taxi trop importants :) )
Pour le prix, ca vaut la peine non ? Ah si on avait ça à Paris, la vie de consultant serait plus simple.
C’est là que nous allons parler et entendre parler de SharePoint 2010. Je n’ai pas dit que nous allions découvrir SP 2010 :) mais nous aurons finalement l’autorisation d’en parler publiquement… Et nous aurons des choses à dire.
Au plaisir de vous voir à Vega
Christian
Ca fait longtemps, trop longtemps que je n'ai rien publié sur ce blog.
A un tel point que je me demande si j'ai encore des lecteurs.
Mais bon, je viens de prendre une bonne résolution: je vais m'y remettre.
La matière ne manque pas: Office 2010 , vNext (oui, enfin là, faudra attendre fin octobre et la conférence de Las Vegas pour avoir plus d'information).
Ceci dit, une des raisons de mon désinstérêt momentané pour ce blog, c'est Twitter. En effet, j'aime disposer de l'info immédiatemment, ce qui est le cas sur Twitter. Et le fait de pouvoir faire des recherches et pouvoir filtrer me donnent satisfaction. Je ne voyais plus l'intérêt de poster quelque chose qui était déjà largement divulgué sur Twitter...
Mais bon, ce blog sera le complément dans la durée de mes twitts !
Pour info, vous pouvez me suivre à http://www.twitter.com/chris_hougardy
A très bientôt
Après cette journée bien remplie, voici l’agenda prévu pour demain mardi :)
Kerberos Part 1: no ticket touting here. Does SharePoint add another head?
Spencer Harbar Bob Fox
Search can be your best friend you just need to know how to talk to it.
Agnes Molnar
IT107
Office SharePoint Server Patching: Notes from the Field
Neil Hodgkinson
IW308
Business Data Catalog in theory and practise
Nick Swan
Robert Foster
IT109
IT Pro Ask the Experts Panel part 1
Open Mic for delegates to try and stump the panel of IT Pro experts.
Et là, il sera déjà 17:30 h , l’heure de préparer l’agenda de mercredi.
Mike, de chez Quest (collègue donc de Joel Oleson) nous a gratifié d’une session géniale sur l’utilisation de SQL avec SharePoint.
Partant du principe que SQL se laissait installer, selon lui, sur n’importe quoi, il a devisé, pendant une heure trente sur les multiples façons d’installer, de configurer et d’optimiser les servers SQL.
Il nous a montré, contrairement au vieux mythe qui déclare que “SQL is not scalable” '(SQL n’est pas extensible, on ne peut pas ajouter facilement des servers), comment configurer correctement sa ferme de serveurs SQL.
Comment éviter, dès le départ, de se retrouver bloqué lorsque le total des data à conserver dans SQL devient trop important.
Comment calculer les accès en fonction des IO , etc…
Sa présentation est déjà online sur son server mais sera également disponible sur le DVD post-conférence. Par contre, je ne sais pas si ce DVD sera disponible uniquement pour les participants ou s’il sera mis en vente.
Sa seconde session de la journée , en compagnie de Steve Smith, portera sur le Capacity Planning et fera l’objet d’un autre post.
MythBusters – debunking common SharePoint Farm Misconceptions - Spencer Harbar
C’était donc la première session de ma conférence, et pas n’importe laquelle puisque présentée par Spencer.
Ce dernier a profité pour enfoncer certains mythes que l’on retrouve régulièrement dans le monde SharePoint, à savoir, et par exemple:
-Kerberos va accèlerer le fonctionnement de votre ferme
-SharePoint n’est pas “scalable”
- il n’existe pour ainsi dire pas de “chiffres d’or” qu’il faut ou ne faut pas dépasser
J’en passe et des meilleurs.
J’aurai l’occasion de revenir plus tard et plus en profondeur sur le contenu de cette session car je la trouve particulièrement interessante.
European SharePoint Best Practices Conference
European SharePoint Best Practices Conference
Suis arrivé cet après midi à mon hotel (Comfort Inn Victoria) à proximité du Queen Elizabeth II Conference Centre après un voyage en Eurostar sans problème.
La journée commencera demain à 10:45 h après le keynote de Joel Oleson avec
IT101, MythBusters – debunking common SharePoint Farm Misconceptions - Spencer Harbar
This interactive, whiteboard session will dive into common SharePoint Farm Myths and discuss common misconceptions around Global Deployments, Farm Topologies, Shared Service Providers, High Availability, Security and more. Alongside best practices for each “myth”, the SharePoint “magic numbers” will be covered and there will be plenty of scope to discuss any particular queries you may have on farm deployment
Mon pote Spence, ca ne peut pas être mal.
Tiens, je profite de l’occasion pour dire que Spencer Harbar était un des tous premiers à suivre la formation de Master en SharePoint organisée ces deux dernières semaines à Seattle. Rien que cela en dit beaucoup plus que ce que je pourrais bien écrire.
Son blog est une mine d’informations et, tout particulièrement, propose une liste de tous les SP, mises à jour, patches etc… disponibles pour WSSv3 et MOSS.
A demain donc pour un compte rendu online .
Christian
Comme j’ai eu l’occasion d’en parler dans le post précédent, je serai à Londres la semaine prochaine pour la Conférence sur les bonnes pratiques.
Cette conférence en est déjà à sa troisième édition, après Washington en septembre dernier et San Diego en février, et sera donc la première en Europe.
Elle n’est pas organisée par Microsoft et est donc, de ce fait, la plus grande conférence sur et autour de SharePoint, organisée en dehors des circuits habituels.
Je vous laisse découvrir l’agenda, ou vous aurez l’occasion de voir que tous les utilisateurs, qu’ils soient IT, Dev ou décideurs, auront du pain sur la planche.
A vous voir à Londres.
Christian
J’ai reçu, ce premier avril (ce qui donne toujours un caractère un peu particulier à la chose), un mail de Microsoft m’annonçant que j’étais récompensé pour mes contributions et mon aide à la communauté en général, par un award MVP.
Celui-ci est le 8eme et je devrais donc être habitué, mais non, c’est toujours avec un vrai plaisir que je vois arriver ce mail du 1er avril :)
J’en profite pour reprendre le fil de ce blog là ou je l’ai laissé il y a trop longtemps…
Je serai la semaine prochaine à Londres pour la Conference sur les Bonnes Pratiques et j’essayerai, pour autant que le wifi le permette, de rapporter ce que je vois en temps (presque) réel.
Christian
Une étoile brillante s'est éteinte au firmament des SharePointers.
Patrick Tisseghem nous a laissé, mercredi soir, pour voguer vers d'autres cieux, que je lui souhaite cléments, et aller retrouver David Boschmans, à peine un an et un mois après le départ de ce dernier.
J'avoue ne savoir quoi dire tellement cet évènement est inattendu.
Patrick était un personnage légendaire dans le monde de SharePoint, ceux qu'il a aidé se comptent par centaines, lui qui était toujours aussi discret et presque effacé...
Je présente mes sincères condoléances à sa famille et ses proches.
Patrick, tu nous manques déjà...à bientôt
Christian
Et pour cause...
Alors que je configure une nouvelle machine virtuelle qui servira de base à toutes nos machines à venir, je passe un temps fou, mais alors vraiment fou à regarder une barre d'installation qui ne progresse pas....
La machine, composée de Windows 2008 Server Ent, SQL 2008 ENT ainsi que Visual Studio (ne me demandez pas pourquoi j'installe ce truc, je n'en suis pas l'utilisateur principal...) nécessite le SP1 de VS2008 pour pouvoir fonctionner avec SharePoint 2007.
Et c'est là que ca commence à devenir redoutable. Ca fait plus de deux heures que je regarde le soft d'install avec un désespoir sans cesse croissant...
J'ai bien entendu vérifié qu'il n'était pas planté... Non, non, ca fonctionne mais alors comment...
Inutile de dire qu'on peut s'attendre rapidement à un patch qui va patcher le patch, rien que pour corriger ce problème d'installation. Il est en effet insupportable d'attendre deux heures pour installer VS et encore deux heures pour le premier SP. Ca va donner quoi quand il y en aura deux ou trois ??? :)
Je vous raconterai mon retour d'expérience avec un box en 2008 complet dès que j'aurai un peu le temps.
Vous entendez souvent dire qu’on attaque pas en direct une DB SQL quand on fait du SharePoint sous peine de faire un dégât que l’on ne soupçonne pas toujours. Et c’est vrai, il y a peu de choses positives à faire, alors que le contraire n’est pas vrai.
Je vais aborder ici le plan de maintenance qu’un administrateur de bases de données (DBA) (tant SPS que SP ou WSS v2 et v3) peut effectuer sans danger.
Le wizard de configuration permet de lancer les tâches de maintenance suivantes :
- Contrôle d’intégrité de la base de données
- Réduction en taille de la base de données
- Réorganisation de l’index
- Effacer l’historique
- Mettre les statistiques à jour
- Reconstruire un index.
Dans le tableau ci-dessous se trouvent les recommandations de Microsoft sur les tâches à faire et à ne pas faire ;
| Tâche | Faire ou pas ? |
| Contrôler une DB | Oui |
| Réduire la taille d’une DB | Oui |
| Réorganiser un index | Oui |
| Effacer l’historique | Oui |
| Mettre à jour les statistiques | Oui mais cette tâche n’est pas nécessaire parce que le Timer de SharePoint se charge de le faire automatiquement |
| Reconstruire un index | Non. Cette tâche ne permet pas une restauration des options de l’index avant la reconstruction. Il est par contre possible d’utiliser des scripts qui restaurent ces options. Ce problème ne concerne pas SQL 2005 avec le SP2 |
Les critères suivants ont été utilisés pour déterminer si la tâche était sans danger ou pas.
. Si la tâche modifie le schéma de la base de données
. Si la tâche impacte de façon négative les performances.
Les résultats peuvent, bien entendu, dépendre de l’environnement. Pourtant, si vous utilisez l’utilitaire du plan de maintenance pour réaliser des tâches qui sont listées ci-dessus comme sans danger, il est fort probable qu’une augmentation des performances en résultera.
Voici les références des KB qui supportent ce post :
841057
930887
En suivant le premier lien, vous aurez un aperçu de ce qu’il est possible de faire subir à une base de données et qui aura des résultats que vous n’escomptez pas sur votre environnement SharePoint.
Et oui, la gouvernance SharePoint, c’est aussi du SQL J
A côté des outils professionnels de gestion et de gouvernance édités par Microsoft et dont je parlerai plus dans un autre post, il existe une série d’outils gratuits que l’on peut trouver sur Codeplex et qui aident les responsables IT à gérer leur ferme. Ces outils, à en juger par le nombre de téléchargement sur le site, sont encore peu connu, alors que bien souvent, ils peuvent vous sauver la mise ou vous donner des informations précieuses sur l’état de votre (vos) ferme(s)
En voici quelques uns, parmi les plus utiles, à mon avis bien sûr :
1.Microsoft IT Site Delete Capture LE 1.0
Cette feature permet de faire un snapshot d’un site lorsqu’il est effacé et en sauvegarde le contenu dans un directory.
Vous savez qu’il n’est pas possible, sauf à avoir un DBA de classe, de restaurer un site effacé, cela ne se fait qu’au niveau de la collection de sites.
L’outil va, dès lors, utiliser deux méthodes différences en fonction qu’il s’agit d’une collection de sites ou d’un site. Il s’agira de SPSiteCollection Backup et de SPExportSettings.
Vous me direz qu’il s’agit de commandes « Stsadm » et vous aurez bien raison, le truc était ici de créer un snapshot pour faciliter le backup-restore.
2.MSIT Site Life Cycle Management
Un peu comme le précédent, l’outil MSIT SLCM va vous aider à réaliser un backup puis un delete des sites qui ne sont plus utilisés. L’outil, en plus, notifiera automatiquement le processus à l’administrateur du site en question.
3.MSIT SharePoint Reporting Framework v2.1.0
Il s’agit ici d’un outil précieux qui va faire usage de SQL pour générer des rapports contenant des informations récoltées sur une ou plusieurs fermes.
Ces informations sont, entre autres :
- URL des sites
- Site Admin
- Poubelle (espace disque utilisé)
- Bande passante utilisée par site
- Taille des sites
- Taille des quotas…
On voit ici tout le parti que l’on peut tirer de ce genre d’outils.
4.TweakSP Central Admin Extensions
Il s’agit ici d’un outil qui ajoute des fonctions à la console d’administration.
Ces fonctions, qui existent déjà mais sont disséminées sont, par exemple, la taille des db, la hiérarchie, les fichiers de log etc…
Comme vous pouvez le voir, sans devoir dépenser une fortune en licences, il est déjà possible de disposer d’outils mis au point par Microsoft, souvent pendant la période de beta de SP d’ailleurs, qui donneront déjà des informations importantes sur la santé de votre solution.
Je vous laisse découvrir les autres
Souvent, lors de présentations que je donne, j’aborde la notion de performance de la plateforme SharePoint en termes de SLA (Service Level Agreement ou accord de niveau de service).
Cette notion n’est pas nouvelle mais, transposée aux systèmes informatiques, elle ouvre de nouveaux horizons.
Quel est l’objectif du SLA, pour un IT, au sein de l’organisation qui l’emploie ?
Il s’agit de garantir la disponibilité du système informatique et remédier aux périodes d’indisponibilité en fonction de l’investissement que l’organisation est prête à faire en matière de hardware et de personne.
Ainsi, on parlera de SLA à 90 %, 99 % jusqu’à, ce qui est considéré comme ce qu’il se fait de mieux, 99.99999 %
Néanmoins, et surtout pour des raisons financières, garantir un SLA de 99.999 % est déjà une obligation fort contraignante, comme nous allons le voir.
Plantons tout d’abord le décor, en précisant quels sont les termes utilisés, outre SLA en matière de disponibilité de système informatique :
· Temps de réponse (response time)
· La robustesse (robustness)
· La capacité à monter en charge (scalability)
· Disponibilité (availability)
On parle d’architecture à haute disponibilité à partir d’un SLA de 99.99%
Pour chiffrer cette disponibilité, il est nécessaire de déterminer les bons paramètres :
· L’uptime : c’est la période de temps ou le système fonctionne correctement, depuis son démarrage ou son redémarrage
· Le MTBF (mean time between failures) : c’est le temps moyen entre deux interruptions de service. Ce MTBF ne prend pas en compte les pannes récurrentes dues, par exemple, aux défauts de fabrication du hardware ou à son usure.
· L’AFR (annualized Failure Rate) qui représente le nombre de composants à changer chaque année
· Le dowtime qui représente la période de temps ou le service n’est pas assuré
· Le MTTR (mean time to repair) représente le temps moyen nécessaire à la réparation et à la restauration du service
· L’AST (agreed service time) qui est, en fait, l’accord que vous avez avec l’organisation au sujet des exigences de continuité de service.
Il existe plusieurs méthodes pour calculer le temps de disponibilité (D), celle que j’utilise est celle-ci
D = 
L’organisation calculera plutôt de cette façon :
D = 
Une troisième façon de calculer sera
D = 
Comment améliorer notre SLA ?
En améliorant le MTBF par exemple. Ceci peut être fait en assurant la redondance du hardware (router, firewall, carte réseau…), la redondance du l’infrastructure logicielle (Network Load Balancing, SQL clustering…)
Il est possible de réduire le MTTR en assurant la formation des équipes chargées de la maintenance, tant logicielle que hardware, en définissant des procédures claires et détaillées et en utilisant des procédures de monitoring (ce point particulier fera l’objet d’un article détaillé dans le futur proche)
A titre d’exemple, vous trouverez dans le tableau ci-dessus les temps d’indisponibilité réels en fonction du pourcentage de SLA
| Downtime |
| Disponibilité | En sec. Par an | En min par an | En heures par an | En jours par an |
| 90 % | 3 155 760 | 52 596 | 877 | 37 |
| 98 % | 631 152 | 10 519 | 175 | 7 |
| 99 % | 315 576 | 5 260 | 88 | 4 |
| 99.8 % | 63 115 | 1 052 | 18 | |
| 99.9 % | 30 558 | 526 | 9 | |
| 99.99 % | 3 156 | 53 | | |
| 99.999% | 316 | 5 | | |
| 99.9999 % | 32 | | | |
| 99.99999 % | 3 | | | |
Ainsi donc, pour répondre à un SLA de 99.999 %, cela veut dire que votre système ne pourra pas être indisponible pendant plus de 5 minutes par an. Ce SLA est plus communément utiliser et porte le nom de « Règle de 5 neufs ».
Plus le pourcentage de SLA sera haut, plus l’effort en termes humains et de matériel sera élevé.
A vos calculatrices…
5. Education et formation
Parce que l’adoption de SharePoint par les utilisateurs est le secret de la réussite, l’éducation et la formation sont deux des outils qui vont permettre d’accéder à cette réussite.
Il ne s’agit pas ici, uniquement, de montrer et d’expliquer comment SharePoint fonctionne mais également d’aider les utilisateurs à créer des solutions pour les problèmes réels qu’ils rencontrent quotidiennement dans leur travail.
| Education et formation |
| Points | Que faire ? | Pourquoi le faire ? |
| Formations de départ | · Acquérir ou créer un modèle de formation pour les utilisateurs finaux ainsi que les ressources pour donner cette formation · Acquérir ou créer un modèle de formation ainsi que les ressources nécessaires pour le helpdesk · Créer un guide qui reprend toutes les prescriptions en matière de gestion en application au sein de l’organisation pour pouvoir s’y conformer · Acquérir ou créer un modèle de formation pour les développeurs · Créer un guide pour les développeurs qui reprenne toutes les prescriptions en vigueur dans l’organisation en matière de développement | Former les utilisateurs, tant à SharePoint, qu’aux différentes prescriptions en vigueur au sein de l’organisation est l’étape proactive la plus importante pour assurer la cohérence et la gestion de la plateforme SharePoint au sein de l’organisation. Non seulement faut il connaître ce que SharePoint permet de faire mais également ce qu’il est permis de faire au sein de l’organisation |
| Développement de Communautés | · Créer des forums de discussion online ou chacun pourra aider ses pairs et poser ses questions · Créer des opportunités de formation en environnement formel ou informel (pendant le déjeuner, en salle de classe…) | Certains échanges ne se font pas de façon optimale dans un cadre formel. Placer les utilisateurs dans les meilleures conditions pour communiquer sur leurs problèmes et attentes et montrer aux autres utilisateurs ce qu’ils ont déjà réalisé avec la plateforme peut se faire de multiples façons : déjeuner, pause café… |
| Formation permanente | · Prévoir des formations régulières qui permettront de mettre en évidence ce qui a été appris par un groupe auprès d’autres groupes de l’organisation · Réaliser régulièrement un audit de la plateforme pour découvrir quelles sont les possibilités qui ne sont pas ou mal utilisées. | Définir de façon formelle votre intention d’auditer régulièrement la solution implémentée d’un point de vue de l’utilisateur permet de remarquer quels sont les manquements et de déterminer quelles sont les formations supplémentaires nécessaires. Cela donne également le sentiment aux utilisateurs qu’on ne les abandonne pas. |
6. Navigation, Taxonomie et moteur de recherche
Ce dernier chapitre de notre plan de gouvernance aborde les points relatifs à la façon de trouver l’information, à savoir la navigation, la taxonomie et le moteur de recherche. Ces trois points sont réellement importants pour le taux d’adoption dans le long terme de la plateforme SharePoint car ils sont les outils de base qui vont permettre à l’utilisateur de trouver l’information qu’il cherche quand il ne sait pas ou elle est sauvegardée.
| Navigation, Taxonomie et Moteur de recherche |
| Points | Que faire ? | Pourquoi le faire ? |
| Répertoire des sites | · Définir la structure des répertoires de sites en y incluant tous les groupes importants ainsi que les associations · Développer une stratégie de liaison entre les différents types de sites tels que site d’entreprise, de pole, de département, d’équipe, etc. | Définir comment les sites vont être organisés est la démarche par laquelle il sera donné aux utilisateurs de retrouver l’information dont ils ont besoin. Développer une stratégie de liaison entre les différents types de sites devient une nécessité quand un seul répertoire devient trop important pour être encore géré de façon optimale en une seule entité. |
| Types de contenu | · Définir les types de contenu de base (core content types) au sein de l’organisation · Définir des champs clé pour établir un lien entre les documents et les systèmes opérationnels | La consistance mène à une plus grande aisance pour retrouver l’information. Cette consistance est encouragée par la promotion de l’utilisation de types de contenu standards |
| Fourchettes de recherche | · Créer des sources de contenu pour les différents sites ou est stockée l’information au sein de l’organisation · Promouvoir l’utilisation du BDC (Business Data Catalog) pour permettre la recherche d’information métier. | Le moteur de recherche est un outil prodigieusement riche qui est essentiel pour trouver de l’information au sein de l’organisation. Au plus il y a du contenu disponible à l’indexation, au plus il sera aisé, pour les utilisateurs, de trouver l’information dont ils ont besoin. |
| Relevance de la recherche | · Déterminer qui sera responsable de la définition des critères de recherche de base · Mettre au point des systèmes qui permettent d’éliminer le « bruit » lors de la recherche de fichiers, de mots clé ou de synonymes. | Bien que le moteur de recherche disponible dans SharePoint Server 2007 se soit beaucoup amélioré par rapport à ses versions précédentes, il n’en reste pas moins vrai qu’une plus grande efficacité peut être atteinte en réglant de façon très fine ce moteur. |
La définition du succès
La gouvernance de la plateforme SharePoint est un point sur lequel l’administrateur d’une ferme ne peut plus faire l’impasse.
C’est en développant un plan de gouvernance minimum, qui met clairement en évidence les processus et les communique de façon la plus large possible, qu’il sera possible d’avoir un taux d’adoption de la plateforme élevé tout en maintenant un niveau de contrôle approprié sans entraver l’utilisation journalière de la technologie SharePoint par les utilisateurs finaux.
2. Développement et configuration
La technologie SharePoint a rendu plus floue la limite entre ce qui est développement et ce qui est configuration. Il est vrai que la discussion de savoir si SharePoint est une plateforme collaborative ou une plateforme de développement est loin d’être terminée, avec ses farouches opposants et militants.Ce chapitre va couvrir ces deux parties, tant du point de vue de la configuration que du développement, parties essentielles du plan de gouvernance, permettant que les solutions qui sont implémentées soient cohérentes.
| Développement et configuration |
| Points |
Que faire ? |
Pourquoi le faire ? |
| Style maison |
· Créer les modèles qui vont déterminer à quoi les sites SharePoint vont ressembler· Déterminer quels types de sites pourront être ou pas modifiés· Déterminer quelles parties du modèle pourront être ou pas modifiées par l’utilisateur |
Utiliser un style maison ne va pas seulement donner l’impression que le site fait bien partie de l’organisation mais va également promouvoir une meilleure navigation ainsi qu’une meilleure organisation. Définir quelles zones pourront être changées ou pas créera la flexibilité nécessaire à l’adoption de la solution |
| Outils de customisation |
· Déterminer quels sont les outils de customisation qui pourront être utilisés (SharePoint Designer, etc.)· Déterminer de façon claire et communiquer quelles sont les actions qui seront ou pas autorisées avec ces outils (comme par exemple, customiser un site, ce qu’on appelait à l’époque de SPS2003 unghoster un site) |
Probablement chaque pole de l’entreprise souhaitera apposer sa marque (logo, couleurs…) sur son site.Le challenge sera de contrôler les modifications qui sont apportées par les différents pôles pour faire en sorte que cela ne soit pas un obstacle à la maintenance des sites. |
| Modèles et définitions de site |
· Etablir des lignes de conduite claires en matière de développement de définition de sites· Instaurer des politiques de déploiement de ces définitions de sites telles que par exemple les pré-requis pour une installation dans la GAC… |
Gérer les modèles (templates) et les définitions de site sont déjà un challenge dans une organisation de taille moyenne.Communiquer dès le début du projet les décisions qui sont prises en matière de gestion de ces templates et définitions de site, et le faire sans ambiguïté, permettra de gérer de façon optimale les remontées des différents groupes d’utilisateurs |
| Code source et « build control » |
· Déterminer s’il est nécessaire d’avoir un repository global pour tous les codes installés sur la plateforme (TFS, etc.…)· Etablir les standards pour la création de composants, tant sur un serveur central que les lignes de conduite pour la création de logiciels· Assurer que le code sera documenté, les avertissements pris en compte… |
Le Code Source est le cœur même des améliorations de SharePoint apportées à votre organisationEtablir une liste stricte de ce qui peut être attendu et de règles au sujet du développement de code ne pourra que rendre le processus de maintenance plus aisé et conduira à un système beaucoup plus stable. |
| Support pour les bugs |
· Déterminer les responsabilités de chacun en matière de support |
Il est inévitable que des bugs soient trouvés dans le code et ce, parfois, longtemps après le déploiement.Savoir à qui s’adresser le cas échéant pour être certain que ces bugs soient corrigés est essentiel pour la survie à long terme de la plateforme SharePoint. |
| Développements standards |
· Etablir des règles claires déterminant quelles « Assemblies » pourront être installées dans le GAC et celles qui ne le pourront pas· Etablir des règles au sujet de l’utilisation de l’attribut « AllowPartiallyTrustedCallers » |
La sécurité d’un site est déterminée par le code qui est autorisé à tourner sur ce site et avec quelles permissions.Les accès de sécurité du code .NET et les implications du déploiement dans le GAC sont important pour la maintenance d’un niveau de sécurité suffisant. |
3. InfrastructureAlors que la plus grande partie des points d’infrastructure peuvent être considérés comme des détails d’implémentation, il en est pourtant qui auront un impact significatif sur la façon dont SharePoint sera déployé et quelles « features » seront disponibles.Les points d’infrastructure que j’énonce ci après sont suffisamment importants pour être inclus dans le plan de gouvernance parce qu’ils ont un impact sur la façon dont la plateforme sera utilisée.
| Infrastructure |
| Points |
Que faire ? |
Pourquoi le faire ? |
| Firewalls |
· Déterminer les règles qui vont régir les connexions, au départ des servers web, des web parts d’édition de contenu et de visualisation de flux RSS |
La bonne pratique veut qu’on n’autorise pas les serveurs à accéder directement au web.Donner la possibilité d’inclure du contenu venant d’un autre site au moyen d’une web part d’édition de contenu ou au travers d’un flux RSS peut créer une exposition à des attaques de style « cross site scripting ».Contrôler à quels sites extérieurs il est possible d’établir des liens est non seulement un point opérationnel mais également de sécurité. |
| Load Balancing |
· Décider et communiquer au sujet de la configuration du load balancing en matière de rémanence de session |
Les développeurs doivent savoir s’ils peuvent s’attendre à ce qu’une session simple soit transférée sur un autre serveur |
| Environnements |
· Déterminer quels environnements seront utilisés pour développer et pour tester les solutions dans SharePoint.· Définir les critères de développement et de test pour chaque environnement. Communiquer les règles de déploiement tel que la nécessité pour un template de faire usage de la GAC |
Définir les environnements de test et de développement aide les utilisateurs et les développeurs à savoir de quelles ressources ils peuvent disposer pour tester les modifications et les développements sans impacter l’environnement de production.En matière de développement, il est devenu monnaie courante d’utiliser des machines virtuelles (avec des licences MSDN), par contre, la ferme de qualification (ou pré production) doit être aussi proche que possible de la ferme de production. Ce qui induit des coûts parfois importants. |
4. Préoccupations d’ordre opérationnelLa gestion d’une plateforme SharePoint, comme c’est le cas de tout environnement déployé à grande échelle, a plusieurs facettes.Ces différentes facettes, qui sont une partie importante de votre plan de gouvernance parce qu’elles assurent que le système va rester opérationnel et qu’elles déterminent les attentes que les utilisateurs peuvent avoir de SharePoint, sont reprises dans la liste ci-dessous.
| Préoccupation d’ordre opérationnel |
| Points |
Que faire ? |
Pourquoi le faire ? |
| Monitoring |
· Monitorer au niveau SharePoint, du server et du site· Définir les réponses à apporter pour chaque type de problèmes qui pourraient arriver |
Un système qui n’est pas accessible n’est pas utilisable par les utilisateurs. C’est une évidence. Avoir une approche multidimensionnelle de la surveillance du système favorise une meilleure prise de conscience des problèmes de la plateforme. |
| Uptime et Downtime |
· Définir un agenda reprenant les périodes d’indisponibilité (downtime)· Communiquer la procédure à utiliser pour signaler une période de downtime qui n’aurait pas été annonçée ou tout problème de performance· Définir la procédure de réponse à toute période de downtime non agendée. |
Déterminer des périodes pendant lesquelles le système ne sera pas disponible est critique pour permettre de faire des mises à jour, d’appliquer des correctifs.Publier les processus en cas de downtime non agendé permet de rassurer l’utilisateur final quand une interruption non souhaitée arrive. |
| Récupération de désastre |
· Plan de récupération d’un fichier (par exemple via le versionning ou la poubelle de site)· Plan de récupération d’un ou plusieurs sites· Plan de récupération d’un serveur· Plan de récupération d’une ferme géographiquement distribuée |
Un désastre peut toujours arriver. Ce n’est pas une question de si mais bien de quand et comment.Les prévoir renforce le taux d’adoption de la plateforme (sensation de sécurité) ainsi que l’impression que le serveur sera toujours opérationnel. |
| Récupération de data et de documentation |
· Codifier l’utilisation des besoins de gestion en terme de dossiers (« records management ») au sein de SharePoint· Définir les règles d’archivage de sites, ceci y compris les avertissements et les approbations. |
La technologie SharePoint peut aider à la gestion des problèmes rencontrés en matière de gestion de dossiers, à savoir la conservation de trop ou trop peu d’informations.Définir comment SharePoint fonctionnera à cet égard permet de s’aligner sur les règles de gouvernance de l’organisation . |
| Quotas |
· Etablir des quotas d’archivage par type de site· Etablir un processus de requête d’augmentation des quotas |
La gestion de l’archivage est de la responsabilité de tous les utilisateurs de l’organisation.La mise à disposition de lignes de conduite peut aider à un contrôle raisonnable de la consommation d’espace disque. |
| Rapportage |
· Définir quels sont les rapports d’audit nécessaires au bon fonctionnement· Etablir un rapport d’utilisation de l’espace d’archivage· Développer un rapportage à l’usage des administrateurs des différentes activités |
Le rapportage sur ce qui a été fait est essentiel pour définir les besoins.Encourager le rapportage des activités et de l’archivage des données permet de créer une boucle de feedback nécessaire à l’organisation pour comprendre la plus value qui est dérivée de l’utilisation de la plateforme SharePoint. |
A suivre J
Comme j’ai déjà eu l’occasion de le dire à maintes reprises, je vais essayer de poster ce que je pense être important à savoir en matière de gouvernance SharePoint.
Je ne vais pas numéroter mes posts car je suis incapable de dire combien il y en aura. En fait, ce blog devrait être, dans les prochains mois, quasiment dédicacé à la gouvernance.
Ainsi donc, puisque gouvernance il y a, il me semble logique de commencer par expliquer ce qu’il y a lieu de comprendre par ce terme, de plus en plus utilisé ces derniers temps.
La gouvernance, selon Wikipedia, permet d’aligner le système d’information (tactique) sur les métiers de l’entreprise (stratégie) ; l’objectif étant de piloter et contrôler la participation du Système d’information à la création de richesse. Le SI est un investissement, l’enjeu est de mesurer le Retour sur Investissement (ROI).
Je compléterai cette définition en ajoutant que la gouvernance « manage » le déploiement des technologies de l’information. Manager, comme dans management de projets, c’est prendre en considération les risques, les coûts et l’utilité de la solution, une fois déployée. Il est donc raisonnable de résumer la gouvernance à : essayer de contrôler les risques, coûts et adoption du système informatique.
Il est important de faire la balance entre ces différents objectifs, trouvant une voie qui ne sera ni trop contraignante ni trop lâche. Il n’est pas possible d’avoir un taux d’adoption très large sans gérer la gouvernance, de même qu’exercer une gouvernance trop serrée irait à l’encontre du pourcentage d’adoption en bloquant les utilisateurs dans leur créativité.
Maintenant que le concept de gouvernance est un peu plus clair, il est temps d’envisager les différentes catégories qui seront importantes dans votre gouvernance de SharePoint.
Il s’agit principalement de :
1. Gestion opérationnelle et de projet
2. Développement et configuration
3. Infrastructure
4. Problèmes d’utilisation
5. Education et formation
6. Navigation, taxonomie et moteur de recherche.
Les chapitres suivants iront plus avant dans le détail de chaque domaine et essayeront de décrire les sujets qu’il y aura lieu d’inscrire à votre plan de gouvernance.
Chaque chapitre contiendra un tableau qui indique le nom d’un groupe d’actions ou de décisions (sujets), les actions spécifiques à apporter (Que faire ?) ainsi que les raisons sous-jacentes (Pourquoi le faire).
L’objectif ici étant clairement de vous fournir, à vous lecteur, tant un guide pratique pour créer votre plan de gouvernance que de vous donner un éclairage de fond sur les différents sujets, de sorte que vous soyez à même d’identifier de nouveaux sujets, propres à votre organisation, et les ajouter ainsi à votre plan de gouvernance.
1. Gestion opérationnelle et de projet
Ce sujet comprend l’approche traditionnelle de la gestion de projet ainsi que les problèmes qui pourraient être décrits de façon plus formelle comme gestion opérationnelle car ils font plus référence à la gestion de la plateforme et non pas à la gestion de projet associée à la construction initiale. Dans ce chapitre, nous aborderons la construction ainsi que les différents points opérationnels qui nécessitent de prendre une décision dès le début du projet pour promouvoir la consistance.
| Gestion opérationnelle et gestion de projet |
| Points | Que faire ? | Pourquoi le faire ? |
| Communication | Etablir un plan de communication qui comporte : - Qui sera en charge de la communication - Quand cette (ces) communication aura-t-elle lieu ? - Quel sera le contenu des différentes communications ? - Quel sera le vecteur de la communication ? (mail, document, newsletter…) Etablir un point de contact central pour tous ceux qui ne sont pas directement impliqués dans la gouvernance. | Etablir une attente au sujet de la nature des différentes communications ainsi que de leur contenu, aidera les utilisateurs à comprendre comment contacter l’équipe en charge du projet ainsi que de leur ouverture à la discussion et facilitera l’adoption du projet. |
| Processus de déploiement | Définir un processus qui sera utilisé pour le déploiement des applications développées en interne ainsi que des logiciels achetés sur la plateforme SharePoint. | Définir le processus de déploiement génère une compréhension claire de la part des équipes de développement au sujet de ce qu’ils peuvent attendre si leur logiciel est installé sur la plateforme. Cela élimine les problèmes de dernière minute pendant le déploiement et réduit d’autant le nombre de versions nécessaires, et par voie de conséquence, les couts de management. |
| Modifications du processus de gestion | - Définir comment les modifications seront suivies, cataloguées et approuvées ; - Décider quel support sera utilisé pour conserver les anciennes versions de configuration, de code et des composants de la solution | L’accès permanent aux données est primordial, gérer les modifications et différentes versions des développements permet de gérer de meilleure façon cet accès. De la consistance dans l’approche, la gestion des responsabilités de chacun encourage une plus grande stabilité de l’équipe ainsi qu’une appropriation du projet meilleure. |
| Attribution des budgets | - Décider si des budgets seront alloués au niveau des unités de travail ou pas ; - Dans la négative, décider où la gestion des coûts sera effectuée et par quel moyen | La gouvernance SharePoint en général et la plateforme technologique SharePoint en particulier coûtent beaucoup d’argent. La gouvernance implique, dans la majorité des cas, une plateforme centralisée. Trouver les fonds pour réaliser cette plateforme est essentiel et parfois pénible. |
| Sponsorisation | - Etablir un comité de gouvernance de SharePoint pour vérifier les contrôles ainsi que l’adoption - Solliciter un membre de l’exécutif de l’entreprise pour être l’avocat de la plateforme et attirer l’attention du management sur l’initiative - Encourager les responsables de service au fait de SharePoint à partager leurs connaissances avec leurs pairs | La plateforme SharePoint possède le potentiel pour modifier de façon radicale (mais pour le mieux) la façon dont un logiciel est développé ou la façon dont les projets sont menés. Il n’en reste pas moins que si l’équipe de management de la société ne le comprend pas que les utilisateurs n’ont pas envie d’utiliser les possibilités qu’offre SharePoint, les chances de succès du déploiement au sein de l’entreprise se présenteront sous de mauvais auspices. |
| Rôles et équipes | - Il est important de définir clairement les rôles et les responsabilités de chacun, tant au niveau de l’apprentissage qu’au niveau de la gestion de la plateforme SharePoint. - Définir une équipe stratégique pour s’occuper des problèmes stratégiques - Définir une équipe pouvant travailler de façon verticale et horizontale et qui sera en charge des problèmes plus complexes qui pourraient arriver entre les différentes unités de la société. | Il est important de définir, dès le début du projet, et ce de façon claire, les rôles de chacun et de créer les équipes qui seront à même de répondre à tout genre de problèmes qui pourrait survenir pendant le déploiement de la plateforme pour ne pas mettre celui-ci en danger. |
| Classification de la plateforme et des sites | - Créer une classification par nombre d’utilisateurs et par longévité : entreprise, département, équipe, projet et personnel. - Créer une classification par type d’utilisation : portail de communication, applications de BI, collaboration pour faciliter le fonctionnement des équipes. | Expliquer de façon logique les solutions disponibles au sein de l’organisation, ainsi que les moyens pour communiquer avec les composantes de cette organisation. |
| SLA (Service Level Agreements) | - Créer un SLA au sujet du temps nécessaire ainsi que l’approbation pour la création d’un site - Créer un SLA pour la résolution des problèmes via le helpdesk - Négocier un SLA au sujet des performances, lors du premier chargement du site dans un browser, lors des chargements suivants et la performance lors de l’utilisation en remote. | Créer des SLA permet de savoir comment fonctionne la plateforme et ce qu’on peut en attendre et dans quels délais. Les SLA’s sont des obligations que se donnent les gestionnaires de la plateforme vis-à-vis des utilisateurs, renforçant la confiance de ces derniers et augmentant le taux d’adoption. |
| | | |
L a suite au prochain numéro J
Christian
C'est en ces termes choisi que notre bien aimé CTO, MVP, RD, ami de patron a annonçé le wygday 2008 qui se tiendra la semaine prochaine à Lille.
Voici le lien pour les infos et surtout l'inscription, il est encore temps.
http://wygday.wygwam.com/
Voila de quoi, mes petits camarades et votre serviteur, auront l'occasion de vous entretenir pendant cette journée à ne rater sous aucun prétexte...
MOSS, Sharepoint .NET 3.5, ASP.NET 3.5 + SYNC Fx Silverlight 2.0 IIS 7.0 VSTO + OpenXML Interopérabilité + OpenXML Architecture technologique Live et Agents conversationnels Donc, à vous voir jeudi prochain, à Lille :)
Christian
(Wygteam member)
More Posts
Next page »