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 !)