IT & Bank luxembourg

Type d'article: Bank 0% IT  100% 

La première chose à laquelle on pense qu’en on réfléchit à l’informatique écologique est la consommation électrique. Les solutions consisteraient à éteindre les écrans, les ordinateurs et les imprimantes quand on n’en a pas besoin.

Le sujet est bien plus vaste et plus complexe. Par exemple selon le site www.greenit.fr l’impact écologique de la construction et de la fin de vie des matériels informatiques serait du même ordre de grandeur que celui de leur phase d’utilisation. Ainsi garder un PC plus longtemps serait aussi efficace écologiquement que de l’éteindre.

Le CIGREF (club des directeurs informatiques français) réfléchit à la question écologique et a publié un document à ce sujet. Le CIGREF a conçu un questionnaire d’évaluation de la « maturité écologique » d’un système d’information et l’a utilisé pour faire un état des lieux. Le CIGREF recense également les bonnes pratiques écologiques.

Je pense que le monde informatique n’en est qu’à une phase de prise de conscience écologique. Celle de la recherche de solution a commencé mais la réelle mise en oeuvre est devant nous.

Gwenael Oliot

References:

• Publication du CIGREF http://www.cigref.fr/cigref_publications/RapportsContainer/Parus2009/Systemes_d_information_eco-responsables_CIGREF_2009.pdf 
• Outil d’évaluation du CIGREF http://www.cigref.fr/cigref_publications/RapportsContainer/Parus2009/2009-Outil_d_evaluation_CIGREF-SI_eco-responsable.xls
• Article www.greenit.fr http://www.greenit.fr/article/materiel/24-fois-plus-de-co2-lors-de-la-fabrication-dun-ordinateur-que-lors-de-son-utilisati
• http://www.thegreengrid.org

Type d’article Bank 25%  IT 75%

Le clouding computing est la dernière mode informatique. Etes-vous cloud ? Comment est-ce possible vous n’êtes pas encore cloud ? Attention vous êtes peut-être en train de rater la nouvelle révolution informatique : L’informatique sans ordinateur et sans informaticien !

Le clouding promet des applications informatiques développées et hébergées dans les nuages. Avec le cloud plus de problème informatique plus de problème d’informaticien, une connexion réseau suffi, la capacité s’adapte aux besoins et on ne paie que ce qu’on utilise. Le clouding a pour objectifs de rendre la distribution des applications informatiques aussi simple que la distribution l’électricité : une prise et c’est tout. Le clouding serait même écologique.

A la fin des années 90 début 2000, les market places informatiques devaient révolutionner le commerce. Les magasins classiques avaient du souci à se faire, puisque tout aller s’acheter sur Internet d’un simple click ! Aujourd’hui, dix ans et deux éclatements de bulle spéculative plus tard, on va toujours acheter ses chaussures dans des boutiques qui sentent bon le cuire. Le commerce électronique s’est ajouté aux canaux de distribution traditionnels sans les remplacer. La révolution n’a pas eu lieu, mais l’évolution est en cour.

Le clouding va sans doute suivre la même voie. Externaliser totalement certaines applications va sans doute être pertinent pour certaines entreprises, externaliser toute l’IT de toutes les entreprises est une chimère. Les entreprises ont du mal à aligner leur IT à leur business avec des équipes informatiques dédiées comment y arriveraient t’elles avec des solutions génériques dans les nuages ? Comment comparer l’électricité qui se caractérise simplement par une tension, une fréquence et une intensité à une application informatique caractérisée par des centaines de page de spécification ?

La réalité n’est pas aussi caricaturale puisqu’il existe plusieurs niveaux de clouding. Le premier niveau (IaaS) consiste à externaliser la gestion des serveurs informatiques. Le second niveau (PaaS) consiste à ajouter les logiciels d’infrastructure tels que les systèmes d’exploitation et les systèmes de gestion de base de données. Le troisième niveau (Saas), le plus abouti, consiste à externaliser également les applications métier.

Les deux premiers niveaux reviennent plus ou moins à ce que beaucoup d’entreprise font déjà en sous-traitant leur data center. Le troisième niveau est moins courant mais existe déjà depuis les années 90 sous le nom de Application Service Provider ou ASP.

La sous traitance des data center est répendue dans le secteur bancaire luxembourgeois. Cette sous traitance est prévues par les articles 29-3 et 29-4 de la loi du 5 avril 1993. Le mode ASP pourrait être envisagé pour les applications hors du cœur de métier bancaire comme la messagerie et la bureautique. L’IT d’une banque est à la fois son ossature et son système nerveux comment les banques pourraient-elles se différentier en mettant en commun leur solution IT ?

Le clouding n’est donc pas une révolution, c’est une évolution d’un mouvement ancien qui est l’externalisation des services informatiques. Il est probable que l’effet de mode cloud apporte une attention et des moyens qui n’auraient pas été présents sans lui et accélère un peu le mouvement.

Gwenael Oliot

Références:
·Livre blanc sur le clouding : http://www.syntec-informatique.fr/content/download/716911/10898717/file/SYNTEC-livre%20blanc-cloud_computing_HD.pdf
·Définition du clouding http://fr.wikipedia.org/wiki/Cloud_computing
·Texte de loi sur les PSF http://www.cssf.lu/uploads/media/loi_MiFID_130707_upd_181209.pdf

Type d’article bank 50%  IT 50%

Pour suivre à la micro seconde les évolutions des marchés, de plus en plus d'organisme laissent à des logiciels la décision de passer des ordres en bourses. C'est ce qu'on appelle l'automatic trading. Si un ordinateur peut être le pilote automatique d'un avion pourquoi ne pourrait-il pas prendre des décisions d'investissement ?

Que ce soit un être humain qui passe un ordre ou une machine, le résultat est le même et l'organisme émetteur est engagé. Un bug qui achèterait n'importe quoi serait une sorte de Kirviel qui pourrait passer des centaines d'ordre par seconde. On imagine les dégâts...

Heureusement, les informaticiens et les banquiers sont des gens sérieux et les logiciels de trading automatique sont conçus, testés et exploités avec la plus grande rigueur. Enfin presque...

Selon un article du Financial Times (http://www.ft.com/cms/s/0/84950872-09e5-11df-8b23-00144feabdc0.html?nclick_check=1), des bugs ont été constatés par différentes bourses. A la manière des pirates informatiques qui font tomber des serveurs en leur envoyant des milliers de requête, ces bugs auraient noyés les bourses sous des montagnes d'ordre erroné. La seule conséquence aurait été de perturber le fonctionement des bourses.

A quand une affaire à la Kirviel avec une baie de serveur informatique dans le box des accusés?

Gwenael Oliot

Type d’article: Bank 50%  IT 50%

I hope this document helps IT people and fund people understand each other building the best solution for fund services. Comments are welcome in this blog or by mail at oliotg@yahoo.fr

Type d’article : Bank 50%  IT 50%

Gwenael Oliot

Type d'article: Bank 50%  IT 50%

L'Institut de Formation Bancaire Luxembourg (IFBL) propose des programmes de certification professionnelle pour tous les métiers de la banque. L'offre de certification est particulièrement bien fournie pour le secteur des fonds. Il y a une certification pour tous les métiers : Agent de transfert OPC, Comptable OPC, Agent banque dépositaire OPC, juriste OPC. Seuls les informaticiens ont été oubliés...

Aujourd'hui l'informatique est la colonne vertébrale de l'organisation des OPC. De plus en plus de règles métiers sont dans les systèmes IT à tel point que certaines activités traditionnelles sont vidées de leur substance. Combien y a-t-il de comptable fonds qui saisissent des transactions dans le système IT sans savoir vraiment sur quels comptes vont être passées les écritures ?

Pour les informaticiens OPC comprendre une exigence métier OPC et la première étape pour concevoir une solution IT OPC. Pour cela il faut être informaticien ET agent métier OPC. C'est là que l'IFBL pourrait apporter son savoir faire en formant les informaticiens.

Qu'est-ce que pourrait être le parcours de certification « Informaticien OPC » ?

D'abords comme pour toutes les autres certifications métiers OPC on pourrait imaginer devoir subir le parcours de base OPC. Ce parcours de base présente les produits financiers les plus rependus ainsi qu'une vision d'ensemble du métier des fonds.

Ensuite il faudrait ajouter des cours métiers complémentaires qui existent déjà dans l'offre IFBL : Un M1 comptabilité, un M1 agent de transfert, un M1 agent banque dépositaire. Ainsi l'informaticien aurait une vision d'ensemble des opérations d'un fond.

Enfin il faudrait concevoir et mettre en place de nouveaux modules de formation propre aux métiers informatiques. On peut imaginer :

• M1 : Connaitre l'urbanisme des systèmes IT OPC. L'objectif serait de connaître les grands blocs applicatifs présent dans un système informatique OPC : le signalétique valeur, le référenciel fonds, les systèmes comptables, TA, Custody ainsi que les flux de données échangés entre ces blocs.
• M1 : Connaitre la messagerie SWIFT pour les OPC. L'objectif est de connaitre les infrastructures techniques SWIFT et les principaux messages SWIFT et normes ISO15022, ISO20022.
• M1 : Connaitre les solutions d'échanges IT avec les fournisseurs de données de marché. Connaitre les infrastructures techniques et protocole d'échanges avec les principaux market data provider : Bloomberg, Telekurs etc...
  

Le parcours de certification ne devrait pas contenir de cours trop techniques lié à tel ou tel langage de programmation ou tel ou tel système d'exploitation. Il serait également hors de propos de faire de la publicité pour tel ou tel progiciel bancaire.

Y aurait-t-il des étudiants intéressés par des formations OPC IT de l'IFBL ?

Mon expérience personnelle montre que le marché n'est pas nul. J'ai suivi plusieurs formations IFBL et il m'est arrivé de n'être pas le seul informaticien à venir apprendre le métier de banquier. Il est également possible que l'offre stimule la demande et que la création d'une certification IT draine de nouveaux étudiants. Il serait souhaitable de faire un sondage auprès des membres de l'ABBL pour valider l'opportunité de cours IFBL IT. Je suis convaincu que des informaticiens formés aux métiers des OPC seraient un atout pour la place financière Luxembourgeoise.

Si l'IFBL trouve mon idée intéressante, je suis à sa disposition pour l'aider à la mettre en place.

Gwenael Oliot

Type d'article: Bank 50%  IT 50%

Enfin je me permets d'ajouter une référence française vers l'excellent site du CIGREF http://www.cigref.fr/

Bonne lecture,
 
Gwenaël Oliot

Type d’article: Bank 0%  IT:100%

Rond comme un ballon, jaune comme un citron, c’est Pac Man. Gentil petit bonhomme poursuivit par des fantômes, c’est Pac Man. Cela vous dit quelque chose ? Eh bien à moi oui… Il s’agit d’un jeu vidéo des années 1980. Une petite boule jaune pilotée par le joueur est poursuivie par des fantômes dans un labyrinthe et doit manger des pilules sans jamais être rattrapé.

C’est en 1987, quand j’étais en seconde, que j’ai programmé mon premier Pac Man. A cette époque j’avais un ordinateur Amstrad CPC 464. Cette superbe machine était équipée d’un écran 256 couleurs, d’un lecteur de cassette (les disques dures et les cartes flash n’existaient pas, et les lecteurs de disquette étaient trop chers) et de 64 ko de mémoire vive. Pour moi le grand atout de l’Amstrad face à son concurrent le Comodore était la simplicité de son langage de programmation.

J’ai passé plusieurs vacances scolaires à programmer mon Pac Man. Un des plus grand problème auquel j’ai dû faire face était la nécessité de faire bouger le Pac Man en même temps que le fantôme. Je bien dit « Le » fantôme car mon Pac Man n’avait qu’un seul fantôme mais doté du pouvoir de traverser les murs du labyrinthe. Ce pouvoir présente deux avantages. Le premier est que tous les vrais fantômes traversent les murs (c’est bien connu). Le second est que l’algorithme de poursuite du Pac Man est beaucoup plus simple, il suffit de diminuer la distance entre le fantôme et sa proie sans se soucier des murs… Le programme final comptait plusieurs milliers de ligne de Basic.  

J’ai codé mon deuxième Pac Man en 1994. Fraîchement diplômé de mon école d’ingénieur j’étais à la recherche d’un premier emploi. Lors d’un entretien d'embauche, Nat Systèmes, l’éditeur du logiciel de développement NSDK m’avait donné pour chalenge de réaliser en une semaine un programme quelconque. Contrairement aux autres candidats qui avaient choisis des programmes très sérieux de gestion, j’ai choisi de coder une nouvelle version de mon Pac Man sur PC avec NSDK. Le contrat a été rempli, je me souviens que le recruteur jouait avec enthousiasme avec mon jeu. C’est donc Pac Man qui m’a permis de décrocher mon premier job. Plus tard j’ai utilisé les possibilités de NSDK pour faire tourner mon Pac Man sur Macintosh.

J’ai codé mon troisième Pac Man en Java en 1999. Il s’agissait d’une applet que j’ai programmé en un week end. Tout cela était orienté objet, quelques classes et quelques centaines de ligne de Java ont suffit.

A quand la quatrième version de Pac Man ? En quelle technologie ? Le dernier langage que j’ai exploré en 2008 est le Flex, mais il est trop proche de Java pour me donner envie de créer un quatrième Pac Man… Je suis cependant certain que cela me reprendra. J’aime trop la programmation pour que cela s’arrête. L’inspiration reviendra tôt ou tard…

Gwenael Oliot,

Type d’article : Bank 0%  IT 100%

L’activité du test fonctionnel est à la frontière entre le métier et L’IT, incluse entre les tests unitaires du programmeur et les tests métiers de la maîtrise d’ouvrage.

Les tests unitaires sont des tests « boites blanches » d’un module d’application, les tests fonctionnels sont des tests « boites noires » d’une application, les tests métiers sont des tests « boites noires » d’un processus et donc de plusieurs applications.

Le point d’entrée du travail du testeur fonctionnel est la documentation des exigences fonctionnelles. La première tâche consiste à rédiger les cas de test. Il faut recenser les exigences fonctionnelles et pour chacune  prévoir le ou les cas de tests qui permettent de garantir la conformité du logiciel. Il s’agit d’être astucieux en créant les cas les plus simples possibles tout en étant exhaustif.

Une fois les cas définis, il s’agit de les enchaîner sous forme de scénario. L’ordre d’exécution ne doit pas être laissé au hasard. Une bonne pratique consiste à estimer le niveau de risque des cas de test et de commencer quand c’est possible par les plus risqués. Ainsi on peut augmenter la probabilité que les bugs les plus graves soient trouvés en début de campagne de test, ce qui laissera plus de temps pour les corriger. Il est également utile d’estimer la complexité des cas de test car cela permet de suivre plus finement l’avancement des campagnes de test.

L’étape suivante est la préparation des tests. Pour chaque cas il s’agit de préparer les données de test. Deux solutions sont possibles, soit identifier des données existantes soit construire des données sur mesure. La première approche qui est la plus simple est conseillée. Malheureusement il arrive que les données n’existent pas, par exemple pour un tout nouveau système ou quand il s’agit de tester un cas très particulier. La préparation des tests inclut la réalisation d’outillage de test. Les tests fonctionnels se limitant à une seule application il est souvent nécessaire de simuler la présence d’application amont ou aval. Pour réaliser ces outils le testeur fonctionnel doit le plus souvent faire appel à un programmeur.

L’étape suivante est l’exécution des tests. Chaque cas est exécuté si possible dans l’ordre défini par les scénarios avec les données et les outils préparés aux étapes précédentes. Quand un résultat n’est pas conforme aux exigences, le testeur en informe l’équipe de développement qui confirme le bug ou remet en cause la pertinence du cas de test. Le testeur doit donner les informations les plus précises possibles au programmeur pour l’aider dans son diagnostique. S’il s’agit d’un bug, une nouvelle version du programme doit être livrée et testée. Un processus clair de suivi des bugs et corrections est indispensable. Régulièrement le testeur fonctionnel rend compte de l’avancement de ses tests. Le nombre de cas de test exécuté pondéré par leur complexité est un bon indicateur d’avancement.

Un bon testeur fonctionnel doit être rigoureux pour ne rien laisser passer, astucieux pour trouver les cas de test les plus simples, patient quand rien ne marche, diplomate pour signaler les bugs sans agresser les programmeurs et disponible quand il s’agit de donner un coup de collier à quelques jours de la mise en production. Une bonne connaissance de l’application à tester est un grand atout et du bon sens est indispensable.

Quelques conseils pour un testeur fonctionnel :

• Avant toute chose, il faut réclamer des documents d’exigence fonctionnelle (ou en rédiger).
• Ne pas négliger la phase de préparation pour utiliser la phase d’exécution des tests à tester réellement (La phase de préparation n'est pas sur le chemin critique du projet alors que l'exécution oui).
• 33% de l’effort sur la rédaction des cas de test, 33% sur la préparation, 33% sur l’exécution est un bon ordre de grandeur pour la repartission de la charge.
• Lors de la planification d’une campagne il est sage de prévoir une durée et des ressources pour exécuter plusieurs fois tous les cas de test. En effet, certains bugs peuvent bloquer l’exécution des tests pendant de longue période, ou la livraison successive de corrections nécessiter d’exécuter plusieurs fois les même cas.
• Soyez courtois avec le programmeur même si rien ne marche.
• Soyez inflexible sur le respect des exigences fonctionnelles, c’est votre raison d’être. Si une exigence n’est pas respectable alors il faut négocier son amendement mais ne pas cacher une non-conformité.
• Gardez autant que possible des preuves de vos tests (par exemple des print screen), car il se trouvera toujours quelqu’un pour vous reprocher de ne pas les avoir exécuté correctement.

Gwenaël Oliot

Article sur les tests unitaires: http://oliotg.blog.lu/post/553/2619

Type d'article: IT 50%  Bank 50% 

SWIFT est-il un sujet pour informaticien ou pour banquier?

SWIFT est une coopérative de banque, offrant des services et interfaces informatiques sécurisées entre plus de 7500 institutions financières réparties sur 200 pays. Les interfaces informatiques sont affaires d’informaticien mais la communication interbancaire est une affaire de banquier.

Voici un exemple de message SWIFT ISO15022 MT540 :

:16R:GENL

:20C::SEME//MYREF001

:23G:NEWM

:16S:GENL

:16R:TRADDET

:98A::SETT//20080623

:98A::TRAD//20080620

:35B:ISIN CH0001234567

:16S:TRADDET

:16R:FIAC

:36B::SETT//UNIT/521,

:97A::SAFE//54321

:16S:FIAC

:16R:SETDET

:22F::SETR//TRAD

:16R:SETPRTY

:95R::DEAG/CEDE/12345

:16S:SETPRTY

:16R:SETPRTY

:95P::PSET//CEDELULL

:16S:SETPRTY

:16S:SETDET

La chose est maintenant entendue, il faut forcement être informaticien pour comprendre un truc pareil !

Après traduction en français, le message ci-dessus est une instruction de réception de titre en free of payment. La référence du message est MYREF001, la date de la transaction est le 20/06/2008, la date souhaitée de settlement est le 23/06/2008. La réception porte sur 521 titres ISIN CH0001234567 à livrer sur le compte numéro 54321. Le settlement a lieu en Clearstream et les titres proviennent du compte numéro 12345 : Il n’y a qu’un agent back office d’une banque qui peut comprendre ce jargon !

Il faut donc être informaticien et banquier pour comprendre un message SWIFT.

L’exemple ci-dessus est tiré d’un contexte back office titre, mais SWIFT a une couverture beaucoup plus large. Elle traite également en amont de l’initiation et de la confirmation d’ordre et en aval de custody ou de gestion de collatéral. La gestion cash a également ses propres messages…

La maîtrise de SWIFT passe par la connaissance d’un socle technique commun auquel il faut ajouter la connaissance de métiers bancaires particuliers. Dans le socle technique on trouve la connectivité (le réseau, les passerelles, l’adressage, etc…) et la grammaire des messages. D’un point de vue métier, en continuant dans l’exemple du back office titre, il s’agit de connaître en détail le cycle de vie d’une instruction de son émission au settlement en passant par le matching et éventuellement par sa cancellation.

En synthèse, SWIFT est un sujet qui intéresse le banquier et l’informaticien en permettant l’implémentation de processus métiers interbancaires en STP (Straight Through Processing).

Gwenael Oliot

Type d'article IT:100%  Bank:0%

MEGA, la suite logicielle de modélisation des systèmes d’information s’est mise au goût du jour en étant certifié TOGAF par l’Open Group.

Le saut n’a pas dû être trop grand, puisque MEGA offrait déjà toutes les fonctionnalités nécessaires : MEGA est un outil de modélisation puissant construit autour d’un référentiel d’entreprise.

Toutes les strates d’un systèmes d’information peuvent être représentés dans MEGA : processus métiers, couche fonctionnelle, strate applicative, strate technique, modèle de données etc… Le référentiel MEGA, assure une intégrité entre les différents modèles et une gestion multi utilisateur des mises à jours. C’est aussi un outils de communication puisque tous les diagrammes peuvent être publiés dans un intranet au format HTML.

Tous les ingrédients étaient donc déjà présents pour que MEGA soit reconnu comme étant un outil support de TOGAF. Ceci a été chose faite quand MEGA a publié sa nouvelle fonctionnalité appelée « MEGA EA Accelerator for TOGAF »

Les nombreuses sociétés déjà utilisatrices de MEGA sont en bonnes positions pour une adoption de TOGAF et celle encore non outillées peuvent voire en MEGA un référentiel d’architecture éprouvée.

Méthode de pointe + Suite logiciel éprouvée = Une solution pour l’architecte d’entreprise.

Gwenael Oliot

Type d'article: IT 50%  Bank 50% 

Si vous recherchez SWIFT sur Google vous trouverez majoritairement deux types de site : ceux dédiés à une petite voiture citadine et ceux dédiés à un système informatique inter bancaire. Il faut être précis dés le début : le présent article traite du système informatique. Maintenant que les choses sont claires nous pouvons commencer.

Dans le langage courant, « un SWIFT »  est un message relatif à un sujet financier : une demande de virement de fonds de compte à compte, un accusé de réception d’un ordre d’achat de titre, un relevé de position de compte etc... La particularité d’un message SWIFT est d’être électronique et compréhensible par un système informatique. Ainsi il est possible de le traiter de manière automatique. Concretement, le contenu des messages SWIFT s’inspire des télex et des fax qui s’échangent entre institutions.

Comme Frigo est une marque de réfrigérateur, SWIFT est en fait une entreprise. Il s’agit d’une coopérative détenue par des acteurs du monde financier. Son objectif est de promouvoir des techniques d’échange d’information entre institutions financières. Aujourd’hui SWIFT offre des services de messagerie et d’interface informatique à plus de 7500 institutions (banques, assurances, bourses, entreprises …) réparties dans 200 pays.

SWIFT gère les réseaux informatiques, l’infrastructure matériel et logiciel nécessaire à l’échange des messages. Elle coordonne également les efforts de normalisation des formats des messages.

Plusieurs infrastructures sécurisées sont proposées en fonction du volume de message traité et du degré d’autonomie souhaité par une institution : Infrastructure privée, Infrastructure mutualisée ou simple accès Internet. Des solutions d’infrastructure robustes et scalables existent pour les institutions les plus exigeantes pouvant gérer plusieurs dizaines de milliers de message par jour. En supplément du simple acheminement des messages, SWIFT propose également des solutions d’intégration.

SWIFT est l’autorité d’enregistrement des normes ISO15022 et ISO20022 et joue un rôle moteur dans la définition des formats des messages. La norme ISO15022 est la plus ancienne et s’appuie sur un langage propriétaire appelé FIN. ISO20022 est en cours de déploiement et s’appuie sur une grammaire XML.

ISO15022 normalise les messages dans les domaines du paiement et chèques, du transfert entre institutions, des marchés monétaires et des changes, de la gestion des titres, des traveller cheques etc…  ISO20022 prend en charges les messages des domaines métiers normalisés plus récemment comme celui des fonds ou du proxy voting. L’objectif est qu’à terme ISO20022/XML remplace totalement ISO15022/FIN.

Gwenael Oliot

Pour en savoir plus :

• www.swift.com
• www.iso20022.org
• www.iso15022.org
• www.swiftcommunity.net

Type d'article. IT 100%  Bank 0%

En tant qu’architecte IT je m’intéresse au monde de l’open source. Il s’agit d’un univers dynamique et rester à la page n’est pas facile. L’événement organisé le 25 novembre 2008 par le centre de recherche Henri Tudor sur le thème « open source critical ready »  a été pour moi une piqûre de rappel. Des professionnels distributeurs de produit open source et sociétés de service spécialisées sont intervenus.

De ces présentations je retiens deux nouveautés : l’apparition d’applications métiers open source et la notion d’appliances.

Jusqu’à présent j’ai travaillé avec ou entendu parlé de produits d’infrastructure technique, d’outils de développement ou bureautiques open source. Il existe aujourd’hui des applications métiers open source : ERP, solution bancaire, application comptable, solution décisionnelle… Elles présentent les mêmes avantages que leurs aînées plus techniques à savoir un coût de licence nul et le fait d’être téléchargeable gratuitement. Ceci représente une réelle évolution puisque l’open source s’attaque maintenant à la couche applicative des systèmes informatiques.

L’intégration de produits open source n’est pas une chose facile. Il n’est pas évident de trouver la version de Linux compatible avec le SGBD open source cible qui fonctionne avec la bonne version de java et de Tomcat. A un instant donné il est possible de trouver le cocktail parfait, mais tout est à refaire dés qu’il faut changer de java ou upgrader la base de données… Les appliances sont une réponse à cette problématique, il s’agit de package de produits open source complémentaires qui évoluent de manière intégrée. Ainsi on peut avoir une solution d’infrastructure technique open source « clé en main » par exemple OS+SGBD+Java+Serveur Web. Le concept est poussé plus loin quand on ajoute au package une application métier open source. On obtient une appliance ou système informatique open source « clé en main ».

Deux motivations justifieraient le passage à une solution open source : La réduction des coûts et l’innovation. Une solution open source serait 40% moins cher qu’une solution closed source. Les coûts de supports sont voisins mais l’économie de licence est en faveur de l’open source. Quand un produit open source est innovant et que cette innovation est en ligne avec la stratégie d’une entreprise utilisatrice alors le temps pour mettre une solution sur le marché serait plus court dans le monde open.

Le licensing dans le monde open source reste un sujet complexe et mouvant qu’il ne faut pas négliger avant de se lancer dans un projet d’entreprise.

En résumé, le monde de l’open source gagne en maturité. Des solutions open d’infrastructure technique servent des applications d’entreprise critiques. Le segment des applications métiers est maintenant attaqué. Le monde open source crée des briques de plus en plus crédibles pour la boite à outil de l’architecte IT.

Gwenael Oliot

Kind of article: IT: 100% Bank 0% 

Spring is a technology to know if you are involved in java enterprise application development. This article would help you to get started.

Spring is a java server side open source framework. One target of Spring is to give the possibility to create enterprise applications and services without using EJB.

Spring is a dependency injection framework (DI) and an implementation of aspect-oriented programming (AOP) that puts glue between following components:

• A database access framework that can work with plain old JDBC or can be integrated with Hibernate or other persistence frameworks.
• A transaction framework on top of JTA.
• A security framework.
• An implementation of MVC pattern.
• Integration facilities with EJB, Webservices, JNDI, JMX etc…
• etc …

Spring is important because since 2005 it has becomed a true alternative of using EJB, and becomes more and popular. Today knowing Spring is a requirement to be involved in most of java projects in Luxembourg.

Here is an example of SOA built on top of Spring framework:

But I can not speak about Spring better than Rod Johnson who is Founder of open source Spring Framework and author of J2EE without EJB does.

(theserverside.com)

CLICK HERE to hear Rod Johnson speaking >>>>

 http://event.on24.com/clients/default/presentation/default.html?titlecolor=000000&new=2&eventid=93721&sessionid=1&key=5234624FEAF43C5788BDD29B06C941DF&contenttype=A&eventuserid=305999&playerwidth=950&playerheight=680&caller=previewLobby&text_language_id=en&format=wmmulti

Gwenael Oliot

To know more about Spring:

Type d'article: IT 100%  Bank 0% 

In professional IT development, source management is a key subject that must be addressed as soon as a project becomes bigger than one hundred men days.

What ever the technology and language are, the same question still arises: Should I put my sources in a single big project or should I split them in several smaller? There is no good answer; it depends of your development context. I’m sure you are not happy with this consultant sentence, so let’s go a bit further.

A first idea is to put every thing in the same bag. This is the easiest choice. Every component may use every other. There is only one compilation procedure, only one repository from configuration management point of view. The problem is that it may become a mess. Components of databases layer may use components from graphical user interface, reusable components may be linked to any particular specific component, all the bad practices you can imagine…

Creating dedicating projects may prevent to build such a spaghetti plate. Database access components are in a dedicated project, graphical user interface components are in another. Reusable part is segregated in a particular project. Use of a component by another can not be hidden because an explicit “use” must be set up between projects. This solution is more expensive because the more projects you have the more source administration is complicated. You have to manage multiple compilation procedures, references between projects and some time loops of references. Loops of references, (that is to say a project A uses a project B that uses back project A) are not forbidden but may make the compilation procedure tricky.

A source map must be drawn at the very beginning of the project. This is important because a mistake at this step may be difficult to fix. The first key point to remember is that it is easy to merge two distinct projects but very complicated to split an existing one. So if things are not clear in your mind then build multiple projects because it will be easy to merge them latter.

The main advantage of multiple projects is to help preventing from a spaghetti plate. If you have other solutions to manage this risk then multi projects may be useless. For example, if your development team is experimented then its members will avoid forbidden links between components even if they are in the same project.

I will tell you two stories that will help you to understand.

I’ve already worked on a huge project of migration of an informatics’ system from mainframe to client server technology. The project was cut into phases. Phase one was to put technical infrastructure in place with development of a navigator that should have been the glue between future functional applications. The problem was that this first phase was designed as a monolithic project, in a way that the glue was not ready even for the first functional application. A task force was put in place in order to split the big source bag into smaller. It worked at the end but the head of the chief architect felt during the battle. In that case, the technical gap was important, the technology was very new and the development team was based on new comers. The risk of spaghetti plate was very high so segregated projects was the good design.

In another context I worked in an experimented team, with a stable and well known technology. The application was several years old and the team that built it was still in place. The application was spread among a dozen of Eclipse projects. This was very expensive from source management point of view. There were a lot of (justified) loops of reference that made compilation a nightmare. At this point the decision was taken to merge some projects. This merge was not a very complicate task and it was a good decision.

To conclude, before choosing a source management strategy, one big project or a lot of small, try to evaluate your spaghetti risk, and keep in mind that it is far easier to merge small projects than split a big one.

Gwenael Oliot

Type d'article: IT: 100%  Bank: 0%

Le YAJUG est le club des utilisateurs des technologies Java au Luxembourg. Le YAJUG a organisé le 16/10/2008 son événement d’automne.

Cet événement s'est déroulé en trois parties de 45 minutes :

• Une présentation sur le développement des pluggins Eclipse.
• Une présentation de SpringSource Application Platform qui est un serveur d’application java qui implémente un sous ensemble de la spécification J2EE.
• Une présentation sur le Web Contain Management WCM.

Les deux premières présentations étaient très techniques avec des démonstrations en live, la troisième était plus haut niveau avec un retour d’expérience sur la mise en oeuvre de deux projets WCMs.

L’événement a attiré quarante personnes environ et s’est terminé par un pot très convivial. 

Au cours des présentations une nouvelle technologie Java a été citée à de nombreuse reprises, il s’agit d’Equinoxe qui est une implémentation de la spécification OSGI. Cette technologie permet une gestion dynamique des composants Java au run time avec entre autre le chargement de composant à la demande et la possibilité de faire cohabiter plusieurs versions d’un même composant.

Les présentations ont été filmées et sont disponibles (ou vont bientôt l'être) sur le site du YAJUG http://www.yajug.lu/

Gwenael Oliot

Type de sujet:  75% IT  25% Bank

Dans mon article SOA dans l'industrie des fonds  j’expliquais en quoi l’utilisation de SWIFT dans les échanges des messages d’achat vente de part de fonds entre distributeurs et agents de transfert était une implémentation de SOA.

Un communiqué de presse Clearstream paru dans Paperjam intitulé « L’utilisation par Clearstream des normes SWIFT améliore l’interopérabilité » décrit un autre exemple de SOA SWIFT appliqué au domaine du settlement titre.

A lire :  http:  //www.paperjam.lu/presse/2008/09/0909_Clearstream/index.html

Gwenael Oliot

Type de sujet: IT 100%  Bank 0% 

 

Un bug informatique est un comportement d’un logiciel qui n’est pas conforme à ses spécifications. Une conséquence direct est que s’il n’y a pas de spécification il n’y a pas de bug…

 

Cette définition n’est pas universelle. Il m’est arrivé de travailler chez un éditeur de logiciel dont le responsable du développement affirmait qu’un bug était un dysfonctionnent identifié par un utilisateur final. Il n’est pas surprenant que cet éditeur ait quasiment disparu à cause du manque de fiabilité de ses solutions…

 

En fait plus un bug est identifié tardivement dans le processus de développement d’un logiciel plus il coûte cher.

 

L’idéal est qu’il n’y ait pas de bug. Ceci est possible, si les spécifications sont de qualités et si le développeur est compétent. L’organisation de revue de code est une bonne pratique pour diminuer le nombre de bug.

Si un bug est identifié par le développeur lui même pendant ses tests unitaires, alors la partie droite de son cerveau communique avec la partie gauche et au bout de quelques minutes de réflexion, de codage et de compilation le problème est résolu.

Si un bug est trouvé par l’équipe de test alors celle-ci doit formaliser sa description dans un ticket d’incident. Le développeur doit alors comprendre le contenu du ticket, reproduire le problème (ce qui n’est pas toujours simple), le corriger, et livrer la correction en environnement de qualification. L’équipe de test peut ainsi vérifier la correction et clore le ticket.

Si un bug est identifié par l’utilisateur final cela devient beaucoup plus complexe. Cet utilisateur doit faire appel à l’équipe support qui doit analyser le problème et ouvrir un ticket d’incident. Il est bien évident que cette étape est particulièrement délicate car le diagnostique est réalisé dans un contexte de production. Une fois le ticket ouvert le processus est le même que dans le cas précèdent avec quelques étapes supplémentaires qui sont l’installation de la correction en production et la correction des conséquences du bug. Un bug a parfois des conséquences néfastes sur l’intégrité des données de production. Il est souvent nécessaire de livrer et d’exécuter des scripts correctifs pour remettre les données en état. Il arrive parfois que ces scripts soient eux-mêmes bugués ce qui induit une nouvelle itération du processus…

Il est donc important de ne pas négliger l’étape des tests unitaires pour que le maximum de bugs soit identifié par le développeur lui-même. C’est au chef de projet de prévoir du temps et de contrôler que les tests sont bien réalisés. Les développeurs sont souvent réticents à ce genre tâche car ils préfèrent le codage qui est une activité plus créative et plus valorisante. Le chef de projet doit exiger des rapports de tests unitaires formalisés dans lesquels les développeurs s’engagent sur le périmètre de leurs tests.

Gwenael Oliot

Gwenael Oliot, professionnel de l'informatique bancaire.

• Principal
• Archives
• Albums
• Liens
• dashboard

• IT [25]
• Banque [20]
• Management [8]
• Fonds [12]
• Général [1]

• Green IT, l’informatique écologique.
• Clouding or not clouding?
• Automatic trading et bugs automatiques.
• IT architecture of a fund service provider
• L’automatisation gagne du terrain dans les fonds luxembourgeois
• Circulaire CSSF 02/77 : les erreurs de VNI et dépassements de limite d’investissement.
• Et si des informaticiens OPC étaient certifiés par l'IFBL ?
• Le boom des hedge funds au Luxembourg
• Top compétence au 10/11/2009
• Target2 Securities (T2S) simplifie les réseaux de sous dépositaire.
• Les restrictions d’investissement des fonds luxembourgeois
• Target2 securities (T2S) au Luxembourg
• Les directeurs informatiques du secteur bancaire Luxembourgeois.
• De UCITS III à UCITS IV
• Pac Man Story

• mehdi benammar: le développer en haskell (http://www.haskell.org/), langage fonctionnel, "sans boucle sans...
• nvitale: Si vous comprenez l'anglais, vous serez potentiellement intéressé par la vidéo ici:...
• Nicolas: Bon, impossible de poster un commentaire de plus de 20 caractères, doc je répond là : ...
• oliotg: paperJam Business Club: donne un avis actualisé sur la note de PricewaterhouseCoopers...
• superRIA:Comparer Flex et les applets, c'est comme comparer une lampe à pétrole et une lampe hallogène....
• Laurent U.:Merci pour cet article qui peut contribuer à la pédagogie autour des RIAs au Luxembourg.
• Laurent U.:Simple petit apport par rapport à mon expérience, les développeurs Java maitrisent Flex et...
• Olivier Gourment:Bonne analyse des deux nouveautés de SOA: standards et gouvernance. Le second est souvent...

• Dark pools et bourses classiques. (3170 Times)
• Comparatif AJAX, FLEX et Applet. (1923 Times)
• De SWIFT ISO15022 à ISO20022 : un exemple tiré des fonds. (1547 Times)
• Message SWIFT pour les nuls (1293 Times)
• Témoignage sur les certifications OPC IFBL/ALFI (1287 Times)
• Impact de MIFID sur la fonction de compliance. (1106 Times)
• Le test fonctionnel pour les nuls. (1085 Times)
• Introduction to ADOBE Flex technology (1069 Times)
• Message SWIFT : Un sujet pour informaticien ou pour banquier? (1045 Times)
• SOA dans l’industrie des fonds : Révolution ou pétard mouillé ? (997 Times)