L’importance de la modélisation dans les entreprises

ceisarLe CEISAR à fait paraitre un article sur l’importance de la modélisation et de la place des objets metier dans la transformation du SI d’une entreprise à l’occasion d’un partenariat avec Praxemehttp://www.ceisar.fr/actualites-et-evenements/detail-de-l-actualite/back/1/article/ceisar-praxeme.html
J’ai adhéré à l’association Praxeme Institute début 2013 suite à une formation en Business Architecture & Transformation mais lorsque je parle de Praxème peu de collègues connaissent :  TOGAF et Urba-EA sont des méthodologies plus connues. Alors voici un petit résumé de ce que je considère de plus novateur dans Praxème.
praxeme
Praxeme sépare la partie métier (ou Business Architecture TOGAF) en 3 « aspects » :
      • l’aspect sémantique où sera défini le modèle métier  : modèle de donnée orienté objet
      • l’aspect pragmatique  ou sont définis les processus métier, organisation, jargon, habitude
      • l’aspect géographique : pour les différences juridiques, culturelles, les distance inter-sites et autres décalages horaires qui méritent d’être pris en compte.

 

L’aspect sémantique défini le modèle métier, plus pompeusement le « coeur de métier » ou « le savoir métier » :
  • les objets métier mais pas les processus métier ni l’organisation qui porte dessus
  • les règles métier indépendamment de la façon dont l’activité métier est pratiquée dans une organisation
  • les différents états des objets et les transitions autorisées (cycle de vie, règles de gestion)
C’est une documentation unique et partageable avec plusieurs organisations de l’entreprise (ex: filiales étrangères).
Souvent après ces explications ce n’est pas encore assez  clair pour le néophyte alors voici un exemple que j’ai consolidé à partir de plusieurs messages d’une discussion entre adhérents de l’association Praxeme :
2042Lorsque l’on travail avec des organisations (quelles soient gouvernementales ou privées) on est aussi confronté à la volonté de ces organisations à résister à tout changement et à légitimer leur existence dans leur forme actuelle. Donc, inconsciemment, a leur volonté de modéliser des objets pragmatique en au lieu des objet sémantiques. Prenons la feuille de déclaration de revenus (c’est l’époque…) le piège consisterait à modéliser l’objet métier « déclaration 2042 »  plûtot que les objets métier « revenu », « contribuable », etc. : un modèle uniquement pragmatique (avec l’objet métier 2042) ne sera applicable qu’en France, et rendra difficile la transformation de la gestion des impôts (comme par exemple la mise en place de prélèvement à la source) alors qu’un modèle sémantique (avec des objets métier moins lié à l’organisation actuelle mais plus à la « réalité » : revenu, contribuable, etc.) est indépendant de l’organisation existante et potentiellement applicable dans d’autres pays.
Pour le reste de la méthode (les aspects logique, logistique et physique) c’est plus « classique » ont retrouve les couches logique/fonctionnelle, applicative, infrastructure/technologique d’Urba-EA ou TOGAF. L’Organum par exemple, reprend les idées de l’Architecture Repository TOGAF.
Un regret personnel : le latin est utilisé pour nommer différents éléments de la méthode et cela a été volontairement choisi par soucis d’universalité mais je trouve que cela apporte de la confusion à beaucoup de personne peu habitué à cette langue.
Pour plus d’information sur l’aspect sémantique voir http://wiki.praxeme.org/uploads/Modus/PxPRD20Semantic_FR.pdf

 

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.