Qu'est ce qu'il faut savoir pour être un bon architecte?
Version imprimable
Qu'est ce qu'il faut savoir pour être un bon architecte?
Bonjour,
De l'expérience.
Olivier
Moi j'aurai dit de la passion et un sens du travail. Mais Nathieb s'y connaît sûrement mieux que moi ;)
De l'expérience, de la curiosité, de l'implication
Bonjour,
Je parle par expérience de mon expérience, pas beau ça :ccool:.
Il ne suffit pas de bachoter, même si c'est la base de la curiosité de notre métier, mais de faire ou de faire faire, voir de défaire.
Je cotoie trois type de profils d'architectes
Les expérimentés du jargon, limites commerciaux (bagage Technico commerciaux):boulet:
Les experts (pas ceux de miami):ccool:
les, "connais pas, ça existe ? ah ouais ?".8O au moins ils avouent
Dans tout les cas, j'ai cotoyé des personnes qui dans le monde informatique, m'auront transmis l'humilité.
Mais force est d'avouer qu'après moultes projets, Administration de système (Linux, Aix , Win..., Sun etc ... ) et développements, je me sens plus apte à conceptualiser ou organiser une architecture, mais bon cela dépend encore de la taille des projets.
On pense pas de la même façon une architecture dans une PME ou dans une grande entreprise, ce sont deux mondes différents, voir deux échelles différentes.
J'avoue qu'une double compétence admin/dev est aussi un plus.
Après, effectivement cela dépend de la spécialisation et des centres d'intérêts ;)
mais là c'est perso.
Olivier
Merci pour vos réponses, au fait j'ai près de 5 ans en dev et j'aimerais m'orienter en architecture SI et je veux en parler à ma hiérarchie et j'aimerais avoir des pistes au delà de l'expérience pour bien assurer mon prochain poste.
je ne vois pas bien le rapport entre un expérience en dev et de l'architecture de SI ....Citation:
Envoyé par friedamichelle
au fait qu'est ce que vous appelez un architecte?
Bonjour,
Cela peut répondre à ta question
http://www.clever-age.com/veille/cle...chitectes.html
Olivier
Merci bcp cet article répond à mes questions.
Citation:
Envoyé par nathieb
oui..Citation:
Envoyé par nathieb
Quoique la distinction fonctionnel / applicatif / logiciel est dérivée des modèes WaterFall, et pose en général de très graves problèmes dans les gros projets...
Bonjour,
Peux tu préciser ton affirmation.
Olivier
disons que si l'équipe est grosse et les 2 perosnnes par exemple fonctionnel et applicatif sont 2 personnes différentes, les pensées, architectures, et priorités vont diverger assez vite.
Exemple : pour les trucs comme ce qu'avait lancé Douste-Blazy (mais l'AP plus de 15 avant) et qui continue (à coûter des milliards), l'architecte applicatif va vouloir un module sécurité qui va dépendre de la catégorie de l'utilisateur, un architecte fonctionnel va le voir comme "un module", et du coup cela aura une influence non négligeable sur la vision de l'arborescence, et généraera des discussions d'une part longues, et d'autre part avec un résultat vraisemblablement "entre 2", donc satisfaisant ni pour l'un ni pour l'autre..
D'autre part, un architecte fonctionnel peut, si le projet est gros et long, devenir "obsédé" par les relations dans la BD, par exemple, et oublier la partie "applicative"...
J'ai vu ces 2 exemples.. conduisant à des catastrophes.. de quelques dizaines de millions d'euros...
mais je suis entièrement d'accord avec ton premier post de réponse :D
Bonjour,
Je suis d'accord avec toi, si on oublie tout l'aspect technique, fonctionnel et finance, cela se résume a des relations humaines.
En fait, un prof me disait, il y a longtemps, et cela ma marqué, tu prends des tronches dans chaque domaine, incapable de communiquer ou de faire des concessions, t'es sur à 99% de l'échec.
D'ailleurs, par expérience, quel que soit la méthodologie V, XP ou SCRUM
c'est l'implication qui peut tout changer, et une pointe de génie parfois ;)
olivier
D'où le rôle important de l'architecte intégrateur qui encadre les autres architectes.
@Souviron34 : si ce sont les catastrophes auxquelles je pense et qui ont fait la une des journaux, ces projets étaient trop gros et complexes même si l'idée à la base était bonne.
Pas seulement... Un certain nombre ont fait la une de journaux en France, mais d'autres dans d'autres pays aussi..Citation:
Envoyé par Makichan
Et j'ai travaillé dans un tel projet, justement à essayer de le sauver... (60 personnes, 15 ans, 80 millions, 2 millions de lignes de code).. Mais aussi dans d'autres qui n'ont pas atteint la presse (100 personnes, 150 millions, 10 ans, 3 millions de lignes...)...
Outre la taille beaucoup trop grande des équipes, et le cycle en V, la "séparation des visions" induite par une telle séparation des rôles est une catastrophe en gestation quel que soit le projet...
Car souvent dans ces cas les responsabilités, de même que les équipes, sont //, et il faut des "réunions de coordination", etc etc, qui font que, outre la perte de temps, et l'espacement des réunions, les "chemins de pensée" ont le temps de s'imprégner..
On peut avoir des projets très gros et très complexes , et les réussir...
Ce que je m'évertue à faire passer comme message dans les discussions concernant ces sujets est simplement que, par expérience et réflexion, il m'apparaît évident que la manière "industrielle" de l'industrie informatique de se structurer et de diviser le travail ne peut, de manière générale, qu'aboutir à des échecs pour de tels projets...
La division du travail est calquée sur les chaînes de production, sauf que les chaînes REPRODUISENT un prototype, alors que une équipe informatique est l'équivalent du bureau d'études...
L'emploi de (grosses) SSII renforce encore cette fragilité annoncée, aucune n'ayant intérêt à ce que le projet se termine...
peux-tu m'en dire un peu plus sur le cycle en V ?
Pour les grosses SSII, il en va de leur réputation, donc elles n'ont aucun intérêt à ce que le projet ne soit pas mené à terme parce qu'il y a d'autres contrats à la clef.
Par contre je veux bien croire qu'il y ait des dépassements de coûts et de temps si le client demande des modifications en cours et que le projet soit + long au final.
Simplement que le formalisme et la rigidité du cycle en V , ainsi que le taylorisme associé, a d'abord l'inconvénient majeur qu'il faut TOUT modéliser avant de commencer...Citation:
Envoyé par Makichan
Et justement lorsqu'on s'attaque à des projets très complexes, il est illusoire de vouloir tout modéliser "à frod".
D'autre part, on est pris avec les décisions du départ à cause du cycle.
Enfin, le tailorisme et les rôles ne peuvent justement pas prendre en compte que ce soit les évolutions ou nouveautés techniques, les modifications pratiques, ou légales, etc de manière simple et efficace..
Pour exemple, un tel projet décide qu'il lui faut une BD, et un dictionnaire de termes...
Il définit une certaine architecture.
Au bout d'un certain temps, vu que l'architecture et l'analyse de base est figée, l'effort finit par se concentrer sur la BD..
Dans l'exemple que je donnais plus haut, l'achitecte , qui était pourtant le même depuis le début du projet, était incapable, au bout de 15 ans, de me résumer ce qu'était censé faire le logiciel. Le mur de son bureau était couvert du schéma de la BD et des relations entre les tables, et c'était ce qu'il me montrait...
Mais il a fallu que je m'adresse au Marketing pour savoir ce que ça devait faire...
Sur un autre plan, à un moment donné nous devions faire une démo dans une autre langue... L'organisation du travail a provoqué une évaluation de délai de 3 à 4 semaines pour la traduction du fameux "dictionnaire" (équipe sépcialisée dans la création et la maintenance de ce truc). L'expert avec lequel j'étais en binôme est parti un weekend chez lui, avec son PC personnel et son logiciel de reconnaissance vocale, et est revenu le lundi matin avec l'ensemble du dictionnaire traduit... :aie:
Pas évident..Citation:
Envoyé par Makichan
Vu qu'en général dans ces très gros projets, elles sont un acteur essentiel (que ce soit interlocuteurs des boîtes ou des gouvernements ou administrations), elles savent qu'on continuera à les prendre.
Et entre louer 100 personnes pendant 10 ans et ne les louer que sur 5 ans, ya pas photo de leur point de vue...
Je ne sais pas si tu parlais de ça, mais le DMP par exemple, commencé vers 1984, n'est toujours pas en vue avant mini 10 ou 15 ans...
En 1996 le Canard évoquait environ 2.4 milliards de francs par an pour ça, et pour n'arriver à rien de tangible.. Depuis 2004 et Douste-Blazy c'est encore pire, puisque c'est en partie européen, avec en particulier l'Allemagne...
Et quand on regarde qui travaille dedans, CQFD...
Merci pour ta réponse
C'est un peu contradictoire, tes 2 parties...Citation:
Envoyé par nathieb
Moi, ce que m'avait dit l'architecte dont je parlais dans le post au-dessus c'était :
"Je veux faire quelque chose d'extraordinaire avec des gens ordinaires"
Ce à quoi je lui avais répondu :
"Tu vas à l'échec : pour faire des choses exraordinaires il faut des gens extraordinaires".
(PS: et ils ont été à l'échec. La boîte a coulé et 80 millions d'argent du contribuable sont partis à la poubelle)