TOGAF, la belle à marier


Les frameworks d’architecture d’entreprise français tels que Urba-EA et Praxème sont peu connus à l’international et parfois opposés à tort aux frameworks anglo-saxons comme le célèbre TOGAF auquel je viens d’être formé.
TOGAF est orienté activités de l’architecte : il est fort sur ce sujet avec des check lists de quoi faire à chaque étape d’un projet par exemple.  Certains trouverons aussi des « manques » sur les méthodes et le formalisme a appliquer à chaque phase d’un cycle projet TOGAF, mais ces manques sont volontaires pour laisser la place au « comment faire » de ces phases à d’autres méthodes. Ces méthodes doivent d’ailleurs être choisies en phase préliminaire et référencées dans la « reference library » de l’ « architecture repository », .
Par exemple PMBOK peut être utilisé dans les phases F et G du cycle de transformation du SI de l’ADM (la rosace ci-contre).
L’un des objectifs de la phase préliminaire de l’ADM est d’adapter l’ADM au contexte d’une entreprise mais aussi à d’autres frameworks, outils et formalisme.

Lors de phase préliminaire de l’ADM il est conseillé d’adapter la démarche, et globalement tous les éléments du framework, au contexte de l’entreprise.

 

C’est donc en phase préliminaire que l’on peut décider d’appliquer Urba-EA ou Praxème à TOGAF.
Christophe Longépé aborde ce sujet au chapitre 11.3.3 de l’ouvrage « Le projet d’urbanisation du SI » 4eme edition (ISBN 978-2-10-052883-7) je n’en parlerais donc pas ici…
Je viens du développement et de la modélisation orienté objet, et, mon plus grand regret est que dans TOGAF  l’approche « objet métier » est réduite à une « Data Entity » sans la dimension « objet » : sans opération, ni cycle de vie.
Cette DataEntity est élaborée dans un 2nd temps après les processus métier. Contrairement à Praxème qui préconise d’élaborer des objets métiers (analyse de l’aspect sémantique, qui exprime la connaissance du métier, indépendamment de la façon de mener l’activité.) avant ou à minima avec les processus métier.
Je viens de suivre une formation TOGAF, et j’en ai profité pour apporter le support et les notes que j’ai prises lors d’une formation  Praxeme « Business Architecture & Transformation » suivie en début d’année.
Voici mes réflexions sur le mariage de ces deux framework d’entreprise :
Le méta-modèle de TOGAF (part. IV) peut converger avec Praxeme si l’on fait les modifications suivantes :
  • déplacer la « Data Entity » dans le domaine de la « Business Architecture » du « Metamodel Reference with Relationship »
  • renommer la « Data Entity » en « Business Object » et que l’on y prend en compte le cycle de vie et des opérations.
  • utiliser UML pour les objets métier et BPMN pour les processus métier
La part. III de l’ADM, nommée « guide lines & techniques », peut ensuite être complétée avec les guides de Praxeme : le guide de l’aspect intentionnel dans peut compléter la phase A, les guides des aspects sémantique (http://wiki.praxeme.org/uploads/Modus/PxPRD20Semantic_FR.pdf), pragmatique, géographique  peuvent compléter la phase B (analyse du métier) et l’aspect logique la phase C (analyse du système d’information) de l’ADM.
Je considère Praxeme comme un complément essentiel à TOGAF et il donc opportun que certaines entreprises choisissent de marier Praxeme et TOGAF.