Mise en place d'un département d'architecture


12

Un peu de contexte:

Imaginez une société de développement de plus de 200 personnes définissant finalement une équipe/un département d'architecture plus ou moins indépendant. Le portefeuille de logiciels constitué de plus de 20 «projets»/applications de différentes tailles en production a été pris en charge par les chefs d'équipe/responsables techniques, qui étaient également responsables de l'architecture des projets. En raison de la nécessité de consolider et de contrôler l'architecture et de permettre certains grands travaux de reconstruction sur l'ensemble des systèmes, en plus de l'échange de connaissances si nécessaire, l'entreprise a décidé de mettre en place un service d'architecture.

  • Quels sont les DO s et NE s d'une telle entreprise?

  • Qui sont les personnes qui composent une telle équipe d'architecture?

  • Quelles devraient être leurs responsabilités?

  • Qu'en est-il de leur champ d'application?

  • Quelles sont les stratégies de transition utiles pour l'entreprise? Comment éviter ces regards ironiques chaque fois que quelqu'un mentionne même "l'équipe d'architecture"?

  • Votre entreprise a-t-elle déjà subi un tel changement avec succès?
    Pourquoi a-t-il échoué?
    Pourquoi était-ce réussi?

C'est devrait pas une discussion sur (ce qui est très étroitement liée;) "Qu'est-ce architecutre?". Les points vraiment intéressants seraient acceptables/réalistes, peut-être même des moyens sans friction pour installer une telle équipe, sans compter bien sûr certains avertissements concernant les batailles à ne pas même commencer.

  0

Comme je l'illustre dans ma réponse ci-dessous, il n'existe pas d'équipe d'architecture _one_ pour une organisation de cette taille. Trop de sujets couvrent aussi. 24 sept.. 082008-09-24 05:44:52

+2

Presque 5 ans plus tard, je suis curieux de savoir quel chemin a été choisi, et comment il s'est avéré être :) 05 avril. 132013-04-05 03:59:57

7

Voici quelques questions qui devraient être pensé:

  • Quel est le mandat exact de l'équipe d'architecture?
  • Quel est le livrable de l'équipe d'architecture? Un cadre, des lignes directrices, une aide à la mise en œuvre ... Ou sont-ils simplement Architecture Astronauts?
  • Est-ce seulement pour les applications à venir, ou ce sera un backport?
  • Qui sera responsable du backporting? (Et nous entendons le budget ici ...)
  • Des ressources seront-elles allouées pour tester les backports?
  • Est-ce que l'équipe d'architecture a du muscle, ou la direction va-t-elle se coucher lorsque le premier groupe entamera les 4 mois qu'il faudra pour mettre en œuvre les changements ...
  • Comment allez-vous gérer les frictions entre les différents groupes de projet? et l'équipe d'architure (et il y aura des frictions?). Les opportunistes considéreront cela comme une merveilleuse opportunité de jockey pour la position ...
  • Sachez que ce sera avant tout un jeu politique ...

Mon ami, vous avez une route difficile à venir ...

La première étape est d'être très clair sur ce l'équipe d'architecture est censée réaliser. Pourquoi as-tu mis l'équipe en place?
Essayez-vous d'unifier toutes les applications, développer un cadre commun, quoi?
Quel est le mandat et la vision de cette équipe?

Quel que soit le chef de cette équipe, mieux vaut avoir des compétences interpersonnelles.
Il ne faut pas pas le être le codeur brillant qui peut siffler la chanson thème star wars et faire de légers bruits de sabre ... mais il devrait probablement être dans l'équipe dans une capacité technique.

Vous devriez probablement renseigner l'équipe avec des personnes qui connaissent la plupart des projets. Je serais méfiant de choisir tous les pistes actuelles, car cela pourrait prendre une bonne partie des connaissances des équipes actuelles. Et avouons-le, ces équipes doivent être productives tandis que l'équipe d'architecture propose ses propres livrables.


1

Question intéressante. D'abord, vous devez avoir une idée claire du problème que cette équipe d'architecture est en train de résoudre. Si vous ne pouvez pas définir clairement la "mission" de l'équipe, elle échouera et le fera avec de grandes explosions. :)

Cela étant dit, la première étape est de définir le problème que vous résolvez. Essayez-vous de suivre la technologie? Essayez-vous d'incorporer de la réutilisation du code entre les projets? Essayez-vous d'utiliser votre personnel de développement au meilleur effet possible? Il y a plusieurs raisons de mettre en place une équipe d'architecture et compte tenu de votre configuration, l'une d'entre elles pourrait être suffisante. D'après votre question, il semble que votre objectif soit de retravailler les applications existantes, ce qui constitue un bon premier pas.

Puisque vous avez déjà un groupe de prospects qui ont une bonne connaissance spécifique des applications, il serait judicieux de commencer avec eux. Réunissez-les et éliminez ce que devrait être la nouvelle architecture globale. Vous pourriez également vouloir obtenir un consultant pour aider à faciliter la conversation à ce stade. Définir les objectifs de la reprise et en sortir avec une «grande image» que tout le monde peut accepter. Après cela, je voudrais prendre une poignée de prospects et les promouvoir (remplissant les pistes du pool de développeurs) à l'équipe d'architecture. Ils vont ensuite rencontrer les prospects pour s'assurer que les choses se passent selon ce "Big Picture".

Je ne voudrais pas apporter un tout nouveau groupe de l'extérieur. Cela créerait une dynamique indésirable Us vs. Them qui n'est jamais bonne. Les étrangers n'auraient aucune idée de la façon dont les choses sont censées fonctionner ou pourquoi les choses ne fonctionnent pas comme la logique impliquerait qu'elles le devraient. :)


0

En général, faites très attention aux incitations à la fois politiques et autres associées au groupe d'architecture. il est loin d'être facile pour le 'comité de révision architecturale' (ou tout ce que vous voulez l'appeler) de devenir des obstacles au progrès. Tout ce qu'il faut, c'est aucune incitation à améliorer les choses et une incitation négative lorsque les choses changent et ne s'améliorent pas immédiatement.

réaliser que des erreurs seront commises, certaines «grandes nouvelles technologies» se révéleront être des modes à la mode, et encourager le changement et l'innovation. cela peut donner lieu à des bouleversements occasionnels à court terme et à des transformations ratées, mais cela vaut mieux que la stagnation.

et l'alternative conduit inévitablement à la stagnation; Dans des organisations plus importantes, j'ai vu des carrières ruinées parce qu'un gestionnaire croyait assez dans son équipe pour soutenir leur recommandation de la nouvelle technologie jusqu'au sommet, fournir des études de cas pour le prouver et le soutenir jusqu'au bout. Lorsque la nouvelle technologie a finalement été approuvée (après presque une année de querelles politiques), le CTO (qui s'y est opposé tout le temps) a revendiqué l'innovation et a transféré le directeur à un département de backwoods. Dans un autre incident, une nouvelle technologie a été proposée, avec de nombreux exemples de succès dans le même domaine d'activité, et un comité a été formé pour étudier la question. Cinq ans plus tard ils étudient toujours le problème, et rien n'a été fait


1

"Architecture" dans ce contexte en soi ne signifie rien. Cela signifie "experts sur des sujets transversaux". Chaque fois que vous avez une "équipe d'architecture", vous aurez une équipe transversale qui fournira des services pour de nombreux projets.

Comme indiqué par les réponses précédentes, vous devez savoir quels sujets un tel "département d'architecture" devra traiter.

Maintenant, voici un exemple d'organisation d'équipes d'architecture basée sur plusieurs sujets:

  • affaires et l'équipe d'architecture fonctionnelle: écrit de nombreuses spécifications liées à l'entreprise et vérifie l'alignement entre l'application existante et flux de travail fonctionnel, afin de compléter une cartographie cohérente d'application. Application Architecture équipe: fournit la cartographie, mais décide également de la façon dont les spécifications fonctionnelles décidées par l'équipe Business and Functional Architecture seront organisées en applications.
    Par exemple, vous avez besoin d'un module fonctionnel pour «processus de portefeuille», mais l'équipe Architecture d'application peut décider de le diviser en un «lanceur», un «répartiteur», une interface graphique, etc.
  • équipes Architecture technique, toujours composé de:
    • équipe d'architecture d'exécution, pour tous les sujets non-affaires purement technique (exploitation forestière, KPI, cadres, ...)
    • équipe architecture de développement (évaluation de l'outil et support, étude technologique, gestion des référentiels pour le contrôle de version et de configuration)
    • OA (Operational Architecture) pour rendre un environnement "exécutable" (c'est-à-dire connaître les bons processus, les bons serveurs et les bons réseaux pour déployer votre système soit pour homologation soit pour production.)

Vous voudrez peut-être ajouter une équipe logistique pour toute la gestion du serveur et des réseaux, avec les tâches de stratégies de sauvegarde et DRP. Et une stratégie de support basée sur un bon système de cas.

Et vous êtes prêt à partir.

Maintenant, ne pas oublier que lorsque vous commencez une « grande reprise », votre architecture fonctionnelle aura pour mission de faire respecter les cohérences aussi bien entre:

  • les projets retravaillés pour être sûr qu'ils restent dans le périmètre fonctionnel fixe
  • les hérités projets pour être sûr que leurs maintenances n'impliquent pas opposés choix par rapport à celui appliqué aux projets retravaillés.

Toute reprise dans un magasin de cette taille signifie en effet être en mesure de faire les évolutions nécessaires à l'héritage des projets en attendant la reprise pour produire les premières versions. (L'héritage ne peut pas simplement attendre et rester immobile pendant 2-3 ans de Rework)

Une grande reprise devrait impliquer trois jalon important:

  • 1/dialogue avec l'héritage
  • 2/compléter la héritage
  • 3/remplacer l'héritage

Signification tout élément donné est en effet développé trois fois! ;)

Bonne chance et bonne nuit.


0

Je pense que l'équipe d'architecture doit avoir des personnes suffisamment expérimentées pour connaître le fonctionnement interne de toutes les équipes de développement et être capable de dire Non aux demandes/lignes directrices. J'ai été dans des équipes avec de bons développeurs, mais je n'ai pas assez d'autorité et j'ai fini par suivre les cadres supérieurs de différentes équipes et j'ai produit des frameworks incompatibles.


2

L'architecture est difficile à obtenir. Les «architectes» ont besoin de puissance pour faire avancer les choses, mais ils doivent être suffisamment avertis pour ne pas abuser de ce pouvoir et s'aliéner complètement le reste de l'entreprise.

J'ai travaillé à deux endroits où des équipes d'architectes ont été mises en place - l'une a été un succès, l'autre ne semble pas si bonne. À l'endroit où il y a eu succès, c'était un environnement relativement petit où l'architecte en chef était reconnu comme chef technique, et les autres membres de l'équipe avaient d'excellentes compétences en écriture et en politique. Tout le monde a agi dans le meilleur intérêt de l'organisation. À l'endroit où cela ne fonctionnait pas très bien, les architectes représentaient clairement des factions spécifiques dans l'organisation, et ne gagnaient pas la confiance ou le respect de l'ensemble du lieu. Le résultat fut que l'on passa plus de temps à cuire des excuses pour contourner l'architecture qu'à en retirer toute valeur. Dans ce cas, la frustration s'est transformée en comportements passifs/agressifs et autres comportements antisociaux.

Je pense que les autres questions que vous posez sur la portée/les responsabilités/la transition sont toutes remplies par «ça dépend». Cela dépend de l'entreprise, des gens, de l'argent et du calendrier.


0

Vous devez travailler dans les scénarios d'entreprise A) et B)

A) Que faire si vous ne définissez pas vers le haut, à savoir ne font rien:
Les estimations de la reprise sur les coûts d'entretien allant

B) Vous configurez ensuite:
Perturbation des livrables à court terme, due au détournement des ressources.
Plusieurs produits risquent d'être désavantagés à court terme.
Coûts de la main-d'œuvre supplémentaire perçue.
Qui signaleront si les produits en s'affaibli par l'exercice (performance ou inflexibilité perçue)

Suivant Voir les équipes de produits à façon même exercice, comparer les résultats.

Si vous le justifier, voici deux itinéraires que j'ai vu:
1. Choisissez un produit phare pour conduire l'architecture et ajouter des ressources à ce projet.
Préparez-vous à ajouter plus de ressources, et soyez patient sinon le produit principal souffre.
Vous risquez la division avec cette route, cela fonctionnait lorsque le produit principal représentait 40% du chiffre d'affaires.
2. Démarrer une petite équipe, tirée des discussions les plus prometteuses qui ont eu lieu en interne, intégrer progressivement la nouvelle architecture dans chaque produit.
Weave cette équipe travaille dans le travail des produits.

Certaines questions pour vous de regarder:
1. Comment bientôt vous devez réaliser la convergence de l'architecture pour obtenir le bénéfice de l'entreprise.
2. Qui sont les membres de l'équipe qui parlent déjà de la convergence de l'architecture, et demandent/suggèrent-ils son importance, vous avez besoin de cette question sur le «back burner» pour 80% de vos chefs d'équipe.

Que ne pas faire
* Location à des experts de l'extérieur (sauf si vous êtes dans un vrai bordel maintenant)
* Donnez après quelques mois, c'est à long terme.
* Modifier tous les projets à la fois.
* Commencez jusqu'à ce que vous ayez un noyau de trois qui peut rendre cela possible.
* Laissez le département d'architecture devenir une plus grande qu'elle ne doit être
* Que ce soit perçu le département d'architecture résoudra les équipes de produits problèmes
* Que tout produit semble être « en attente de la nouvelle architecture »
* Let le département d'architecture "définir tous" ou avoir une portée de fluage
* Forcer tous les produits dans l'architecture, certains ne peuvent pas s'adapter (par exemplepas développé dans le même pays)

Que faire:
* Armé d'une bonne justification de première question obtenir la haute direction d'acheter et se demander le produit équipes de signaler des progrès
* Faire étape changements de l'alignement du produit par rapport à l'architecture
(Voir justification de la poing ensemble de questions)
* Avoir une carte routière pour tous les produits pour converger ou non.
* Pensez à ce que l'architecture de base offre et qui maintient ses objets
* Permettre aux équipes de produits pour contribuer à la base en termes de les caractéristiques, les codes et l'entretien de base
* trainig d'installation sur la façon d'utiliser le travail de l'équipe d'architecture pour nouveaux arrivants et équipes existantes


0

L'architecture seule pourrait transformer les gens en astronautes/zombies. Donc, ils devraient certainement avoir un code à faire, même si c'est un prototypage de base. En fait, le succès de leurs prototypes doit être facteur de révision définitive.

Ils devraient donner des présentations mensuelles/des blogs fréquents qui suivent leur travail, afin que les autres membres de l'organisation puissent apprendre.

Il devrait y avoir des objectifs académiques comme être familier avec certaines plates-formes/outils/livres et philosophies de conception. Ils devraient avoir le temps de poursuivre de nouveaux outils/projets/responsabilités dans des projets existants s'ils en ont envie. Ils auraient la responsabilité de faire au moins 3 à 4 révisions de code de modules critiques et de proposer des directives de style de code. Ils auraient la responsabilité d'examiner les conceptions de bas niveau au moins des modules clés.

On devrait leur donner du temps libre en tant qu'individus ou en équipe pour construire quelque chose qu'ils pourraient juger utile. Ils devraient avoir la possibilité de renoncer à l'architecture et de retourner au travail régulier s'ils le souhaitent sans pénalité.

Ils devraient avoir les informations sur ce qu'il se passe dans tous les projets en cours d'exécution dans l'organisation. Au moins un projet doit être suivi de près afin qu'ils puissent informer leurs pairs de ce qui se passe ailleurs. Cela peut éventuellement être le projet dans lequel ils effectuent des révisions de code et autres.

Ils devraient avoir une personne très technique comme gestionnaire.

Les architectes devraient passer d'un projet à l'autre dès qu'ils connaissent très bien l'un d'entre eux, et être autorisés à suivre le prototype qu'ils suivent en travaillant avec le projet original.

Avoir au moins un but réel (comme consolider tous les points communs entre les projets en une seule bibliothèque) chaque 1 année

Investir du temps et de la formation pour faire en sorte que les architectes ne reçoivent pas l'ego lié et la conduite assez professionnelle. La résolution des conflits et d'autres formations non techniques ainsi que le budget pour les réunions techniques et les formations seraient également nécessaires.


0

Considérez-vous de lire/acheter cet article de l'ACM: The Software Architect. Il existe plusieurs références disponibles et l'auteur est exceptionnellement lucide sur un sujet aussi diffus. Il ne répondra pas directement à vos questions, mais l'article concentrera votre stratégie.

La meilleure réponse à votre question fait un bon point: Concentrez-vous sur les compétences non techniques et définissez des objectifs. J'ajouterais une compréhension profonde de la façon dont les choses se font dans votre organisation.