En effet, la complexité, tout autant que la variété et la vitesse d’évolution des solutions mises en oeuvre demandent régulièrement la mise en place d’équipes spécialisées. Parce que leur maîtrise, j’entends par là la capacité à une mise en oeuvre réellement efficiente, est devenue quasiment impossible au sein de chaque équipe qui doit pouvoir en faire usage.

Résultat immédiat : une multiplication des équipes de support (dites quelquefois transversales).

Conséquences : une dépendance accrue des équipes de projet vis-à-vis de ces équipes de support, en profondeur (elles sont les seules à savoir, ou à pouvoir [questions d’autorisations] intervenir sur les technologies dont elles sont dépositaires), et en largeur (elles se multiplient comme déjà dit).

Inutile de dire que la multiplication des dépendances a pour corrolaire immédiat que :
– l’équipe de projet est de plus en plus souvent dans l’attente d’un délivrable (un serveur, une base de données, un jeu de données de test, un service au niveau d’un application server, un pipe sur  l’ESB, un processus sur le  BPM, le déploiement d’un outil, une configuration quelconque, …) ;
– l’intégration devient un cauchemar en termes organisationnels (il manque toujours quelque chose ou quelqu’un);
avec les conséquences qui s’ensuivent en termes de délai et de coûts, en développement proprement dit et souvent tout autant en maintenance.

Je vois encore deux autres facteurs d’inquiétude :
– les équipes de support sont naturellement moins impliquées que les équipes de projet sur la question de l’orientation sur le résulat pour le client (une forme d’application du principe “[plus] loin des yeux [plus] loin du coeur”) – osons le dire en des termes appropriés, la vie dans les équipes de support est souvent moins stressante que dans les équipes de projet;
– la lassitude guette les équipes de projet, avec son risque apparenté, le désengagement.

Et donc je n’hésite plus à poser la question suivante : ne faudrait-il pas en revenir, pour partie en tous les cas, à des feature teams, soit des équipes dotées de tous les moyens nécessaires à l’accomplissement de leurs missions au bénéfice de leurs clients directs?

La définition suivante (voir www.featureteamprimer.org) va dans ce sens, avec les réserves voulues sur les défauts cachés du développement agile poussé à l’extrême.

Le but de ce blog n’est évidemment pas de traiter le sujet en profondeur. Je me contenterai donc de quelques premières et rapides réflexions sur le sujet, à travers l’exercice des “dix principes”.

1. La standardisation garde du sens sur les outils stratégiques.
2. La standardisation doit être plus qu’intramuros. Elle doit aussi s’appliquer entre partenaires “privilégiés”.
3. A contrario, la standardisation ne doit pas être  dogmatique sur les outils non stratégiques pour tous les feature teams, sauf à réduire les coûts de licences (crise oblige). Sur le plan tactique, des zones de liberté riment avec agilité /efficacité (l’histoire militaire, par exemple, l’a amplement démontré).
4. La standardisation est un must au sein d’un feature team.
5. Sur les outils stratégiques chaque équipe doit posséder les compétences voulues. Une stricte dépendance vis-à-vis des équipes de support est à proscrire.
Dit autrement, les équipes de support doivent être et rester des équipes de support. Elles ne doivent pas nourrir les dépendances.
6. Les équipes de support n’ont pas nécessairement vocation à devenir “éternelles”. Un outil stratégique devenu banal ne mérite peut-être plus une équipe de support. Il faut savoir “nettoyer”.
Une équipe de support dans la durée n’a peut-être de sens que sur les technologies rarement utilisées par les équipes de projet, et pour lesquelles le maintien de la maîtrise dans la durée s’avère impossible par manque de pratique.
7. L’introduction d’un nouvel outil stratégique se fait via une équipe dédiée. Dans un premier temps, l’équipe de support reste seul maître de la nouvelle technologie, avec la volonté de diffuser  rapidement les compétences vers les équipes de projet utilisatrices en vue de les rendre indépendantes.
8. Les “principes” évoqués ici sont valables tant pour l’infrastructure que pour le développement.
9. Le management doit s’intéresser aux approches “converged infrastructure”, en vue de réduire le besoin en spécialistes pointus induits par les architectures (trop) distribuées et faciliter la mise à disposition et la redistribution des ressources.
10. La mutualisation des moyens entre partenaires doit être encouragée. Elle contribuera à réduire les dépendances de nature technique.

En espérant que ces quelques lignes contribueront à alimenter votre réflexion sur les problématiques de la standardisation et de l’agilité.

Une lecture conseillée sur le sujet (concise et claire) : https://s3-eu-west-1.amazonaws.com/geantsduweb.com/uploads/download/downloadable/33/octo-gdw-feature

Momenteel is het gov.uk project in een beta-test fase.  In een interessante blogpost heeft men een overzicht gegeven waarin men een tipje van de sluier oplicht van de wijze waarop men dit initiatief heeft aangepakt.

Hieronder vat ik de belangrijkste punten even kort samen.

Public cloud hosting in een eerste fase

In een eerste fase is er gebruik gemaakt van Amazon als cloud provider (publieke cloud).  De achterliggende idee was om snel vooruitgang te boeken en niet te moeten wachten op de beschikbaarheid van het eigen UK G-Cloud initiatief (Private cloud for UK government).  Dit is een goede keuze want het gebruik van een publieke cloud maakt het mogelijk om op een paar uur te beschikken over een stabiele, mature, en vooral goed omkaderde cloud infrastructuur (IaaS).  Zo kan men snel feedback en expertise vergaren over de vereisten voor de eigen cloud infrastructuur (mocht deze er nog niet zijn) en de toepassing zelf.  Ik negeer hier even de alombekende bezwaren die er zijn m.b.t. de confidentialiteit en de Patriot Act (vooral in het kader van de publieke sector).   Mits men hiervan op de hoogte is, en men de nodige voorzorgsmaatregelen neemt, is het perfect toelaatbaar om een publieke cloud te gebruiken voor dit type van projecten in een beta-fase.

Bij de implementatie heeft men rekening gehouden met het feit dat men finaal moet kunnen overstappen naar de UK G-Cloud.  Hiervoor heeft men bij het ontwerp van de diensten keuzes gemaakt die perfect ‘overzetbaar’ zijn naar een andere cloud-omgeving.  De toekomst zal uitwijzen in welke mate men in deze opzet geslaagd is.

Iteratieve selectie van diensten

De diensten die men via gov.uk zal aanbieden zijn via het “Needotron” initiatief in kaart gebracht (momenteel is een eerste iteratie beschikbaar). Hierbij is er expliciet gekozen om tot een betere afstemming te komen tussen wat de overheid kan aanbieden en wat de burger hoopt te krijgen.

Gaandeweg heeft men de nodige tools opgezet om dit proces te ondersteunen zodat men de prioriteiten van bepaalde diensten kon vastleggen.  De webapp die men hiervoor heeft gebouwd is beschikbaar op github.  Mogelijk is dit een bron van inspiratie om iets vergelijkbaars op te zetten in onze eigen context.

Agile Projectaanpak

Voor het gov.uk project is er expliciet gekozen voor een agile project-filosofie.  Dit is een erg slimme keuze voor een initiatief van deze grootte waarbij nog veel factoren onzeker zijn (niet in het minst de onzekerheid m.b.t. tot de diensten die men gaat aanbieden en in welke vorm men deze best kan aanbieden).  Een meer exploratieve manier van werken (los van het feit dat de algemene manier om een project op een agile manier te organiseren enorme voordelen heeft) is in zo’n geval zeker aan te raden.

Het is in ieder geval een mooi voorbeeld dat aangeeft dat deze manier van werken perfect mogelijk is in de context van de publieke sector.  Er is op dat vlak trouwens een expliciete wil om af te stappen van de traditionele “mega” opzet van overheidsprojecten (c.f. het rapport “System Error fixing the flaws in government IT”).

Open Source en (onconventionele) Technologie Stack

Er is gebruik gemaakt van technologiëen die niet meteen gebruikelijk zijn in de publieke sector (eigenlijk ook niet in andere “enterprise” sectoren).  Noteer alvast het gebruik van programmeertalen zoals Ruby en Scala.  Voor de databank werd oorspronkelijk gesteund op MySQL, maar aangezien er een goede match is tussen de data en wat NoSQL alternatieven te bieden hebben gaat men meer en meer gebruik maken van MongoDB (vooral dit laatste is een “verrassende” verschijning op het toneel).