Nouvelle mission chez EDF
Missions et références
Depuis juin 2012 : Architecture technique SAP chez EDF :
- Etude de fusion des 8 instances SAP FI/CO pour la comptabilité EDF
- Etude d’un parcours de migration vers une solution de Cloud Computing pour SAP
- Rédaction de DATs (Document d'Architecture Technique) décrivant l'interface entre les besoins métier, les exigences de disponibilité/sécurité/confidentialité, les fonctionnalités du progiciel et les contraintes de production de l'infogérant
- Migration de 90 instances SAP : ECC6, BW, Sap Content Server, SAP PI, SAP GRC, Solution Manager : Interface entre la MOA EDF, la DSI EDF et l'infogérant
De février à mai 2012 : Groupe Casino à Saint-Etienne avec les objectifs suivants :
- Rationaliser et améliorer les procédures de copie/refresh d'instances SAP
- Gérer le projet de migration OS/DB de Windows/SQL Server vers Aix/DB2 de l'instance SAP orienté FI/CO
- Mener des campagnes de mesure et d'amélioration de performances SAP
- Qualifier et spécifier la mise en œuvre du monitoring des Business Processes avec Solution Manager
- S'intégrer à l'équipe de support N3 et y apporter son expertise
Décembre2011-Janvier 2012 : OTAN CEPMA (Central Europe Pipeline Management Agency)
Mise en oeuvre d'un PRA pour la production Oracle/SAP
Réalisation technique :
- Reprise de l’instance de production sur un serveur de secours
- Import ZFS des volumes répliqués au niveau de la baie de disques Compellent
- Paramétrage Oracle et SAP
- Recette technique et fonctionnelle
De janvier à septembre 2011 : Tereos (Industrie du sucre et des céréales)
Définition de l'architecture technique permettant d'exécuter les nouveaux environnements de production
- SAP ECC6 et Business Objects BI 4.0 : 40 000 SAPs
- Autres environnements SAP : GRC, APO, TDMS
- CI/DB Serveurs Sun M9000 + SAN HDS AMS2500
Gestion du projet de déploiement
- Rédaction du Plan Qualité de Projet
- Rédaction et suivi de planning
- Coordination des intervenants
Comment s'y retrouver dans tous ces standards ? Et le DSI de poursuivre : « J'ai formé mes équipes à ITIL, et maintenant vous venez me parler de Togaf, je n'y comprends plus rien. »
Et c'était aussi un sujet proposé chez Arismore à l'occasion d'une réunion d'architecte d'entreprise à laquelle je participais récemment. Comment intégrer Togaf avec les autres standards ?
J'ai proposé ce schéma qui a reçu un accueil très positif. Je vais donc le commenter : Lire la suite
Dans les phases de conception et de design Togaf (Vision de l'architecture, Architecture Business, Architecture des systèmes d'information, Architecture technique), on peut travailler avec des outils et des langages de modélisation tels que Archimate ou le langage UML
Les phases de solutions, de planification et de mise en oeuvre s'ouvrent sur les tehcniques de gestion de projet telles que Prince2 ou PMBOK
Enfin, lorsque l'on arrive à la phase de gestion du changement, il est clair que l'on arrive dans des domaines familiers à ITIL
Si l'on veut entrer dans plus de détails, voyons comment l'on peut interfacer Togaf et Prince2. On peut alors remarquer les mêmes objectifs fixés par un contrat d'architecture Togaf avec un mandat de projet et un document d'initialisation de projet vus par Prince2. De manière similaire, une définition de chantier d'architecture Togaf et un cas d'affaire (Business Case) Prince2 répondent à la même préoccupation : s'assurer que le chantier d'architecture et le projet répondent bien à des besoins business, ont un sponsor, un objectif identifié et un budget.
Passons à la fin du cycle Togaf lorsqu'il s'agit de passer en production. C'est alors que les équipes ITIL peuvent entrer en jeu. Sans doute ne seront-elles pas dépaysées lorsqu'elles noteront la structure en cycle de Togaf, comparable au processus d'amélioration permanente ITIL V3. De manière similaire, TOGAF se construit avec un référentiel d'architecture (le continuum) contenant des Building Blocks, là où ITIL ne se conçoit pas sans la CMS (ex CMDB) référençant les CIs.
On voit donc que, chacun dans son domaine, partage les mêmes outils conceptuels, et que pour passer de l’un à l’autre il existe des passerelles facilitant le dialogue entre les différentes équipes. Du besoin et de la vision business jusqu’à la mise en production, il doit être possible de partager un même langage et un même objectif. De la production à la direction, il doit aussi être possible de comprendre les potentialités comme les limites de l’informatique.
On verra prochainement la question de la valeur de celle-ci. Vaste sujet
Écrire commentaire