Les architectes d'applications doivent-ils écrire du code?

Question

C'est une question souvent posée, qui a des vues sur les deux côtés. Ceux qui sont en faveur d'argumenter:

• Pour la conception d'un système pour des codeurs, vous devez comprendre comment le code (et codage)
• Vous ne pouvez pas concevoir un système sans être au courant de ce qui se passe au niveau du sol
• L'Architecture n'est pas seulement à propos de larges coups de conception, mais sur l'adaptation à l'évolution des besoins au niveau du code

d'autre part,

• L'Architecture est d'un haut niveau de rôle et ne doit pas être préoccupé par la mise en œuvre de détails
• Le codage est une détaillé orienté, les chefs-bas funtion qui est en contradiction avec la gestion des risques, la vision large de la nature de l'architecture
• L'Architecture est au sujet de technique de gestion du risque et non pas de la mise en œuvre
• L'Architecture est une question de leadership. Il est difficile de mener de derrière

Dans mon expérience, les architectes ne doivent pas passer beaucoup de temps à coder, mais doit rester en contact avec le code de base, principalement à travers le développement de la communication, de l'examen et se lève. Si vous passez beaucoup de temps à coder vous perdre de vue les enjeux de haut niveau et devenir inefficace dans la gestion des risques techniques.

Answer 1

Même si votre argument contre le codage est valable, je pense qu'il est important que l'équipe de développement vous respecte et respecte vos décisions de conception. Si vous «subissez les conséquences» de vos décisions d'architecture, elles seront beaucoup moins susceptibles de les remettre en question.

Tout le temps, je vois des architectes qui ne sont pas en contact avec le codage et dont les équipes de développement le savent. Ils ne reçoivent pas beaucoup de respect.

Answer 2

Ab-so-frickin-lutely

Il n'y a rien de pire qu'un architecte qui a perdu le contact avec la réalité.

Cela fait partie du travail de garder les pieds sur terre et la tête dans les nuages.

Answer 3

Juste pour donner mon grain de sel (et ma vision de la "architectes")

Je crois qu'il y a plusieurs types d'architecte, chacun dans leur domaine:

• d'affaires et fonctionnelle architectes: ils sont intéressés aux activités de l'entreprise et des fonctions de flux de travail, et ils devraient effectivement pas toujours le code, parce qu'ils ont de pouvoir s'abstraire de tout type de mise en œuvre, et ils doivent produire des spécifications fonctionnelles , qui quitte la solution technique ouverte.

• applicative architectes: ils divisent un domaine fonctionnel (comme "pertes et profits" l'analyse de l') dans les applications (comme "portefeuille processeur", "lanceur", de "dispatcher", "gui"). Ils n'ont pas besoin de code, mais ils devraient être ancien codeur afin d'avoir une idée claire des défis techniques qui leur architecture doit répondre. Leur principale compétence n'est pas de codage, mais l'écoute des collègues des services techniques afin de choisir la bonne solution. Ils vont alors produire des techniques de mise en œuvre qui doivent être mises en œuvre (codé).

• architectes techniques: ils sont responsables du choix et/ou la mise en œuvre de cadres techniques (ceux qui sont génériques pour toute fonctionnelle du projet, comme indicateur de performance clé, l'exploitation forestière, la gestion des exceptions), et ils doivent absolument le code (et le code), depuis leurs composants seront utilisés par toutes les autres équipes fonctionnelles.

• le développement des architectes (hey, c'est moi ;) ): en charge du développement des outils et des processus et de la technique des sondages, ils devraient le code et l'amour de codage .

Je crois donc il n'y a pas qu'une seule réponse: cela dépend de votre domaine architectural et de l'expertise: quand il s'agit de " l'application des architectes, je crois que les trois dernières catégories peuvent avoir différentes de codage de l'expérience...

Answer 4

Je pense que le rôle de l'architecture est en train de changer. Je vois de moins en moins de la tour d'ivoire architectes qui conçoivent un système complet pour les plus humbles, les programmeurs de mettre en œuvre dans une cascade de processus.

Lorsque vous faites itérative des projets de communication entre les architectes et les programmeurs devient de plus en plus important. L'architecte fait partie d'une équipe et doit être capable de gérer l'évolution des exigences et de nouvelles idées en collaboration avec les programmeurs. Dans des situations comme ça le travail d'un architecte et d'un programmeur sont plus étroitement liés. J'ai vu des équipes où la dev-conduit a pris sur le rôle des architectes livrer bien pensé à des architectures de vraiment compliqué de trouver des solutions.

edit En réponse à un commentaire
Je pense que dans la distinction entre l'application, de solutions et enterprise architect est un peu artificiel et ne correspond vraiment pas dans de nombreux cas. Rôles de sécurité de l'architecte, architecte de données, etc. donner un beaucoup plus claires disinction entre les responsabilités. Vous pouvez regarder ici pour plus de détails http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm

Par la façon dont, à partir de la lecture de votre question, j'ai remarqué que la plupart des arguments contre le codage des architectes semblent indiquer une solide structure de gestion/rôle de leadership pour l'architecte. Je pense que c'est une bonne idée de la séparation de la gestion et de l'architecture des rôles. C'est mieux d'avoir de la technique, les gens partagent leur temps entre le codage et l'architecture que de entre la direction et de l'architecture.

Answer 5

Oui. Les architectes logiciels qui n'ont pas écrit de code pendant des années perdent le contact avec les réalités de la construction d'un produit. Ils commencent à produire de grands projets avec des niveaux d'abstraction toujours plus élevés, qui semblent ne pas tenir leurs dates d'embarquement.