Autant que je sache, architecte de solutions est simplement un terme "marketing" différent de architecte d'applications. Est-ce correct ou les rôles sont-ils réellement différents? Si c'est le cas, comment?
Et oui, j'ai recherché cela à la fois sur StackOverflow et sur Google.
Mise à jour 1/5/2018 - Au cours des 9 dernières années, ma réflexion a considérablement évolué sur ce sujet. Dans notre industrie, j'ai tendance à vivre un peu plus près du bord saigné que la majorité (même si je ne repousse certainement pas les limites autant que beaucoup de gens très intelligents). J'ai été architecte à différents niveaux, des applications aux solutions, en passant par les entreprises, dans plusieurs entreprises, grandes et petites. J'en suis venu à la conclusion que l'avenir de notre industrie technologique est essentiellement sans architectes. Si cela vous semble fou, attendez quelques années et votre entreprise rattrapera probablement son retard, ou vos concurrents qui le découvriront vous rattraperont (et vous dépasseront). Le problème fondamental est que "l'architecture" n'est ni plus ni moins que la somme de toutes les décisions qui ont été prises concernant votre application/solution/portefeuille. Donc, le titre "architecte" signifie vraiment "décideur". Cela en dit long, également par ce que ne dit pas . Il ne dit pas "constructeur". Créer un cheminement de carrière/hiérarchie qui indique implicitement aux gens que "construire" est inférieur à "décider", et que les "décideurs" ne sont pas directement responsables (par la différence de titre) de "bâtiment". Les gens qui sont encore accrochés à leur titre d'architecte vont s'égarer et protester contre "mais je suis de la partie!" Génial, si vous êtes juste un constructeur, renoncez à votre titre sans signification et arrêtez de vous distinguer des autres constructeurs. Les entreprises qui insistent sur le fait que "tous les constructeurs sont des décideurs et que tous les décideurs sont des constructeurs" agiront plus vite que leurs concurrents. Nous utilisons le titre "ingénieur" pour tout le monde, et "ingénieur" signifie décider et construire.
Réponse originale:
Pour les personnes qui n'ont jamais travaillé dans une très grande organisation (ou l'ont fait, mais c'était une organisation dysfonctionnelle), "architecte" peut avoir laissé un mauvais goût dans la bouche. Cependant, il ne s’agit pas seulement d’un rôle légitime, mais également d’un rôle hautement stratégique pour les entreprises intelligentes.
Lorsqu'une application devient si vaste et complexe que traiter avec la vision technique globale et la planification, et traduire les besoins de l'entreprise en stratégie technique devient un travail à plein temps, c'est un architecte d'application. De plus, les architectes d’applications conseillent et/ou dirigent les développeurs et connaissent bien le code de leurs applications responsables.
Lorsqu'une organisation a tellement d'interdépendances d'applications et d'infrastructure qu'il lui est temps d'assurer leur alignement et leur stratégie sans être impliqués dans le code d'aucun d'entre eux, il s'agit d'un architecte de solution =. L’architecte de la solution peut parfois ressembler à un architecte d’application, mais sur une suite d’applications particulièrement volumineuses qui constituent une solution logique pour une entreprise.
Lorsqu'une organisation devient si importante qu'elle devient un travail à plein temps pour coordonner la planification de haut niveau pour les architectes de solutions et définir les termes de la stratégie de technologie d'entreprise, ce rôle est architecte d'entreprise =. Les architectes d'entreprise travaillent généralement au niveau de la direction, conseillant le bureau CxO et ses fonctions de support, ainsi que l'entreprise dans son ensemble.
Il existe également des architectes d'infrastructure, des architectes de l'information et quelques autres, mais leur nombre total représente un pourcentage inférieur à celui des "trois grands".
Note: de nombreuses autres réponses ont indiqué qu'il n'y avait "pas de standard" pour ces titres. Ce n'est pas vrai. Rendez-vous dans le service informatique de n’importe quelle entreprise du groupe Fortune 1000 et vous constaterez que ces titres sont utilisés de manière cohérente.
Les deux idées les plus courantes idées fausses à propos de "architecte" sont:
Ces idées fausses proviennent d'un grand nombre d'architectes qui font un très mauvais travail et d'organisations qui font un travail terrible pour comprendre le rôle d'un architecte. Il est courant de promouvoir le meilleur programmeur dans un rôle d'architecte, mais ce n'est pas correct. Ils ont des compétences qui se chevauchent mais pas . Le meilleur programmeur est souvent l'architecte idéal, mais ce n'est pas toujours le cas. Un bon architecte a = bien compréhension de nombreux techniques aspects de l'industrie informatique; a meilleur compréhension de besoins et stratégies d'entreprise qu'un développeur doit avoir; excellente compétences en communication et souvent des compétences en gestion de projet et en analyse d’entreprise. Il est essentiel que les architectes se salissent les mains avec du code et restent techniquement vigilants. Les bons font.
Fondamentalement, dans le monde des certifications informatiques, vous pouvez vous appeler à peu près tout ce que vous voulez, à condition de ne pas vous enfoncer sur les pieds d'une "vraie" organisation professionnelle. Par exemple, vous pouvez être un "ingénieur de solution certifié Microsoft" sur votre carte de visite, mais si vous écrivez la phrase magique "Ingénieur professionnel" (ou P. Eng), vous aurez des ennuis juridiques à moins que vous n'ayez cet anneau de fer. Je sais qu'il existe un titre similaire pour les "vrais" architectes, dont je ne me souviens pas, mais à condition de ne pas mentionner que vous pouvez être un "architecte de réseau certifié Cisco" ou similaire.
Il existe des différences valables entre les types d'architectes:
Les architectes d’entreprise recherchent des solutions pour l’entreprise en harmonie étroite avec la stratégie de l’entreprise. Par exemple, dans une banque, ils examineront le paysage informatique complet.
Les architectes de solutions se concentrent sur une solution particulière, par exemple un nouveau système d’acquisition de cartes de crédit dans une banque.
Les architectes de domaine se concentrent sur des domaines spécifiques, par exemple un architecte d’application ou un architecte de réseau.
Les architectes techniques jouent généralement le rôle d'architectes de solutions en mettant moins l'accent sur l'aspect commercial et davantage sur l'aspect technologique.
Non, un architecte a un travail différent de celui d'un programmeur. L'architecte est davantage concerné par les exigences non fonctionnelles ("ility"). Comme la fiabilité, la maintenabilité, la sécurité, etc. (Si vous n'êtes pas d'accord, considérez cette expérience de pensée: comparez un programme CGI écrit en C qui fait un site Web compliqué à un Ruby sur Rails implementation Ils ont tous les deux le même comportement fonctionnel; choisir un RoR architecture a quels avantages.)
En règle générale, un "architecte de solution" concerne l'ensemble du système (matériel, logiciels, etc.) qu'un "architecte d'application" travaille sur une plate-forme fixe, mais les termes utilisés ne sont pas très rigoureux, ni bien normalisés.
Il n'existe pas de définition standard des intitulés de poste d'architecte dans l'industrie. Les architectes d'application, de système, de logiciel et de solution font généralement référence à un développeur expérimenté possédant de solides compétences en conception et en leadership. L'équilibre entre la conception, la stratégie, le développement (souvent des services de base ou des cadres) et la gestion diffère selon l'organisation et le projet.
Le seul titre d'emploi "Architecte" qui a vraiment une signification différente pour moi est "Architecte d'entreprise", que je considère plutôt comme un poste de stratégie informatique.
Un "architecte" est le titre donné à quelqu'un qui peut concevoir plusieurs couches d'applications qui fonctionnent ensemble à un niveau élevé. Tout ce qui entre dans un type générique d'architecte sans un type de technologie spécifique ("Solutions", "Applications", "Business", etc.) est une expression marketing.
Il y a en fait une grande différence: un architecte de solutions considère une exigence de manière globale, par exemple, il s'agit de réduire le nombre d'employés dans un centre d'appels prenant des commandes Pizza, un architecte de solutions examine l'ensemble des composants à venir. ensemble pour satisfaire à cela, des choses telles que le logiciel de reconnaissance vocale à utiliser, le matériel requis, le système d'exploitation le mieux adapté pour l'héberger, l'intégration du logiciel IVR avec le système de provisionnement, etc.
Une application archirect dans ce scénario, quant à elle, traite des spécificités de la manière dont le logiciel va interagir, du langage le mieux adapté, de la meilleure utilisation des API existantes, de la création d’une API si elle n’en existe pas, etc.
Les deux ont leur place, les deux tâches doivent être accomplies pour respecter les exigences et dans les grandes organisations, des personnes dévouées le font. Dans les ateliers de développement plus petits, il arrive souvent qu'un développeur doive prendre en charge toutes les tâches architecturales. développement global, car il n’ya personne d’autre, je suis trop cynique pour dire que c’est un terme marketing, c’est un rôle réel (même si c’est le développeur qui le prend de façon ponctuelle) et particulièrement utile lors du lancement du projet .
Ça sonne pareil pour moi! Bien que je ne sois pas totalement en désaccord avec Oli. Je donnerais le titre d'architecte logiciel à quelques personnes choisies, mais l'expérience me dit que les personnes qui méritent le titre d'architecte logiciel ne l'utilisent généralement pas.
D'après mon expérience, lorsque je consultais chez Computer Associates, le cri du marketing était "vendre des solutions, pas des produits". Par conséquent, lorsque nous obtenions un projet et que je devais mettre mon chapeau d'architecte, je serais un architecte de solutions, car je concevrais une solution qui utiliserait un certain nombre de composants, principalement des produits CA, et éventuellement des éléments de tiers ou codés à la main.
Maintenant, je suis plus concentré en tant que développeur, je suis un architecte d'applications eux-mêmes, donc je suis un architecte d'applications.
C'est ainsi que je vois les choses, mais comme cela a déjà été discuté, il existe peu de normes de nommage.