Je lisais récemment des portraits dithyrambiques de la monnaie complémentaire Bitcoin, chargée de toutes les vertus car « indépendante des états et des organismes centralisés » …

Très techniques, les démonstrations de ses atouts me laissent sceptiques. Par exemple, il est dit que tout est transparent dans les règles du jeu, la masse monétaire est limitée à 21 millions de Bitcoin. Alors que se passera-t-il quand tous les Bitcoin seront distribués ? Il y aura déséquilibre de la demande en Bitcoin et donc la valeur de la monnaie augmentera par rapport à ses contreparties, devises ou marchandises. Si votre boulanger vous vendait la baguette à 10 Bitcoin, elle n’en vaudra plus que 5, puis 1, .. Alors ils faudra bien que la communauté réagisse collectivement car à ce rythme, les premiers épargnants en Bitcoin deviendront vite richissimes. C’est d’ailleurs le seul sens de cette monnaie : donner à terme beaucoup de pouvoir d’achat aux gens qui y auront investi les premiers. Lire la suite »

En Octobre dernier, la communauté Européenne Lean IT s’est réunie autour d’experts internationaux comme Dan Jones, Jean Cunningham ou Michael Ballé …

J’ai eu la chance d’y être invité pour présenter un retour d’expérience en tant que DSI de la Bred, sous la forme de 5 initiatives concrètes, assez éloignées des politiques classiques comme « schéma directeur d’urbanisation », « déploiement CMMi », ou autres « plans d’alignement stratégique » …. Les supports et vidéos sont disponibles sur le site de la manifestation.

L’édition 2012 est en préparation et recherche des conférenciers …

Benoit Poelvoorde nous explique en deux minutes la difference entre le cinema belge et le cinéma français …

Au-delà de la caricature entre les deux pays, il décrit plutôt assez bien la différence entre une grande et une petite organisation. Dans une petite organisation, le comportement par défaut est la coopération, l’entraide, qui nécessite une hiérarchie plate par définition, sinon l’entraide s’arrêtera au statut de chacun : « un premier assistant ne déplace pas une voiture voyons ! ». Outre le « tous égaux » des petites structures, Benoit Poelvoorde remarque aussi que cet artisanat rime avec pauvreté de moyens, développant le sentiment que chaque contribution est décisive pour la survie du groupe.

Lire la suite »

All models are wrong, some are useful (Edward Deming)

You’ve probably seen many MIS cartographies. You know, those squares and rectangles imbricated, linked each other .. These diagrams contain a lot of information. They are most often maintained by dedicated teams and stored in a database, so that users can zoom in zones, areas, or districts. Users can find an application, its dependencies (but often, the map is not the territory ..) but who are those users? What benefit do they get from that?

As we all know «all models are wrong, some are useful». So what do we need a cartography for? We want to understand and discuss and take collective decisions. «We» stands for executive, managers and operationals.

Today executives don’t understand why we should reinvest in this «project» (note the typical misunderstanding between project and product; they tend to think that when the project is finished, the costs are over. It’s the opposite, once the project is finished, the life of the product begins, with continuous improvement .. or death), while operationals are unable to explain why they are so improductive, typically because of technical debt … Actually no one really understands each other world, and middle-managers try to take control on the debate with tons of cartography (ohh, look ! it would be so nice to merge these two application blocks, the titles say they do the same ..).

So we need a simple and comprehensive tool to better understand and discuss organizations IT assets – and liabilities, and take smarter decisions together: where to invest, on what, where to de-invest, etc.

OK, let’s get in : for each application in the system – we’ll call them product – we are going to measure 3 metrics : value, total cost of ownership (TCO) and technical debt. Then we’ll use a convention to display them as bubbles – rather than squares – to exhibit the fact that a system is not only a program, but a team of people as well. Team = Product.

While TCO can be measured quite precisely, we’ll see that we need to accept rough synthetic models for value and debt…


Value should be measured from the end-user standpoint. Hence the value of this system is not the amount of money it has costed, but rather the answer to the question «what would we do if we no longer had it ?». Here the temptation of complex multidimensional modeling is often strong, especially among engineers : «we should aggregate the loss of not being in the market for x days plus one third of the damage on the brand, estimated as customer loyalty divided by …». Stop!

There is no «true value» to measure here. There is just an approximate consensus, which has its own value : everyone agrees on the importante (or unimportance) of this product.

So discuss the question «what would we do if we no longer had it?» again and again. Discuss between IT and end-users, and executives. Argue, propose simple, unidimensional models. And at some point, someone will suggest a synthetic approach that best represents what should be understood by everyone.

By experience, these synthetic models fall in two categories, depending on the asset being «front-office» or rather «back-office» :

front-office assets, like a web store (Amazon, eBay, ..), are worth the revenues the company makes through them. Most of the time, if we don’t have them, this revenue will be lost. Value = revenues made through this chanel.

back-office assets are different. If we loose them, we can still talk to our customers and make revenues, we just have to manually do what we used to do with the help of computers (accounting, control, inventory, purchasing). Imagine a solution that would only require spreadsheets and basic workforce, you always can! (look back 30 years ago if you lack imagination). Value = total workforce cost per year, because spreadsheets and data space are nearly free nowadays.

Now you have one figure in € or $. If you add all the values of your sub-systems, front and back-office, it can be greater than your company revenues, which just shows that IT is very important in your company (eMerchant, banks, telcos ..).

As end-user value is the most important thing to see, we’ll use it as the main scale of our diagram, it will give the surface of each product, like :

Total Cost of Ownership (TCO)

Costs of a system are not only the project costs or the maintenance costs, but include all what we shouldn’t have to pay for if we didn’t have this system: hardware, software, production staff, support staff. In typical IT departments, production teams are separated from development teams. While it is often easy to track development costs at a product level, you’ll have to do some analytical accounting in the datacenter, where things are more mutualised. Start basic, asking the question at your production staff («OK, so roughly, this application takes 2 thirds of this Unix server, which is managed by those 2 people for half of their time?»), and checksum that the sum of all production costs equals the production total budget, including managers, licences, datacenter, energy ..

Now to remain visual and comprehensive, we’ll use a shade of gray to display costs as a fraction of value. The darker the shade, the lower the ratio TCO/value : dark assets cost more than what they are useful, light assets bring more value than what they cost. In the middle, grey assets are neutral, we could decide to «decomputerize», it would be the same for the company.

Technical debt, a liability

How could we simply approximate the last metric of our cartography? Remember the goal: discuss, get a consensus on what should be done. The best way is to ask people in the field (developers, production guys..) : «what do you think we should invest to go back to a normal state of productivity? (a state where you are happy to maintain the code, where you no longer suffer from reccurent incidents, etc.)». You may have to ask several times the question as often, people that have lived for long in a decayed environment tend to think that it is normal, so ask again, «how much to transform this code into Open-Source or Google-class code that you would be proud of. Then they will start to speak the truth and talk about their regular pains : technical obsolescence, lack of tests, data & code doublonning, code heterogeneity. Ask them the number of man-days required for a cleaning project, and valuate it in € or $.

We will then display this debt in €, as a fraction of the annual total cost, with a crust surrounding the asset. A crust visibly empeds an asset from developing, it is easily understandable by executives : bahhh big crust! ahhhh small crust! The thick crust on the right represents the equivalent of one year of costs of the asset (we should focus our entire energy for one year to clear it), a thin one, one tenth of the total cost (less than a month of the whole team to clean).

For products that are known to let their users very unsatisfied, it is a good idea to add the «end-user debt» as another contribution to the debt: how big a project that would produce all the features users have been complaining about for so long? I encourage you to be creative here : add it to the same crust or create another layer of crust with a different color…

Well, so where we go now? The cartography is not a goal in itself, it is a tool aimed at taking smarter decisions together, geeks, bosses and end-users. Imagine discussions with a result like this:

Or a discussion with your boss on something like this (more likely your situation …):

Now you must say, how to automatically build such a map? Just download this Excel tool I wrote, unzip the archive and start with the README. I distribute it under the GPL License so feel free to distribute and improve it.

Last, this cartography standard is evolving thanks to YOUR contributions. Help me. Comment. It should be improved, for instance by isolating variable costs from fixed costs at the production (datacenter amortization..), and probably many others learnt from experience.


Thierry Breton, ancien ministre, ex patron de France Telecom et actuel dirigeant de Atos veut éradiquer les mails internes, coupables d’une pollution de 5 à 20 heures par semaine du temps de ses collaborateurs : 80% du flux de messagerie serait proprement contre productif. Sa volonté est de transvaser les usages bénéfiques de la messagerie interne dans les outils dits de « réseaux sociaux », messagerie instantanée, wikis et autres moteurs de recherche.

Chronique parue dans 01 Informatique – La fin de l’eMail

Lire la suite »

Dans un livre très documenté, Extension du Domaine de la Manipulation, Marcella Marzano nous fait voyager via Kant, Freud, Hannah Arendt, Max Weber ou encore Tocqueville pour évoquer la transformation du statut du travail, et sa progressive prééminence au centre de nos vies. Du travail « trepanum », instrument de torture, réservé aux esclaves et aux serfs, le travail se transforme à partir du XVIIIe siècle en un moyen d’accomplissement, de réussite. Evolution salutaire, mais qui progressivement au XXe opère un glissement totalitaire, où l’on ne travaille plus pour vivre, mais où l’on vit désormais pour travailler. Les lieux de travail se transforment en « institutions totales », des entreprises à la fois Eglise et Nation, pourvoyeuses d’une éthique et d’un mode de gouvernement, imposant un pouvoir spirituel et temporel.

Ainsi chez Orange, Danone ou Renault, malgré des discours humanistes – développement durable, organisation participative, efficacité par l’épanouissement des salariés .., la réalité semble parfois plus nuancée.

Chronique parue dans 01 Informatique du 31 mars 2011

Lire la suite »

Docteur Goulu est mon ami

Publié: 22 juillet 2010 dans Billet d'humeur

Découvert récemment l’excellent blog du mathématicien Docteur Goulu qui fait oeuvre de pédagogie et d’humour pour nous faire découvrir toutes les réponses aux questions qu’on ne manque pas de vous poser et auxquelles vous n’avez jamais la réponse du type « toi qui est ingénieur, dis-moi cela vaut-il plus le coup d’installer des éoliennes 100km plus au nord pour récupérer 10% de vent supplémentaire et en contrepartie subir les pertes dues au transport ? » … (la réponse est oui). Pourquoi un mathématicien Perse, adulé en Ouzbekistan, Abou Jafar Muhammad Ibn Mūsa al-Khuwārizmī est à l’origine de nos algorithmes ou encore comment faire rentrer l’univers dans un seul nombre !

Riche, intelligent, et drôle.

J’ai eu la chance de discuter avec des élus de la région PACA ce week-end, et d’évoquer avec eux l’intérêt que je porte au sujet de l’Open Data. En deux mots, ouvrir les données consiste à rendre disponible à la foule des gisements d’informations jusque là accessibles aux seules administrations : lieux de tournage, tonnes de déchets collectés par quartier, investissements urbains, crimes, … Jetez un oeil sur le site de la ville de San Francisco pour mieux en comprendre les possibilités.

Que faire de tels gisements ? Lire la suite »

L’USI 2010 a encore été un grand moment cette année. J’ai eu la chance d’y présenter au format TED (20 minutes) nos retours d’expérience pour des DSI plus performantes et conviviales … C’est ici.