Cependant cette généricité est une qualité qui peut être déroutante aux premiers abords.

Quand Togaf vous suggère de développer une Vision d’Architecture (en Phase A)  ou bien des Architectures de Transition (en phase E), c’est très bien.

Certes, et à quoi peut ressembler une vision d’architecture ou une architecture de transition. Les templates apportent un exemple de réponse possible.

Pour répondre à ce type de questions, The Open Group propose depuis quelques temps deux séries de templates de certains livrables TOGAF.

C’est une initiative plus que louable pour les praticiens et les formateurs.

Disons le simplement, ces templates sont avant tout fait pour servir d’exemples.  Ils sont un excellent moyen de démythifier la pratique d’architecture.

Les templates sont un moyen de concrétiser une forme possible d’un livrable. Un exemple donc, pas un modèle.

Comme toujours et complétement dans l’esprit Togaf, c’est à chaque entreprise de contextualiser ses documents types.

Togaf ne propose rien de magique, mais uniquement des choses issues de « pratiques de praticiens ».

Les templates n’échappent pas à cette approche. Ils sont avant tout utiles pour donner un exemple de « à quoi cela peut ressembler en vrai ».

The Open Group propose deux « paquets » gratuits (un simple formulaire pour recevoir un lien pour télécharger le fichier).

Le contenu du premier paquet (en anglais) :

• Architecture Definition Document
• Architecture Principles
• Architecture Vision
• Business Scenarios
• Request for Architecture Work
• Requirements Impact Assessment
• Statement of Architecture Work

Vous pouvez le récupérer depuis le lien suivant : http://www.opengroup.org/bookstore/catalog/i092.htm

Le contenu du second paquet est plus conséquent, avec des exemples de livrables et des exemples d’artefacts :

delivrables :

• Preliminary Phase: Architecture Principles, Architecture Repository, Business Principles-Goals-Drivers/Business Principles-Goals-Drivers, Organizational Model for Enterprise Architecture, Request for Architecture Work, Tailored Architecture Framework
• Phase A: Architecture Vision, Capability Assessment, Communications Plan, Statement of Architecture Work
• Phase B, C, D: Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap
• Phase E: Implementation and Migration Plan, Transition Architecture
• Phase F: Architecture Building Blocks, Architecture Contract with Business Users, Architecture Contract with Development Partners, Implementation Governance Model
• Phase G: Compliance Assessment, Solution Building Blocks
• Phase H: Architecture Change Request, Requirements Impact Assessment

Artifacts :

Catalogs:
- Application Architecture: Applications Portfolio Catalog, Interface Catalog
- Business Architecture: Contract-Measure Catalog, Driver-Goal-Objective Catalog, Location Catalog, Organization-Actor Catalog, Process-Event-Control-Product Catalog, Role Catalog, Service-Function Catalog
- Data Architecture: Data Entity-Data Component Catalog
- Preliminary: Principles Catalog
- Requirements: Requirements Catalog
- Technology Architecture: Technology Portfolio Catalog, Technology Standards Catalog
Core Diagrams:
- Application Architecture: Application & User Location Diagram, Application Communication Diagram, System Use-Case Diagram
- Architecture Vision: Solution Concept Diagram, Value Chain Diagram
- Business Architecture: Business Footprint Diagram, Business Services and Information Diagram, Functional Decomposition Diagram, Product Lifecycle Diagram
- Data Architecture: Class Diagram, Data Dissemination Diagram
- Opportunities and Solutions: Benefits Diagram, Project Context Diagram
- Technology Architecture: Environments & Locations Diagram, Platform Decomposition Diagram
Extension Diagrams:
- Technology Architecture: Network Computing-Hardware Diagram, Processing Diagram
Matrices:
- Application Architecture: Application Interaction Matrix, Role-System Matrix, System-Function Matrix, System-Organization Matrix
- Architecture Vision: Stakeholder Map Matrix
- Business Architecture: Actor Role Matrix, Business Interaction Matrix
- Data Architecture: Data Entity-Business Function Matrix, System-Data Matrix
- Technology Architecture: System-Technology Matrix

Vous pouvez le récupérer depuis le lien suivant : http://www.opengroup.org/bookstore/catalog/i093.htm

Bonne lecture, enfin bonne pratique !

Ce document est issu des travaux du Cercle CIGREF Architecture d’Entreprise, co-animé par l’Architecture Forum France.

Le Cercle a réuni un panel de praticiens et d’experts, issus des entreprises membres du CIGREF ainsi que de d’organismes, outre l’Architecture Forum France comme le CEISAR et le Club Urba-EA.Cet effort collectif de mise en commun est à saluer.

Le document s’adresse à un public qui, connaissant le sujet Architecture d’Entreprise, souhaite travailler plus spécifiquement sur les aspects liés à la mobilisation des acteurs autour d’une démarche. C’est d’ailleurs clairement explicite dans le titre

L’Architecture d’Entreprise :  Un cadre global de coopération pour les acteurs de l’entreprise

Fidèle à son rôle de diffuseur de connaissances, le CIGREF permet le téléchargement du document via son site, découvrez donc au plus vite cet opus.

Pour les plus impatients, voici la synthèse du document.

« Plusieurs années d’urbanisation du SI en ont montré les apports potentiels mais aussi les défis. Pour concrétiser et pérenniser ces démarches et leurs bénéfices, il est nécessaire de les placer dans un cadre de coopération plus large. C’est l’objectif de l’Architecture d’Entreprise.
Tout DSI a saisi aujourd’hui l’intérêt de mettre en oeuvre une démarche d’Architecture d’Entreprise. Les méthodes, les frameworks et les outils sont nombreux. Nécessaires, ils ne sont pas l’essentiel. Le défi majeur est certainement la mobilisation des acteurs.
L’Architecture d’Entreprise doit réunir tous les acteurs et tous les processus de l’entreprise. La première évidence est que l’Architecture d’Entreprise n’est pas, et ne doit jamais être, cantonnée à un débat d’experts. La seconde évidence est qu’il faut travailler la communication associée.
Le DSI a à distinguer ce qui doit être l’objet d’une discussion avec ses collègues et la Direction Générale, de ce qui est du ressort d’une expertise interne à sa direction.
La démarche, et le discours qui l’accompagne, doivent être solidement ancrés dans les enjeux et objectifs que l’entreprise choisit de relever. Cela exige une prise en compte fine du contexte de l’entreprise. De même, il faudra choisir les apports attendus d’une démarche d’Architecture d’Entreprise à l’aune de ces objectifs. Il faut sortir des pièges d’une « communication attrape‐tout ». «