Accéder au contenu principal

Quel est le rôle de l'architecte logiciel ?

Michael Stiefel donne dans sa présentation "Architects? We Don't Need No Stinkin’ Architects!"  une définition du rôle de l’architecte logiciel que je trouve très intéressante et pas uniquement parce qu'il l'associe à la prise en compte de l'expérience utilisateur ;)

  
La présentation est en elle-même excellente (la définition de l’abstraction en se basant sur la peinture moderne par exemple) mais je vais surtout revenir sur les points qui m’ont marqué :
  • L’architecte n’est pas obligatoirement le meilleur développeur car son rôle dans une équipe n’est pas le même.
  • Le rôle de l’architecte est de transformer la vision de l’expérience utilisateur en une abstraction correcte : l’architecture du logiciel. L’expérience utilisateur dépasse le domaine de l’UI et doit couvrir l’ensemble du logiciel.
  • Il insiste sur le fait que prendre en compte la facilité d’utilisation permet de pousser l’unité du design et son intégrité conceptuel ou, dans l’autre sens, une intégrité conceptuelle portée par l’architecte permet une unité du design et est vecteur de facilité d’utilisation. C'est d'ailleurs un des meilleurs points d'une vision UX dans le cadre du développement.
  • L’architecte doit avoir une vision holistique du projet et tenir compte de l’ensemble des besoins: performance, scalabilité, coût, sécurité, robustesse, facilité de déploiement, workflow...
  • L’architecte est l’intermédiaire entre les personnes du métier et les « technologistes ».
  • L’architecte doit aider le métier à comprendre les implications techniques d’une story et, pour cela, il doit s’aider du contexte. Le contexte permet de se trouver les bonnes réponses en fonction du projet et de l’organisation.
  • Il met en avant que le point fort de l’architecte est de poser les bonnes questions et non pas d’avoir les bonnes solutions ce qui est le point fort des meilleurs développeurs.
 
Que pensez vous de cette vision du rôle de l'architecte ?

 

Commentaires

Posts les plus consultés de ce blog

Summary of 'Clean Architecture' by Robert C. Martin

Summary of 'Clean Architecture' by Robert C. Martin
Uncle Bob, the well known author of Clean Code, is coming back to us with a new book called Clean Architecture which wants to take a larger view on how to create software.

Even if Clean Code is one of the major book around OOP and code design (mainly by presenting the SOLID principles), I was not totally impressed by the book.

Clean Architecture leaves me with the same feeling, even if it’s pushing the development world to do better, has some good stories and present robust principles to build software.

The book is build around 34 chapters organised in chapters.
Programming paradigm After some introduction, there is an overview of three paradigm of programming:

structured programming which imposes discipline on direct transfer of controlobject oriented programming which imposes discipline on indirect transfer of controlfunctional programming which imposes discipline upon assignment

Uncle Bob tells us that each of these paradi…

Le développeur incompétent est un mythe

Sous ce titre complètement arbitraire et très clairement provocateur, je vais passer un contre pied aux derniers articles que j'ai lus sur le métier de développeur.
Par exemple :
http://patricelamarche.net/2011/05/24/lincomptence-des-dveloppeurs/ 
http://blogs.codes-sources.com/tja/archive/2011/10/04/etre-un-bon-d-veloppeur-c-est-aussi-une-question-d-attitude-personnelle.aspx 
Ça tombe bien c'est juste avant la soirée du Paris JUG sur le métier de développeur ! Et comme on se plaint que les présentateurs ne sont pas de vrais (?) développeurs, je vais en profiter pour donner mon avis.

Alors voila, d'après ces articles, un bon développeur connait ses fondamentaux.
Ok soit mais quelle est cette liste de fondamentaux ? 
Chez certains, c'est les maths et l'algorithmie pure, d'autres c'est C++ par coeur et savoir retourner une chaine de caractère en moins de 3 instructions et une seule allocation mémoire, d'autres c'est Java JEE, ses 100 jsr et frameworks in…

Behaviour Driven Development at Zenika

I have assisted to the Zenika's conference about Behaviour Driven Development given by Mauro Talevi from Agilesque.

The presentation was mainly decomposed in 3 parts : Introduction to BDD, Presentation of JBehave (the API used to do BDD in java) and return on experience about a real project.

Introduction to BDD.

BDD brings together Test Driven Development and Domain Driven Design by
- describing behaviour is a better form of testing
- describing needs from from point of view of it's stakeholder

BDD relies on the use of a specific language to help communication between the business, developers, testers, analysts and managers. It improves presentation.
Behaviours are described by scenarios with a why ? the value, a who ? the actor and the what ? the feature.
BDD introduce a grammar of steps GIVEN a context, WHEN there is an event, THEN produce an outcome AND do other steps.
BDD offers step parametrisation, aliases for changing language or tabularisation for changing parameters for a give…