Actualité

Dans PRINCE2 le Cas d’affaire représente la justification du projet et couvre généralement la durée, les coûts, les bénéfices et les risques. Il est fondamental pour valider la viabilité continue du projet.  

Qu’est ce que le Cas d’affaire ? Définition

L’un des principes de PRINCE2 veut que la projet démontre une justification continue pour l’Entreprise.

Le Cas d’affaire offre un ensemble d’informations utiles pour juger si le projet est (et demeure) opportun, viable et réalisable, en vue d’étayer les décisions concernant son investissement (continu).

 

Finalité du Cas d’affaire

Le but d’un Cas d’affaire est de documenter la justification de mise en oeuvre d’un projet, en s’appuyant sur une estimation des coûts (développement, mise en service et maintenance) par rapport aux bénéfices prévus tout en tenant compte des éventuels risques associés. Il doit définir la manière et le moment de mesurer les bénéfices prévus.

Durant le processus ‘Élaborer le Projet’, l'exécutif écrit l’ébauche du Cas d’affaire, ce sera ensuite au tour du chef de projet de détailler le Cas d’affaire pendant le processus ‘Initialiser le Projet’. Le Cas d’affaire sera finalement accepté et confirmé durant le processus ‘Diriger le Projet’.

Le Cas d’affaire est utilisé tout au long du projet. Il est utilisé durant le processus ‘Contrôler une Séquence’ pour évaluer les impacts des incidences et des risques. Il est revu et mis à jour à la fin de chaque séquence de management par le processus ‘Gérer une Limite de Séquence’ et à la fin du projet par le processus ‘Clore le projet’.

 

 

Composition du Cas d’affaire

La DIP devrait comprendre les éléments suivants :

Sommaire : souligne les points clés du Cas d’affaire, avec notamment les bénéfices importants et le retour sur investissement. Raisons : spécifie les raisons justifiant la réalisation du projet et explique comment le projet permettra la réalisation de la stratégie et des objectifs de la direction d’entreprise, du programme ou du client ; Options pour l’entreprise : une analyse et une recommandation raisonnée pour choisir entre les différentes options basiques pour l’entreprise : ne rien faire, faire le minimum ou faire quelque chose. Bénéfices attendus : la conséquence des résultats désirés à réaliser grâce à l’utilisation des livrables du projet. Les bénéfices sont exprimés en termes mesurables par rapport à la situation telle qu’elle existe avant le projet et doivent être à la fois quantitatifs et qualitatifs. Contre-bénéfices attendus : l’impact d’un ou plusieurs résultats du projet peuvent être perçus comme négatifs par une ou plusieurs parties prenantes. Les contres-bénéfices sont les conséquences réelles d’une activité, alors que, par définition, un risque est incertain et ne peut jamais se matérialiser. Période d'exécution : correspond à la durée de déroulement du projet (résumé du plan de projet) et à la période de réalisation des bénéfices. Coûts : donne un résumé des coûts du projet (extrait du plan de projet), des coûts des opérations courantes/maintenance et de leurs dispositions de financement. Evaluation de l’investissement : compare les bénéfices et les contre-bénéfices globaux aux coûts du projet et aux coûts des opérations incrémentales courantes et de la maintenance. Risques principaux : donne un résumé des risques clés liés au projet avec l’impact probable et les plans si les risques se matérialisent.  

 

Les données sources pour élaborer le Cas d’affaire

Dans PRINCE2, l’ébauche du Cas d’affaire reprend les éléments suivants :

• Le mandat de projet et l’exposé du projet concernant les raisons d’être du projet
• Le plan de projet pour ce qui concerne les coûts et les durées
• Les bénéfices attendus par les utilisateurs principaux
• Les informations concernant l’optimisation de l’investissement par l’exécutif
• Le registre des risques
• Le registres des incidences

 

Format et présentation du Cas d’affaire

Le Cas d’affaire peut se présenter sous les formes suivantes :

• Un document, une feuille de calcul ou des diapositives de présentation
• Une entrée dans un outil de management de projet

Le Cas d’affaire est à la base de tous les processus décisionnels et garantit que le projet conserve sa justification, que les besoins de l'entreprise peuvent être satisfaits et que les avantages escomptés peuvent être obtenus.

Téléchargez votre modèle de document personnalisable PRINCE2 2017 Cas d’affaire de QRP International.

PRINCE2® is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

La certification HERMES Foundation est une qualification professionnelle dans le domaine de la gestion de projet. Cette certification atteste de la compréhension de la méthode de gestion de projet HERMES. Il est avantageux, mais non indispensable, que les participants aient déjà une expérience de travail sur des projets.

Public cible

• Chefs de projet
• Membres d’équipes projet
• Contrôleurs
• Décideurs
• Membres du PMO
• Responsables qualité
• Responsables de pilotage

Format de l’examen HERMES Foundation

• Langues : Allemand, Anglais, Français
• Durée : 60 minutes
• Questions : 40
• Type : QCM à choix unique
• Matériel : Aucun document autorisé
• L’examen comprend 40 questions à choix multiple couvrant les domaines suivants :
  • Principes de base de HERMES (notamment structure méthodologique, vues, phases, livrables, tâches, rôles, modules et scénarios)
  • Domaine d’application et structure du scénario standard « Service – Produit »
  • Modules du scénario standard « Service – Produit »
  • Organisation de projet (rôles) du scénario standard « Service – Produit »

Pour réussir l’examen, une connaissance de base de HERMES et de la gestion de projet est requise. Il est recommandé de suivre une formation de 2 à 3 jours. Vous obtiendrez comme avantages une amélioration durable de la qualité des projets, une réduction des risques d’exécution et la capacité à créer des scénarios personnalisés pour vos projets.

Questions types de l’examen HERMES Foundation

L’examen comprend 40 questions types à choix unique. Chaque question a une seule bonne réponse. Une réponse correcte vaut 1 point. Une réponse omise vaut 0 point. Le minimum par question est de 0 point.

Les questions couvrent les thèmes suivants :

• Principes de base de HERMES
• Domaine d’application et structure du scénario « Service – Produit »
• Modules du scénario standard
• Organisation de projet (rôles) dans le scénario standard

Trois types de questions sont posés : standard, négatives, complétions (mot manquant).

Exemple « standard »

Laquelle des affirmations suivantes concernant le module « Organisation » est correcte ? a) Le module « Organisation » décrit l’organisation de mise en service. b) Le module « Organisation » décrit l’adaptation de l’organisation. c) Le module « Organisation » définit l’organisation du projet. d) Le module « Organisation » définit l’organisation opérationnelle.

Exemple de question à mot manquant :

Complétez correctement : Les modules… a) …sont des blocs de construction pour la création de projets et de scénarios. b) …regroupent des résultats, tâches et rôles sans lien direct avec la solution ou la réalisation. c) …ne sont pas composés de tâches et de résultats. d) …décrivent le cycle de vie de projets d’une certaine nature. Exemple de question négative : Quelles des possibilités suivantes ne fait pas partie des quatre manières d’adapter un scénario ou de créer un scénario personnalisé ? a) Supprimer des tâches et livrables b) Ajouter un rôle spécifique à un module c) Supprimer un module d’un scénario existant d) Intégrer un module thématique supplémentaire dans le scénario existant

Objectifs d’apprentissage de HERMES Foundation

Après avoir suivi la formation HERMES, les participants seront capables de :

• Comprendre les bases de la gestion de projet selon HERMES
• Avoir une vue d’ensemble du domaine d’application et de la structure des deux scénarios standards : développement et adaptation de services/produits
• Approfondir les modules « Pilotage de projet, Direction de projet, Fondements, Approvisionnement, Organisation, Produit et Mise en service » dans le contexte complet d’un projet
• Analyser en détail l’organisation de projet (rôles) et leurs responsabilités dans le cadre d’un projet de type service/produit
• Savoir comment créer des scénarios personnalisés
• Réussir l’examen Foundation pour obtenir la certification HERMES

Certification HERMES Foundation

Les participants qui réussissent l’examen reçoivent un certificat. En cas d’échec, une attestation de participation est remise.

L’institution chargée de la certification HERMES en Suisse est la TÜV SÜD Akademie.

La validité du certificat HERMES Foundation est à vie ; il n’expire jamais.

TÜV SÜD fournit des informations détaillées sur la certification et la recertification sur son site internet.

Visitez notre page HERMES Foundation ou contactez-nous pour en savoir plus !

QRP International est fier d'annoncer le lancement des nouvelles certifications DevOps de PeopleCert.  

DevOps - PeopleCert

DevOps (mot composé qui vient de «développement» et «opérations») est une approche de développement de logiciels qui combine le développement de logiciels (Dev) avec des opérations de technologie de l'information (Ops). L'objectif de DevOps est de raccourcir le cycle de vie du développement des systèmes tout en livrant fréquemment des versions logicielles, en étroite adéquation avec les objectifs de l'entreprise de manière plus rapide, plus qualitative et plus rentable. PeopleCert propose désormais ses propres certifications DevOps: ces nouvelles certifications ont été conçues autour des organisations utilisant des pratiques de gestion des services informatiques bien établies, pour leur fournir des conseils sur les processus, les outils et l'intégration de culture avec DevOps.    

Les niveaux de certification DevOps de PeopleCert

Le système de certification DevOps de Peoplecert comprend actuellement trois certifications distinctes: PeopleCert DevOps Fundamentals Les candidats obtiennent des conseils pratiques pour livrer efficacement avec DevOps, grâce à 15 pratiques essentielles en relation avec les référentiels ITSM - Déjà disponible.   PeopleCert DevOps Leadership Les candidats apprennent comment implémenter les pratiques DevOps et comment réaliser un changement culturel de façon à obtenir une meilleure collaboration et communication au sein de l’organisation - Déjà disponible.   PeopleCert DevOps Engineering Les candidats obtiennent des conseils pratiques sur l'utilisation des outils d'automatisation et sur la manière dont ces outils prennent en charge la culture et les pratiques DevOps - Bientôt disponible.   N'hésitez pas à nous contacter pour avoir plus d'informations sur les formations et certifications DevOps de PeopleCert.

Afin de renforcer sa présence dans le domaine de la formation en gestion de projet, ProfeoQRP a décidé de collaborer avec processCentric.

processCentric est une société de formation et de conseil pour les professionnels Suisses. Ce nouveau partenariat nous permet d’élargir notre portefeuille de formation avec des méthodes telles que HERMES 5.

 

processCentric GmbH

processCentric GmbH a été fondé en 2015 par Serge Schiltz. Grâce à ses activités en tant qu'expert en gestion de processus et de projets dans différents secteurs, principalement dans les services financiers, il a pu gagner une expérience très large dans la conception et le pilotage des processus de l'entreprise et la réalisation de projets de changement.

La mission principale de processCentric GmbH est d'offrir aux entreprises une vision globale des processus et des projets de l'entreprise, qui constitue un élément majeur de l'activité de l’entreprise. ProcessCentric propose différents services :

• Services de conseil pour la mise en oeuvre d'une gouvernance d'entreprise efficace avec une approche axée sur les processus.
• Formations dans le domaine de la gestion des processus, la gestion des projets d'évolution et la gestion d'entreprise axée sur les processus.
• Soutien actif pour la mise en place d'une gestion de processus stratégique, une gestion d'entreprise axée sur les processus et la mise en oeuvre des projets de changement.

 

ProfeoQRP : Nous mettons notre expertise à votre service

Nous développons des solutions complètes adaptées aux besoins de votre entreprise. Nous collaborons étroitement avec vos équipes pour identifier vos besoins, définir et organiser votre formation, élaborer et exécuter un plan de mise en œuvre de la méthodologie et adapter la ou les Bonnes Pratiques à votre organisation

Nous adaptons chaque session au contexte personnel des participants par des exemples concrets, supports visuels, jeux, ...

Depuis 2000, QRP International soutient les professionnels et les organisations dans le développement de leurs compétences et l’implémentation des Bonnes Pratiques de Management, en proposant des formations, certifications et prestations de conseils sur mesure.

Formations, certifications, conseil et accompagnement, expérience internationale, compétences pédagogiques d’exception, suivi client, réactivité et flexibilité. QRP est la solution que vous recherchez.

Nos chiffres :

• +25 centres de formation en Europe
• +20 ans d’expérience dans la formation et le conseil
• +20.000 professionnels formés
• 6 langues de formation
• 9,17 sur 10 de moyenne attribuée aux performances des formateurs

Nous sommes fiers de pouvoir afficher un taux de réussite aux examens de 95% grâce à la qualité de nos formations et de nos formateurs.

En outre, la philosophie de nos formateurs n’est pas uniquement de vous faire obtenir la certification, mais d’illustrer la méthode avec des exemples pratiques afin de vous permettre d’appliquer facilement vos nouvelles compétences dans votre organisation.

Nous proposons régulièrement des formations en Suisse, aussi bien en allemand qu’en français ou en anglais.

Si vous souhaitez en savoir plus sur Profeo/QRP ou sur nos services, contactez-nous dès maintenant !

En 2019, nous avons vu de nombreux exemples d'initiatives DevOps réussies dans de petites et de grandes entreprises. Bravo à tous ceux qui y ont participé.

Mais qu’en est-il du futur de DevOps 2020? Tout comme les experts de la communauté DevOps, nous pensons que les dix tendances suivantes façonneront la prochaine année de DevOps à travers le monde.

  1) Agile et DevOps augmenteront la collaboration entre la technologie et les départements métier 2) La formation, l’apprentissage et l’amélioration des compétences DevOps deviendront une priorité organisationnelle 3) La montée en compétences et la polyvalence des professionnels entraîneront l’augmentation des compétences en T 4) De plus en plus d’équipes changeront d’état d’esprit et préféreront “produire de la valeur” plutôt que “faire le travail” 5) La fatigue des outils va empirer avant de s’améliorer 6) DevOps deviendra plus mesurable et les métriques seront mieux définies 7) Les équipes DevOps gagneront plus et connaîtront une satisfaction accrue au travail 8) Il pourrait y avoir une réunification de DevOps et de la gestion des services 9) Une nouvelle génération de membres IT prend le relais 10) L’adoption de l’intelligence artificielle augmentera et les équipes DevOps devraient le vérifier    

1) Agile et DevOps augmenteront la collaboration entre la technologie et les départements métier

Agile et DevOps sont des mouvements populaires qui ont vu le jour avec la technologie. Toutefois, dans de nombreux cas, Agile et DevOps n'ont pas pu s'extraire de la technologie. A l’inverse, dans certaines entreprises Agile a pu être adopté par d'autres département comme la finance, le marketing, les ressources humaines ou les achats. Certains hauts dirigeants invitent de plus en plus l'ensemble de leur organisation à «devenir agile».

Malgré cette expansion aux autres départements, il ne semble pas que la communauté technologique ait pour autant uni ses forces avec leurs collègues des autres départements. Pourtant, avec la pression concurrentielle que le numérique exerce sur les organisations, nous devrions commencer à voir plus de collaboration entre les départements, avec Agile comme déclencheur.

Pour accélérer cette collaboration, n’hésitez pas à encouragez vos équipes à parler aux autres départements de leur expérience avec les méthodes agiles. Voici quelques exemples de questions qui peuvent aider à briser la glace :

• Comment utilisez-vous Agile ?
• Que faites-vous exactement ?
• Qu'est-ce qui change pour vous ?
• Quels problèmes rencontrez-vous ?

Comment pourrions-nous travailler ensemble pour vous aider à résoudre certains de ces problèmes ? Ces questions aideront les professionnels des différents départements à se connaître - en tant que personnes - et la collaboration s'améliorera.    

2) La formation, l'apprentissage et l'amélioration des compétences DevOps deviendront une priorité organisationnelle

DevOps nécessite d'essayer de nouvelles technologies. Une étude récente de DevOps Institute a révélé que 55% des répondants au sondage préfèrent recruter en interne leurs équipes DevOps. Malheureusement, de nombreuses entreprises n'ont pas les compétences nécessaires et l'embauche de nouvelles personnes n’est pas toujours possible en raison des contraintes budgétaires.

FedEx tente une approche différente : apprendre à ses propres ingénieurs comment construire de nouvelles applications et réécrire des applications modernes fonctionnant dans le cloud hybride de l'entreprise de logistique. L'entreprise savait qu'elle n'avait pas les compétences adéquates dans son bassin de talents d'ingénieurs, ce qui a conduit son directeur informatique à lancer FedEx Cloud Dojo. Cette "université" interne a déjà requalifié plus de 2 500 programmeurs de logiciels.

Les organisations qui souhaitent utiliser DevOps pour faire avancer leurs transformations numériques doivent apporter des améliorations drastiques dans les domaines de la formation, de l'apprentissage et de l'amélioration des compétences essentielles pour DevOps. Le DOI prévoit une progression active de cet objectif en 2020.

   

3) La montée en compétences et la polyvalence des professionnels entraîneront l’augmentation des compétences en T

Avec la prise de conscience des difficultés de recrutement sur le marché des talents, les organisations et les individus risquent d’investir massivement dans la montée en compétence et la polyvalence afin de répondre à la demande croissante de nouvelles compétences.

Alors que tous les acteurs de l'informatique devront devenir plus multi- compétences, les développeurs en particulier devront élargir leur éventail de compétences dans des domaines tels que les tests, la "conteneurisation", l'infrastructure, l'IA et la sécurité.

L'accent sera également mis davantage sur les compétences comportementales telles que l'empathie, l'expérience client et la collaboration. Les silos commencent à s'effondrer dans de nombreux domaines, et la nécessité pour chacun d’avoir des compétences en forme de T (expertise pointue dans un domaine, associée à des compétences générales diversifiées) devient primordiale pour permettre et soutenir l'innovation.

Ces formations et cette nouvelle collaboration (cf paragraphe n°1) conduiront davantage de professionnels à développer de nouvelles compétences techniques et professionnelles et des qualités personnelles, ajoutant de nouvelles expertises et capacités aux membres des équipes.

   

4) De plus en plus d’équipes changeront d’état d’esprit et préféreront “produire de la valeur” plutôt que “faire le travail”

La cartographie des flux de valeur peut aider à changer la façon dont les équipes perçoivent le DoD (Definition of Done) de : «j'ai fait mon travail» à : «la valeur est réalisée». C'est l'un des moyens les plus efficaces pour changer les comportements et amener les équipes à penser au cycle entier de ce sur quoi ils travaillent. C'est pourquoi l'adoption du Value Stream Management est primordiale en 2020.

Le VSM permettra d'automatiser les sorties du flux de valeur pour un suivi permanent de la progression. Cela permet à une équipe de connecter toutes les parties des chaînes d'outils complexes de DevOps, aux données dérivées du système basées sur des temps de cycle.

Les équipes qui adopteront le Value Stream Management en 2020 pourront baser leurs prochaines expériences d'amélioration sur des décisions et des priorités basées sur les données.

   

5) La fatigue des outils va empirer avant de s'améliorer

Le nombre d'outils et de référentiels dans le secteur technologique est déconcertant. Les défis auxquels les équipes informatiques sont confrontées pour les comprendre, les interconnecter et les appliquer se poursuivront, et en 2020, aucune véritable résolution n'est en vue.

La concurrence dans la chaîne de montage DevOps est féroce et florissante. Le nombre d’événements et de conférences sur la technologie et les Bonnes Pratiques ne cesse de s'accroître. Les livres, les blogs et les vidéos inondent les boîtes de réception d'e-mails, et les experts d'opinion sont impatients de partager leur expertise. A cela s’ajoute l’apparition de nouveaux outils open source pour intégrer les nouvelles technologies.

Pour survivre aux défis de la complexité, il devient de plus en plus important d'avoir une stratégie d'automatisation. Pendant que vous travaillez à son développement, ne perdez pas de vue les problèmes réels que vous essayez de résoudre et comment vous pouvez yarriver en tirant parti de vos propres équipes.

   

6) DevOps deviendra plus mesurable et les métriques seront mieux définies

"Ce qui se mesure se gère” Cette citation est toujours valable, plus de 60 ans après que Peter Drucker l'ait référencée dans son livre, “The practice of management.” Ce que nous voulons tous éviter, cependant, c'est le syndrome de la mesure juste pour mesurer..

En ce qui concerne DevOps, pour les prochaines années, les mesures d'amélioration continue que nous connaissons aujourd'hui continueront d'être les mesures clés qui comptent. En 2020, nous nous attendons à ce que davantage d'organisations se mettent d'accord sur ce qu'il faut mesurer et adoptent ces mesures.

Ceux qui recherchent du soutien peuvent s'appuyer sur les mesures de performance décrites dans la recherche de DevOps Research and Assessment (DORA), qui cite cinq mesures de livraison de logiciel et de performance opérationnelle (SDO) qui peuvent être utilisées comme indicateurs de succès pour les équipes DevOps hautement performantes.

Les références clés du rapport fournissent des conseils sur les domaines où les équipes doivent s’améliorer en 2020. La sélection de ces métriques clés et leur remplissage avec des données fourniront un aperçu de la valeur et du parcours de DevOps.

   

7) Les équipes DevOps gagneront plus et connaîtront une satisfaction accrue au travail

Les employés qui continueront sur la voie DevOps en 2020 auront des retombées positives aussi bien au niveau pécunier que sur leur satisfaction au travail. L'automatisation permettra aux employés de travailler sur plus de projets à valeur ajoutée au lieu de tâches manuelles basiques, ce qui améliorera leur satisfaction au travail et, espérons-le, réduira les niveaux de stress.

Seront concernés en particulier, les ingénieurs DevOps qui travaillent sur l'automatisation et la collaboration pour une livraison de logiciels améliorée. Ils peuvent s'attendre à ce que leur salaire soit considérablement plus élevé que leurs pairs dans des rôles traditionnels, tels que les administrateurs système.

Les investissements dans la formation et les certifications auront également une incidence positive sur la qualité du code et pourront donc améliorer les résultats de l’entreprise. Ceci, à son tour, pourrait enfin changer l'équation de la valeur au sein des organisations et donner au service informatique une véritable place stratégique tout en améliorant certainement la façon dont les autres départements collaboreront avec les services informatiques à court et long termes.

   

8) Il pourrait y avoir une réunification de DevOps et de la gestion des services

Avec la sortie récente d'ITIL 4, 2020 sera une année intéressante pour les organisations ayant adopté DevOps et les référentiels de gestion des services informatiques. Le développement et la gestion de produits logiciels nécessitent des techniques agiles, en mettant l'accent sur la co-création de valeur de manière à réduire les déchets.

DevOps, la gestion des services et d'autres Bonnes Pratiques comme SRE peuvent coexister pour aligner les équipes, répondre aux demandes des parties prenantes et améliorer la valeur délivrée. Étant donné que la transformation numérique ne se fait pas instantanément dans une organisation, les entreprises devraient commencer par les Bonnes Pratiques et méthodologies adaptées à leurs besoins en commençant petit, puis apprendre, développer leur expertise et évoluer.

   

9) Une nouvelle génération de membres IT prend le relais

Le nombre de personnes qui se souviennent des jours avant DevOps commence à diminuer. La jeune génération des équipes informatiques et DevOps d'aujourd'hui ne se souvient pas des silos stricts, où il y avait des lignes strictes autour des domaines de responsabilité tels que l'infrastructure, les opérations, la conception d'applications, le développement, les tests et la sécurité.

Ils ne se souviennent pas de l’impact énorme de la transition entre les équipes et les groupes. Ils ne savent pas que les "product owners", "business analysts", architectes, développeurs, testeurs, devaient s'entendre et coordonner la planification, le développement, les tests, le déploiement, l'exploitation et la gestion d'un logiciel.

Ecrire cette phrase était épuisant, imaginez la vivre. Lorsque nous avons célébré le 10e anniversaire de DevOps en 2019, nous avons vu la suppression du mur entre les Devs et Ops. C'est d’ailleurs une bonne raison pour nous tous de célébrer.

   

10) L'adoption de l'intelligence artificielle augmentera et les équipes DevOps devraient le vérifier

L'IA et l'apprentissage automatique (ML) ont récemment été classés comme les technologies d'entreprise les plus importantes de la prochaine décennie, selon un récent rapport de l'ISACA. Les deux joueront un rôle essentiel dans les opérations informatiques de nouvelle génération et les équipes DevOps.

AIOps donnera aux équipes DevOps la capacité d'analyser plus de données plus rapidement, ce qui leur permettra d'améliorer les processus, les tâches et la prise de décision clés. En 2020, attendez-vous à voir davantage d'équipes DevOps adopter ces outils, qui automatisent l'ingestion d'énormes volumes de données, utilisent l’apprentissage automatique pour analyser les données et ont la capacité de tirer parti des connaissances pour l'automatisation ou la prise de décision.

Le marché des AIOps a déjà pris de l'ampleur, avec 22% des entreprises informatiques utilisant le ML et la data sciences dans leur cadre de travail. L’éventail de fournisseurs est large avec une variété d'experts. Cette année, le marché des AIOps poursuivra son passage d'un projet scientifique à une phase pilote et expérimentale.

Il reste beaucoup de travail en 2020 pour faciliter l'adoption de DevOps. Il faudra plus que se concentrer sur les outils et les techniques. Les initiatives DevOps doivent être enregistrées en tant que programmes de changement, nécessitant du temps, des ressources et un engagement prioritaire de tous les chefs d'entreprise.

Nous espérons que certaines de ces tendances se réaliseront cette année et que DevOps sera reconnu comme une nouvelle façon de travailler.

 

 

Originally published on The Enterprisers Project and reproduced with kind permission of “Devops institute”. Translation: © 2019 DevOps Institute. All Rights Reserved. Translated by QRP International, on behalf of Devops Institute in (01/2020)

 

Le cadre de référence TOGAF® est une méthode pour développer l’architecture d'entreprise, grâce à l'utilisation d'un ensemble d'outils, et est disponible gratuitement sur le site Web Open Group pour les organisations souhaitant mettre en œuvre une architecture d'entreprise.

La première version publiée en 1995 était basée sur le cadre d’architecture technique de la gestion de l’information (TAFIM), développé par le département américain de la Défense.

 

Les objectifs de TOGAF

Le cadre de référence TOGAF® est une approche de développement architectural "rapide" et de gouvernance efficace. Il ne prescrit pas les modèles à utiliser pour représenter l'architecture, mais guide le processus lors de la création de l'architecture. Grâce à son évolutivité, il peut être utilisé pour les organisations gouvernementales, les grandes entreprises et même les petites et moyennes entreprises.

En examinant les différents niveaux d'architecture qu'un framework peut prendre en charge, TOGAF® essaie de prendre en charge tous les niveaux, allant de l'architecture d'entreprise, de données, d'application à l'architecture technologique.

 

Les avantages de TOGAF®

• Une méthode testée et appliquée par des milliers d'architectes numériques
• Un dictionnaire commun, pour que chacun puisse comprendre les informations fournies par l'architecture résultante

 

Le cadre de référence TOGAF® 

La structure TOGAF® est composée des principales parties suivantes:

• Le Cadre de Capacité : Who ? Qui devrait être impliqué ?
• Le Cycle ADM, pour Architecture Development Method (ADM) : What ? Que faire ?
• Les lignes directrices et techniques d'ADM : How ? Comment faire ?
• Le Cadre de Contenu : Which ? Quelle documentation produire ?
• Continuum d'entreprise et outils : Where ? Où stocker la documentation ?

 

ADM: La méthode de développement architectural

La méthode de développement architectural est une approche détaillée, divisée en phases, qui explique comment gérer l'ensemble du cycle de vie d'une architecture.

 

Phase préliminaire: Dans cette phase, l'équipe d'architecture d'entreprise, les principes architecturaux et le cadre à utiliser sont définis.

 

Phase A - Vision de l’architecture : Cette phase permet d’identifier :

• La liste des parties prenantes, leurs rôles, leurs implications
• Un consensus sur les objectifs, les exigences, les contraintes et les règles d’architecture
• Le périmètre impacté
• Le plan de développement du cycle ADM, les moyens humains, techniques et financiers
• Une cartographie à grande échelle de l’architecture initiale et de l’architecture cible
• L’identification des risques et le plan pour les réduire

 

Phase B - Architecture Métier : Le métier avec ses exigences, ses processus et ses entités, gouverne l’architecture d’entreprise. La phase B Métier permet de fixer l’architecture cible et de mesurer les impacts. Les résultats de cette phase peuvent être définis en utilisant, par exemple, UML ou IDEF-0.

Le choix de la méthode de modélisation utilisée est basé sur les vues (views) requises, dont les “viewpoints” sont identifiés dans cette phase.

 

Phase C - Architecture des Systèmes d'Information : Le but de cette phase est de décrire l'architecture des données et l'architecture des applications. Les vues créées dans cette phase sont à nouveau modélisées dans la modélisation choisie. Pour les bases de données, par exemple, il peut s'agir de modélisation de données relationnelles.

 

Phase D - Architecture technique : Le but de cette phase est de décrire l'architecture technologique qui constituera la base des travaux de mise en œuvre ultérieurs.

 

Phase E - Solutions et opportunités : Cette phase identifie les caractéristiques du changement, détermine les contraintes de mise en œuvre, valide les dépendances et identifie toute architecture de transition. Le résultat de cette phase constituera la base du plan de mise en œuvre requis pour passer à l'architecture cible.

 

Phase F - Planning de migration : Cette phase se concentre sur la priorisation des projets et les coûts de migration des différents projets sont estimés. Le résultat final est une feuille de route détaillée de l’architecture, incluant le plan de mise en œuvre et de migration.

 

Phase G - Gouvernance de la mise œuvre : Pour chacun des projets de mise en œuvre, une organisation correspondante est désignée pour assurer sa mise en œuvre. Parallèlement, des revues de conformité seront effectuées pour s'assurer qu'à la fin de cette phase, le système est entièrement réalisé et implémenté conformément aux spécifications.

 

Phase H - Gestion de la maintenance et des évolutions : Le cycle de vie de l'architecture ne s'arrête pas après la mise en œuvre du système. Le but de cette phase est de gérer les modifications de l'architecture de manière cohérente. Afin de maintenir l'architecture flexible et dynamique, tout changement technologique ou environnemental doit être rapidement intégré à l'architecture.

Au cours de cette phase, la décision est prise sur la nécessité d’initier formellement un nouveau cycle d'évolution de l'architecture pour chaque demande de changement. Cette décision doit être prise sur la base de critères prédéfinis, qui détermineront si une demande de changement ne nécessite qu'une mise à jour de l'architecture actuelle ou un redémarrage du cycle.

Ces critères ne sont pas prédéfinis par le cadre TOGAF®, car l’acceptation du risque diffère trop d’une organisation à l’autre.

 

Phase Gestion des exigences: Le cercle central du cycle ADM nous montre que les différentes phases de l'ADM sont alimentées par les exigences. Le cadre TOGAF® ne prescrit pas une manière spécifique de collecter et de gérer ces exigences, il spécifie uniquement ce que doit être un processus efficace de gestion des exigences.

Les inputs pour le processus de gestion des exigences sont fournies par les différentes phases du cycle ADM.

 

Résultat final : Lors de l'application du cadre de référence TOGAF® pour créer une architecture, de nombreuses organisations ne bénéficient pas toujours des bénéfices prévus. Cela est généralement dû au fait qu'une architecture est souvent mise en œuvre de bas en haut, où la direction ne s'engage pas suffisamment pour atteindre les objectifs de l'entreprise avec des objectifs architecturaux, ce qui rend impossible d'atteindre l'objectif de l'entreprise attendu par le biais du levier de l'architecture.

Ce problème se produit pour chaque framework utilisé pour créer une architecture. Il est donc essentiel que le plan stratégique, utilisé dans la phase A, soit partagé et approuvé par l'ensemble de l'organisation.

 

Claudio Restaino

Claudio est formateur accrédité TOGAF® et consultant en systèmes de gestion des services informatiques depuis plus de 17 ans. Il est responsable du groupe de travail pour la version italienne du glossaire TOGAF®. En tant que formateur, son objectif principal est de combiner son expérience personnelle avec sa connaissance rigoureuse des référentiels  ITIL, TOGAF®, COBIT, DevOps, Lean Six Sigma, ISO 27001, afin de partager son expérience sur la mise en pratique des méthodologies en gestion des SI.

Suivez Claudio sur Linkedin

TRADEMARKS AND STATEMENTS TOGAF® is a registered trade mark of The Open Group in United States and other countries.