Penser comme un architecte
Aussi en 28 langues
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)
Module 1 sur 7 du chapitre Penser comme un architecte de données, le premier chapitre du cours Data Architect. Chaque module se suffit à lui-même. Précédent : la présentation du chapitre · Suivant : Le modèle de données est l’ossature
La question à laquelle répond ce module : quelle est la différence entre construire et concevoir une architecture, et que fait réellement un architecte ?
Pendant la plus grande partie de ma carrière, j’ai été un bâtisseur.
J’ai commencé comme développeur. J’ai travaillé en Java et en .NET avant de passer à Salesforce, et j’ai passé des années à concevoir des systèmes, écrire du code, intégrer des plateformes, former des architectes et revoir des architectures.
Mais l’une des leçons les plus importantes que j’ai apprises en chemin, c’est qu’être un excellent bâtisseur et être un excellent architecte, ce n’est pas toujours la même chose.
Un bâtisseur se demande :
Comment est-ce que je construis ça ?
Un architecte doit se poser d’autres questions :
Faut-il le construire ?
Pourquoi le construisons-nous de cette façon ?
Quelles sont les autres options ?
Que se passe-t-il quand cela devient plus gros ?
Que se passe-t-il quand cela tombe en panne ?
Et quelle décision prenons-nous aujourd’hui dont nous regretterons, dans trois ans, de ne pas y avoir réfléchi davantage ?
Je me souviens d’un projet pour un commerce de détail qui gérait des rendez-vous. J’ai demandé : combien de rendez-vous par jour et par magasin ? Puis : combien de magasins avez-vous ? Et combien de jours par semaine êtes-vous ouverts ? Très vite, j’ai compris que nous aurions des millions de rendez-vous rien que la première année. Ce sont les questions qu’un architecte pose au début d’un projet.
C’est ce changement de façon de penser qui est vraiment le sujet de ce cours.
La personne qui tient le plan
Section intitulée « La personne qui tient le plan »J’ai souvent utilisé cette analogie pour former des architectes.
Imaginez un chantier. Des gens coulent du béton, tirent des câbles électriques, installent la plomberie, montent des cloisons et font des dizaines d’autres métiers spécialisés. Ils doivent être très bons dans ce qu’ils font.
Mais il faut aussi quelqu’un qui tienne le plan.
Cette personne doit comprendre comment toutes ces pièces s’assemblent. Elle doit remarquer quand ce qui se passe dans une partie du projet crée un problème ailleurs.
C’est ça, l’architecture.
Dans la technologie, on fait parfois l’erreur de croire que l’architecte est simplement celui qui en sait le plus. Ce n’est pas vraiment ça. Connaître la plateforme compte. Il faut de la profondeur technique. Mais l’architecture n’est pas un jeu-questionnaire.
Le travail de l’architecte est de prendre de bonnes décisions, parfois avec des informations incomplètes et des exigences contradictoires, et de comprendre les conséquences de ces décisions.
C’est une compétence très différente.
Ne vous contentez pas de prendre l’exigence
Section intitulée « Ne vous contentez pas de prendre l’exigence »L’une des premières habitudes que je veux voir chez les architectes est simple :
Demandez pourquoi.
Quelqu’un vous dit :
Il nous faut un autre objet.
Pourquoi ?
Il faut copier ce champ sur le compte.
Pourquoi ?
Il faut stocker toutes ces données dans Salesforce.
Pourquoi ?
Cela ne veut pas dire faire des difficultés. Cela veut dire comprendre l’exigence métier réelle au lieu de mettre en œuvre immédiatement la solution proposée.
Une exigence arrive souvent déguisée en conception.
« Il nous faut un nouvel objet personnalisé » n’est pas forcément une exigence. L’exigence est peut-être en fait « nous devons suivre cette information séparément ». Ce n’est pas la même chose.
Une fois que vous comprenez la vraie exigence, vous pouvez commencer à explorer les options. Un nouvel objet est peut-être exactement la bonne réponse. Peut-être que l’information a sa place dans quelque chose qui existe déjà. Peut-être que Salesforce ne devrait pas du tout détenir ces données.
L’architecte doit séparer ce dont le métier a besoin d’une façon proposée de le fournir.
Nous travaillions sur une application commerciale, et le client avait plusieurs approbations, chacune avec un approbateur et une date. Sa première demande était d’ajouter Approbateur 2 et Approbateur 3, chacun avec une date, comme champs sur l’opportunité. En creusant, nous avons compris qu’il pouvait y en avoir plus de deux ou trois. Nous avons donc déplacé les approbations dans un objet enfant. La demande portait sur plus de champs ; l’exigence était de suivre chaque approbation, quel qu’en soit le nombre.
Penser au-delà de l’exigence
Section intitulée « Penser au-delà de l’exigence »Deux habitudes découlent du fait de demander pourquoi, et chacune a son propre module plus loin dans ce chapitre.
Il y a généralement plus d’une réponse. Salesforce nous donne beaucoup de façons de résoudre un problème, et certaines sont fausses presque immédiatement. Choisir entre celles qui fonctionnent, c’est l’art des compromis (module 4).
Et les exigences qu’on vous donne ne sont pas toutes vos exigences. Personne ne dit « assurez-vous que ça fonctionne quand le chargement de nuit ne réussit qu’à moitié », mais c’est quand même une exigence. Je regarde chaque conception à travers trois prismes : construire pour aujourd’hui, prévoir demain, prévoir l’échec (module 5).
Pensez à quelqu’un qui engage un architecte pour concevoir un bâtiment. Il ne demande pas d’alarme incendie ni de sprinklers, ni que le bâtiment résiste à un tremblement de terre. Il s’attend à ce que cela fasse partie du travail, sans le demander. Notre monde fonctionne de la même façon. Personne ne demande une gestion élégante des erreurs, des journaux ou un moyen de reprendre quand quelque chose échoue. C’est à l’architecte de savoir lesquels de ces systèmes ont leur place dans la conception, et de les y mettre.
Rendez votre raisonnement visible
Section intitulée « Rendez votre raisonnement visible »Un architecte ne devrait pas simplement entrer dans une salle et annoncer : « Voilà ce que nous allons faire. »
Votre travail consiste aussi à expliquer pourquoi. Je veux que les parties prenantes comprennent les options que nous avons envisagées et les compromis en jeu. Cela ne veut pas dire remettre à un dirigeant un document de conception de 40 pages. Cela veut dire être capable d’expliquer la même architecture à un développeur, au métier et à un dirigeant : des conversations différentes sur la même décision.
Et la façon de le faire, ce sont des plans et des instructions clairs, comme la personne qui tient le plan sur le chantier. Pour un architecte de données, l’un des plus importants de ces plans est le modèle de données.
Si personne ne comprend pourquoi une décision a été prise, il y a de bonnes chances que quelqu’un finisse par la défaire. Et cette personne aura peut-être d’excellentes raisons de le faire, parce que personne n’a jamais expliqué la décision d’origine.
L’architecte n’a pas besoin de tout construire
Section intitulée « L’architecte n’a pas besoin de tout construire »Il y a une autre transition qui peut être difficile, surtout pour ceux qui arrivent à l’architecture par le développement.
Vous n’avez pas à tout construire vous-même.
J’aime toujours comprendre comment les choses fonctionnent à un niveau très technique, et ce socle compte. Mais en tant qu’architecte, votre responsabilité devient plus large que votre propre mise en œuvre. Vous n’avez pas à tout construire ; vous devez savoir donner à ceux qui construisent la bonne direction et les bons paramètres. Cela veut dire en comprendre assez pour guider leur travail, pour reconnaître quand une mise en œuvre proposée crée un problème d’architecture, et pour passer des détails à la vue d’ensemble.
Parfois, cela veut dire plonger dans une requête, une API ou un modèle de données.
Parfois, cela veut dire prendre du recul et se demander si nous devrions faire tout cela en premier lieu.
Et de plus en plus, ce qui construit, ce ne sont plus seulement des personnes. Avec l’IA, l’architecte peut travailler directement avec l’outil qui génère les objets, le code et les écrans. La direction, les paramètres et les consignes vont alors à l’IA, et bien les donner devient de plus en plus la responsabilité de l’architecte. Nous y reviendrons au module 7.
Cela fait partie du chemin du bâtisseur à l’architecte.
Votre travail est de prendre des décisions
Section intitulée « Votre travail est de prendre des décisions »En fin de compte, l’architecture est une affaire de décisions.
Certaines décisions sont faciles à changer. D’autres non.
On peut changer une présentation de page. On peut renommer une étiquette.
Mais choisissez le mauvais modèle de données fondamental, publiez des identifiants dont des dizaines de systèmes vont dépendre, ou placez la copie maîtresse de données critiques au mauvais endroit, et changer d’avis devient beaucoup plus coûteux.
Ce sont des décisions d’architecture. Et ce sont exactement les décisions sur lesquelles ce cours se concentre.
En tant qu’architecte de données, vous allez prendre des décisions sur la façon dont l’information est structurée, où elle se trouve, comment elle grandit, comment elle circule, qui peut y accéder et comment le reste de l’entreprise la comprend.
La technologie compte.
Mais connaître toutes les fonctionnalités de Salesforce n’est pas le but.
Le but est de développer le jugement qui permet de savoir quel outil utiliser, quand l’utiliser, à quoi vous renoncez et ce qui se passe ensuite.
C’est ça, penser comme un architecte.
Et maintenant, nous pouvons commencer à penser comme un architecte de données.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »- Si une demande est une vraie exigence, ou une conception proposée pour y répondre.
- Quelles questions poser avant de construire quoi que ce soit : faut-il le faire, pourquoi de cette façon, que pourrions-nous faire d’autre, que se passe-t-il quand cela grandit ou échoue.
- Quelles décisions reviennent à l’architecte, et lesquelles appartiennent à ceux qui construisent ; et quelle direction et quels paramètres donner à ceux qui construisent, personnes ou IA.
- Comment expliquer une décision pour qu’un développeur, le métier et un dirigeant la comprennent chacun.