Journées SQL Server 2014 (JSS2014) : Session Machine Learning

Je suis évidemment bien à la bourre pour vous rappeler de libérer du temps dans votre calendrier pour les JSS2014 la semaine prochaine (lundi 1 et mardi 2 Décembre).

Logo JSS2013

Pour rappel ce sont 2 jours de conférences gratuites, organisées par le groupe des utilisateurs, hébergées au centre des conférences de Microsoft à Paris (Issy).

Allez-y pour les 2 jours, pour une session entre midi et deux, pour seulement une demi-journée, pour une session au petit matin ou encore une session en fin d’après midi, mais allez-y: c’est gratuit et y’a du speaker

Voilà le programme, le formulaire d’inscription (gratuite), et si vous restez pour déjeuner direction les lunchbox.

De mon côté je présente une session sur Azure Machine Learning, et plus globalement le Machine Learning vu par un pro de la BI. Rendez-vous Mardi 02/12 matin (10h30 – 11h30) en salle Prairie.

Somebody's happy!

J’espère vous y voir 😉

Modélisation dimensionnelle : Dimensions hétérogènes en Sur-type et Sous-type

N’ayez pas peur du nom à rallonge, le concept est finalement assez simple 😉

Cette technique super utile est évidemment couchée sur le papier par nos amis les retraités, dans leur bible incontournable (oui je parle de Kimball…).

Couverture DWH Toolkit 3rd Edition

Imaginez que vous bossez pour une compagnie d’assurance, qui vend des polices d’assurance pour plusieurs types de produit: auto, moto, habitation, personnelle…

Côté modélisation dimensionnelle (après consultation du chapitre 16 du DWH Toolkit), on voit bien une table de fait qui va couvrir les transactions des polices, permettant de suivre le cycle de vie des dossiers:

  • Création / modification du dossier (détails de l’assuré, dates de début…)
  • Création de la couverture et association à l’objet à couvrir (type de produit, options… par exemple un tout risque auto + vol)
  • Obtention d’un devis avec la génération du tarif
  • Validation du devis et création de la police effective, demande des justificatifs
  • Obtention des justificatifs et pérénisation du dossier

A cette table de fait on va associer une série de dimensions, les axes d’analyse qui nous permettront de ventiler et analyser les faits. Ici on retrouvera les différentes dates, l’assuré, la couverture et l’objet couvert, l’employé responsable du dossier, les attributs du dossier…

Alt

Seulement voilà, après réunion avec le métier, on se rend compte que les attributs des dimensions Couverture et Objet Couvert ne sont pas du tout les mêmes entre le domaine auto et habitation. En effet, il paraît assez normal qu’on ne décrive pas une maison et une voiture avec les mêmes informations.

Il est quand même à noter que pour des soucis de consolidation et de reporting transverse, on doit tout de même constituer une table de dimension « chapeau », avec une série d’attributs simples qui concerneront à la fois l’auto et l’habitation (valeur, risque, localisation géographique…).

Côté modélisation, Kimball nous recommande alors d’utiliser la technique Sur-type / Sous-type (Supertype / Subtype). Nos tables de dimension initiales deviennent des tables de Sur-type, elles détiendront les attributs communs. A ces tables on va ajouter des tables de dimension de Sous-type, à savoir Couverture Auto, Couverture Habitation, Objet Couvert Auto et Objet Couvert Habitation, qui contiendront elles les attributs spécifiques à chaque ligne de business.

Alt

Deux choses à noter:

  • On réutilise les mêmes valeurs de Surrogate Key pour les dimensions Sur-type et Sous-type, inutile d’encombrer la table de fait avec des FK supplémentaires
  • On intercale des vues entre ce schéma et les utilisateurs, pour apporter:
    • la vision consolidée (toutes les lignes de la table de fait et uniquement la dimension Sur-type)
    • des visions par ligne métier (un filtre sur la table de fait pour n’exposer que les transactions du type) et la dimension Sur-type accompagnée de la dimension Sous-type:

Alt

Plutôt cool non? On a le beurre et l’argent du beurre avec cette approche 😉

Evidemment on ne peut appliquer cette méthode que si les mesures présentes dans la table de fait sont communes à tous les processus métier (Auto, Habitation…)

Dans le cas contraire, il est nécessaire de créer des tables de fait différentes, chacune avec ses mesures propres. Notez que dans ce cas, il est toujours possible d’utiliser l’approche Sur-type / Sous-type, pour disposer d’une table de dimension permettant la consolidation et le reporting transverse. Voir pourquoi ne pas aller plus loin et créer une table de fait de consolidation, qui portera les mesures communes et la table de dimension Sur-type. Le gros avantage c’est d’être capable d’exposer en une passe les données de haut niveau sans repasser par 2 tables de bas niveau qui peuvent être plus lourdes (mais on s’en passe très bien si la solution contient un cube OLAP).

Pour aller plus loin: les chapitres 10 et 16 du Datawarehouse Toolkit 3rd Edition.

Management des équipes dans l’entreprise, avec agilité ou pas…

En ce moment, plein de sujets me trottent dans la tête, mais aucun dans un état abouti et clair. Alors je vous les livre tels quels 😉 Un de ceux qui contribuent à cette situation c’est le bon Michael O. Church, un bloggeur et développeur américain plutôt connu et assez grande gueule sur l’état du management dans l’industrie logicielle et particulièrement dans la Silicon Valley (qui on le rappelle, sur certains aspects est le modèle de ce qui fera dans quelques années dans le reste du monde).

Je recommande des perles comme son très bon réquisitoire pour le craftsmanship, sans jamais dire le mot, un point brillant sur les dynamiques en jeu lors d’un recrutement et comment les retourner en sa faveur, ou dernièrement une critique assez acerbe de l’Agilité, telle qu’elle est couramment implémentée ainsi que dans ses fondements, dans le contexte de l’entreprise vue par le prisme MacLeod/Gervais/Rao (que je recommande d’une telle force que vous ne pouvez pas ne pas l’avoir lu).

Sur ce dernier sujet les arguments sont valables, même si on sent qu’il n’a jamais vraiment eu la chance de participer à un projet SCRUM qui fonctionne correctement (en même temps c’est plutôt rare…). Mais j’accroche quand même bien avec son idée que l’agilité répond à un problème, la bonne allocation du travail aux productifs (les développeurs au sens large), qu’on pourrait peut-être complétement éviter.

Réaction des coachs agiles à cet instant précis de l'article

Réaction des coachs agiles à cet instant précis de l’article

Sa solution c’est de renverser le problème, soit l’Open Allocation, qui veut qu’on n’assigne pas les projets aux développeurs, mais que les développeurs choisissent eux-mêmes les projets auxquels ils veulent contribuer. Ce n’est pas une utopie puisqu’il existe déjà un exemple d’implémentation, Valve (PDF), l’un des éditeurs logiciel les plus innovants du moment. Notez en passant que ça n’est pas sans détracteurs.

Le but devient alors de passer du Politics-Driven-Development (Waterfall) au Business-Driven-Development (via l’agilité) jusqu’à l’Engineering-Driven-Development (avec l’Open Allocation). Ça peut paraître extrême, mais vu l’état actuel de l’industrie, il va certainement falloir tirer vers cet extrême pour ramener la situation à l’équilibre.

J’aime beaucoup ce courant de pensée, qu’il illustre en disant qu’on ne doit pas laisser le contrôle d’un avion aux passagers (BDD), mais bien au pilote (EDD).

J’aime l’élégance de l’idée (et très égoïstement, la liberté que cela pourrait m’apporter) mais j’ai encore du mal à la réconcilier avec une réalité business. Parce que les passagers, ceux qui payent, doivent quand même bien choisir la destination du vol, et cette contrainte doit bien s’imposer à l’organisation d’une façon ou d’une autres. D’autant plus que dans son exemple de réussite, Valve, les développeurs sont également des joueurs (donc clients), on est donc dans un cas particulier pour lequel l’EDD = le BDD.

Prise de décision chez Valve - un processus communautaire

Prise de décision chez Valve – un processus communautaire

Dans le fond tout ça rejoint quand même bien les pratiques recommandées du lean, qui pousse à la mise en place d’équipes alignées sur les streams de valeur client plutôt que les habituels silos fonctionnels : Manufacturing, HR, Marketing, Sales, Direction Technique, IT… Les équipes sont de plus rendues autonomes dans la prise de décisions locales et inscrites dans des cycles d’amélioration continue. Elles sont pluridisciplinaires, managées par les moyens plutôt que les objectifs, ce qui leur permet de retrouver un réel sens métier dont découlent les performances (et pas l’inverse).

Imaginez une société de retail, qui fabrique et vend des vêtements et souhaite avancer sur les sujets Internet of Things et vêtements connectés. Quelle meilleure équipe à mettre en place que celle dédiée à une population clientèle très précise (sportifs?), sur un besoin très précis (tracking de la performance personnelle à la fitbit/jawbone), composée du chef de produit (marketing), d’un ingénieur d’étude de l’usine de fabrication, d’un kiné, d’un vendeur magasin, d’un contrôleur de gestion, du community manager concerné, de développeurs web, app, back office, embarqué… On met tout ce petit monde au même endroit, et là vous l’avez la petite société dans la société, avec un PnL propre, une responsabilisation face au produit, et une grosse envie de réussir.

Tout ça on aime. Pas de débat. La question c’est plutôt : comment constituer ces équipes ? L’Open Allocation dans ce cas, ce serait d’avoir les chefs de produit qui pitchent les idées aux différents contributeurs, afin de les recruter et constituer l’équipe. Mais pour que les idées soient sexy il faut déjà que les contributeurs soient intéressés par le contexte métier. Si aucun développeur ne court, voir personne ne fait de sport, comment motiver les gens à rejoindre l’équipe ? Sommes nous alors plutôt devant un problème de recrutement ? Autrement dit, les développeurs de l’IT de Décathlon doivent-ils être des sportifs ?

Le flic de Bervely Hills, Eddie Murphy pas forcément très convaincu Voilà, pas vraiment de conclusion, juste plusieurs idées qui s’imbriquent et qui commencent à apporter une image de l’entreprise qui pourrait se matérialiser dans un futur proche, et dans laquelle il ferait bon vivre… 😉

En Novembre cette année, c’est à Seattle que ça se passe!

Cette année encore c’est avec beaucoup de plaisir que j’irai au MVP Summit la première semaine de Novembre, invité par Microsoft, payé par ma boîte, Cellenza, autant vous dire que la vie est belle 🙂

La cerise sur le gâteau, c’est que la même semaine, en quinconce comme qui dirait, se déroule le PASS Summit. Vous le savez, le PASS c’est la Professional Association for SQL Server, le méga groupe mondial des utilisateurs des technos data issues de Microsoft. Evidemment le GUSS, notre groupe d’utilisateurs en France, est une émanation du PASS, c’est un « chapitre local » en mode Sons of Anarchy, local chapter for France !

Photo des motards de Sons of Anarchy

Et sinon… vous pensez quoi de Power Query dans un contexte de Data Governance ? Jean-Pierre tu préfèrerais pas qu’on aille boire une bière plutôt?

Le PASS Summit c’est genre la plus grosse conférence data dans l’écosystème Microsoft, et de loin. Sur place il y a juste toutes les stars du milieu (la liste est ridicule).

C’est simple, pour moi participer au PASS Summit c’est le meilleur retour sur investissement possible en terme de formation et motivation pour quelqu’un qui travaille dans la stack SQL Server. Oui l’addition peut paraître salée, entre le coût de la conférence, les billets d’avion et le logement sur place, mais rien d’autre ne déclenche un tel boost de compétences et d’implication chez un collaborateur.

Logo du PASS Summit 2014

Cette année la délégation française est vraiment nombreuse, c’est le moment, rejoignez-nous à Seattle 😉

Une rentrée bien silencieuse…

S’il est vrai que mon rythme de publication a bien ralenti dernièrement, ne vous inquiétez pas, c’est pour de saines raisons !

J’en avais déjà parlé, et vous l’avez certainement vu à travers mes récentes lectures, je travaille à fond sur ma veille technologique. Avec David nous avons la chance de disposer d’un peu de bande passante pour la R&D, on ne pourra pas nous reprocher de n’avoir su en profiter :

  • Big Data avec Pig et Hive sur HDInsight (Hadoop sur Azure, le cloud Microsoft). David présente même une session sur le sujet au SQLSat ce samedi
  • Passage de la certification ScrumMaster. Alors oui le plus gros critère de notation c’est la présence à la formation payante, mais bon… C’est qui les patrons de la BI Agile maintenant ? 😉
  • Et surtout un gros focus sur Machine Learning à travers : la formation Coursera de Stanford (spéciale dédicace à notre camarade de classe Geoffrey), 10 semaines de cours sur la théorie et son application dans Octave (un dérivé Open Source de MatLab). Et là on enchaine sur le parcours certifiant de Data Scientist de l’Université Johns Hopkins, toujours sur Coursera, 10 modules de 4 semaines, cette fois en employant R.

Maintenant je peux le dire : franchement, le Machine Learning, ça déchire.

Je vais bien sûr vous faire découvrir (ou dépoussiérer) la discipline prochainement via une série d’articles, mais je voulais avant cela bien digérer le tout. En effet une des premières leçons qui m’a été transmise est la suivante (via Drew Conway) :

Diagramme des compétences requises en Data SciencePetit jeu: saurez-vous placer le spécialiste BI là-dessus ?

  • Hacking Skills (capacité technique) : Check !
  • Expertise métier ? Derrière une bonne modélisation dimensionnelle se cache une belle compréhension du métier : Check !
  • Math et Stats : bof bof…

Vous l’avez deviné, en plein dans la Danger Zone !

Archer et Lana, quote Danger Zone

Je vous laisse lire l’article qui va avec pour creuser, mais vous comprendrez donc que j’avance prudemment sur le sujet. Parce qu’il ne faudrait pas que sous prétexte d’occuper le terrain, je vous enduise d’erreurs 😉

 

Revue : Peopleware (3rd Edition) par Tom DeMarco et Timothy Lister

Couverture Peopleware 3rd editionPeopleware, Productive Projects and Teams (3rd Edition) – (Amazon.fr) par Tom DeMarco (Wikipedia) et Timothy Lister (Wikipedia)

Je continue dans la série des revues pour vous parler d’une référence dans le domaine du management d’équipe et de projet : il s’agit bien entendu de Peopleware. Ecrits par 2 consultants légendaires en gestion de projets et organisation d’équipes, c’est un condensé de ce qu’il faut faire pour motiver sa troupe et réussir ses projets informatiques.

Je vais faire court : si vous êtes ou voulez devenir manager IT, quel que soit le domaine, c’est un incontournable. Dedans une grosse dose de bon sens délivrée en courts chapitres de quelques pages, un vrai plaisir à lire. Ça parle RH, vie de bureaux, relations interpersonnelles, construction d’équipe, mise en place d’organisations inscrites dans des cercles vertueux…

Morceaux choisis :

  • Il faut arrêter de croire que nos métiers sont centrés autour des technologies. Les chercheurs qui font les découvertes fondamentales de nos domaines sont ceux qui travaillent effectivement sur les technologies. Nous, nous ne sommes que les utilisateurs des technologies qu’eux développent. Et à ce titre nos métiers sont donc plus centrés autour des relations humaines qu’autre chose. (p5 )
  • Les statistiques sur la lecture sont particulièrement décourageantes. Le développeur moyen ne possède aucun livre sur son domaine d’expertise, et n’en a même jamais lu un. (p11, Vous en êtes où du DWH Toolkit? ;))
  • La qualité, bien au-delà d’un simple prérequis de l’utilisateur, est une mesure de haute productivité. (p21, cf le Lean)
  • La fonction d’un manager n’est pas de faire que les gens travaillent, mais de faire qu’il soit possible qu’ils travaillent. (p34, on ne doit pas motiver, mais plutôt limiter la démotivation…)
  • Loi de Gilb : tout ce qui doit être quantifié peut être mesuré d’une manière qui est meilleure que de ne pas le mesurer du tout. (p58, on parle qualité, satisfaction… à prendre en compte dans les ROI et décisions stratégiques en plus du numéraire)
  • Par exemple : le « E-Factor » = Nb heure de travail ininterrompu / Nb heure de présence physique. (p64, à utiliser pour vérifier qu’un environnement n’est pas trop toxique au travail)
  • L’effet pervers d’un taux de turnover élevé (cycle des démissions/recrutements) et qu’il s’auto-entretient. Les collaborateurs partent vite donc il n’y a pas d’intérêt pour l’entreprise à investir sur eux. Mais s’il n’y a pas d’investissement, les collaborateurs démissionnent rapidement. (p120)
  • Le but de la constitution d’une équipe n’est pas d’atteindre un objectif, mais de définir et travailler vers un objectif commun. (p136)
  • La short-liste des techniques pour détruire une équipe : management défensif, bureaucratie, séparation physique, fragmentation du temps de travail sur des projets multiples, réduction de la qualité du produit, fausses deadlines, micro-management. (p144, avec du détail sur chacun des points)
  • La liste étendue des techniques pour détruire une équipe : primes annuelles sur objectifs, management par objectif, récompenses individuelles, et plus globalement tout ce qui tourne autour de la mesure et la gratification des performances. (p157, toujours avec le détail sur place)
  • A l’inverse, la liste des activités qui contribuent à l’équipe: faire de la qualité un culte, permettre à tous de comprendre le pourquoi de chaque décision, construire un sens de l’élitisme, encourager l’hétérogénéité, préserver et protéger les équipes qui gagnent, apporter une vision stratégique mais laisser le champ libre au niveau tactique (p168, toujours avec le détail sur place)
  • Les bonnes méthodes pour atteindre une convergence sur les pratiques sont : les formations, les outils d’automatisation, les revues par ses pairs. (p180)
  • Le péché ultime du management c’est de faire perdre son temps à quelqu’un. (p193)
  • Le changement ne peut se produire que si les collaborateurs se sentent en sécurité. (p208)
  • Une organisation peut apprendre de 2 façons : elle instille des nouvelles compétences et approches à ses membres, ou elle se redessine pour opérer d’une manière différente. (p212)
  • Dans tous les cas, la maturation d’une organisation est limitée par sa capacité à conserver ses membres. (p212)

Je recommande chaudement !

Peopleware, Productive Projects and Teams (3rd Edition) – (Amazon.fr)