Déploiement d'agents dans toutes les unités commerciales sans contrôle central

Il existe deux approches standards pour déployer des agents dans une grande organisation, et les deux échouent de manière visible dès le départ.

L'équipe centrale

Un groupe est propriétaire de tout le développement des agents. La gouvernance est excellente, les normes sont cohérentes et, en quatre mois, elles sont en file d'attente.

L'équipe qui comprend le mieux le travail est l'unité commerciale, et elle dépose désormais des demandes et attend. Les demandes sont hiérarchisées, le contexte se perd dans la traduction et les unités commerciales qui s'en soucient le plus commencent de toute façon à construire les leurs, en dehors de la gouvernance que l'équipe centrale existe pour assurer.

L’échec n’est pas l’incompétence. Le fait est qu’une équipe centrale ne peut pas détenir des connaissances sur douze domaines différents.

La mêlée pour tous

Chaque unité construit ce qu'elle veut. L’adoption est rapide, l’enthousiasme est grand et personne ne peut répondre à ce qui se passe.

Au sixième mois, il y a des agents sans propriétaire, des efforts dupliqués entre les unités qui résolvent le même problème trois fois, des informations d'identification dans les fichiers de configuration et une ligne de coût que personne ne peut attribuer. Le premier incident grave produit une réaction qui arrête tout.

Ce qui fonctionne réellement

Une équipe de plateforme propriétaire des rails et des unités commerciales propriétaires des agents.

L'équipe de la plateforme est responsable des éléments qui doivent être cohérents : la gestion des identités et des informations d'identification, l'application des politiques au point d'action, la piste d'audit, l'attribution des coûts, le harnais d'évaluation et le catalogue partagé.

Les unités commerciales sont responsables des éléments qui nécessitent une connaissance du domaine : ce qu'il faut automatiser, à quoi ressemble un bon résultat, à qui appartient chaque agent et s'il vaut toujours la peine de l'exécuter.

La frontière est la partie utile. Une unité ne peut pas refuser l’attribution ou l’audit, car ce sont des propriétés de la plateforme plutôt que des choix. Une unité n’a pas besoin de demander la permission pour construire quelque chose, car la construction n’est pas une ressource limitée.

Le catalogue est ce qui arrête la duplication

Trois unités résolvant le même problème séparément constituent le gaspillage le plus courant dans un déploiement à grande échelle, et il est entièrement invisible sans un endroit commun où regarder.

Un catalogue interne dans lequel les agents peuvent être parcourus, dupliqués, publiés et annulés transforme ces efforts dupliqués en une réutilisation. La deuxième unité part du travail de la première unité et l'améliore, et l'amélioration revient.

C’est à cela que sert l’Agent Hub, et c’est la partie d’un déploiement le plus souvent reporté et le plus souvent regretté.

Les budgets appartiennent à l'unité

Le contrôle budgétaire central recrée la file d'attente sous forme financière. Les budgets unitaires qui bloquent plutôt que préviennent confèrent à chaque unité une réelle autonomie dans le cadre d'une exposition limitée et rendent le commerce visible aux personnes les mieux placées pour le juger.

La chose à installer en premier

Propriété par agent, avant le déploiement plutôt que pendant celui-ci. Tout le reste peut être modernisé avec effort. La propriété rénovée par deux cents agents dont personne ne se souvient que la construction est le pire projet de cette liste.

Suivant

Les pages Agent Hub couvrent le catalogue partagé, le forking et le versioning. Les pages du système d'orchestration d'agent couvrent l'attribution, la politique et les budgets, qui sont les rails que possède une équipe de plateforme.