“Architecte big data”, ce sont trois mots qui vont bien ensemble. On les entend souvent, et une recherche Google remonte un nombre certain de CV et d’offres d’emploi. Moi-même, dans les réponses commerciales d’OCTO, je me cite souvent comme “architecte big data”, à même de faire partie d’une équipe projet chez le client. Une partie du travail consiste souvent à expliquer les concepts de big data aux architectes "tout court" du client, avant de les rassurer en leur montrant que les systèmes que nous construisons peuvent rentrer dans le moule de leurs standards (et si possible sans passer pour un hippie irresponsable).

Je suis de plus en plus sceptique sur la pertinence de l'expression "architecte big data". Etre architecte big data, c’est avant tout être architecte, avec une casquette big data. Précision : cette affirmation ne remet absolument pas en question la valeur d’un expert pointu sur les technologies Hadoop ou NoSQL, pour ne citer qu’elles. Ces technologies sont fort complexes, l’expertise reste extrêmement précieuse. Mon propos vise plutôt une expression à la mode qui masque un vrai problème de perception, chez les consultants comme chez les clients. Aujourd’hui tout architecte devrait avoir une connaissance de big data suffisante pour mener à bien son travail, l’expression ne devrait être qu’un pléonasme. Cette connaissance s'acquiert en acceptant de remettre en question les schémas d'architecture maîtrisés en entreprise, en s'aventurant vers des terrains techniques nouveaux et risqués -- risque que l'on réduit en adoptant une culture de l'expérimentation, grâce à des POC (Proofs of Concent) fréquents.

20% de big data, 80% d’architecture de SI

Quel est concrètement le rôle d’un architecte big data ? Il est là pour concevoir une solution technique répondant à un besoin fonctionnel, dans le cadre d’un projet informatique. Ce projet peut être une application métier faisant appel à des briques de la mouvance big data, ou bien un data lake (i.e. un super datawarehouse avec (souvent) des vrais morceaux d’éléphant dedans).

Regardons d’un peu plus près les questions que l’architecte big data va devoir se poser :

• quels sont les usages de l’application : exploration, calcul, data science, ingestion temps réel, restitution ?
• quelles sont les sources de données ? les systèmes aval ? faut-il exposer des API ?
• quelles sont les exigences de qualité de service ? de sécurité ?
• quel est le cycle de vie de la donnée, par quelles transformations passe-t-elle, comment la gouverner ?
• pour un data lake, comment faire cohabiter des charges de travail (workloads) variées ? héberger des projets différents en harmonie ?
• sur quelle plateforme s’appuyer ? quels sont les outils de son écosystème à combiner pour chaque usage ? faut-il faire de la lambda-architecture ?
• comment dimensionner l’infrastructure ? quels sont les compromis envisageables pour satisfaire les besoins fonctionnels à un coût raisonnable ?
• à quel éditeur faut-il faire appel ? faut-il faire des POC ?

On reconnaît là en grande partie le travail d’un architecte de SI, à la rigueur d’un architecte décisionnel dans le cas du data lake. A la marge, le choix des outils vient apporter la touche “big data” à la recette -- mais comme une épice, il en faut peu pour parfumer tout le plat (de fait, on retiendra à la fin qu’il s’agit d’un projet big data !).

Tout comme l’architecte classique, l’architecte big data raisonne à base de patterns (infocentre versus datamart, batch vs fil de l’eau, etc.), en appliquant des connaissances acquises à chaque nouvelle situation. Ces patterns ont des incarnations différentes dans le monde du big data, ils sont centrés sur les données plutôt que sur les services ; mais les questions à se poser restent les mêmes.

Tout comme l’architecte classique, l’architecte big data doit assurer une veille technologique pour se tenir à niveau des évolutions d’un monde en mouvement constant. Les offres commerciales se multiplient, les partenariats technologiques entre éditeurs également. Penser à la dispersion du patrimoine logiciel de Pivotal par exemple, ou à la multiplication des offres couplées matériel + logiciel (appliances).

Tout comme l’architecte classique, l’architecte big data doit aligner son discours sur les nouveaux modes d’organisation : agilité, DevOps, ne sont pas des vains mots, surtout avec des technologies dont la maturité... hem, relative rend le cloisonnement entre études et exploitant très périlleux (combien de fois par semaine devez-vous redémarrer un service Hadoop sur le cluster de développement ?).

Comment fabrique-t-on un architecte big data ?

On comprend donc que le rôle d’architecte big data est avant tout celui d’un architecte qui se tient à jour des nouveautés apportées par big data. Là où un expert (qui, insistons-nous, reste absolument nécessaire dans l’équipe) possède des connaissances profondes des outils, l’architecte doit avoir pour faire ses choix une vision “en largeur” des technologies big data. Par exemple, il sait distinguer les cas d’usages typiques d’Hadoop ou de NoSQL, et connaît les différents patterns d’intégration pour connecter un système big data au reste du SI avec son héritage.

La transformation d’un architecte en architecte big data n’est pas spécialement compliquée. Les formations “administrateur” des éditeurs donnent un très bon aperçu des outils big data, dans leur diversité, et une excellente vue d’ensemble des plateformes big data. Le reste s’apprend sur le tas, au gré d’expérimentations et de POCs, en se faisant accompagner par des experts...

Certes, le monde du big data est vaste. Certes, les outils sont compliqués à aborder ; il faut s’y frotter pour en comprendre les ressorts. C’est là une bonne occasion de redécouvrir son âme d’ingénieur, de satisfaire son insatiable curiosité, pour proposer des solutions nouvelles aux défis inattendus de la digitalisation. Nous voyons trop souvent des architectes qui ne font qu’appliquer des calques d’architecture fossilisés, par méfiance de la nouveauté, ou plus sournoisement parce qu'ils sont dans des organisations où on ne leur reprochera jamais de faire “comme on a toujours fait”. De manière ironique, cette remise en cause de la manière de faire est plus difficile chez les architectes décisionnels, qui (en caricaturant un peu) appliquent des patterns de conception invariables (ODS, datawarehouse, datamart, 3NF) à un périmètre technologique borné (SGBD, ETL) et à un écosystème logiciel dominé par quelques grands éditeurs indéboulonnables.

A l'inverse, il est bien sûr possible à un expert de prendre du recul pour devenir architecte. La connaissance pointue des technologies lui permettra de généraliser à un système plus vaste les patterns de conception fondamentaux des systèmes big data : distribuer les calculs et les données, garantir une haute disponibilité avant tout, contourner les goulets d'étranglements des I/O, etc. Mais il faudra apprendre à placer un système big data dans un SI global, chargé d'histoire et pas toujours très porté sur les “nouvelles technos”.

En guise de conclusion

Il n'y a plus d'excuse à ignorer ces écosystèmes. Ainsi, ces dernières années, Hadoop est passé du statut de brique technique pour exécuter des batches, à une véritable plateforme multi-tenante dotée de fonctions de sécurité, de haute disponibilité, de gestion des ressources partagées, de gouvernance de la donnée, ... bref, des fonctions indispensables pour passer en production, et qui parlent le langage des architectes. Charge maintenant à ces derniers de faire l'autre moitié du chemin : comprendre le mode d’emploi des technologies big data, pour agrandir l’espace des choix technologiques dans lequel ils puisent au quotidien.

Encore une fois, martelons-le, il ne s’agit pas de spécialiser seulement les architectes qui souhaitent voguer vers les rives enchanteresses du big data : nous sommes convaincus qu’aujourd’hui, tout architecte DOIT avoir une casquette big data. De même, il doit avoir une casquette NoSQL, mobile, d'architectures réactives, etc. -- le propos se généralise aisément. La casquette n'est pas un cadeau bonus distribué avec les ouvrages académiques sur big data, elle se gagne en réalisant des POC et en faisant évoluer les pratiques d'architecture de l'entreprise.