Commençons par une réalité dérangeante : les limites imposées ne correspondent jamais aux préférences locales. Si c’était le cas, ces limites seraient inutiles. Elles sont nécessaires pour apporter les avantages qu’un décideur local, et en particulier une équipe de mise en œuvre locale, ne percevra jamais.
L'autre dure réalité, c'est que la plupart des directions détournent l'attention des préférences locales. Réfléchissez-y., La semaine dernière, mon PDG en exemple La gamme de produits A a été conçue pour vendre davantage de produits. leur marché existant, Famille B à réussir à augmenter les prix, et la famille C à réduire leurs coûts. Personne n'a décroché le poste passionnant et stimulant qui consistait à inventer de nouveaux produits géniaux ou à conquérir de nouveaux marchés exotiques.
Les gammes de produits A, B et C ont fait l'objet d'un travail acharné et de limites strictes.
Des objectifs et des contraintes de performance clairs leur ont été communiqués. Le PDG s'est appuyé sur les principes de base de bonne gouvernance.
Le PDG n'a pas non plus ménagé les unités opérationnelles de soutien. Le service informatique s'est vu confier une mission complexe. La priorité absolue était de des coûts informatiques inférieurs aux revenus. En filigrane se trouvait l'exigence fondamentale de justifier en permanence l'existence des TI. La réalisation des activités principales (Produit) nécessitait un gain d'efficacité grâce à la mise à l'échelle d'un service partagé. Sans cet avantage, la justification du soutien apporté à l'unité commerciale d'activité disparaît.
C'est la racine inconfortable de ombre IT, Finance parallèle, et RH fantômes—ils ont échoué au test d'avantage concurrentiel. Le recours à des services partagés parallèles est autorisé lorsque les équipes principales doivent accomplir une tâche qui n'aurait pas dû être nécessaire : se détourner de leur mission première, la satisfaction client, et reproduire les services d'un prestataire de services partagés défaillant.
Toute cette friction et cette complexité pour obtenir le meilleur des deux mondes : l'attention focalisée, la créativité et les contraintes nécessaires.
Vous connaissez ma thèse, notre profession architecture d'entreprise existe pour combler les frictions et la complexité.
En tant que architecte d'entreprise, Mon rôle est d'aider les décideurs à comprendre quand une exigence de service partagé, apparemment déraisonnable, présente en réalité une valeur ajoutée maximale. Mon rôle consiste également à optimiser la marge de manœuvre décisionnelle locale.
Je gagne ma vie à la frontière de l'espace négatif de Carver. J'impose le moins de contraintes possible, favorisant au maximum la liberté locale. C'est dans cette liberté locale que se concentrent l'attention, la créativité et les connaissances spécialisées, nous permettant de réaliser l'impossible.
Nos organisations ne sont pas le fruit d'un gigantesque plan quinquennal soviétique parfait. Elles sont le résultat d'un milliard de décisions locales, chacune optimisant les gains et les coûts réels.
Pour maximiser l'autorité locale, mon équipe de consultants EA Nous remettons activement en question nos contraintes. Nous nous demandons si elles sont nécessaires. Si nécessaire, pouvons-nous les assouplir ? Transformer une règle stricte en normes, les normes en modèles, les modèles en principes, et les principes en absence totale de contrainte.
Nous nous taquinons sur notre infaillibilité et notre omniscience. Nous vérifions explicitement si un choix différent a une importance. Et, si c'est le cas, pourquoi?
Si nous ne pouvons pas déclarer pourquoi c'est important, Nous ne pouvons justifier la suppression des libertés locales. Sans cette justification, nous commettons simplement l'erreur de privilégier notre opinion. Vous comprenez la plaisanterie : privilégier nos opinions ne peut se justifier que par notre… omniscience et infaillibilité.
Concrètement, nous conduisons pour modèles d'architecture— une approche éprouvée et efficace pour résoudre un problème prévisible. Si vous ne trouvez pas d'approche éprouvée et efficace pour résoudre un problème prévisible, vous devriez probablement attendre une attention soutenue, de la créativité et des connaissances spécialisées. Alors, attendez-vous à l'impossible.
Dans le Modèle de navigation nous insistons sur le morceau difficile—les limitations et le travail nécessaires à la réussite du modèle. Après tout, si vous ne voulez pas, ou ne pouvez pas, faire le morceau difficile le modèle est une approche qui n'a pas démontré son succès. Quand nous ne voulons pas, ou ne pouvons pas, faire le morceau difficile Ce modèle aboutira à un canyon impraticable et plus coûteux.
Je considère les implémenteurs comme mes implémenteurs. Une partie de mon équipe. Des spécialistes capables de faire preuve d'une attention soutenue, de créativité et de connaissances approfondies.génie créatif appliqué.
Les personnes qui mettent en œuvre des projets encadrés et contraints sont une chose magnifique. Chaque jour, elles accomplissent l'impossible.
Il me suffit de leur expliquer les règles du jeu et comment le score est comptabilisé — les attentes et les contraintes en matière de performance. Écartez-vous !
Cette semaine, nous allons explorer en détail l'utilisation gouvernance de la mise en œuvre à Réalisez l'impossible. Je sais que l'approche normale consiste à lancer gouvernance de la mise en œuvre comme une bataille dystopique entre des exécutants sournois qui dupent l'architecte autoritaire et dominateur.
Balivernes!
Il y a quelques secondes, le passage semblait sûr.
TOGAF affirme que les responsables de la mise en œuvre sont responsables des décisions d'implémentation.
En plein dans le Cadre TOGAF Guide pratique Article 15.2 (Rôles, devoirs et droits de décision), "Tous les droits de décision concernant les choix de mise en œuvre proposés, tels que la conception, la sélection des produits et la séquence des changements, appartiennent à l'implémenteur.."
Sans ambiguïté. Les responsables de la mise en œuvre sont pleinement responsables des décisions relatives à cette mise en œuvre.
Aussi clair que 'L'architecture appartient aux parties prenantes. Elles définissent les priorités, les préférences et les orientations. Tous les droits de décision concernant l'architecture cible, ainsi que toute dérogation à la cible et son application, leur sont dévolus..'
Sans ambiguïté. Les parties prenantes sont propriétaires de tout. décisions d'architecture.
Nous avons combiné les énoncés de la section 15.2 — droits de décision des parties prenantes et droits de décision des responsables de la mise en œuvre — avec l'espace de décision sans restriction de Carver. En utilisant le liste de contrôle de la gouvernance de la mise en œuvre Et tout s'emboîte parfaitement.
L'implémenteur a-t-il interprété de manière raisonnable les directives et les contraintes de l'architecture cible ?En termes de Carver, ont-ils respecté les attentes et les contraintes de performance explicites qui encadraient leur espace de décision ?
Comme je l'ai dit plus haut, expliquez-leur comment la victoire est jugée. Ajoutez les contraintes minimales. Écartez-vous du chemin. Exigez l'excellence.
Donner vos implémenteurs Un problème facile. Donnez-leur un problème difficile. Donnez-leur un problème insoluble. Peu importe, car s'ils savent les règles du jeu Ils remporteront toutes les victoires possibles. Toutes les victoires possibles. À chaque fois.
Il s'ensuit, comme architectes d'entreprise nous définissons clairement les règles du jeu— comment le score est comptabilisé et ce qui n'est pas autorisé. Nos outils de travail : lacunes, lots de travaux, VRP, feuilles de route dynamiques et les spécifications architecturales. Orientations, contraintes et liberté locale maximale.
Franchement, se mettre à l'écart est l'une des choses les plus difficiles à mettre en œuvre. architectes d'entreprise Nous sommes des personnes passionnées et engagées dans la résolution de problèmes.
Pour définir un objectif, je dois envisager une manière plausible de l'atteindre. Sans une mise en œuvre plausible, l'incertitude grandit et réduit à néant tout bénéfice.
Que mise en œuvre plausible est la façon dont je le ferais. Cela correspond à mon expérience, mes préférences et mes préjugés. Je peux énumérer les raisons évidentes de faire certaines choses. ma façon. Attention. Il n'y a qu'un pas entre tomber amoureux et… Voici comment je procéderais à prétendre à l'omniscience et à l'infaillibilité.
Pour élaborer des spécifications d'architecture, je dois renoncer à l'omniscience et à l'infaillibilité. Je dois changer de perspective. la façon dont je le ferais Des règles. Puis, transformer les règles en normes, les normes en modèles, les modèles en principes. Toujours viser l'ultime transformation : l'absence totale de contrainte.
S'enflammer pour ma méthode conduit à l'échec par orgueil. Instinctivement, nous ajoutons toujours plus de contraintes. Chaque contrainte est injustifiée. Chaque érosion érode notre potentiel. nos responsables de la mise en œuvre' La liberté. Chacun limitant sa créativité et son génie.
Prenez un instant pour y réfléchir. Lorsque vous libérez l'expertise du domaine, l'expérience, la passion, la créativité et le génie de vos implémenteurs Ils vous mettront toujours en valeur. Vraiment en valeur.
Ils donnent vie à nos idées.
Ils concrétisent les espoirs et les rêves des parties prenantes.
Ils vont transformer notre organisation.
Quand les choses tournent mal
Les choses tournent toujours mal.
Cela peut être aussi simple qu'un flux de données hérité. Cela peut être aussi insidieux qu'un choix d'implémentation fait il y a des décennies. Cela peut être dû à une contrainte de temps.
Il se peut que tu m'aies écouté, puis que tu aies donné vos implémenteurs Un problème difficile, un problème encore plus difficile, et enfin un problème insoluble. Parfois, pour reprendre ma métaphore sportive, nos responsables de la mise en œuvre Ils n'arrivent tout simplement pas à marquer. Parfois, ils ne peuvent pas gagner le match.
En ce triste jour, nous passons à liste de contrôle de la gouvernance de la mise en œuvre questions 2 à 7.
Les questions 2 à 7 s'apparentent beaucoup à la définition d'un objectif. La différence réside dans le fait que nous avons déjà des dépenses engagées ; chaque choix a donc un coût. Notre rôle est de… garde le bénéfice maximal.
Pour réfléchir aux avantages, je cours vers le Naviguer heuristique de valeur :
Valeur = Bénéfice/Incertitude - ((Coût_Mise_en_Œuvre^Incertitude) + (Coût_Opérations^Incertitude))
Je me tourne vers l'heuristique car, lorsqu'un problème survient, deux choses peuvent se produire :
- Le bénéfice escompté disparaît.
- les coûts prévus augmentent
Ou, pire encore, les avantages disparaissent tandis que les coûts augmentent. Quel que soit le calcul, la valeur disponible s'évapore.
Revenons à mes principes simples. Exemple robuste d'observabilité élastique EA. Nous mettons en œuvre Elastic. Nous en attendons deux avantages. Premièrement, les opérations informatiques bénéficieront d'une meilleure visibilité et d'un environnement applicatif/infrastructure plus performant. Deuxièmement, le développement d'applications profitera d'une télémétrie améliorée et pourra ainsi optimiser ses applications. architecte d'entreprise, Je ne me soucie pas de ce qui se trouve dans l'espace de décision du développeur. Seuls la valeur, les avantages et les contraintes m'intéressent. l'architecture imposé au projet.
On connaît tous la chanson quand quelque chose tourne mal. L'équipe de développement arrive à la réunion de mise à jour l'air abattu. Ils nous annonceront qu'un des quatre problèmes suivants s'est produit.
- Le projet ne peut que créer un canyon infranchissable plus étroit – un effondrement bénéfique
- Le projet doit réaliser des travaux supplémentaires pour combler l'écart – augmentation des coûts
- Une contrainte architecturale entrave la réussite : effondrement des bénéfices non liés au projet ou augmentation des coûts non liés au projet
- Ils n'ont pas respecté une contrainte architecturale : effondrement des bénéfices non liés au projet ou augmentation des coûts non liés au projet
Si vous avez une faiblesse architecture de portefeuille et gouvernance de la mise en œuvre, Vous pouvez vous attendre à ce que les équipes de mise en œuvre présentent la réduction de la difficulté comme une victoire. Elles mettront en avant la diminution des risques, le respect des délais et même les économies réalisées. architecture de portefeuille Selon eux, le projet n'aurait pas dû être financé et ils détournent les fonds du portefeuille.
Le liste de contrôle de la gouvernance de la mise en œuvre Les questions 2 à 7 portent sur la formulation d'une recommandation de conformité architecturale à l'intention des parties prenantes. Le projet Elastic a été financé afin d'améliorer l'environnement applicatif et d'infrastructure des équipes SRE/Opérations et d'optimiser le portefeuille d'applications grâce à la télémétrie.
Vous avez trois véritables choix :
- Poursuivre les efforts supplémentaires pour obtenir les avantages escomptés moins de valeur
- Réduisez les attentes et assouplissez une contrainte qui diminue les bénéfices du projet ou de l'entreprise. moins de valeur
- Conclure que le rapport avantages/coûts sera toujours négatif et abandonner l'initiative
Tester la recommandation
Le liste de contrôle de la gouvernance de la mise en œuvre Les questions 2 à 6 servent simplement à vérifier si vous avez bien fait votre travail. La liste de contrôle demande :
- Les PME sont-elles d’accord avec les faits et votre interprétation (question 2) ?
- Les PME approuvent-elles votre recommandation (question 3) ?
- Votre analyse architecturale soutient-elle votre conclusion et votre recommandation (question 4) ?
- Existe-t-il des problèmes particuliers générant de l'incertitude dont votre partie prenante devrait être informée (question 5) ?
- Vos parties prenantes comprennent-elles l’impact que ce problème aura sur la valeur attendue de l’architecture (question 6) ?
Je sais, ce sont des questions de gouvernance difficiles. Toutes posées à la architecte d'entreprise, à propos du architecture.
Tout cela parce que la question 1 a fait voler en éclats l'approbation de l'objectif par les parties prenantes.
Revenons à la Guide pratique tableau 4 — approbation des parties prenantes interférer avec une organisation par ailleurs prospère Pour obtenir davantage, ils étaient prêts, en contrepartie, à travailler et à prendre des risques. Les calculs ont démontré une valeur suffisante après prise en compte du risque.
La première question est très ouverte. Elle demande s'ils respectent l'architecture. C'est une question importante. Elle sera liée à tout. préoccupation Chaque partie prenante avait son mot à dire. Cela inclura :
- Apporte-t-on les bénéfices escomptés ?
- Est-ce que cela correspond à l'effort attendu ?
- Leur mise en œuvre est-elle durable ?
- Ont-ils respecté toutes les contraintes ?
Chaque fois que nos équipes de développement interprètent mal l'architecture, c'est un regret. Peu importe la raison, le résultat est le même : notre client n'obtiendra pas ce pour quoi il a payé.
C'est pourquoi architecte d'entreprise Il faut reprendre le travail et formuler une recommandation à la partie prenante concernant son objectif. Il ne s'agit pas d'une discussion avec les responsables de la mise en œuvre sur les choix de mise en œuvre, ni d'une négociation avec le chef de projet sur le périmètre du projet. Il s'agit d'une recommandation à formuler à la partie prenante déçue.
Je déteste ces recommandations. Je déteste devoir me rendre à l'évidence : même pas… mes implémenteurs pourrait concrétiser mes idées. Si mes implémenteurs N'ayant pu concrétiser l'idée, je suis confronté à la dure réalité : mon analyse était erronée et j'ai mal conseillé mon interlocuteur.
Cette situation est très différente de celle où mon actionnaire ne suit pas ma recommandation. Je dois donc en conclure que je n'ai pas compris les contraintes, la tolérance au risque ni les priorités de la partie prenante.
Quand mon implémenteur Si le résultat n'est pas à la hauteur, c'est soit que j'ai mal communiqué, soit que mon analyse n'était pas à la hauteur de mes exigences.
Conclusion sur l'intégrité du contrat ininterrompu
Nous voici au cœur de architecture d'entreprise basée sur les meilleures pratiques. Pourquoi cette profession existe-t-elle ? Pourquoi des systèmes complexes comme celui-ci ? Cadre TOGAF existent. Pourquoi nous utilisons modèles formels. Pourquoi nous travaillons dur pour construire feuilles de route d'architecture. Pourquoi nous nous efforçons tant de réduire les risques liés aux initiatives de changement.
Architecture d'entreprise C'est difficile. C'est complexe. Accompagner le changement a des répercussions concrètes sur notre organisation.
Chaque fois que je dois formuler une recommandation de non-conformité, nous sommes dans une situation délicate. Le projet de mise en œuvre a engendré des pertes financières considérables, et continue d'en engendrer davantage. Le temps réduit drastiquement la valeur ajoutée attendue. Je suis sous pression.
Voilà pourquoi TOGAF Phase G stress architecte d'entreprise Engagement. Pourquoi rédigeons-nous un engagement ? contrat d'architecture en termes que les responsables de la mise en œuvre peuvent suivre. Nous effectuons gouvernance de la mise en œuvre Des analyses précoces dans le but de déceler les problèmes au plus tôt.
Chaque prise précoce coûte moins cher qu'une prise tardive. La prise précoce est une constante dans TOGAF. Phase A tests permettant de vérifier si une idée peut franchir des obstacles minimaux ? Phase E feuille de route dynamique il regorge de VRP offrant des étapes de réduction des risques, d'arrêt et de pivot. Phase G Cela nous incite à procéder à un examen lors de l'initiation, de la conception et des phases majeures. En dernier recours, à mise en service.
Dès que nous constatons un manque à gagner, notre réaction est toujours la même. Voici une recommandation sur la marche à suivre : redoubler d’efforts et dépenser davantage, accepter un bénéfice moindre ou abandonner le projet. Abandonner à Phase A nettoie le tableau blanc. Phase G Nous nous débarrassons de choses que nous venons d'acheter. Des choses qui, nous l'espérions, amélioreraient les choses. Des choses dont chacun espère secrètement qu'elles pourront encore les améliorer.
Voici mon défi cette semaine. Examinez les directives de votre architecture. Que faites-vous pour les aider ? vos implémenteursLes règles du jeu — comment gagner et ce qui est interdit — sont-elles claires ?
Pour aller plus loin, pouvez-vous retracer la valeur de votre spécifications d'architecture sont-ils appliqués ? Lorsque vous avez établi un modèle, avez-vous inclus le morceau difficile dans Modèle de navigation pour permettre le calcul de la valeur ?
La semaine prochaine, nous passerons au architecture d'entreprise domaine. Étant donné le architecture des systèmes d'information doit permettre architecture d'entreprise, Nous devons la connaître. Notre architecture d'entreprise a de multiples utilités. Premièrement, elle définit les contours du contexte de l'entreprise. Deuxièmement, elle indique où et comment mon organisation crée de la valeur. Enfin, elle définit les limites du changement. Modèles de capacité Elles jouent un rôle particulier dans la définition des limites et la nécessité du changement. Je pense que ce sera une série divertissante.
Passez une excellente semaine !
Comme toujours, vos commentaires et questions sont les bienvenus.
Salutations,
Dave
Dave Hornford
Conexiam