Les relations entre les DBA et les développeurs m'ont toujours amusé. Bien que les deux services soient souvent opposés, les deux métiers sont interdépendants et les erreurs des uns impacteront pour longtemps le travail des autres. D'un coté les DBA redoutent les développeurs : ils ne comprennent pas comment bien utiliser leurs bases de données, ils les considèrent comme une réelle menace pour la sécurité du SGBDR et donc pour la qualité de leur sommeil. A l'inverse, les développeurs eux méprisent souvent les DBA : comment diable peut-on se spécialiser autant dans un domaine si minuscule comparé à l’art si vaste et si noble qu'est la programmation. En somme, bien que leurs intérêts divergent, chacun est condamné à travailler avec l'autre.
Jeremy travaille dans une grande société de télécom française, il s'occupe de la partie analyse de données. Avec un ETL, il alimente une grosse base de données décisionnelle pour ensuite faire des statistiques via des rapports Business Object.
Récemment, dans le cadre de la démarche d'urbanisation et de gouvernance du SI à travers une démarche qualité ITIL et une approche CMMI suite aux conférences Gartner que le DSI a suivi (ce bon vieux « magic quadrant »), l'entreprise décida de revoir ses règles et ses procédures de communication entre service. Chaque service a ainsi créé des documents regroupant les meilleures pratiques, les règles de sécurité, et le plan de reprise d'activité en cas de sinistre : des méthodes que tout SI digne de ce nom se doit d'appliquer.
Ainsi, des formulaires ont été créés pour communiquer d'un service vers l'autre. C'est un bon système qui évite beaucoup de problème de communication et qui responsabilise les personnes par la simple trace écrite des demandes. Un des DBA de la société sauta sur l'occasion pour protéger leur base des vils développeurs en faisant un peu plus que "revoir les règles et procédures".
Il faut savoir que la base décisionnelle sur laquelle travaille Jeremy possède plusieurs versions: une pour le développement et une pour la production. L'usage voulait que les développeurs soient maîtres des modifications sur la base de développement et que, après validation par les DBA, l'on réplique les changements sur les bases de production lors des montées de version.
Pour éviter tout problème avec les ses bases de données, l'un des DBA décréta que la base de développement devrait être une parfaite copie de la base de production. Ainsi, aucune modification dans la base de développement ne serait être acceptée.
Après de vifs débats et des explications musclées sur le fait qu'une simple demande de modification d'un état peut impacter complètement le modèle d'une base décisionnelle, les développeurs eurent enfin de nouveau l'autorisation de modifier leur bonne vieille base de développement... ou presque.
En effet, pour "mieux voir les modifications faites sur la base de développement", les champs qui étaient ajoutés ou modifiés sur la base de développement devaient être préfixés par un "Z". Préfixe qui bien sûr, ne serait pas répliqué sur les bases de production. Autant dire qu'avec à peu près 20 job ETL et plus de 50 états utilisant directement le nom des champs de la base de données, les mises en production s'annonçaient légendaires.
La seule explication plausible qu'ait pu donner le DBA pour soutenir son idée géniale fut l'utilisation d'un logiciel de modélisation de base de données. En effet, il suffisait de sélectionner les colonnes de toutes les tables par ordre alphabétique pour connaître instantanément les modifications effectuées sur la base de données.
C'est seulement après avoir vu les implications de cette gestion des schémas de base de donnés et après une mise à jour plus que fastidieuse, que le BDA, la mort dans l'âme, se résigna à simplement renforcer ses formulaires de demandes de mises en production. Les nouvelles procédures ainsi mises en place furent utilisées un peu plus longtemps que les anciennes avant de les rejoindre tout naturellement au placard. Le système de fonctionnement de l'entreprise redevint plus viable, du moins jusqu'a la prochaine conférence Gartner...
o462:
