BIG DATA : Théorème de CAP

Ce billet compare l'approche décisionnelle classique (BI) à l'approche Big Data.

En premier lieu, il est important de comprendre que si les fins de chacune de ces approchent sont similaires (Prévision, optimisation, Risque,...), L'espace temps d'application n'a plus rien à voir. Un peu comme si l'on comparait l'équation d'attraction universelle de Newton et l'approche relativiste d'Einstein. Cette dernière tend vers la première pour des vitesses négligeables par rapport à la célérité de la lumière.

Ainsi ceux qui prédisent la mort de la BI traditionnelle au profit de BigData s'enflamment un peu vite où se trompent partiellement. Des systèmes comme par exemple le SI Comptable, impose une consistance absolue qu'il n'est pas envisageable de traiter avec du Big Data.

NOSQL vs SGBDR

Avec des base de données NOSQL, comme MongoDB, Cassandra, HBASE, BigTable, Dynamo, un langage universel de requête comme SQL n'existe pas (Hive est un outil de requête avec une interface SQL adaptée). Cette fonctionnalité est obtenu ad'hoc par programmation en Java ou en Pithon, en utilisant les API. L'importance du schéma des données, formalisé en Data Définition Language (DDL), n'est plus le sujet côté NOSQL, et les forte contraintes relationnelles (index, clés primaire, jointures,...) sont justement volontairement bannies pour traiter massivement les données. On raisonne plutôt par liste par composition de colonnes ou documents, bannissant ainsi la nécessaire intégrité référentielle en 3eme forme normale et plus.

Mais alors, que faire avec des données suspectées par construction d'être "éventuellement intègres" ?
Ci-dessous, différents éléments de réponses théoriques.

ACID

Atomicité	Une transaction s'exécute complètement ou pas du tout. Si une partie de l'opération échoue, la totalité de la transaction échoue.
Consistance	Le système est dans un état cohérent à chaque instant, avant et après une transaction.
Isolation	2 transactions "simultanées" sont indépendantes. Elles n'interfèrent pas l'une sur l'autre.
Durabilité	Le système est capable de se remettre dans un état cohérent après une perte ou une panne.

BASE

 - Basically Available

 - Soft - state

 - Eventual consistency

 BA : se réfère à la disponibilité perçue des données distribués. Si un nœud échoue, une partie des données ne sera pas disponible, mais la couche de données entière reste opérationnel.
 
S : État mou: Les données ont besoin d'une période de rafraîchissement (asynchronisme). Sans un rafraîchissement, les données seront expirer ou être supprimé.

E : La cohérence éventuelle signifie que les mises à jour finiront par se répercuter sur tous les serveurs, étant donné le temps de rafraîchissement .

Basically Available

Consistency	Cohérence : Tous les nœuds du système voient exactement les mêmes données au même moment.
Available	Disponibilité : garantie que toutes les requêtes reçoivent une réponse.
Partition-Tolerance	Tolérance au partitionnement : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).

Le Théorème de CAP nous dit qu'il est impossible pour un système informatique de calcul distribué de garantir en même temps ces 3 contraintes. On ne peut en garantir que 2 à la fois, selon 3 combinaisons distinctes à un instant t : {CA ; CP ; AP}.

CALM :  - Consistency As Logical Monotonicity

 Une application cliente doit elle même compenser l'éventuelle inconsistance de la base NOSQL qu'elle requête, ce qui peut s'avérer complexe et sources d'erreurs. Une solution de contournement est de considérer une base de données CALM, C'est à dire une base ou les faits massivement volumineux jouissent d'une totale invariance, c'est-à-dire, pas d'opération UPDATE et DELETE atomique. C'est le cas par exemple  des logs que produisent les systèmes de surveillance et d'alertes, et plus généralement toute information produite par une machine, un robot ou un objet connecté.


FLUCTUAT NEC MERGITUR

Pourquoi Le BigData fascine-t-il autant ?

Quand on parle de BIG DATA, incontestablement, nos yeux brillent, nos neurones se donnent la main, et se connectent, pour entrer dans la danse de cette nouvelle technologie si prometteuse.

Bien que cette technologie existe depuis maintenant 10 ans pour répondre aux problèmes de valorisation de l’information massive, nous n'avons aujourd'hui en Nov. 2015 en France, qu'un spectre relatif d'usage concret.

En janvier 2013, Dan Ariely écrivait dans FB, "Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it..." Heureusement en France, nous sommes décidés et très motivé pour perdre notre pucelage. Nos amis américains, comme toujours sont les précurseurs, et fidèles à leur devise "Just do it", ils se lancent. Ce n'est pas parfait au premier coup, mais c'est pas grave, on sera meilleur la prochaine fois. A la différence, nous français, nous voulons que la nuit de noce soit parfaite, alors on prend le temps de la réflexion et de la préparation avant de se lancer, en lisant au passage les expériences plus ou moins réussites des autres. Cette différence fondamentale se vérifie dans la mise en œuvre de nos processus, et de notre gouvernance, etc.. Heureusement cette état d'esprit bien qu'ayant aussi des avantages, tend vers plus de flexibilité et d'agilité, afin de gouter plus rapidement au fruit convoité, et de profiter de ces retombées. La vie est trop courte...

Flexibilité, Agilité, hier, mais tout va très vite et aujourd'hui, c'est Volume, Variété, Vitesse. La belle n'attend plus, Elle a beaucoup à donner à ceux qui la mérite, et ces charmes sont innombrables et multi formes.

Plus sérieusement, La technologie Big Data fascine car elle est simple, basée sur le parallélisme de stockage (CAP) et d'exécution (Programmation distribuée), pas chère à mettre en œuvre, sur des serveur basics et pleine de promesse business. Elle est boostée par le pragmatisme des formats de données élémentaires (listes, documents, colonnes), quitte à opérer quelques entorses à la sacro-sainte ACIDité pour plus de disponibilité, pourvu qu'on assèche le lac de données en temps fini. Elle permet de transformer un temps d'analyse, exponentiel en un temps d'analyse linéaire. Ainsi, les phénomènes traditionnellement appréhendés par de l'échantillonnage statistique, trouvent maintenant un écho puissant et pas cher avec le Big Data, sur un spectre de donnée beaucoup plus grand, et dont la récolte promet des investigations futures encore inconnues. Notre médaille Field, Cédric Villani, nous rappelle aussi, que mathématicien est le meilleur métier du monde.

Le prédictif, comme dans une boule de Cristal ? Ça aussi ça passionne autant que ça effraie. Un des exemples les plus incroyables en terme de prévision et l'usage qu'en fait la police de Memphis, qui a fait baisser sa délinquance de 36%, et en réorganisant le planning des rondes et des interventions, par un ordinateur, selon les plus fortes probabilités de risque de crimes à un instant données. On est plus à l'échelle d'une gare qui étudie des flux de personnes ou d'un magasin qui analyse l'appétence de ses clients pour un paquet de lessive sur une campagne de 1 mois, mais à l'échelle d'une grande ville, où l'on croise simultanément, les historiques d'interpellation, la météo, les voitures volées, etc.., le tout en temps réel.   "That is Big Data"...


Résistance Paris Bataclan : FLUCTUAT NEC MERGITUR

Stratégie du SI

INTRODUCTION

Je discutais la semaine dernière avec le DG d’un petit cabinet de Market digital sur Paris, sur le thème de La rationalisation des systèmes d’information. Il faut dire que le bonhomme a de l’expérience, en matière de développement d’entreprise, doublé d’une curiosité intellectuelle, et triplé d’une sympathie naturelle et communicante.

Il me dit :
« Emmanuel, ça fait 17 ans que je monte des entreprises, et comme bien d’autres j’ai perdu 4 fois et gagné 5 fois. Dans tous les cas, ce n’est jamais l’IT qui drive l’entreprise, mais le business. »

Mon sang ne fait qu’un tour, je me ravise, je souris gravement, non pas du manque de profondeur de ce que je viens d’entendre, mais plutôt de cette méconnaissance et cette acculturation qu'un homme de marketing peut avoir concernant deux notions très différentes qu'il semble mépriser à défaut de maitriser : Le système informatique (IT) et le système d’information (SI).

 Je laisse passer l’humeur avant de revenir à la charge le lundi matin. Mon Weekend a été consciencieux et laborieux et je remercie mon interlocuteur de m’avoir poussé dans mes retranchements pour finalement parfaire le message, et lui mettre le nez dans son vrai problème.

Je lui dis :
 « Le business est le seul driver de l’entreprise, tu as maintes fois raison. Le marché, les tendances, les opportunités, les ventes croisées, le carnet de commande, le réseau d’affaire, contribuent à développer le chiffre d’affaire de ton entreprise. Mais si le business et le driver, le SI (Système d’Information) en est le booster, son levier, pourvu qu’il soit rationalisé. Aïe Aïe Aïe, j’ai dit "rationalisé" ! Bon J’assume... Pourvu qu'il soit bien dimensionné, par rapport à tes objectifs et ta cible. . Aïe Aïe Aïe, j’ai dit "Cible"... »

Je lui dis encore :
« C’est un peu la même différence entre une vitesse et une accélération ». Une variation de la vitesse s'appelle une accélération, et elle booste ta vitesse à la hausse ou à la baisse. Confondre vitesse et précipitation n'aide pas à y voir plus clair. »

« Ta vitesse est imposée par le marché, la croissance (y en a plus), les besoins de consommation, tes alliances... Ton accélération est définie par la compétence des Hommes, l'innovation des technologies qui te fait cruellement défaut, et la maîtrise de ton SI. »

DÉFINIR IT ET SI

Pour parler du SI, encore faut-il le définir pour éviter les confusions, et le différencier de « IT » (Système informatique).

---

L’IT est l’ensemble des moyens techniques et technologique physique, concret, permettant de produire un service automatisé à partir d’informations. Il s’agit des serveurs, des disques des réseaux, de la connectique, des PC et autres smartphones connectés et intelligents. L’IT est palpable par le béotien qui y voit une collection de machines « esclaves » capables d’exécuter en masse un processus formel pour lui faire gagner du temps et de l’argent. 

---

Le SI est, quant à lui, une notion plus abstraite, qui laisse perplexe, le profane. Il retient malgré tout ce terme, très usité bon an mal an dans les médias.

---

Le SI est l’ensemble des actifs matériels (IT) et des actifs immatériels de l’entreprise, permettant de produire l’information métier, l’information de pilotage, l’information organisationnelle…. Bien souvent, nos amis américains (avec Togaf), réduisent le SI aux applications et aux données, ce qui pour nous français, de culture merisienne, praxemienne, est insuffisant. Aux données et aux applications qui s’en nourrissent, nous y rajoutons, les procédures, les processus métier et les procédés. C’est-à-dire le jus de cerveau pour faire travailler ensemble tout un village gaulois talentueux mais indiscipliné, qui toujours, d’abord, commence par dire : « - C’était mieux avant ». D’ailleurs dans la méthode UP (Unified Process) on retrouve ce terme de « Discipline » pour parler de compétences projet (voir matrice UP). 

---

 DIFFÉRENCES DES POSTURES ENTRE IT ET SI 

- On installe des logiciels sur un PC ou un serveur et on gère des licences (IT), 
- On fait coopérer, inter-opérer les applications entre elles avec des flux (SI) 

- On installe un logiciel de CRM, on le maintient et on assure sa disponibilité et son MCO (IT) 
- On capitalise les contacts clients et les besoins qu'on a pour en assurer une vue à 360 (SI). 

- On pirate une machine (IT), 
- Pour y dénicher une information secrète (SI). 

- L'IT est concret et physique, Il est la composante de production à un instant donné. 
- Le SI est abstrait et logique, Il est représenté par un existant, une cible, et une stratégie pour y aller. 

- Le DBA optimise une base de données pour diminuer les temps de réponse, assurer la sécurité, la disponibilité,… (IT) 
- La modélisation sémantique et logique des données, indépendante de tout SGBD, permet de s'abstraire des considérations tactiques, inutile pour causer périmètre Stratégique. (SI) 

- Le cloud computing (IAAS, PAAS, SAAS) concerne d'abord le monde de l’IT
- alors qu'un conseiller en stratégie permettant d’expliquer pourquoi il faut passer au SAAS, appartient au monde du SI.

- Les livrables informatiques résultants des projets (IT),
- Les compétences que l'on forme ou que l'on rémunère (SI),
- La capitalisation des livrables pour l'étude d'une amélioration future ou continue (SI)... 


Stratégie du SI - 2eme Partie (A suivre) 
La seconde partie traite de la mise en œuvre des stratégies économiques avec le SI.

SSILEX SAS : Imatérialisation vs Dématerialisation

Avant, pour des questions juridiques, on matérialisait les flux numériques sur du papier blanc lisible par les contractants : Pour cela il fallait : Imprimer, Envelopper, Timbrer, Poster, SIGNER, Envelopper, Retimbrer, Reposter, puis scanner, avant d’atterrir en GED (Gestion Électronique des Documents).

Cette magnifique chaine s'appelait la dématérialisation. Cette "fracture numérique" a bien entendu un coût, en organisation, en temps et en euro, rendant la chaîne, peu agile, et pour tout dire inéfficace.

Mais ça, c'était avant :-) .... Pour sortir de ce carcan, la société SSILEX SAS innove. Elle apporte l'Imatérialisation du processus de contractualisation, pour le fluidifier et le simplifier. Le contrat est maintenant édité, signé, et transmis en GED, simultanément.

La technologie SSILEX rend le processus parfaitement fiable, et opposable devant un tribunal, Réduisant par la même le niveau de risque de litige sur contrat, à néant, malgré l'amplification du risque lié à l'arrivée des classes  action à la française (Loi Hamon).

DSI : Evoluer pour ne pas disparaitre

A l'heure ou le système monétaire mondial sursaute, avec le renforcement des mesures de gouvernance des risques de Bâle 3, et une crise qui dure depuis 2007, les DSI du secteur Banque/Assurance doivent se réinventer. Ils n'ont en réalité pas le choix, au risque de se voir remplacer par des profils plus agile, plus à l'écoute, qui manage des hommes, des idées et des ambitions pour l'entreprise.
Le DSI de demain sera un "Service Builder", anticipant les questions et les problèmes, et modelant par la même, le Système d'Information (SI) et non plus seulement le Système Informatique (Infrastructure Physique). Le DSI de demain sera un homme de service.

Ne pas confondre SI et Système Informatique ! 

Dissocier SI de Système Informatique. Nous dénommons IT, le Système Informatique (Ensemble des actifs matériels et logiciels du parc informatique), duquel nous dissocions le Système d'Information - SI  (IT + Compétences + Données +  Procédés + Plan de construction).

Le SI est en perpétuel mouvement difficile à palper, à partager et à valoriser, Il est le creuset des expressions humaines et du potentiel collectif de l'entreprise 2.0.

Pour l'Architecte d'Entreprise (AE), la donnée métier est le véritable actif immatériel de l'entreprise, et la création de valeur, n'est qu'une séquence de transformation de la données qui s'effectue à travers les processus métier, en unité de temps, d'action et d'acteur, pour transformer les données. Il est donc fondamental de décrire, partager, challenger et capitaliser, les processus métier de l'entreprise. C'est le domaine de l'architecture d'entreprise.

Évoluer ou Disparaitre 
De nombreux forums d'architecture d'Entreprise se font quasiment tous l'écho de la difficulté que rencontre la profession, trop souvent à l'étroit dans une Direction IT exclusivement tournée vers le passé et le présent, dans sa stratégie défensive de sauvegarde des meubles. Le MCO (Maintien en Conditions Opérationnelles ) est certes important, mais ne doit pas être un frein à l'évolutivité du système. Cette stratégie n'est pas bonne ; elle est même une ineptie, avec la maturité aujourd'hui du Cloud Computing qui remplace désormais les lourds investissements IT d'hier en une ligne comptable à cout variable. Le Cloud IAAS et PAAS est la garantie d'un service d'infrastructure optimisée avec un bien meilleur service, et moins cher, notamment pour les PME.

Il existe plusieurs raisons pour expliquer la sortie de route de la DSI :

1. Des investissements lourd et tardifs, sans veille technologique,
2. Le virage du cloud a été loupé,
3. Une DG qui perçoit l'IT comme un centre de cout, et non de profit,
4. Un manque d’intelligence collective au board,
5. Un manque de visibilité sur le marché,
6. Des ambitions pas ou peu partagées (culture du secret).

La délocalisation de l'IT, dans le cloud, Oui,  celle du SI, Non !!

Mais comment modèle-t-on un Système d'Information (SI) ?

L’AE définit comment une Entreprise Opère (le « présent ») et se Transforme (le « futur ») : comment des Acteurs (Humains ou Ordinateurs) effectuent des Actions (Processus, Fonctions) à l’aide d’Informations (données).
L’Architecture ne définit pas la stratégie de l’Entreprise (quels produits, pour quels marchés, avec quels partenaires, sur quels territoires), mais cette stratégie est un « input » pour l’Architecture d’Entreprise.
Lorsque le fonctionnement de l’Entreprise devient trop complexe il faut Modéliser ses Opérations pour qu’elles s’effectuent efficacement: le Modèle permet de comprendre, mémoriser, communiquer, former, guider les Acteurs, pour qu'ils travaillent ensemble.

La modélisation peut être globale via des Cartes (cartes d’Entités du métier, cartes de Processus, cartes de Fonctions, cartes de Blocs, cartes de Services...) ou détaillée.
 
Le modèle détaillé comprend 3 parties :

• Le Modèle d’Acteurs,
• Le modèle d'action, On distingue : 
• le Modèle de Processus (« Vendre », « Produire », « Gérer »)
• le Modèle de Fonctions qui composent les Processus (« Tarifer », « Imprimer »).
• Les procédures : la check list du pilote mono acteur)

•  Et les Modèles d’Informations des Contacts, Personnes, Client, Produit, Contrat, Compte...

Quelques bonnes pratiques d’Ingénierie pour accroître l’agilité
La promotion des bonnes pratiques d'ingénierie est au cœur des préoccupations des Architectes d'entreprise, pour accroitre l’Agilité : (Issue des travaux du CEISAR)

• Rechercher un Modèle unique partagé par les Métier et l'IT pour éviter les malentendus.
• Définir un langage Métier rigoureux pour faciliter la communication entre Métier et IT.
• Réutiliser des Composants sous toutes les formes pour diminuer la charge de travail.
• Modéliser le Coeur-Métier avant l’Organisation.
• Appliquer chaque fois que possible l’Approche Coopérative plutôt que l’Approche Contractuelle.

Pour appliquer ces recommandations, il faut faire évoluer les Rôles dans la Transformation et adapter les Organisations, ce qui suppose de Former les acteurs concernés.

En conclusion, je dirais qu'il est fondamental que chaque fonction de l'entreprise soit bien connue des architectes d'entreprise, et que son terrain de jeu le SI, doit être dissocié de celui des directions informatiques auxquelles on le rattache traditionnellement. Dans l'idéal, l'architecte d'entreprise joue une mi-temps dans chaque direction sous la responsabilité de la DG afin d'y percevoir et d'anticiper les besoins et exigences et réinventer les cibles de demain, en fonction de la stratégie définie.

Méthode, Il faut de la méthode ...

Je discutais avant hier avec un chef de projet informatique d'une banque, lors d'un petit déjeuner technologique. Celui-ci, au détour d'un java (ça veut dire "café" en argot américain), me dit: "Chez nous les projets informatiques sont quasiment tous soumis à la loi du coût minimal, et les projets commencés aujourd'hui, doivent être livrés pour hier.

L'homme, avec un sourire grave et le regard circonstancié, n'avait pourtant pas l'air de plaisanter.
"Quelle méthode Projet, utilisez vous", lui demandais-je interrogatif ?

"Ben.... on en a pas trop, mais comme on est super fort on arrive à délivrer pour faire plaisir au métier"
dit-il d'un air convaincu et convainquant.

Bon alors là le diagnostique est clair....
En tant que chief Architect, expérimenté, voici en une demi heure, les quelques conseils que je lui donnais pour faire avancer sa réflexion sur son rôle et ses responsabilités.

1°) Les métiers demandeurs sont tes clients. Ils pensent que leur projet du moment est le projet du siècle, et leur réflexe naturel et de t'en dire le minimum pour aller vite, car le temps c'est de l'argent. Parfois même, croyant bien faire, ils lâcheront des mots techniques d'un jargon pas toujours maîtrisé dans un FranGlais que ni Molière ni Shakespeare ne comprennent, soit par habitude, soit par négligence, soit les deux.

2°) Les métiers demandeurs te justifieront tout le temps que leur projet est super rentable et que tu as intérêts à le prendre en compte pour le bien de l'entreprise. Demande leur donc de s'engager sur une enveloppe de gains potentiels chiffrés, de gains d'opportunités chiffrés, et du coût à ne pas faire, toujours chiffré, cela te fera gagner du temps, et te sera utile plus tard, en phase " préparation" pour le calcul du ROI.

3°)   Le client est objectivé sur la croissance, dans les quelques cas que tu m'as cités. Il sera félicité pour cela, et espérons que toi aussi. Mais en revanche, même s'il a une idée relativement précise sur les risques de conformité, juridique, ou d'obligations réglementaires, qui l'empêche de dormir, il est assez mal préparé à la notion de risques liés au système d'information. Dans les coûts du projet, c'est ton devoir de les prendre en compte, et de te faire aider de ton RSSI. Sinon, cette fois, c'est toi qui feras des insomnies.

4°) Ton client est encore moins bien préparé aux problématiques d'architecture et d'urbanisation du SI, qui, projet après projet, peuvent croitre de façon complètement anarchique (ou pas) en fonction du talent de l'architecte en chef. L'entropie d'un SI est un sujet majeur dont l'objectif est de pouvoir assurer dans le temps la disponibilité, l’efficience, la mise en œuvre simple de solution innovante, plus prosaïquement, éviter que le coût marginal d'un dossier ne deviennent de plus en plus élevé. En principe l'anarchie dans le SI doit empêcher tout le monde de dormir, à commencer par le DSI et l'urbaniste, et les métiers.

5°) Pour cela ton projet (La déclinaison informatique du projet du siècle) doit être vu à travers une méthode d'architecture, te permettant de considérer que tout projet est une transformation potentielle du SI (les projets de maintenance de patrimoine sont à isoler). A ce titre les impacts doivent être mesurés à long terme par l'équipe Architecture, pourvu que ton projet s'inscrive sur un axe stratégique défini et un portefeuille de projets arbitrés. Les transformations grosses mailles devraient alors apparaître dans un ensemble plus vaste que ton projet, nommé "Roadmap".

6°) Ton projet doit mettre en œuvre des disciplines d’ingénieries (Il en existe 5) et des disciplines de support (il en existe 4). Ton rôle de chef de projet entre dans la catégorie des disciplines "Support" (Project Management)

7°) Dans ton entreprise, tu me dit que tu délivres à temps; C'est bien !! Vous êtes probablement corvéables à merci. Les besoins arrivent en ordre dispersés sans véritable alignement avec la stratégie, et la charges ne compte pas la qualité. Cela génère du stress, et de la souffrance humaine, pas toujours perceptible immédiatement, pour un manager, lui même en souffrance. Au paroxysme de la flexibilité on serait dans une situation ou les projets sont aussi nombreux que les besoins, et les mises en production aussi nombreuses que les projets.
uhmm comment dire ???

8°) Tu dois mettre en place, un système de pilotage AGILE. Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients”
Couple ton approche agile avec du formalisme et de la rigueur:
- En amont sur les aspects métiers et fonctionnels,
- En aval sur les aspects applicatifs et techniques.
Cela passe par une refonte globale des habitudes de travail, la formation des équipes autour d'un langage d'entreprise fédérant et formel, comme UML, la mise en œuvre des projets à l'aide d'une méthode agile.


9°) Tu dois délivrer mais au juste prix "durable" pour ne pas risquer de mettre en péril et dans le temps, le SI. Tes demandeurs de projets du siècle ne comprennent pas toujours cela, mais ils n'accepteraient pas non plus que dans le temps, tu délivres de moins en moins vite, ou de plus en plus cher. Tu seras alors malgré toi réduit en esclavage du SI que tu auras négligemment engendré. En fait, dis toi, que tes clients s'adressent à un pro, pas à un épicier. Le devis doit prendre en compte tous les coûts permettant d'assurer la pérennité du SI. Ton planning devrait classer les activités par disciplines pour t'assurer de les couvrir quand c'est nécessaire, et d'avoir des plans d'itérations standards.

Plus facile à dire qu'à faire. Tu n'es qu'un maillon, certes important mais un maillon quand même. La solution est un électro choc managériale, une prise de conscience, une lumière, un espoir "que le changement c'est maintenant" :-). Tu devras alors être objectivé sur la qualité du SI, et plus sur la quantité de livraison dans un temps irréaliste. Des demain regardes tes objectifs.

10°) Ton projet doit être poussé par les exigences: Elles seront formalisées par des cas d'utilisation (en UML) et l'ensemble de ces cas formera le squelette de ta solution d'architecture..... Bravo et bienvenu dans le monde du processus unifié (UP). Cette méthode objet de gestion de projet est une méthode agile, déclinable à volonté pour tes propres besoins.
Je te raconterai une suite possible dans un prochain déjeuner techno .... :-)

... Mais au fait, as tu déjà entendu parler de UML ?

"Oui bien sur, qui ne connait pas de nos jours  ???"


En sa qualité de responsable d'Architecture IT, Emmanuel PESENTI est amené régulièrement à animer des présentations sur la méthode projet UP qu'il met en place au service du référentiel d'architecture du SI, sur les objectifs à venir, et la façon d'y arriver.

Cette méthode est unique et s'appuie sur ses 10 dernières années d'expérience, de pilotage par les modèles et expliquant comment les artéfacts d’ingénierie des projets se capitalisent dans un référentiel d'architecture, structuré en UML.

Qu'est-ce que l'Architecture dans le contexte de TOGAF ?

Selon la norme ISO/IEC 42010:2007, l’architecture se définit comme étant une organisation fondamentale d'un système incarné par ses composants, leurs relations mutuelles et avec l’environnement, et les principes régissant leur conception et leur évolution.

TOGAF se conforme bien à cette définition tout en l'étendant. En effet, pour TOGAF, il est important de parler de "description formelle" du système décomposé en composant d'architecture, pour guider sa mise en œuvre. La structure des composants, leurs relations, les principes et les directives régissant leur conception et leur évolution au fil du temps.

TOGAF couvre la mise-en-œuvre de 4 types d'architectures, dont la complémentarité permet de refléter la réalité de ce qu'est l'architecture d'entreprise.

• L'architecture métier : La stratégie métier, la gouvernance, l'organisation, et les processus métier fondamentaux.
• L'architecture des données : La structure de l'organisation des données logiques et physiques en tant qu'actif métier géré ainsi que les ressources pour les gérer.
• L'architecture applicative : La représentation individuelle et détaillée de chaque application de l’écosystème et les interactions (Flux, événements) inter-applicatifs, justifiés par .
• L'architecture Physique : Les interactions entre le logiciel et sa plate-forme physique de déploiement requise, pour supporter les exigences de performance des services métiers. On y trouve classiquement les infrastructures les middleware, le réseau, les communications, ...

Pourquoi TOGAF ?

• TOGAF est un cadre de méthode complet reposant sur des bonnes pratiques d'architecture,
• TOGAF est complémentaire à d’autres cadres d’architecture,
•  il est d'usage libre et évite de réinventer la roue,
• TOGAF est maintenant largement adopté,
• 10 000 certifiés,
• 100 000 copies téléchargées,
• C'est un standard, ouvert indépendant des éditeurs et des méthodes,
• Il assure un alignement IT - métier,
• Possibilité de rejoindre les 300 membres qui ont développé TOGAF,
• Professionnalisation du métier d’architecte.

Passez à l'action avec Mon Coach Carbone

Smartphones, Box, Téléviseur HD, Tablettes numériques ... Avec les nouveautés technologiques, la consommation des ménages en équipements explose, tout comme la consommation en CO2.

Nous aussi, GEEK de tout poil, sommes conscients des responsabilités environnementales et des enjeux économiques courts et long termes. Associons plaisir, business et responsabilité.

Avec cette vidéo, voici quelques conseils d'utilisation qu'il est bon de rappeler, avec Mon Coach Carbone...

Equipement-Passez à l'action avec Mon Coach... par fondationnaturehomme

J'ai fait le test : Voici mon bilan   ...   A vous de jouer ....

Consultant SI : Qui est-il ? Que fait-il ?

Un consultant en systèmes d'information est une personne ayant une grande culture IT (projet, Architecture, service) et qui aime apporter des solutions innovantes, spécifiques, en echos aux problématiques métiers de ses clients. Sa valeur ajoutée n'est pas celle d'un spécialiste sur une technologie particulière, mais plutôt celle d'un compositeur "technophile" à la recherche d'harmonie globale de plusieurs instruments. Mais avant, il doit écouter et comprendre l'attente dans son ensemble, pour fournir des solutions globales. Entre un spécialiste (le musicien) et un consultant (compositeur), le courant passe bien, les enjeux sont communs, seuls les leviers et la méthode, changent. Un spécialiste a bien souvent une activité précise, répondant à des métriques, ou aidé par des templates et des frameworks. Le consultant quant à lui fait du pur spécifique en composant, combinant, malaxant la technologie dans une approche globale, bornée par les coûts... Ces outils préférés sont Power-Point Word et Excel et MS Project. Il assiste la maîtrise d'ouvrage pour la définition des besoins et des solutions à mettre en œuvre, dans un souci de meilleure intégration dans le système d'information d'entreprise. Voici ses principales tâches et activités d'un consultant SI

Organisation et Assistance MOA
    - Audit, études et conseil en organisation de l'entreprise.
    - Conseil en optimisation des processus métiers (BPM, Lean,...)
    - Conseil en optimisation de l'utilisation des outils et systèmes en place
    - Sensibilisation desDirections aux technologies ressentes et la valeur ajoutée d'une DSI qui joue son rôle.
    - Sensibilisation des utilisateurs finaux sur les apports de la DSI en termes d'innovation technologique pour simplifier leur process.

Assistance MOA
    - Assistance à la maîtrise d'ouvrage pour le développement d'une DSI orientée service.
    - Assistance au pilotage de projets (Planning, Coordination, suivi des risques, Plans d’actions, rédaction de support de comités, …
    - Prescriptions et recommandations pour la mise en œuvre d'un projet ou d'une solution.
    - Définition de spécifications fonctionnelles (Objets métiers, règles métiers, cas d'utilisation).
    - Rédaction du cahier des charges pour le maître d’œuvre.
    - Étude de l'architecture applicative et fonctionnelle et de son évolution.
    - Évaluation et choix d'un progiciel.

Assistance aux changements
    - Préconisations sur le management dans le cadre de l'accompagnement d'un projet.
    - Anticipation et gestion des impacts sociaux.
    - Conception du plan d'accompagnement.
    - Accompagnement auprès des utilisateurs.
    - Conception et réalisation de documentations pour les utilisateurs et de manuels.

Qualités requises
Un consultant SI, comme tout autre consultant, doit être curieux, passionné, et aimer le contact avec les gens. Sans tomber dans la caricature "GEEK", le consultant SI est un technophile à la croisée des MOA et des MOE, capables d'adapter son discours selon l'interlocuteur, et de répondre aux besoins d'évolution des SI. Il doit se faire reconnaitre rapidement dans son silo de compétence, et tirer des liens entre les différents spécialistes, des domaines adjacents à son étude.

Un consultant doit avoir des capacités d’analyse et de synthèse, ainsi qu’un bon « relationnel client ». Il doit aussi savoir être force de proposition et être un bon pédagogue. Enfin, au fur et à mesure de l’avancement de sa carrière, il est généralement amené à exercer un rôle de plus en plus commercial.