L’architecture d’entreprise : vision métier ou technologique?

J’entends souvent la question suivante : L’architecture d’entreprise (EA) doit-elle être centrée sur la vision Métier ou Technologique ?

On parle aujourd’hui de plus en plus régulièrement d’architecture Business et on réalise facilement l’amalgame avec l’EA.

L’architecture Business n’est qu’un domaine de l’architecture d’entreprise qui, pour reprendre la définition donnée par TOGAF, en comporte quatre (Business, data, application, technology). Elle adresse la stratégie Business, l’organisation, les Business process clés et les interactions entre ces éléments. L’architecture d’entreprise adresse également la couche technologique permettant de supporter l’architecture Business.

La notion de capacité (capability) que l’on retrouve dans TOGAF est ici intéressante :
(Lire la suite…)

Introduction à la Programmation Orientée Acteurs

Depuis le milieu des années 2000, l’augmentation de la puissance de calcul de nos ordinateurs ne passe plus par l’élévation de la fréquence des processeurs mais par la multiplication des cœurs de processeur au sein de nos machines.

Pour tirer parti de cette multiplication, un algorithme doit être parallèlisé, c’est à dire qu’il doit pouvoir diviser ses instructions et les répartir sur différents cœurs pour une exécution simultanée.
De nombreux outils permettent d’implémenter un algorithme parallèle sur une machine, par exemple la librairie Task Parallelism Library (TPL) en .Net, abordé par Olivier Roux et Alexis Flaurimont ou encore le fork/join en Java étudié par Marc Bojoly et David Rousselie.

D’autres outils, implémentant par exemple le pattern Map/Reduce, permettent de distribuer le calcul vers des cœurs situés sur différentes machines.

Cet article présentera une introduction à la programmation orientée acteurs et les réponses qu’elle apporte à ces différents problèmes. (Lire la suite…)

Domain Driven Design : des armes pour affronter la complexité

« La complexité, c’est comme le cholestérol. Il faut surtout se débarasser du mauvais. » (Proverbe gascon-malgache)

DDD est l’acronyme de Domain Driven Design. Ce n’est ni un framework, ni une méthodologie, mais plutôt une approche décrite dans l’ouvrage du même nom d’Eric Evans. Un de ses objectifs est de définir une vision et un langage partagés par toutes les personnes impliquées dans la construction d’une application, afin de mieux en appréhender la complexité. Nous ne souhaitons pas faire ici une présentation de DDD (voir plutôt ici pour une introduction). Nous voulons montrer comment DDD peut adresser certaines problématiques évoquées dans l’articleJ’ai mal à mon application ! Ca se soigne ? au travers d’un exemple d’application (“je veux vendre et acheter des légumes sur internet”), tout en s’inscrivant dans une démarche de développement Agile.

(Lire la suite…)

Coffre fort & archivage électronique : beaucoup de similarités et une différence structurelle

    En écrivant le livre blanc sur l’archivage documentaire dématérialisé ( « Archivage documentaire : enjeux de la dématérialisation, papier contre bits »), il nous est arrivé de croiser à Octo des collègues travaillant sur des projets de coffre fort électronique. Eux se moquaient volontiers, car l’archivage traîne, il faut bien le dire, une image poussiéreuse (faussement, voir notre livre blanc) tandis que le coffre fort électronique en pleine émergence est plutôt très tendance. Acceptant tout de même de me parler, nous avons échangé. Nous nous sommes alors vite aperçus que leurs problématiques et leurs enjeux étaient très similaires aux nôtres.

(Lire la suite…)

Et si vous codiez une application qui supporte 1 milliard d’utilisateurs ?

Le Challenge USI est un concours organisé dans le cadre de l’USI 2011, en partenariat avec VMware et Steria. Il est ouvert à des équipes d’étudiants et de développeurs qui ont envie d’implémenter des architectures à haute performance, comparables à celles des grands du Web (Google, Facebook, Twitter, etc.). Il consiste à créer une application de Quiz Synchrone qui supporte 1 milliard d’utilisateurs, dont 1 million en simultané. L’architecture technique est complètement libre, sous contrainte de système Linux. Les 3 équipes dont l’application aura permis de faire jouer le plus de monde se verront remettre un prix lors de L’USI en juin 2011.

(Lire la suite…)

Pourquoi les Websockets ?

Après la démocratisation d’Ajax (ie. requêtes HTTP asynchrones en Javascript), plusieurs techniques ont été élaborées afin de permettre le push de données depuis le serveur toujours en utilisant HTTP. C’est grâce à ces techniques que l’on reçoit nos mails dans une application web sans avoir à cliquer sur le bouton « Refresh », que les applications de chat sont possibles sans plugin tierce (Flash, Java, …), etc. Le W3C et l’IETF ont spécifié une API Javascript et un protocole nommé Websocket. Ce protocole connecté est adapté à l’envoi de données dans les deux sens et évite de détourner HTTP de son usage initial (ie. un protocole déconnecté sans état).
(Lire la suite…)

Une architecture d’application Flex maintenable

Le framework Flex permet d’écrire très rapidement des IHM fonctionnelles, notamment grâce au langage MXML. Celui-ci permet effectivement de décrire l’interface avec peu de lignes de code.

Seulement, voilà, une fois l’étape du POC passée, les fichiers MXML s’accumulent, le code ActionScript s’insinue petit à petit dans le code MXML pour implémenter les handlers d’événements, les appels de services, la logique métier. Après quelques temps, il devient de plus en plus difficile de savoir d’où viennent les données affichées (ie. quel code a mis à jour la donnée ?), d’où provient un appel de service (surtout d’où proviennent les valeurs des arguments de cet appel).

Dans cet article, nous verrons quelques bonnes pratiques permettant d’assurer la maintenabilité d’une application Flex.
(Lire la suite…)

Architecture applicative minimum pour tester unitairement

L’un des points fondamentaux pour réaliser un test automatisé est de le rendre reproductible. L’un des critères pour qu’un test soit unitaire est qu’une seule méthode soit testée de façon isolée sans dépendre d’une base de données ou de tout autre système externe. Le moyen le plus efficace pour assurer ces deux caractéristiques est d’utiliser des mocks. Trop souvent, lorsqu’on prononce ces mots devant un client, des réactions de méfiance apparaissent : on a besoin de la base de données dans l’équipe, avec notre code ça n’est pas possible, c’est compliqué… L’objectif de ce billet est de montrer une architecture applicative minimale pour répondre à ce besoin.
(Lire la suite…)

L’administration électronique sera-t-elle Made in USA ?

Depuis plus d’une dizaine d’années, l’administration a lancé un ensemble de chantiers lui permettant d’entrer dans l’ère numérique. A leur rythme, nos différents ministères, collectivités et organismes d’état ont informatisé leurs procédures : renouvellement de papiers, création d’entreprise, déclarations fiscales … ces télé-procédures ont répliqué les processus existants, en les dématérialisant. Utilisées par la moitié des français , elles se heurtent aujourd’hui aux mêmes limites que les entreprises privées avec leur informatique : faire plus de la même chose ne créera que peu de valeur supplémentaire. Nous pouvons optimiser le système de télé-déclaration fiscale, mais cela ne résoudra pas les aberrations et parfois les dysfonctionnements liés à l’organisation des circuits de traitement de la chaîne fiscale, qui va du calcul au recouvrement de l’impôt. De même pour nos systèmes électroniques de santé, qui peinent à faire mieux collaborer médecine de ville, hôpitaux, ou pharmacies.

Alors au fond quel est le problème ? Il me semble que deux contraintes majeures pèsent sur l’émergence de systèmes d’information qui transforment les services publics au plus grand bénéfice des usagers et des personnels administratifs.

La première est l’approche « tout ou rien », qui impose de délivrer dès le départ un service uniforme sur tout le territoire. Cette volonté « égalitaire » nuit aux nécessaires expérimentations de systèmes qui engagent le plus souvent de difficiles réformes d’organisation. Cette approche « nous devons tout prévoir du premier coup » est relayée par le code des marchés publics, et la lenteur des cycles qu’il impose. Impossible dans ce contexte d’embaucher une équipe stable pour lui faire délivrer un système qui se construit peu à peu avec ses premiers utilisateurs … Ce sont pourtant les méthodes qui permettent d’innover de la manière la plus fluide.

La seconde relève de notre peur du « grand fichier », de la nécessaire protection de la vie privée. Pour avoir participé à de nombreux échanges sur service-public.fr, la posture « tout est interdit, tout est cloisonné » s’oppose aux nouveaux usages communautaires engageant à plus de partage et d’interopérabilité. Après avoir dépensé des sommes colossales pour un système d’authentification ultra-complexe à base de certificat, le ministère des Finances a finalement rebasculé vers un procédé plus classique, identique à Facebook, ma banque ou à l’Intranet de mon entreprise. Mais au-delà de l’authentification, ce sont toutes les données manipulées qui subissent interdiction et cloisonnement. Vous pouvez voir ma photo sur LinkedIn, mais pour l’administration, c’est encore un secret d’état.

Mais pendant ce temps, des acteurs privés, essentiellement américains, se lancent sans ces deux contraintes, dans des systèmes permettant aux citoyens et aux agents administratifs de partager, échanger et collaborer dans des réseaux sociaux de « service public ». San Francisco ouvrant ces données (datasf.org) ou Google Health offrant un Dossier Médical Personnalisé pour mieux le partager en toute sécurité avec ses proches et ses soignants, nous montrent une voie inédite, qui nous permettrait peut-être de « percer le plafond » avec nos Technologies de l’Information.

L’administration est donc à un tournant : soit elle décide qu’il est important qu’elle possède et gère ses systèmes électroniques, et elle devra alors faire sauter les deux contraintes qui l’empêchent de les délivrer, en revisitant notamment sa politique de construction et de sécurisation. Soit elle décide d’utiliser ces fournisseurs comme facteurs externes de modernisation, mais en l’assumant et en l’encourageant.

Et vous, que choisiriez-vous ?

Comment segmenter l’offre de cloud computing?

L’informatique est friand des trigrammes et des abréviations et le monde du cloud computing ne fait pas exception à la règle : Iaas, PaaS, SaaS. Ces trois termes proposent de segmenter l’offre de cloud computing. Au delà des mots, qu’est-ce que cela signifie vraiment pour votre entreprise. L’objectif de cet article est de proposer deux visions différentes pour segmenter ce marché : l’une par type de contrat offert, l’autre par typologie de service offert. Nous en tirerons en synthèse quelques repères pour analyser une offre sur ce marché.
(Lire la suite…)