Praxeme

1
Praxeme TOGAFS-IT-A, 31 janvier 2008
 We cant solve problems by using the same kind
of thinking we used when we created them. 
.  Albert Einstein
2
Objectif de la présentation

• Objectif
• Thèmes
• TOGAF et le courant Enterprise Architecture
• Méthodologie dentreprise
• Composantes de la méthodologie
• Enjeux

Positionner la méthodologie Praxemepar rapport
au framework TOGAF et montrer lapport pour SOA
Durée de la présentation 30 mn
Protection des documents
3
Contenu de la présentation

• Présentation de TOGAF
• Positionnement dans le champ de la méthodologie
• Présentation de Praxeme
• Articulation de Praxeme avec TOGAF

4
Présentation de TOGAF
1

• Définition
• Contenu
• Méthodologie

What it is gt A framework for providing a
starting point for EA work gt A reference
document for best practices gt A collection of
"world class" resources gt A disciplined
methodology
Origin TAFIM (DOD USA) TAFIM-Technical
Architecture Framework for Information Management
5
Content of TOGAF

• ADM (Architecture Development Methodology)
• Principles (Rules and Guidelines)
• Enterprise Continuum
• Building blocks
• Business scenarios
• Views and Viewpoints
• Architectural Governance
• Architecture Patterns

6
Architecture Development Methodology
P
Framework And Principles
Architectural Vision
Architectural Change Maintenance
Business Architecture
A
H
B
Implementation and governance
Information systems Architecture
Requirements Management
G
C
F
D
E
Technology Architecture
Migration Planning
Opportunities and Solutions
7
Enterprise Architecture
Business Architecture
Application Architecture
Une approche qui reste "fonctionnaliste"
Data Architecture
Technical Architecture
8
Le champ de la méthodologie
2

• La méthodologie comporte trois chapitres
• Nous positionnerons Praxeme et TOGAF dans cet
  espace

9
Les trois dimensions (PRO3)
Product
WHAT
Process
HOW
Procedures methods
(collective)
(individual)
10
Positionnement des contributions
A complete framework to cover all aspects of the
Enterprise
Start the kinds of architecture
Product
Frameworks Target architectures
Detailed how-to-do ?
UP, RUP, OpenUP...
WHAT
Governance framework process CMMI
Process
HOW
Procedures methods
(collective)
(individual)
TOGAF
Modeling disciplines
11
Présentation de Praxeme
3

• Dans la dimension  Produit 
• Le cadre de référence
• Les aspects
• La Topologie du Système dInformation
• Le changement de paradigme
• Les niveaux dabstraction
• Un niveau supérieur ? aspect sémantique
• Un niveau intermédiaire ? aspect logique
• Les catégories de représentation

12
Première approche lObjet Système
Le savoir cur de métier, notions
Comment relier ?Comment optimiser ?
Lactivité processus métier
Les outils logiciels
Les équipements
13
Business the good description

• Approach by activities
• Classical approach
• Flawed with local variation
• Functional hierarchical breakdown structure
• Semantic modelling
• Additional approach
• Move to genericity
• New solution to cope with complexity

Semantic aspect
Objects
Business objects, real objects (InformationTransf
ormationAction)
Refers to
Pragmatic aspect
Activities
Actors organisational entitiesProcess
use-cases
14
Software the good structure

• Determine the software structure from the
  business description
• Applying MDA standard
• Independently from technical choices
• Technical Target free
• Long term

Semantic aspect
Logical aspect
Objects
Logical services aggregates (logical machines)
Derives
Business objects, real objects (InformationTransf
ormationAction)
Pragmatic aspect
Activities
Derives
Actors organisational entitiesProcess
use-cases
SOA
15
Le cadre de référence
Pre-modelling
The Enterprise System Topology
16
Logical architecture the change
Caricature of an architecturebased upon
functional approach
FD
FD
FD
FD
BO
BO
Logical blocks take in charge functional
domains Which structure the pragmatic model It
stems from that important dependencies
orredundancies since same business objects are
usedinside many functional domains
FD functional domain BO business object OD
objects domain
17
A warrant for agility
Représentationdes données de référence
Règles,isolées et qualifiées
18
Articulation Praxeme / TOGAF
4

• Articulation générale
• Enterprise Architecture Solution Architecture
• Le cadre de référence
• En pratique

19
Articulation générale

• Le principe
• TOGAF est, essentiellement, un ensemble structuré
  dactivités
• Il sinscrit dans la dimension du Processus
• Il donne peu de précisions en ce qui concerne les
  procédés
• Les procédés de Praxeme peuvent sinsérer
  facilement dans le cadre fourni par TOGAF
• Pré-modélisation, modélisation
• Le recours au méta-modèle de Praxeme permet
  de   rigidifier  les notions opératoires
• Méta-modèle les catégories de représentation
  selon les aspects

20
Méta-modèle de Praxeme (extrait)
Synoptique pour laspect sémantique
21
La dérivation du modèle sémantique
Classesémantique
Attributs
Structurede données
Opérations
Automate à états
 Services interne 
Le chemin pour la SOA de refonte
22
TOGAF et Praxeme dimension du Produit

• Le cadre de référence nest pas le même
• Quatre plans pour TOGAF
• La Topologie du Système Entreprise pour Praxeme
• Correspondance
• Larticulation des aspects

Architecture métier
Architecture applicative
Architecture de données
Architecture technologique
23
En pratique

• Le mariage est possible
• TOGAF dans la dimension du Processus
• Praxeme dans la dimension du Produit
• Les procédés de modélisation
• Le point darticulation les livrables
• Plus simple avec un phasage adapté
• Mais ce nest pas une obligation
• Il faut tout de même préciser comment lensemble
  des phases couvre les aspects
• Également, le niveau de détail / profondeur dans
  chaque phase
• Le méta-modèle aide à définir les critères
  dacceptation

24
Conclusion

• Praxeme, une méthodologie dentreprise
• Publique et ouverte
• Fondée sur les standards
• Soutenues par des acteurs publics et privés
• Elle peut être utilisée en complément dun
  référentiel de pratiques tel que TOGAF
• Pour en savoir plus
• Le site de lassociation Praxeme Institute
• www.praxeme.org
• Le livre, 3ème partie

Le sensde laction
Pour nos pratiques IT, ne pas se contenterde
dégrossir les processus mais aussi préciser les
procédés