Le bon et le mauvais XML (suite)

Bis repetita...

Cela fait plusieurs fois que je donne mon avis sur ce sujet, et déjà il y a quelques temps, partiellement, sur ce blog. Voici donc dans le détail un peu d'explication sur les "profondeurs de XML"...

Je reçois ce jour la question d'un collègue et ami :

Si fonctionnellement on a ça :


Alors techniquement on peut avoir ça :


Et donc en XML l'adresse est "imbriquée" :

Est-ce correct ? La recopie avec des imbrications à " l'infini " pose problème, ne serait-ce que la lisibilité du fichier XML, non ?

Ma réponse :
En Java (par exemple) la classe sera définie avec une référence à Adresse :
public class Personne {
private Civilite civilite;
private String nom;
private String prenom;
private Adresse adresse; // <- ceci est une référence vers une adresse (ie: l'objet n'est pas dans la classe personne)
}

On aura d'ailleurs :
public class Adresse {
private String num;
private String voie;
// etc.
}

En XML la notion de référence n'est pas native, ce qui fait qu'on a parfois l'impression (seulement l'impression) qu'on doit imbriquer les niveaux :

Ce XML est valide et utilisable dans un message, oui mais...

Les inconvénients d'une telle pratique sont :
1) Jusqu'où aller ? quelle profondeur notre arbre aura au final ? (ie : message.contrat.contractant.personne.adresse.voie. ... , on peut parfois aller loin comme ça !)

2) Comment référencer la même adresse sans la recopier ?
3) comment avoir la même souplesse qu'en Java : une simple référence vers un objet Adresse depuis un objet Personne qui reste simple ?

Il a donc été créé en XML la notion de référence (id/idref ou key/keyref).
Donc la bonne idée est la suivante :


On est toujours en XML valide (penser à englober les 2 éléments dans un élement de plus haut niveau, par exemple ). C'est un mécanisme standard et conseillé mais peu usité car les développeurs ont tendance à préférer des formats très arborescents, ce qui est une erreur pour la lisibilité et l'évolutivité des messages.

Subsiste alors une question : id/idref ou key/keyref ?
La différence :
Dans id/idref , id est un identifiant local au message (ex: "adresse1"), qui n'a aucun sens en dehors du message.
Dans key/keyref, key est une clef externe au message (ie: numéro de compte client, identifiant de contrat, etc.).
La question du choix entre id et key est très importante, et il convient de n'accorder aucun crédit aux réponses absolues du type "toujours key/keyref" (source: O'Reilly). Il faut, selon le cas, choisir l'un ou l'autre.

Guidelines :
-> Utiliser key/keyref c'est se donner l'avantage de la cohérence (en cas d'incohérence une simple requête au référentiel suffira à retrouver l'information). Typiquement : un n° de contrat, un n° de client, un id de transaction, un code pays.
-> Utiliser id/idref c'est garantir qu'on limitera les niveaux d'arborescence (= garantir l'évolutivité et la lisibilité [par le logiciel] des messages), même si les objets référencés n'ont pas d'identifiant unique déclaré. Cette technique est typiquement utilisée pour des objets plus volatiles : une adresse ou tout type de coordonnées, le résultat d'un calcul ou d'un contrôle, etc.

Pour aller encore plus loin :
On suggère de réifier chaque relation (ie: la flèche, dans le diagramme UML, devient un objet XML, du type , et qui peut utiliser des id/idref), afin d'être encore plus évolutif.

Parfois plus difficile à construire, mais tellement plus viable !

On peut aussi utiliser xlink, etc.

Autrement dit, le champ des possibles est vaste, mais on peut commencer par privilégier id/idref ou key/keyref.

A qui appartiennent les [modèles de] Processus ?

A qui appartiennent les [modèles de] Processus ?
Question saugrenue ou véritable problème organisationnel ?

Tout d'abord, à qui appartiennent les Processus ?

Hypothèse : les processus appartiennent aux métiers.
Les processus appartiennent aux métiers, donc à ceux qui les vivent. Cela semble vrai et efficace : le propriétaire, le gestionnaire, l'administrateur, le pilote, le référent, (etc.) du processus est un acteur métier. Cependant c'est une information presque inutile, puisque le processus ne peut être manipulé, modifié, amélioré, étudié, (etc.) que s'il est modélisé.

A qui donc appartiennent ces modèles de processus ?

C'est une question qui existe dans toutes les organisations, et qui renvoie l'image de la difficulté qu'on a à opérer de façon transverse. Si le processus est transverse, la gestion du modèle l'est , elle, parfois un peu moins.

Les métiers de qualiticien, de stratège, de pilote opérationnel, d'exploitant ou d'architecte SI utilisent tous des modèles de processus. On est même parfois confronté à des modèles différents en fonction de ces métiers, voire de l'usage qui est fait du processus.

Si l'on décrète que la Qualité est propriétaire des modèles de processus, comment garantir que l'architecte SI, sans avoir le droit de redessiner le processus, pourra faire son travail ?
Si le métier possède les modèles de processus on va tomber dans le même travers : une représentation unique destinée à piloter l'activité, mais pas à destination des entités support.

La solution passe par la tolérance
Cinq minutes de tolérance. Vous passez devant un bureau et surprenez un dissident en train de modéliser un processus sans mandat officiel...
Votre réaction ? Virez-le !
Non, essayez de comprendre ses raisons : on n'a jamais tort de redessiner un processus dans son coin, on aurait juste tort de croire qu'il fait foi.

La solution passe aussi par la collaboration
L'étape suivante est la collaboration dans la modélisation de processus : ne gardez pas votre savoir enfermé en lecture seule dans votre référentiel de processus (ou dans ce qui fait office de référentiel). Si une équipe, ailleurs dans l'entreprise, apporte sa modeste pierre à l'édifice, acceptez-là comme un enrichissement.
Il y a autant de modèles de processus qu'il y a de métiers qui les utilisent, et votre référentiel, si bien constitué qu'il soit, ne pourra donc pas tous les contenir.

Définir le langage métier de l'entreprise
L'important au fond est de savoir de quoi on parle, et de fixer au minimum le vocabulaire métier. Pour cela le référentiel devra contenir les listes de termes décrivant vos processus : si "acquisition client" est le nom d'un processus, vous devrez expliquer pourquoi ce nom devrait remplacer, si possible, les autres (tels que "vente", "acquérir client", etc.), afin de vérifier qu'on parle de la même chose. Vous définirez aussi "client", vous direz qu'est-ce qui caractérise une "acquisition", et si d'autres objets métier sont importants pour ce processus. Vous trouverez grand nombre des objets métier importants dans les indicateurs de performance du processus (définis conjointement par la Direction, la stratégie et les acteurs du processus). Vous devrez ensuite accepter modestement que dans votre référentiel le modèle de ce processus, représenté par un diagramme, n'est qu'une illustration.

Propriété collective
Les modèles de processus appartiennent à ceux qui les utilisent, ils peuvent varier d'une entité à une autre. Ils doivent respecter le langage métier de l'entreprise, ou expliquer pourquoi ils divergent de ce langage, si c'est leur finalité (dans le cas d'une conduite de changement par exemple).

Et surtout, restez modeste : les modèles de processus sont toujours un peu faux.

Panique dans le monde des trigrammes

Je profite de cette période de vacances pour poster un petit article détente.

Si vous prétendez animer ou participer à la Gouvernance du SI de votre entreprise, vous devrez réfléchir à cette proposition de vos consultants SI : "on vous propose d'être SOA compliant".

SOA compliant ?

Ce "buzz word" a deux significations dans le monde de la gouvernance informatique :
- Sarbanes-Oxley Act compliant (autrement-dit on vous parle de régulation financière)
- Service Oriented Architecture compliant (autrement-dit on vous parle d'architecture autour -à priori- de la gestion de la performance du SI par les services).

Grâce aux trigrammes on n'y comprend plus rien et on vous vend ce qu'on veut !

Rassurez-vous, on pouvait aussi écrire SOX compliant pour Sarbanes-Oxley, ou SOX compliant pour Schema Oriented XML, l'ancêtre de XML Schema, fondation de base des Web Services qu'on retrouve souvent dans la SOA (l'architecture, pas la loi).
On s'y perd.

Le bon et le mauvais XML

Avant-propos : dans la famille des XML-istes, je suis plutôt du type early adopter (voir le paragraphe History sur REST-art). Mais l'usage d'XML doit se faire au profit des utilisateurs, et cela nécessite quelques précautions.

Limitez les hiérarchies
Finalement la structure arborescente d'XML est un inconvénient quand les hiérarchies deviennent trop profondes.


<message>
   <contract>
      <customer>
         <enterprise>
            <contact>
               <personn>
                  <addresses>
                     <postal>
                        <zipcode>75008</zipcode>
                     </postal>
                  </addresses>
                  [etc.]


Les mécanismes de parsing seront plus lents et compliqués à déboguer, surtout en SAX. Les chemins (XPath) seront plus lents à évaluer. Et finalement le message XML ne sera pas vraiment lisible, non évolutif et souvent erroné (problème des références circulaires non exprimables sous forme d'arbre), contrairement à la promesse d'origine. Paradoxalement, avec des hierarchies profondes, ce sont les XPath qui sont simples à lire, ce qui ne sert à rien : "message.contract.customer.enterprise.contact.personn.addresses.postal.zipcode"

Limitez-vous donc à 2 ou 3 niveaux maximum, et privilégiez l'usage d'éléments de liaison et de référence (xlink ou plus simplement ref/idref).

Limitez le dictionnaire
La taille des noms d'éléments (tags et attributs) est aussi problématique : elle ralentira le traitement des messages (écriture, lecture, parsing), elle occupera plus de bande passante lors des transferts, et elle utilisera plus de disque pourle stockage.
Mesurez la place inutilement consommée pour décrire quelques informations :


<postalAddress>
   <streetNumber>12</streetNumber>
   <streetName>avenue des Champs Elysées</streetName>
   <addressComplement>esc C</addressComplement>
   <zipcode>75008</zipcode>
   <city>Paris</city>
   <Country>France</country>
</postalAddress>


Nombre de caractères contenant l'information : 48 octets.
Taille totale du message : 257 octets.

Là encore c'est paradoxal : un avantage de XML, sa lisibilité par l'oeil humain, devient un inconvénient dès lors que l'on souhaite utiliser XML pour faire dialoguer des machines. Et pourtant aujourd'hui, plus aucun oeil humain ne lit ou écrit du XML, la plupart des développeurs utilisant des générateurs (XmlBeans, Jaxb, JEE5, .Net, etc.).

Certains pourraient rétorquer qu'au lieu d'écrire "streetNumber" on aurait pu écrire "sNu" et, pour "streetName", "sNa", etc. Dans ce cas je ne vois vraiment pas ce qu'on gagne à utiliser XML.

Ce qu'il aurait fallu faire (attention ici on n'est plus dans du XLM valide) : puisque le XML bien formé impose des balises équilibrées, leur fermeture peut être anonyme. Imaginez le même message écrit de façon plus économe :

<postalAddress>
   <streetNumber>12</>
   <streetName>avenue des Champs Elysées/>
   <addressComplement>esc C</>
   <zipcode>75008</>
   <city>Paris</>
   <Country>France</>
</>


De plus, si le message qui suivra est décrit au même format, pourquoi rappeler ce format que le système consommateur a déjà rencontré ?

<postalAddress>
   <>12</>
   <>avenue des Champs Elysées</>
   <>esc C</>
   <>75008</>
   <>Paris</>
   <>France</>
</>


Je trouve cette proposition pas moins lisible (surtout si on a reçu au moins une fois le dictionnaire), et facile à convertir en "full-XML".

Ceux qui disent que le XML avait l'avantage d'être vérifié par le récepteur avant parsing seront encore plus heureux d'utiliser MD5 pour conserver des possibilités de vérification sans alourdir le message lui-même.

Pour ceux que l'évolutivité (la naturelle compatibilité ascendante d'XML) intéresse, aucun problème : ma solution ne supprime pas la notion de tag XML, elle permet de n'en transporter que les éléments essentiels, pas à chaque message. Il faudra néanmoins transporter un numéro de version de message, mais c'est une pratique que je recommande déjà en XML.

Pour utiliser une autre optimisation d'XML voyez par exemple BiTXml.

Restreignez-vous au strict minimum en XML
Si vous consultez la description du protocole HTTP (RFC2616) et de MIME (RFC2045), vous verrez que pour la plupart des échanges les formats sont standardisés. Vous constaterez aussi que le transfert de données simples est couvert par le type de contenu "application/x-www-form-urlencoded" (ex: streetNumber=12&streetName=avenue%20des%20Champs%20Elysees&zipCode=75008), et ces syntaxes sont des standards utilisés par tous les outils Web ainsi que les librairies associées dans tous les environnements (Java, .Net, PHP, Perl, C++, etc.).

Il ne reste au fond que des rares cas de données très structurées qui nécessitent l'usage de XML lors d'échanges M2M (machine to machine). Malgré cette évidence, les frameworks de développement de Web Services vous imposent l'usage de SOAP avec du XML auto-généré de manière opaque. .Net était déjà à l'extrême dans ce sens, JEE5 pousse le bouchon encore plus loin avec un comportement qui sera aléatoire selon le serveur d'application choisi (usage des annotations @Xxx).

Conclusion
Pour synthétiser, utilisez XML dans des messages à hiérarchie limitée (2 ou 3 niveaux), aux tags explicites mais pas trop longs, aux liens entre éléments réifiés, et uniquement si vous n'avez pas d'autre choix.
En définitive XML ressemble à une bonne idée non finalisée à utiliser exceptionnellement plutôt qu'à une solution universelle.

Pour plus d'arguments voir aussi le Guide d'usage de REST-art.

Cartographiez, Modélisez !

Boites et flèches, bulles et lignes, diagrammes, graphiques : tout est bon, tant que c'est adapté à l'interlocuteur.

Cartographiez les données, les systèmes, les applications, les machines, les salles, les flux, les liaisons : tout ceci vous permettra de mieux gérer l'existant.

Modélisez les processus, les données, les acteurs, les interactions, les réactions, les transactions, les règles de gestion : tout ceci est nécessaire pour comprendre les concepts et leur dynamique.

Cartographiez la liaison entre la cartographie et la modélisation (!) : pour connaître les systèmes mis en oeuvre dans les processus, pour connaître les données transportées par les flux, pour comprendre la chaîne de valeur de l'entreprise, pour révéler les chaînons faibles.

Cartographiez et modélisez l'existant : pour assurer l'exploitation, la poduction, la qualité de service.

Cartographiez et modélisez la cible : pour accompagner les projets, arbitrer les priorités, trouver les impacts des projets, pour assurer la transversalité des travaux en cours.

La liste est non exhaustive.

Quelques méthodes :

Avant-tout, la méthode de la méthode : soyez créatifs ! Un directeur général n'attend pas la même présentation qu'un chef de projet ou qu'un développeur. Utilisez des standards, mais uniquement à bon escient. Par exemple, face à un interlocuteur "UML-ophobe" sortir d'UML et passer 30 minutes d'effort pour redessiner un diagramme de façon plus lisible sera certainement payant. Par exemple encore, faire usage de couleurs remarquables, de mise en relief, de jeu sur les tailles, etc.
Votre objectif est de faire un focus sur quelques activités ? Supprimez les détails techniques du processus ! Votre objectif est de faire un focus sur les concepts utilisés ? Supprimez l'UML, faites une liste à plat ! Votre objectif est de montrer des regroupements par catégorie ou par package ? Faites un arbre façon explorer ! etc.

Boites et flèches : UML, BPMN, etc. "Boites et flèches", c'est le langage commun du modélisateur.




Boites et courbes : petite variante bien pratique pour montrer la dynamique : une courbe se suit plus naturellement que des segments de droite, et avec moins de confusion.








Bulles et lignes : pour sortir du côté rectiligne des boîtes. On peut de plus jouer sur le diamètre des bulles.







Flux et swimlanes : d'un simple coup de souris, pour donner une qualification ou une catégorisation globale.








Cartes et plans : analogie avec l'urbanisation (la vraie !), pour attirer l'oeil vers un format "déjà vu".













Plan de métro (croisement entre "Cartes et plans" et "Bulles et lignes") : pour montrer les liaisons (correspondances), les indicateurs ou activités (stations), les hypothèses de départ et les objectifs (terminus de départ et d'arrivée), etc.








Et il y en a encore plein (3D, Etoiles, Spirales, Cibles, ...).

Il n'y a pas de représentation unique pour communiquer ou faire comprendre autour d'un diagramme. Il y a la (les) vôtre(s), et celle(s) de vos interlocuteurs.


Mais souvenez-vous : quelle que soit la forme : Cartographiez, Modélisez !

---
Quelques liens :
Proposition de Philippe Dias (plans de métro)
BPMN et aussi ici et sur Wikipedia.
UML et sur Wikipedia

Processus métier : de la modélisation au design

Mode traditionnel
Dans un mode client-fournisseur, ou MOA-MOE, le travail de l'architecte SI en terme de modélisation des processus revient à dessiner les processus existant ou à mettre en oeuvre avec un formalisme BPMN ou UML2 (par exemple, selon les usages dans l'entreprise).

Dans un projet en mode MOA-MOE, l'architecte porte donc le stylo-BPMN et réalise les diagrammes des processus métier et leur accostage (impacts sur les applications, sur les flux, sur les bases de données) sur le SI.

Mode collaboratif : de la modélisation au (co-)design
Mais la proposition de l'architecte SI se situe en réalité plus en avance de phase. La modélisation a posteriori (systèmes existant) ou en aval des spécifications de besoins dans un cycle en V (projet en cours) doit laisser la place à une collaboration lors du design des processus futurs, en cours de développement ou de refonte.

La réflexion conjointe et transverse de l'architecte SI, des utilisateurs et des personnes en charge du projet conduira naturellement à la réconciliation entre les besoins initiaux, le plus souvent exprimés par les acteurs métier, et les apports supplémentaires (goodies ?) apportés par la technologie employée (ou proposée) qui pourront être traduits en besoin complémentaires.
L'innovation métier s'allie donc à l'innovation technique.

Si de plus le business plan de l'entreprise est basé sur l'économie numérique, vous gagnerez en parts de marché, incontestablement.

Illustration
Lors de la reprise d'un processus l'architecte signale que le client online pourrait voir s'afficher dynamiquement le contenu de son panier et des suggestions complémentaires d'achat en utilisant AJAX sur la SOA mise en place lors des précédents travaux de refonte. Ensemble ils redéfinissent le processus d'achat en diminuant le nombre de clics pour valider le panier ou pour obtenir des articles simplement depuis d'autres zones du catlogue.
Cette illustration n'est pas vraiment innovante, mais elle permet de comprendre le lien entre apports métier et apports technologiques. L'architecte SI met en regard ces deux univers (j'ai même souvent employé l'expression "réduction du fossé métier-SI"), rend plus transverses les processus, aussi bien au niveau métier qu'au niveau SI.

J2EE ? avec discernement

Vous avez déployé une infrastructure J2EE et vous souffrez pour vos performances ?
Vous avez lu les tests de performance de J2EE et vous êtes refroidi ?

Normal.

J2EE n'est pas lent, il en fait juste beaucoup... parfois même un peu trop.

J2EE repose avant tout sur une promesse de fiabilité et de sécurité. Et cela a un coût, payé par les performances. Les serveurs devront être "musclés", et les applications taillées avec attention. Et ce que vos intégrateurs ou éditeurs de serveur d'application font le plus souvent, sans discernement, c'est vous servir du J2EE sous prétexte que la "Standard Edition" n'est pas pour l'entreprise, à l'inverse de l' "Enterprise Edition". Songez que pour eux c'est surtout la promesse d'une réutilisation maximale.

Etudiez votre besoin

Si vous n'exploitez pas les possibilités offertes par J2EE, alors restez sur des solutions ad-hoc en J2SE, au risque d'assister à une dégradation des performances et une augmentation de vos coûts de possession.
L'architecture J2EE n'est pas une mauvaise architecture, loin s'en faut (voir mon précédent article "Java LA plateforme"), mais elle ne s'adresse pas à tous.

Quelques illustrations :

- La plupart des développements J2EE se font en écrivant le minimum de code grace à la richesse de la plateforme. Conséquence évidente, la généricité (du code déjà écrit) en fait un système moins performant (mais plus évolutif) qu'un système au design spécifique.

- Les EJB sont entièrement pris à la charge de la plateforme, ce qui induit un risque sur la charge et les performances, surtout si on utilise les API de persistance. De plus il existe des spécificités d'implémentation qu'il faudra prendre en compte en cas de passage d'un server applicatif J2EE à un autre.

- JSF (et Struts pour ceux qui y sont encore) induisent des indirections et l'usage de beaucoup d'objets pour gérer les contextes de la session et des invocations de services, en échange d'une excellente évolutivité de la plateforme. Ce que vous ne payez pas dans vos développements et tests, vous le payez en performance.

- Plus lointain de J2EE mais à considérer tout de même, les Web Services. L'usage de XML sur HTTP est un frein à la performance mais réduit les temps d'intégration et les risques de dysfonctionnement aux interfaces de vos systèmes. La SOA est bonne pour la fiabilité, mais à étudier de près pour les performances.

Bilan

J2EE semblera peu performant à qui ne fait pas usage d'une majorité des fonctionnalités proposée. Pour celui qui utilise sa puissance, alors c'est une très bonne plateforme, même si un réglage fin des performances reste obligatoire.
Mais surtout, regardez de près : parfois, un simple développement J2SE suffit, même en environnement distribué.

Dernier point : quoi que vous fassiez, privilégiez la sécurité avant tout, avant les performances, et jamais "dans un deuxième temps", comme on entend souvent.

L'organisation au service de l'architecture du SI

Selon le cabinet de recherche Forrester (http://www.forrester.com), la clef du succès pour les architectures multi-canal réside dans la réorganisation de l'entreprise.

Un peu de détail

L'interlocuteur avec lequel j'ai discuté a effecué un parcours de consultant IT dans le secteur bancaire. Dans ce secteur, historiquement, les opérations étaient réalisées au guichet. Puis elles ont pu être traitées par téléphone ou fax avec le conseiller. Puis par téléphone avec un centre d'appels. Puis par le web, le mail, et peut-être bientôt par le messenger, le sms, etc.

Dans une banque organisée en business unit, chaque BU a donc développé ses canaux de communication. Par exemple la BU grand public a ses conseillers, son site web, son call center, etc. La BU bourse idem. La BU crédit idem. La BU asset management idem. etc. Au total, autant de sites web ou de call centers que de BU. Et si vous êtes client de plusieurs BU (pourtant regroupées sous la même marque), c'est autant de canaux différents qu'il vous faut manipuler. Incompréhensible.

Dans une banque organisée par canaux en silos, c'est à dire constituée par ajout de direction en fonction de l'apparition des canaux (direction des agences, puis direction des call centers, puis direction internet, etc.), chaque canal doit implémenter toutes les offres. On se retrouve ainsi face à des dossiers client non échangeables entre canaux, ou des propositions hétérogènes selon les canaux. Par exemple : "Allo bonjour j'ai fait un virement par internet mais je me suis trompé ! - Désolé monsieur, vous êtes à votre agence ici...". Ou encore : "Allo j'aimerais profiter de l'offre que j'ai vue sur internet. - Ah ? connais pas !".

Mon interlocuteur en a donc déduit les faits suivants :

• Tout d'abord il ne s'intéresse plus aux banques mais à leurs canaux.
• Ensuite il résoud la cohérence entre canaux et les contraintes de l'architecture multi-canal en réorganisant les directions ou les BU incorrectement structurées.

On est donc en présence d'une (ré)organisation au service de l'architecture. Mais aussi et surtout d'une architecture pleinement en accord avec les objectifs business de l'entreprise.
Et si en plus on peut mettre une SOA au service de tout ce petit monde, on aura gagné l'architecture de la banque du futur !

L'architecte SI (qui commence vraiment à beaucoup sortir de sa DSI ces derniers temps) a donc aussi la responsabilité de proposer ce type d'adaptation.

Vers le plein emploi ? Oui mais où ???

> Reçu le 28 août 2006 :
>
> Salut,
>
> Comment vas-tu ?
>
> J'ai trouvé ton mail par hasard en faisant une recherche
> sur google sur architecte SI. En tout cas, difficile en ce
> moment de trouver un poste d'architecte SI.
>
> Cordialement,

Salut.

C'est d'autant plus étonnant que les Forrester et Gartner sont d'accord pour dire que le profil d'architecte est le plus recherché actuellement par les entreprises. Je m'étais moi-même demandé, en les entendant, s'ils faisaient écho de statistiques mondiales ou françaises. La plupart des grandes boites françaises étant encore sur un mode MOA / MOE, il est difficile d'exploiter ce qui est vendu par ces cabinets comme l'importance de l'architecte (IT voire "d'entreprise"...) dans la conquête du business.

Good luck,
A+
// Thibault

L'IT Architect Visionnaire est-il un Enterprise Architect ?

L'architecte SI est l'élément visionnaire du SI.

Si je ne l'ai pas écrit in extenso dans les articles précédents (un excès de modestie peut-être ?), je l'ai au moins très fort pensé, et surtout je le vis au quotidien !

J'en suis d'autant plus convaincu que notre mouton à cinq pattes d'architecte SI, devant se plier aux exigences métier de l'entreprise, à leur réalisme face à un SI toujours plus complexe à piloter, doit prendre les bonnes décisions pour demain en connaissant les contraintes techniques et marché de demain.

Pour aller plus loin, au-delà même de la prise en compte des exigences métier, il doit le plus souvent les connaître, les anticiper. Bref, il faut savoir concilier les différentes vues de l'entreprise face à son marché, de l'entreprise face à ses acteurs internes, de l'entreprise face à son SI, et enfin du positionnement de l'entreprise dans son secteur.

Mmmh, on est loin du simple profil ingénieur informaticien, non ? ;-)

Les entreprises US, réalistent à ce sujet, parlent d'ailleurs maintenant d'enterprise architect. C'est un profil rare, mais très clairement identifié dans les organisations et déjà fortement recherché.

Pour information, dans mes "dîners du samedi soir", on me regarde toujours avec un sourire compatissant quand j'énonce ma profession : "architecte SI". Alors "architecte d'entreprise", je n'ose pas encore me lancer...

Convaincre ou enseigner ?

Je fais écho aux conseils et questions soulevés par Christophe (http://urba-si.blogspot.com) dans ses articles traitant de l’action de convaincre, d’expliquer le pourquoi de l’urbanisation du système d’information, de l’approche par processus métier, de la définition de l’architecture du SI comme une activité stratégique du SI (et de l’entreprise), etc.

Je partage l’intégralité de son opinion mais je prône plus de fermeté.

Il est parfois nécessaire d’arrêter de s’excuser d’essayer de convaincre. Dans le secteur de la constitution ou de l’évolution du SI il n’est pas question de convaincre d’adopter l’urbanisation, mais bien de l’enseigner.
La discipline que nous exerçons, appelée architecture (ou urbanisation) des systèmes d’information, applique et met en pratique les concepts de modularité, de couplages faibles entre systèmes, de sécurité, de disponibilité. Elle n’impose aucun choix technologique (choix éditeur vs open-source, choix du langage, choix du framework, pourcentage de spécifique vs ERP, etc.), qui eux feront partie du domaine de la conviction.

Par exemple je parlais de Java précédemment, on est là dans la conviction. Mais pour ce qui est de l’architecture des SI notre métier consiste à enseigner la bonne démarche. Ceci implique d’autant plus de travail qu’enseigner c’est à la fois fédérer, partager, comprendre, répéter, contrôler, accompagner… et convaincre !

Différencier l'Architecte du Développeur

J'ai participé à une discussion autour de la question suivante : quelle différence entre un architecte et un développeur ?

L'architecte sait développer...

L'architecte, je l'ai déjà dit, est aussi proche de la technique que du métier. Cela signifie notamment que pour assurer l'intégration des éléments d'un SI l'architecte doit savoir prescrire des éléments techniques pouvant aller jusqu'au détail d'un code source : synchronisme/asynchronisme et nommage des méthodes ou services, type de distribution des applications, spécificités de d'implémentation des processus métier sur le BPM, norme de codage des échanges, respect de la sécurité, etc.

... le développeur aussi

Le développeur, quant à lui, est spécifiquement confronté à ces question car il est en charge de l'implémentation. Mais ce n'est pas à lui de prendre systématiquement ces décisions techniques, au risque d'être le seul à maîtriser l'architecture de l'intégration des composants applicatifs du SI, et donc d'en contraindre les prochaines évolutions.

Le rôle de l'architecte est donc de répondre à ces questions avant le début des développements. Les réponses viennent des interviews des gens de métier réalisées par l'architecte : quel usage sera fait des services ? qui verra les échanges ? qui pilotera les processus métier ? quelle sera la prochaine application à intéger ? sur quels services métier ? modifiant quels procesuss métier ? etc.

Les spécificités de la SOA et du BPM sont de la responsabilité de l'architecte. Leur implémentation est de la responsabilité du développeur.

Rôle ou Acteur ?

L'objectif n'est pas d'avoir systématiquement deux personnes (acteurs) même pour les petites structures, mais bien deux types d'activités (rôles), bien identifiés. Cela étant, l'augmentation de charge aidant, les deux rôles tendront à s'incarner dans deux acteurs différents.

Analogie

L'analogie avec le monde du bâtiment est assez bonne : sans architecte, peut-on vraiment construire une maison ? Il faudra au moins s'être posé les questions de l'architecte avant de démarrer. L'architecte aura écouté votre besoin, il les aura traduit en exigences techniques à destination de l'entrepreneur, et il pilotera la construction pour s'assurer que vos besoins se transforment en maison...

Merci à Emmanuel Collin, consultant BEA.

J2EE Tech Tips

Comment utiliser l'API JavaMail ?
C'est quoi J2CA ?
Comment mettre en oeuvre JAXB ?

Les J2EE Tech Tips sont disponibles, vous pouvez même les recevoir par mail.
http://java.sun.com/developer/EJTechTips/

Java : LA plate-forme ?

Cet article m'est inspiré par un candidat stagiaire qui me disait : "Java ? connais pas. Mais comme tout langage, ça s'apprend facilement."

Certes, mais la route est longue.

Beaucoup plus qu'un langage

Regardez devant vous : le désert.
Fermez les yeux et comptez jusqu'à 10.
Ouvrez les yeux : une ville, des maisons, des parcs, des routes.

C'est l'impression que me donne Java : l'actualité est débordante d'événements et riche d'apports et d'ajouts autour de Java, qu'ils proviennent du monde Open Source, du monde des éditeurs ou des sociétés de services.

Java est un bouillon de culture qui en fait une plate-forme de premier choix, possédant des ramifications sur tous les niveaux (je mélange volontairement dans la liste ci-dessous les technos, les sources, les open source et les autres, etc.) :

• IHMs (AWT, Swing, SWT, JSP, JSF, Applets, ...)
• Coeur Applicatif (Beans, Servlets, librairies et API multiples, J2EE, Serveurs d'app, ...)
• Echanges de données (XML, Messaging, JAXP, WebServices, mails, ...)
• Persistance (JDBC, JNDI, ...)

Mais aussi déploiements variés (J2SE multi-plateforme, J2ME, JavaCard, ...), environnements divers (Eclipse, Java Studio Creator, ...), etc.

Il en manque encore !

La liste est si longue que j'ai oublié les 3/4 des API ou qui font qu'à chaque fois que je m'aventure sur java.sun.com je passe de longues heures à me délecter (si si) des dernières trouvailles... Ensuite j'enchaîne sur sourceforge.net et apache.org pour enfin me sentir bien !

Bonne visite !

Pour finir, message spécial stagiaires : apprenez Java, c'est le reste qui sera facile à comprendre ensuite.

Pensée unique : c'est non !

Appliquez dans votre métier d'architecte SI le principe d'incertitude.

Grands partisans de la pensée unique, grands pourfendeurs des solutions immédiates, trouvées avant même d'avoir établi la problématique, fuyez ce blog !

Ca y est, cher lecteur, on est enfin entre nous.
Vous pensiez être à l'abri ? Que nenni ! Sur chaque site web commercial, après avoir franchi l'habituelle page d'accueil bourrée des dernières news et de bandeaux publicitaires attrayants, vous tomberez sur l'inévitable onglet "Solutions". Ils n'ont pas encore commencé à comprendre la nature de votre problématique qu'ils sont déjà en train de vous vendre l'outil idéal, à la sauce propriétaire BiduleSoft et au contrat annuel à 20% (formation exclue bien entendu).

Si vous résistez, on vous colle MachinConsulting qui va vous trouver un problème bien à la mesure de la solution de BiduleSoft à condition d'avoir (évidemment) acheté TrucWare.

Fin de la rébellion. :-)

J'enfonce des portes ouvertes ? Tant mieux, un architecte averti en vaux certainement deux. Vous pensez avoir échappé au massacre ? libre à vous, mais restez vigilant.

La pensée unique nourrit les spéculations les plus hasardeuses et engendre les conclusions les plus erronées. Pourquoi ? Parce qu'il n'y a pas de problème générique ni de modèle d'esprit commun.

Votre problème est unique, votre solution le sera aussi.

Ma solution ? (vous voyez, on tombe vite dans le travers !) la voici...
Parlez processus, réfléchissez utilisateur, pensez bout en bout, ayez le réflexe métier, visez le résultat, n'oubliez pas l'avenir. Posez vos hypothèses, parlez-en autour de vous, ouvrez vos réflexions. Et là vous pourrez aiguiller MachinConsulting et les emmener sur la piste de la solution qui vous conviendra.

Pour finir, regardez bien autour de vous : en réalité, la solution est ailleurs. (finir par la musique d'X-Files !)

Patterns génériques d'architecture

Pourquoi inventer quand on peut copier ?

Pourquoi refaire quand on peut réutiliser ?

Pour parvenir à ces malhonnêtes fins (on m'a toujours dit que copier c'était tricher) utilisons les "patterns" d'architecture.

Bref aperçu.

REST : un pattern d'architecture inter-applicative générique

Il est facile, en découvrant REST, de comprendre pourquoi un style d'architecture applicative peut influencer la stratégie de l'application, ses capacités d'ouverture et d'évolutions futures.
Le respect des principes REST dans les applications d'un SI permet de définir à l'avance les capacités futures du système à intégrer les services d'autres systèmes ou à fournir ses services à d'autres systèmes.

En d'autres termes, garantir que vous respectez un certain nombre de principes simples et intelligents, dont REST est un bon exemple, permet d'assurer l'évolutivité du système dans le cadre de ces principes (tautologie non ?), tout en étant sûr, puisqu'il en est ainsi dans REST, que vous ne fermez la porte à aucune technologie d'échange d'information.

REST n'est pas une solution en soit, mais un outil garantissant que vous ne faites pas entièrement fausse route.

A ne pas manquer, sur le même sujet :
- REST : http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
- protocole HTTP : http://www.w3.org/Protocols/rfc2616/rfc2616.html
- W3C : http://www.w3.org/TR/webarch/
- sur le site de JP. Figer : http://www.figer.com/Publications/REST.htm

MVC : un pattern d'architecture logicielle générique

Même si l'intérieur d'une application peut être conçu au style REST (bonne idée d'ailleurs), son design doit être vu de manière souvent plus précise. Ceci est d'autant plus vrai que l'application intégrera des données, des écrans et divers utilisateurs éventuellement simultanément.
La définition très précise de MVC (ou de MVC2) permet de concevoir l'application sans se poser la question du style d'architecture interne, du respect de tel ou tel pattern. Il ne reste plus au concepteur qu'à chercher le framework d'implémentation le plus adapté à l'application et au langage utilisé.

L'erreur classique du développeur qui consiste à "tout casser puisque le modèle n'était pas le bon" peut alors être évitée au moins en ce qui concerne les liaisons entre la visualisation, la présentation, la structuration et les modèles de données, l'internationalisation et éventuellement l'accès aux données persistantes.

A ne pas manquer, sur le même sujet :
- sorte de MVC pour les nuls (c'est vieux mais ça explique bien) : http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html
- la vision sun de MVC : http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html

Autres patterns...

Ce que je constate souvent c'est que l'application des patterns d'architecture se fait quel que soit le niveau (sorte de fractale, comme démontré dans [YCS]) : au niveau composant d'une librairie, au niveau application, au niveau liaisons inter-systèmes, au niveau application server, etc.
Un grand jeu de mon quotidien consiste à utiliser les Design Patterns [GOF] à tous les niveaux de l'architecture du SI, de la note de stratégie globale au détail d'un bout de code. Vous verrez, ça marche !

A votre tour, si ça vous chante, postez en commentaire de cet article les références vers vos meilleurs patterns.

A ne pas manquer, sur le sujet :
- Sun fait le lien entre des use cases et des patterns associés : http://java.sun.com/developer/technicalArticles/J2EE/despat/index.html
- l'architecture J2EE décrite, entre autre, au travers de patterns : http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/

Références ci-dessus :
[GOF] Design Patterns - E. Gamma, R. Helm, R. Johnson, J. Vlissides
[YCS] Urbanisation et BPM - Y. Caseau

Little Indian vs Big Indian

Reflexion de comptoir...

En fait, rien n'a vraiment changé : l'un des grands problèmes des années 80 était la compatibilité entre matériels (mémoires, CPUs), applications (messages, fichiers), etc. : Little Endian ou Big Endian ?
Aujourd'hui, la vraie problématique des DSI c'est le degré d'offshore : Little Indian ou Big Indian ?

NB: vous remarquerez que j'évacue l'hypothèse "pas d'offshore"...

Architecture de SI et Stratégie d'Entreprise

Les Architectes SI sont-ils enfermés dans leur sous-sol de DSI ?

Les Architectes SI sont-ils des animaux étranges, mi-humain mi-développeur (on sait bien que les développeurs ne sont pas des humains), incapables de voir autre-chose que l'informatique ?

Spectre large

Le métier d'Architecte SI couvre un spectre large des activités de l'entreprise, de la compréhension des besoins métier à l'implémentation des systèmes. Dans le titre, "SI" signifie "systèmes d'information" et non "informatique", car il est important de considérer les flux d'information inhérents au(x) métier(s) de l'entreprise et leur interaction avec les composants informatiques.
Mouture étrange de l'informaticien, l'Architecte SI peut se voir tour à tour confier des missions très "métier" ou très "techniques".

Le profil de l'Architecte SI doit permettre de gérer les situations où la stratégie de l'entreprise croise les technologies de l'information. Il se doit de donner au Système d'Information une dimension stratégique pour l'entreprise. Il doit enfin connaître aussi bien l'activité de l'entreprise (la partie "métier" ou "coeur de business") que les possibilités (actuelles ou futures) offertes par le SI.

En définitive, l'Architecte SI participe à la création d'un SI prêt à servir les desseins de l'entreprise autant qu'il contribue à organiser et créer les desseins de l'entreprise.

Conclusions...

• ce mouton à 5 pattes n'est que très rarement un seul homme,
• on doit pouvoir trouver de bons Architectes SI au sein des directions de la stratégie,
• on doit pouvoir trouver de bons directeurs de la stratégie parmis les Architectes SI.

Profession : Architecte SI (IT Architect)

Avant toute chose, je me donne deux mots d'ordres pour la réalisation de ce site :

Premier point, il me concerne : publier un avis c'est déjà offrir un peu de soi-même. Donc publier un avis sur son métier c'est presque une faute professionnelle. J'en prends le risque, notamment parceque ma hiérarchie s'est risquée au même exercice (http://organisationarchitecture.blogspot.com/) et parceque je me promets de toujours me relire sept fois avant de publier un article (je prends donc en compte le fait que le Blog est devenu un outil incontournable d'espionnage industriel). C'est aussi parceque, dans mon métier, internet est une source inépuisable d'informations (à traiter toutefois avec prudence), et que je me sens donc le devoir de, moi aussi, contribuer à l'échange d'informations sur mon activité d'une manière générale.

Second point, il nous concerne : si vous réagissez aux articles en ligne sur ce Blog, ayez en tête le même avertissement. Je ne compte plus les soirées, les trajets en train, etc. où j'apprends énormément de choses sur la concurrence, et je suis désolé pour mes interlocuteurs.

Soyons donc conscients que ce qu'on écrit est lu, parfois avec mauvaise intention.

Ceci étant dit, quel est le vrai sujet de ce site ?

Publier et récolter des avis et informations sur les activités d'Architecture des Systèmes d'Information, donner une vitrine publique à un métier riche et passionnant, et surtout, et j'en suis désolé : ne rien dévoiler réellement de mon activité... ;-)

Mais rassurez-vous, il y a beaucoup à dire tout de même.