Les interfaces de programmation d'applications, ou API, sont la manière dont un développeur interagit avec le code d'un autre. Il peut s'agir d'une simple interface de classe. Ou aussi complexe que la façade d'une bibliothèque, ou même l'API REST d'un microservice d'un fournisseur. Tout comme cette clôture, il existe une poignée de points d'entrée approuvés. Et l'API fait une distinction claire entre ce qui est à moi et ce qui ne l'est pas. C'est incroyablement utile, mais aussi potentiellement limitatif. Que se passe-t-il lorsque j'utilise l'API d'une autre équipe interne et que je découvre un bogue juste après le point d'entrée ? Cette API établit une distinction claire entre la mienne et la leur. Je ne peux donc pas aller dans leur cour et corriger le problème... n'est-ce pas ? Après tout, c'est clairement de leur côté de la barrière.
Le génie logiciel dépend fortement de l'abstraction. Nous avons tendance à envelopper de nombreux détails dans des boîtes métaphoriques. Ensuite, nous interagissons avec cette abstraction/boîte de manière plus prévisible. Parfois, j'empile mes boîtes avec celles de mes voisins pour construire notre fort. Cela peut s'avérer extrêmement utile pour les grands systèmes, mais qu'en est-il de notre communication ? Dans l'exemple ci-dessus, l'abstraction, c'est-à-dire la clôture, m'a encouragé à ne pas corriger le bogue et à le laisser à mon voisin. D'une autre manière, la conception de mon système a encouragé un modèle de communication humaine. C'est la loi de Conway à l'œuvre ! Les organisations ont tendance à développer des systèmes qui reflètent leur propre structure de communication !
Certaines organisations prennent le problème à bras-le-corps. Le célèbre mémo Team APIs d'Amazonen est un exemple. En faisant passer la question de l'API d'un simple défi logiciel à un défi "comment nous faisons des affaires", Bezos a fondamentalement changé le mode de fonctionnement de son organisation. Apocryphe, ce mémo a jeté les bases du géant qu'est AWS. Mais il n'est pas nécessaire que le PDG rédige un mémo pour que votre logiciel contraigne l'avenir de votre entreprise. Prenons l'exemple des banques. La plupart d'entre elles utilisent encore aujourd'hui des applications COBOL datant de la fin des années 1970 et des années 1980. Environ 3 billions de dollars de transactions quotidiennes passent par ces systèmes aujourd'hui. Le succès est incroyable, mais ces logiciels limitent désormais la manière dont l'entreprise peut fonctionner.
Cela révèle une nouvelle question que nous devrions nous poser lors de la conception de logiciels. "Cette architecture encourage-t-elle les comportements dont l'entreprise a besoin ? Nos conceptions peuvent soit favoriser une meilleure communication, soit l'entraver. Qu'entendez-vous par "bon voisinage" dans votre organisation ? Souhaitez-vous un soutien mutuel, comme avec InnerSource Commons? Ou bien croyez-vous en de solides clôtures API et en une forte séparation des tâches ? Ce que vous entendez par "bonnes clôtures" vous indique ce que vous entendez par "bons voisins".
Si vous souhaitez commencer à construire de meilleures " clôtures " au sein de votre organisation, des clôtures qui favorisent une collaboration efficace et l'agilité, contactez-nous ici à Improving ! Créons des API qui ne se contentent pas de faire le travail, mais qui créent un bon voisinage au sein de votre organisation ! Contactez nous dès aujourd'hui et commençons à construire un avenir meilleur, une API à la fois.
