LES ACTUALITÉS DE PRAGMATY

13/05/2014 | Newsletter

Interview de nos spécialistes en architecture SI

Découvrez les points de vue de deux de nos experts en architecture SI, n’ayant pas suivi le même parcours professionnel et donnant ainsi des visions différentes mais complémentaires sur les sujets traités.

Cliquez sur ce lien pour lire l’article au format PDF : Questions à nos architectes

Quel est à votre avis le bon parcours qui permet d’arriver au métier d’architecte SI ?
Bernard : pour la formation de base, il vaut mieux être ingénieur, mais il n’y a pas vraiment de parcours particulier, il n’y a pas une école d’architecture. Il y a bien des concepts reliés à l’architecture, des listes à la Prévert, mais il est nécessaire de faire et de tester. L’architecte SI a besoin d’expérience parce qu’il y a des choses que l’on apprend par les erreurs. Après, on sait ce qu’il faut faire ou ne pas faire, ce qui marche ou pas.
Un autre point important pour devenir architecte SI est de passer par le développement et aller jusqu’à la production, en bref, être généraliste. Il faut avoir fait des projets au niveau études, être orienté utilisateurs et business, être pragmatique, être confronté à des problématique de terrain, d’où la production. Enfin, il faut être bien câblé pour être capable de prendre des décisions sur du dimensionnement.
Jean-Charles : le parcours doit être poussé par l’idée de se mettre face à des défis : il doit être tout sauf confortable. Il faut avoir une compétence sur beaucoup de domaines et même une compétence approfondie sur certains de ces domaines. On ne fait pas un architecte avec un expert mais avec quelqu’un qui est expert dans plusieurs domaines, qui ne sont pas du même ordre (par exemple : cumuler des expertises en base de données et en processus vente, et non pas en base de donnée et J2E). L’architecte doit prendre l’ensemble des points en considération, connaitre ses limites et chercher la bonne personne pour l’aider afin d’avoir une vision d’ensemble. Le parcours doit être empreint d’humilité face à la connaissance : ne pas penser tout savoir. Les articles et la théorie ne suffisent pas. L’architecte est quelqu’un qui a l’habitude de travailler avec les autres, qui a du leadership, qui amène les gens à un consensus. Le premier principe de l’architecte est « je ne connais pas l’architecture idéale de demain ».


Lorsque vous recrutez un architecte quels sont les défauts rédhibitoires ?
Bernard : le manque de pragmatisme et la non prise en compte de l’exploitabilité.
Jean-Charles : le plus gros défaut est le narcissisme, être en position de celui qui sait et qui va imposer sa position aux autres. Alors on a un architecte « tour d’ivoire », à l’ancienne. Pas du tout connecté à l’entreprise ni au métier, pas à l’écoute. En fait, cela se voit assez vite en entretien, parce que la personne ne répond à la question posée mais à sa propre question. Le bon architecte est un agrégateur de données donc celui qui ne prend pas les données des autres mais impose les siennes est un mauvais architecte.


On vous dit qu’un système n’est pas performant ; quels sont vos premiers doutes au sujet de l’architecture ?
Bernard : j’ai des doutes sur le développement logiciel : ce n’est donc pas au niveau de l’architecture. Si l’architecture est mauvaise, même si tu mets une « machine de guerre », tu vas gagner 5%. Par contre, si tu mets les bons logiciels tu gagnes 100%. Mon doute se porte donc sur l’architecture logicielle et applicative. Plus tu joues en haut (sur les utilisateurs par exemple), plus tu as de levier : ce n’est pas en rajoutant des processeurs que l’on améliore les choses.
Jean-Charles : je regarde les intermédiations : comment les flux se transportent et comment ils sont stockés, c’est-à-dire la base de données et les chaines de liaison. Ensuite si cela ne suffit pas on regarde ce qui s’exécute en parallèle. Cela peut être un problème de conception ou d’obsolescence. S’il est question de parallélisme ce n’est pas que c’est mal fait mais c’est que ça n’a pas assez évolué. Alors il faut revoir le développement ou bien organiser les activités dans le temps. Avant on avait le transactionnel la journée et le batch uniquement la nuit, quand il y a moins d’activité. Maintenant, dans certains cas on peut faire tourner à un moment de la journée les traitements. On a en tête l’idéal, mais on regarde l’utilisable dans un contexte donné.


Qu’est-ce qui a évolué dans le travail de conception d’une architecture depuis 7-8 ans ?
Bernard : la virtualisation des serveurs : de nos jours, on peut se détacher des contingences matérielles alors qu’avant il fallait acheter des machines et les mettre en place, sizer l’architecture physique. Il y a très longtemps les main frame étaient très gros et étaient découpés pour en faire plusieurs machines virtuelles. Tu testais sur la même machine. Aujourd’hui on a des capacités physiques et on met des machines virtuelles dessus. 4-5 grosses machines physiques peuvent accueillent 100-200 virtuelles. On part avec une petite capacité et on peut l’augmenter plus tard.
Tu dois avoir une architecture ouverte sur l’internet et donc sécurisée, alors tu dois avoir des spécialistes réseau qui connaissent bien la sécurité sur internet. Avant la virtualisation était l’exception maintenant c’est la norme.
Jean-Charles : le choix : il y a quelques années on n’avait pas vraiment le choix, on avait très peu de produits dans un domaine professionnel donné. Maintenant on a beaucoup de choix et en conséquence beaucoup d’erreurs peuvent être commises. De plus, il y a une chose à ne pas faire quand on a tout ce choix : se faire plaisir, faire du beau qui ne répond pas au besoin. Il y a des concepts qui sont sortis, qui sont très forts (possibilité d’avoir des architectures qui sont évolutives par exemple) mais si on applique directement les concepts à la réalité sans prise en compte de l’expérience on aura des architectures trop complexes par rapport au besoin. L’architecture parfaite fournit un modèle or dans la pratique on ne fournit que le nécessaire. Il y a une tendance à coller au modèle de l’architecture idéale, or ce n’est pas fait pour qu’on s’y colle mais pour qu’on s’en inspire.


Est-ce qu’une architecture IT peut être belle (aspect esthétique) ?
Bernard : Une architecture se concrétise par des schémas, donc oui ils peuvent être jolis. Mais l’esthétique va être dans la formalisation de l’architecture. Jean-Charles a l’art de faire du joli schéma, de mettre des couleurs, de la codification. Seulement la formalisation peut être jolie.
Jean-Charles : Oui elle peut être belle, pour la même raison qu’un tableau peut être beau, il faut de l’harmonie, de l’efficacité et quelque chose d’épuré aussi, de simple.


Les parcours de Bernard et Jean-Charles :

Bernard DUCAU
Ingénieur diplômé de l’Ecole Supérieure d’Informatique de Paris, Bernard possède plus de 20 ans d’expérience dont 12 ans de conseil en tant qu’architecte des systèmes informatiques. Il a été l’architecte d’applications très complexes et très volumineuses fonctionnant en environnement hétérogène. Il a mené diverses opérations concernant l’industrialisation d’opération de maintenance au sein de grands groupes. Il est également spécialiste des relations entre équipes de développement et production/ exploitation.
Il a conduit des opérations concernant l’ingénierie du poste de travail (bureautique, informatique communicante, applications métiers) et l’organisation associée : help desk, ingénierie de back-office, ateliers de masterisation, gestion de parc, télé-intervention, …
C’est un expert sur l’organisation de la production et sur ITIL : il intervient ou est intervenu sur le sujet ITIL chez de nombreux clients. Il a obtenu la certification ITIL Foundation en 2005.
Domaines d’expertise :
• Architecture technique et fonctionnelle
• Expert des processus de production ITIL
• Management et pilotage de projets informatiques
• Interface entre les équipes informatiques, études, production, et les métiers

Jean-Charles LEYNADIER
Issu d’une formation scientifique (ingénieur EFREI, Maitrise en physique Paris VI), Jean-Charles a occupé diverses fonctions managériales et techniques dans le domaine de la production bancaire et financière. Il a quitté sa fonction de responsable du service d’intégration applicative d’une grande institution financière française pour rejoindre le monde du conseil.
Il dispose d’une forte expérience de management d’équipes de taille intermédiaire (jusqu’à une cinquantaine de personnes), de la gestion de projets complexes dans des domaines d’activité fortement contraints et des architectures applicatives et techniques des SI des grandes et moyennes entreprises.
Domaines d’expertise :
• Conseil en organisation et en management de la production informatique
• Expert en architecture et intégration de systèmes
• Management et pilotage de projets informatiques (Projets techniques)
• Audit et conseil en performance des systèmes applicatifs
• Assistance à la maitrise d’ouvrage (Projets techniques ou domaine des flux financiers)
• Architecture technique
• Communication technique (réalisation d’outil de communication sur les aspects techniques)

Contactez nos spécialistes pour en savoir plus sur l’architecture SI !
Bernard Ducau : 06 88 46 66 09 ou bernard.ducau@pragmaty.com
Jean-Charles Leynadier : 06 83 56 76 42 ou jean-charles.leynadier@pragmaty.com