L'architecture des équipes (structure organisationnelle) influence directement l'architecture des systèmes informatiques d'entreprise. Cela est lié à la "loi de Conway" : un système développé par une organisation reproduit les structures de communication des équipes.
Si l'on conçoit un système en tenant compte des équipes interfonctionnelles, il devient possible de répartir la responsabilité par domaines, de minimiser les points de contact et de réduire les dépendances architecturales.
Exemple de formation des domaines de responsabilité et des frontières architecturales :
Dans chaque domaine, l'équipe est responsable, les contrats API sont autant que possible formalisés, et l'interaction se fait via des interfaces publiques ou événementielles. Cela simplifie l'évolutivité du développement et accélère la réaction aux changements.
Caractéristiques clés :
Question : Peut-on confier à une seule équipe la maintenance de plusieurs grands domaines ?
Dans les grands systèmes — non, cela entraîne un risque de surcharge et de goulets d'étranglement dans les communications. Il est préférable de constituer des équipes selon le principe "un domaine — une équipe".
Question : Les frontières des microservices doivent-elles toujours coïncider avec les frontières des équipes ?
Idéalement — oui, mais dans la pratique, ce n'est pas toujours possible. Cependant, il faut s'efforcer d'y parvenir pour optimiser les communications et réduire le nombre d'intégrations interservices.
Question : Est-il important d'harmoniser les décisions architecturales entre les équipes, si elles sont complètement indépendantes ?
Oui, c'est crucial ! Pour éviter le "zoo technologique" et maintenir des normes d'intégration, une harmonisation architecturale est nécessaire, par exemple à travers des comités architecturaux ou des guildes.