1. Les Mardi de l’Urba-EA TOGAF The Open Group Architecture framework [email_address] [email_address] 22 septembre 2009 V2r0
2.
3. Un peu d’histoire, généalogie des « Frameworks » TOGAF 2009 2009 IAF 4.5 influenced influenced IDEFx influenced Merise SSADM Praxeme Urbanisation « À la française »
13. Un méta-modèle , qui couvre l’ensemble des préoccupations d’architecture (Cf. Apports de TOGAF 9) Phases A D Phases E,F,G Phases Prelimirary, A Gestion des Exigences Concept de « Fonction » intégré à l’architecture métier
Un Slide volontairement inextricable qui montre : Depuis le début des années 1990, le bouillonnement des différents Frameworks d’architectures Facteurs d’influences très forts tels que le domaine militaire (DOD), l’organisation fédérale (FEA ou NASCIO) Ce que l’on constate également, c’est que Zachman existe toujours, qu’il a également influencé bon nombre de cadres TOGAF, lui est relativement constant et perein, puisqu’ayant vu le jour en 1995, il est toujours bien dynamique 14 an après Urbanisation à la francaise en 1999-2000 toujours en vie dans nos entreprise nationales Un nouveau né « Praxème » en 2006
Alors bien sûr … le noyau historique de TOGAF c’est la Méthode ADM (« Architecture Development Method ») de conception des architectures. On y retrouve donc une véritable méthode avec découpée en plusieurs étapes ou phases, mais également une collection de Livrables Mais TOGAF c’est aussi d’autres composants tout aussi importants : Tout d’abord un Framework pour décrire les contenus d’architecture c’est le « Content Framework » dans la littérature on trouve également le terme de « Cadre de contenu d’architecture », Les Modèles de référence constituent une base, sur laquelle on peut construire des architectures et des composants architecturaux Plus spécifiques. ADM est une méthode générique pour développer des architectures, il est souvent nécessaire de l’adapter aux particularités d’une Entreprise. Ce que l’on appelle « ADM Guidelines & Techniques » constitue des recommandations utiles pour adapter l’ADM Le « continuum d’entreprise » est une modèle qui permet de structurer un référentiel virtuel pour classer les éléments d’architectures J’y reviendrait dans un slides par la suite. Enfin le Cadre de Capacité d’Architecture fournit un ensemble d’informations décrivant comment créer la fonction d’architecture (ex. un ou plusieurs départements d’architecture)
L’ADM, Architecture Development Method est le composant majeur de TOGAF. Il définit le processus sous la forme de 8 phases (A à H) qui décrivent un cycle d’architecture. En amont de ces 8 phases, on trouve la « Preliminary Phase » qui est transverse aux différents cycles ADM et qui décrit comment décliner Togaf dans l’entreprise, avec quelle gouvernance, avec quels outils mais elle décrit aussi les principes directeurs qui « guident » tout cycle ADM. La phase A est une phase cruciale. C’est elle qui qui cadre les travaux à réaliser pour l’ensemble du cycle ADM en: Identifiant l’ensemble des parties prenantes avec leurs attentes, en validant le contexte et le périmètre métier à traiter, et surtout en donnant une vision de la cible d’architecture. Et là, notez que dans Togaf, la vision d’architecture couvre à la fois les aspects Métier, SI et Technologique. Il s'agit de donner une vision, donc on reste à un niveau relativement macroscopique en focalisant sur les points structurants pour obtenir un GO en fin de phase. Les phases B,C et D permettent de définir les architectures cibles sur les aspects Métier (Phase B), SI (Phase C) et Technique (Phase D). Pour chacune d’elle, s’appuyer sur l’existant pour réaliser une analyse d’écart. C’est uniquement lors de la phase E que l’analyse d’opportunité est réalisée avec les choix de solution. Ces choix sont réalisés à partir des travaux des phases B,C et D. Le métier reste au cœur de la démarche, même pour les choix de solution. C’est lors de cette phase que l’on commence à identifier les projets d’implémentation, qu’on identifie une trajectoire (macro planning) et que l’on définit les architectures intermédiaires (sur les paliers de la trajectoire). Ensuite la phase F fait une analyse de la valeur des travaux résultant de la phase E par une analyse des couts, des bénéfices mais aussi des risques. Elle détaille la trajectoire et les projets associés. La phase G est la phase d’accompagnement des projets d’implémentation au travers des recommandations d’architecture pour les projets, de l’établissement du contrat d’architecture avec les règles de pilotage associées, mais aussi la mesure de la conformité pour s’assurer que les travaux réalisés sont conformes aux recommandations d’architecture. La phase H est phase d’analyse continue pour s’assurer que l’architecture définie est toujours en adéquation avec les besoins métiers. La phase H peut être à l’origine d’un nouveau cycle d’architecture. Enfin, le point central du cycle ADM est la gestion des exigences qui permet de s’assurer que l’ensemble des phases du cycle ADM s’appuient et valident les exigences métier.
Intro: Nous venons de décrire les principes d’un cycle ADM. Confronté à la pratique, les cycles ADM peuvent se décliner de façon différentes et TOGAF définit modes d’utilisation au travers de bonnes pratiques (Clic) Tout d’abord le déroulement d’un cycle ADM peut être itératif. A titre d’exemple, les préliminaires et Vision sont souvent assez liées: Donner la vision d’architecture sur un projet structurant aboutit souvent à faire évoluer les principes d’architecture transverses. De la même façon, les phases E et F sont très interdépendantes voire même traitées en même temps dans certains cas Enfin dans certains cas, des itérations supplémentaires sont à prévoir quand par exemple l’analyse des couts des bénéfices et des risques réalisés dans la phase F nécessite une revisite de l’architecture métier cible. (Clic) Autre cas concret auquel sont confrontées les entreprises est de savoir comment décliner des cycles ADM pour traiter à la fois et de façon cohérente de la définition des architectures stratégiques (Ex: Schéma Directeur), la définition des architectures d’un domaine métier et les architectures de solution par essence plus proche des projets. Ces niveaux d’architecture font intervenir des profils d’architectes différents qui doivent collaborer à une même cible. Ce schéma illustre 2 modes de mise en œuvre proposés par Togaf: 1/ Un seul cycle Togaf dans lequel chaque profil d’architecte apporte sa pierre à l’édifice. Ce mode est préconisé quand on est dans le cas d’une seule et même équipe d’architecte qui traite l’ensemble 2/ Des cycles imbriqués, plus adaptés à des organisations importantes ou a des gros programmes de transformation pour lesquels on doit souvent décliner une vision stratégique, domaines et ensuite projet.
Plutôt que de dérouler toute une série de Slides théoriques, nous avons pensé qu’il était intéressant de montrer Au travers d’un petit exemple quel pourrait être une démarche d’architecture TOGAF. Le CEISAR (Center Of Excellence In Enterprise Architecture) a publié en octobre de l’année dernière Un excellent livre blanc sur l’architecture d’entreprise. Ce livre blanc s’appuie sur une histoire fictive : il s’agit d’un boulanger évoluant d’un mode de fonctionnement Artisanal à un mode de fonctionnement industriel; et pour cela, il utilise une démarche d’architecture d’entreprise. Donc notre boulanger est confronté à quelques enjeux clés : Multiplié par 2 son CA Augmenter sa rentabilité Pour cela, il se fixe des objectifs ambitieux : Multiplier par 3 le nombre de ses boulangeries dans le département Maintenir l’excellent niveau de qualité qui a fait son succès et cela dans toutes ses boulangeries Au passage, que cela se traduit en terme de cible SI et organisationnelles par : La centralisation des achats de matières premières La consolidation des suivi de stocks … etc … Avec TOGAF on appelle cela la phase Préliminaire; dans laquelle on s’attache à décrire les Grands principes directeurs, les normes, l’outillage , … en bref tout ce qui va nous permettre De faire de l’architecture !
Nous avons vu précédemment que le boulanger avait déjà prévu un plan de transformation. Mais un évènement survient: « Un concurrent détourne sa clientèle en proposant un pain biologique aux lardons et aux noix ». Il doit réagir vite ! (clic) Ses objectifs sont finalement assez simples: Proposer de nouveaux pains qu’il vendra dans l’ensemble de ses boulangeries Il se donne 2 mois pour les proposer dans l’ensemble de ses boulangeries Quelle est sa cible ? Du point de vue métier, il doit mettre en place un nouveau processus d’innovation allant des phases de recherche jusqu’à la préparation de la mise en production. Du point de vue organisationnel, il prévoit de séparer les opérations de gestion du quotidien des activités d’innovation. Enfin du point de vue SI, 3 évolutions majeures: Une application pour piloter son processus d’innovation, Mise en place d’un référentiel transverse des recettes en le sortant de la production et enfin profiter de ce projet pour centraliser les achats et le suivi des fournisseurs en conformité avec son schéma directeur.
Dans sa démarche il continue à dérouler un cycle Togaf en définissant sa cible métier. (Clic) 1/ Il commence par définir son processus d’innovation avec les activités métiers concernées, les rôles, les informations manipulées et echangées Il définit ensuite comment il va inscrire ce processus dans l’organisation de sa boulangerie. Ici il choisit de dédier un de ses meilleurs apprenti qui a la fibre innovatrice à l’innovation. Par contre il se garde les activités d’analyse de la concurrence et de ciblage. (Clic) 2/ Pour pouvoir industrialiser ses nouvelles recettes, il est important de les décrire précisément pour pouvoir les reproduire. Il définit les entités métiers comme la notion de Recette mais aussi les objets d’information nécessaires au processus d’innovation. (Clic) 3/ A partir des travaux précédents il réalise une étude d’impacte sur les fonctions métiers de son entreprise et de leur classement: Un quartier « Marketting » est rajouté. Il porte les fonctions d’innovation. Un quartier « Produits » est rajouté. Il porte le modèle métier « Produit » qui inclus les recettes.
Maintenant qu’il a défini sa cible métier, notre boulanger doit se préoccuper des impacts sur son architecture SI. C’est la phase C. (Clic) Naturellement il utilise les résultats des phases précédentes qui vont l’aider à définir sa cible SI qui pour rappel (Phase A) consiste définir un référentiel produit partagé, une nouvelle application marketting, et une opportunité de rationalisation de la fonction « Achat ». (Clic) Par exemple il utilisera les fonctions et le modèle métier (objets d’information) pour identifier les services cibles. (Clic) Ces services sont ensuite regroupés dans des blocs applicatifs (building block) pour former l’architecture applicative. La répartition des données dans les blocs et leur description du point du vue SI est réalisée à ce stade (Architecture des données). La description des echanges tant du point de vue statique que dynamique doivent aussi être décrits. Voila nous avons déroulé les 3 premières phases du cycle Togaf. Dans la phase D (Architecture technique) il pourra analyser par exemple l’impact sur son infrastructure de serveur, réseau, nécessité d’équiper chaque boulangerie d’un PC, etc. Il pourra aussi définir des principes techniques d’échange avec ses fournisseurs etc. Ensuite il étudiera en phase E et F ses opportunités et choix de solution. Il regardera plus précisément l’opportunité d’un progiciel spécialisé dans la gestion des boulangerie …
Le continuum d’entreprise constitue une bonne pratique de classification : Il s’agit de séparer les architectures et les solutions Ranger les éléments (architectures, solutions) suivant leur généricité Continuum des « Solutions » Prenons, par exemple, le cas d’un progiciel de gestion d’assurance santé; Il vient naturellement se ranger dans « Industry Solutions ». Une application développée entièrement en spécifique appartiendra plutôt à l’ensemble « Organisation Specific Solutions » Common Systems Solutions : Les vendeurs de solutions SAAS représentent des exemples typique de vendeurs de Common System Solutions On peux citer l’exemple de SalesForce qui distribue un logiciel de CRM en mode SAAS qui s’applique à tout un ensemble de secteurs. Foundation Solutions : Language de programmation, OS, structures de base pour organiser les opérations du SI (ex. ITIL) On y trouve également des services tels que la formation ou le conseil technologique … Continuum des Architectures : Exemple de www.energistics.com qui distribue un modèle de référence de Processus Métiers dans le secteur Energétique Il s’agit d’un exemple qui vient se ranger dans l’ensemble des « Industry Architectures »
Un des apports important de Togaf 9 est le méta model d’architecture. Il s’applique à toutes les phases du cycle ADM. On notera entre autre le concept de fonction qui pourra faire le lien avec les concepts d’urbanisme comme le POS et les fonctions. « Function: Delivers business capabilities closely aligned to an organization, but not explicitly governed by the organization. » Il est modulaire et il ne préjuge ni d’un outil ni d’un formalisme particulier. Notez malgré tout que Togaf 9 fournit une grille de critères d’évaluation pour choisir un outil. Sa modularité offre de la souplesse dans le processus d’adoption des entreprises. En effet, les entreprises ont déjà souvent un voir plusieurs méta model couvrant tout ou parti des préoccupations d’architecture et passez vers une nouveau méta model en mode big bang n’est souvent pas tres réaliste. D’ailleurs on notera que rien ne continu d’empêcher de faire du Togaf 9 avec d’autres méta model d’architecture comme IAF, Zachman ou autre. En résumé ceux qui faisais du Togaf 8 avec un méta model particulier pourront passer à Togaf 9 sans révolution.
Le référentiel d’architecture est la matérialisation du continuum d’entreprise, il est utilisé pour Mémoriser les produits de la réflexion des architectes (livrables, artifacts, …) Il n’y a pas nécessairement un outil unique qui couvre l’ensemble du référentiel d’architecture Certains éléments sont publiés (sous la forme de livrables) ou de catalogues & diagrammes sur un intranet Les éléments principaux : Le méta-modèle d’architecture La capacité d’architecture définit les structures et processus qui interviennent dans la gouvernance du référentiel Le Paysage de l’Architecture représente une vue des building blocks utilisés à un moment donné dans l’organisation La base d’information de standards (SIB) corresponds aux normes que doivent respecter les architectures La bibliothèque de référence contient des recommandations, des patterns et d’autres informations de référence pour accélérer la conception de nouvelles architectures Le journal d’architecture (Minutes de la Gouvernance) conserve l’historique de l’activité de gouvernance concernant l’architecture Evidemment, le référentiel est en relation avec les modèles de référence externes, les normes externes ainsi que Le(s) comité(s) d’architecture.