Qu'est ce qu'il faut savoir pour être un bon architecte?
Qu'est ce qu'il faut savoir pour être un bon architecte?
Bonjour,
De l'expérience.
Olivier
Architecte destructurant,
be cool, be free
Il nous reste Debian bien sûr
Moi j'aurai dit de la passion et un sens du travail. Mais Nathieb s'y connaît sûrement mieux que moi
- So.... what exactly is preventing us from doing this?
- Geometry.
- Just ignore it !!
****
"The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
***
Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019
De l'expérience, de la curiosité, de l'implication
L'urgent est fait, l'impossible est en cours, pour les miracles prévoir un délai.
Bonjour,
Je parle par expérience de mon expérience, pas beau ça .
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)
Les experts (pas ceux de miami)
les, "connais pas, ça existe ? ah ouais ?". 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
Architecte destructurant,
be cool, be free
Il nous reste Debian bien sûr
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.
Bonjour,
Cela peut répondre à ta question
http://www.clever-age.com/veille/cle...chitectes.html
Olivier
Architecte destructurant,
be cool, be free
Il nous reste Debian bien sûr
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Bonjour,
Peux tu préciser ton affirmation.
Olivier
Architecte destructurant,
be cool, be free
Il nous reste Debian bien sûr
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...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
mais je suis entièrement d'accord avec ton premier post de réponse
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
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
Architecte destructurant,
be cool, be free
Il nous reste Debian bien sûr
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..
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...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
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...
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...
Pas évident..
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...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Merci pour ta réponse
C'est un peu contradictoire, tes 2 parties...
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)
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager