Wiki source for Blog20081028ArchitecteSIorTechiqueOrNotToBe


Show raw source

Quelqu'un (Erwyn sur jabber) m'a demandé s'il pouvait trouver un architecte SI ou un architecte techique sur Grenoble IRL, moi je veux bien aller au ski cet hiver ;-)

===des parcours différents entre Architecte technique et Architecte SI===
l'architecte SI est principalement issu des études
~- il a une bonne compréhension des besoins utilisateurs et du métier
~- il a une très bonne vision des processus et des systèmes techniques mis en oeuvre pour y répondre
~- il a quelques notions des outils du marché
~- il sait estimer la complexité en terme de développement et de déploiement
l'achitecte technique a une bonne connaissance du fonctionnement de la production
~- le projet est ponctuel, la production doit assurer une pérennité sur 3 ans et un bon fonctionnement du point de vue utilisateurs (performances, sauvegardes, disponibilité, confidentialité, intégrité)
~- il arbitre sur les coûts projets et d'exploitation (automatisation vs opérations manuelles, industrialisation)
~- montées de version et tenue à la charge, maintien des engagements de service

===des points communs===
~- une bonne vision technique et métier
~- la volonté que les projets soient faisables et exploitables
~- un recours à une bonne identification des besoins et des possibilités de mise en oeuvre, dans le respect des canons de l'état de l'art
~- une vision pragmatique de ce qui est faisable, ce qui est réalisable et ce qui serait bien (une sorte de monde idéal dans le réel)

===des objectifs différents===
~- l'architecte SI cherche à répondre aux utilisateurs
~- l'architecte technique cherche à répondre aux utilisateurs
~- l'un cherche à mettre en oeuvre ce qui existe, avec parfois quelques aspects novateurs nécessitant une formation des différentes entités support
~- l'autre cherche à mettre en oeuvre ce qui est faisable et acceptable, par rapport à ce que savent faire les entités support : l'estimation de la complexité (se traduisant en coûts et délais) en découle directement. La priorité est l'exploitabilité à court terme, ce qui n'empêche pas de proposer des améliorations.
~- l'un est dans la définition du besoin, l'autre dans la mise en oeuvre

===Architecte SI===
~- souvent issu des départements études, il maîtrise l'intégration de projets complexe (développement et progiciel) et la création d'un catalogue de services répondant aux besoins utilisateurs
~- focalisé sur les besoins utilisateurs, il estime la complexité des projets par leur impacts sur les différents composants du SI
~- attaché à l'état de l'art, il préconise les solutions permettant de répondre au besoin, dans des versions novatrices si nécessaire
~- sa vision globale lui permet de donner une cohérence sur les versions majeures et la coordination nécessaire au niveau des directions de projet
~- il a son mot à dire sur les échanges inter-applicatifs et proposer des solutions d'interconnexion
~- la compréhension du besoin fonctionnel permet d'avoir une vue de bout en bout sur les composants du SI
~- l'état de l'art pousse aux applications client léger (diminuer l'impact de déploiement aux serveurs) et aux traitements au fils de l'eau (et non batchs ou horaires)

===Architecte technique===
~- souvent issu de la production, il maîtrise les impacts sur l'exploitation, la formation des administrateurs, est féru de technologies ayant une valeur ajoutée en terme d'exploitation (sauvegardes, supervision, capacity planning, parfois métrologie...) pour assurer les niveaux de services nécessaires pour les utilisateurs
~- focalisé sur les besoins utilisateurs, il estime la complexité des projets par leurs écarts à un catalogue de solutions maîtrisées, il arbitre entre un mode standard ou un mode projet)
~- attaché à l'état de l'art, il préconise les solutions maîtrisées dans les versions validées permettant de maîtriser les risques projets (version novatrice, version éprouvée) tout en poussant au passage aux dernières versions supportées pour tous les composants (et résorber l'obsolescence).
~- les termes de PRA, PCS, DICT sont au coeur des solutions qu'ils proposent, conformes au cycle de développement retenu et aux directives de sécurité de l'entreprise
~- il a à coeur de proposer des solutions exploitables et maintenues, et choisit les matériel compatibles avec les choix du projet répondant aux exigences de performance identifiées
~- il a son mot à dire sur les échange par le choix de protocoles adaptés et supportés
~- la tenue en charge fait partie du capacity planning, généralement évalué pour les 3 ans à venir (une analyse comportementale de l'application permet d'arbitrer entre les données manipulées et la complexité des traitements pour déterminer les priorités en terme de performances)


===parcours et salaire===
~- l'expérience est la plus-value de l'architecte qu'il soit SI ou technique, c'est la garantie d'une bonne évaluation des impacts et de la mobilisation des équipes impliquées
~- le fonctionnement d'un intégrateur ou d'une TMA n'a de mystère ni pour l'un ni pour l'autre et il peut assister les chefs de projets à encadrer ses équipes de développement dans un réajustement de l'estimation des risques, en vue de leur réduction et trouver les compromis nécessaires à l'intégration dans le SI.
~- tant l'architecte SI que l'architecte technique savent adapter leur discours pour répondre à des utilisateurs ou MOA, notamment lors des études de faisabilité permettant d'estimer les coûts et délais.
~- 10 ans d'expérience et la connaissance d'au moins 3 intégrateurs sur une 20aine de projets assurent une diversité en terme de technologies, de types de projets ou de risques métier. La connaissance de projets court terme (chefs de projets) et longs termes (directeur de programme) est un plus.

===architecte projet et architecte technique===
Le terme d’architecte est très galvaudé (architecte SI, architecte applicatif, architecte projet, architecte technique), il y a aussi des spécialités comme architectes systèmes ou réseau ou telecom.
~- architecte applicatif ou architecte technique même si elle est plus orientée applicatif que technique en tant que tel (le volet relation avec la production est un peu occultée)
~- Un architecte projet intervient par exemple dans une réalisation au forfait et aura dans ses prérogatives :
~~- mise en place du process de livraison,
~~- mise en place des environnements (développement, intégration, recette, préproduction… voire approvisionnement des serveurs/matériels nécessaires au projet),
~~- choix des bibliothèques/outils de développement, parfois un rôle supplémentaire de chef de projet technique et d’encadrement des développeurs sur le volet technique
~- la distinction entre les deux est importante :
~~- lorsque l’architecte technique est en relation avec un intégrateur, l’architecte technique n’a pas la main sur les développeurs et peut plus difficilement orienter les choix : il se concentre sur l’intégration du projet dans le SI mais n’oriente que peu les développements en tant que tel
~~- un architecte technique va avoir dans son portefeuille une dizaine de projets à différents niveaux du cycle projet, selon l’organisation il les suit jusqu’à la réalisation du dossier d’architecture ou parfois jusqu’à la mise en production pour assister le chef de projet
~~- un architecte projet va se limiter à 2-3 projets au maximum en parallèle lorsque ce sont des équipes différentes à gérer, son rôle va être de capitaliser sur le re-use et les bonnes pratiques

===Savoir se positionner en entretien===
Être conscient des activités de l'architecte
~- analyse d'obsolescence / promotion des produits supportés dans l'entreprise (référentiel), gestion des montées de version afférentes
~- préciser son implication dans cycle projet : au sein de l'équipe de développement ? en amont ? en aval (sur les projets en maintenance par exemple)
~- contribution aux revues de patrimoine / évolutions techniques d'un SI, avec un ensemble de chefs de projets, savoir proposer des scénarios compatibles avec les cycles projets
...

Savoir se positionner par rapport
~- aux projets / études / urbanistes
~- experts / sécurité / réseau
~- et par rapport à la production

Compétences
~- capacité de modélisation / sensibilité aux volumétries et analyses de risques afférentes
~- connaissance du fonctionnement des projets, savoir donner quelques exemples de projets où l'anticipation au moment opportun a permis de réduire les risques et coûts
~- capacité à interagir avec des MOA en assistance technique d'un chef de projet et savoir justifier les choix techniques pour atteindre les niveaux de services demandés
~- certification CMMI / ITIL ? pas forcément besoin de les avoir obtenues, mais être conscient que cela va dans le sens des bonnes pratiques

Savoir citer quelques livrables classiques de l'architecte technique :
~- étude de faisabilité
~- dossier d'architecture
~- produire des études de performances en synthétisant les rapports système, DBA, réseau
~- critères de choix de produits / problèmes classiques rencontrés sur projets : exploitabilité, support, coût, interopérabilité, industrialisation, ...

===Méthodologies et cycle de vie===
http://blog.aliston.fr/2010/07/maitriser-les-risques-de-votre-projet-crm-grace-aux-methodes-agiles/ bon schéma + définition sprint (organisation temporelle) et scrummaster, manque liste de livrables précise
[[http://www-igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/process.php]] déroulement d'un sprint
[[http://www-igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/preambule.php#method]] manifeste agile (peu de livrables, l'important étant un produit fonctionnel)
[[http://www-igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/presentation.php#fonctions]] un schéma sur le sprint
[[http://www-igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/artefacts.php]] burndown chart : tableau de présentation des résultats atteints
[[http://www-igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/deepscrum.php#analyse]] défauts de la méthode scrum (peu de documentation)
http://www.aubryconseil.com/post/2007/07/17/262-glossaire-scrum un glossaire des termes
http://www.aubryconseil.com/post/2007/07/18/263-l-agilite-au-detriment-de-l-architecture l'architecture est au cœur de l'agilité, à démontrer sa robustesse et sa pertinence

http://en.wikipedia.org/wiki/Architectural_pattern
http://martinfowler.com/eaaCatalog/ architectural patterns, principalement pour de l'architecture fonctionnelle et logicielle
http://books.google.fr/books?id=e_w99YfrcgkC&pg=PA297&lpg=PA297&dq=%28TADG&redir_esc=y#v=onepage&q&f=false TOGAF 9
http://pubs.opengroup.org/architecture/togaf7-doc/arch/p4/patterns/patterns.htm

http://www.opensecurityarchitecture.org/cms/en/library/patternlandscape/189-0802pattern-003 catalogue de patterns
http://www.opensecurityarchitecture.org/cms/en/library/icon-library icônes en SVG pour schémas d'archi

http://en.wikipedia.org/wiki/Treasury_Information_System_Architecture_Framework

http://www.infra-repository.org/oiar/index.php/Main_Page

===Des points de vue===
http://architectesi.blogspot.com/ (je suis d'accord avec Thibault et Jean-Michel, les connaissant tous les deux :D)
http://www.opensecurityarchitecture.org/cms/en/library/threat_catalogue

===Quelques sujets d'échanges entre architectes===
~- utilisation de inkscape en remplacement de Visio ? dia est-il suffisant dans certains cas ?
~~- lien pour Inkscape à fournir, dia et le svg peuvent aider
~~- http://mageiacauldron.tuxfamily.org/Blog20130102ReplacingVisioByInkscape
~~- connecteurs, cela est un début (+ boîte avec texte inclus)
~- images libres pour décrire un SI, http://openclipart.org (retrouver tags)
~~- quelques tags existants, beaucoup d'images
~- comment générer un dossier d'architecture technique de moins de 2 Mo avec suffisamment de schémas ?
~~- voir comment copier/coller un objet et y faire référence (si cela fait partie de la norme SVG), sinon, se limiter à objets de 25 ko (réduire dégradés ou chemins)
~- schémas types / architectures type ?
~~- oui, http://en.wikipedia.org/wiki/Architectural_pattern (à décliner)
~- gestion boîte noire / boîte blanche : description, impacts d'exploitabilité, installation
~~- notion de boîte grise : non décrite complètement, avec axes de résorption pour faire passer en boîte blanche voire libre
~- identification des différents types d'architecte, activités classiques, erreurs classiques des maîtrises d'oeuvre et MOA ?
~~- Architecte logiciel / Architecte Produit
~~- Architecte Fonctionnel / Architecte projet
~~- Architecte technique + Architecte SI + architecte applicatif + architecte infrastructure
~~- Unifier les compétences vs Urbaniste / cartographe / Urbaniste SI (pouvant descendre sur l'applicatif)
~~- sans compter les spécialités : architecte réseau, système, sécurité, JEE, stockage, etc.
~~- c'est un terme galvaudé, sans compter non plus junior, expert, confirmé, senior
~- utilisation de http://qsos.org pour générer des matrices de compatibilité ? (évolution) niveau de détail d'une CMDB
~- utilisation d'une CMDB opérationnelle pour le capacity planning
~- identification de SPOF, quand cela est-il acceptable (charybde et scylla)
~- le portefeuille de compétences d'un architecte
~- pourquoi être architecte est complexe, mais pas très compliqué ?
~- pourquoi la sécurité réussit-elle à utiliser des normes affichées, mais pas l'architecture ? (il y en a trop !?)
~~- sécurité : EBIOS, ISO 27001
~~- architecture : TOGAF, ISO 646 / 10646, JSR 168 (portlet), ISO 26000 (qui devrait avoir le Green IT dans ses normes), le 29500 et le 32000 basés sur du propriétaire non implémenté effectivement sont pour l'instant à éviter
~- retours d'expériences sur projets de haute volée (aka traités à la rache)
~- les méthodos utiles ? à quoi se former ?
~- veille technologique ou auto-formation ? glande (justification de l'accès Internet) ou temps non-facturé passé à rien faire (contexte SSII) ou un réel investissement pour son évolution (plus pragmatique et représentatif de l'activité inhérente à tout architecte)
~- avoir raison trop tôt est-il raisonnable ?
~~- non
~~- c'est le lot de tout architecte, il y a des études d'opportunité pour cela, des études de faisabilité ensuite pour l'avérer
~- anticiper c'est prévoir, alerter c'est retarder si pas de solution fournie, un vrai dilemme ?
~~- pas de dilemme, un état des lieux à l'instant t
~~- le mieux est l'ennemi du bien : faire maintenant reste améliorable par la suite (oui, plus difficilement, chut), cela s'oppose à pourquoi changer puisque cela marche ?
~- ne pas être compris sur le moment, être apprécié dans la durée ?
~- les tests de tenue en charge : comment synthétiser des recommandations hétéroclites d'experts ?
~~- s'en tenir à CPU et RAM voire un graphisme significatif s'il y en a (éviter les tableaux demandant d'être spécialiste système / base de données / serveur d'application pour être compris)
~~- ne garder que les recommandations concrètes ayant un correctif applicable et n'ayant pas d'effets de bords (ou limiter ces effets pour l'appliquer)
~~- si un architecte technique ne comprend pas ce qui lui est indiqué, comment un chef de projet le pourrait-il ?

===Sujets connexes===
http://linuxfr.org/users/lebouquetin/journaux/etre-technique-ou-ne-pas-etre-que-technique
http://cdn.themetapicture.com/media/funny-arguing-engineer-wrestling-pig.jpg :-) arguing with an Engineer is a lot like wrestling in the mud with a pig, after a couple of hours you realize the pig likes it
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki