Le défaut de l’ingénieur et en particulier du développeur est plus répandu qu’on le souhaiterait. Mais en fait, lorsque je dis LE défaut, il conviendrait de dire LES défauts.

Parmi les écueils les plus courants, on trouve le fait de vouloir réaliser une fonction pour le défi technologique qu’elle représente et non pas pour répondre au besoin ou encore le fait de penser à son CV avant de répondre à la problématique.

Tout ceci est classique. Si vous êtes architecte logiciel, vous le savez déjà et si vous êtes chef d’équipe ou client vous le savez encore mieux

Je suis tombé sur un livre qui recense tous ces défauts. Plus qu’une collection, c’est un inventaire que je trouve exhaustif (pensez bien qu’il y a tout de même 97 défauts!) qui permettra de mieux comprendre les architectes logiciels.

Le livre est disponible sur Amazon mais il est possible de consulter gratuitement le Wiki sur lequel se trouvent une partie du contenu dont voici un extrait :

We often design over-engineered applications as a result of blindly pleasing customers to the greatest extent. We are so distracted by the details of the solutions that we offer, that we sometimes fail to see that we end up solving the wrong problems in the first place.

So here is a little suggestion: don’t just translate customer requirements into code, but strive to be a wise interpreter. In other words: design for needs, not wants.

You should challenge requirement definitions as, almost invariably, customers poorly define and understand their own actual needs.

All too often, they say they want a longer antenna when, in fact, they need a better reception. You should ask simple questions such as « why do you want this feature? » and « what is its benefit? » and you should keep inquiring until you obtain an adequate answer.

Once you have identified the underlying needs, you have the opportunity to look for alternative solutions. Don’t stop at the first good idea and don’t blindly trust your first instincts. As the French philosopher Alain (Émile Chartier) once said: « Nothing is more dangerous than an idea when it’s the only one you have. » Deliberately ask questions such as « this is a way of doing what? » and « how else can this be achieved? »

Incidentally, this is your best chance to reduce complexity in your applications: right at the source, where it matters most. Simple and elegant solutions are often incredibly hard to find and may not be there at all. But do not to give up too quickly, as you may miss tremendous opportunities.

by Claudio Perrone

Vous trouverez aussi des citations de nombreux professionnels :

• Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar)
• Chances Are, Your Biggest Problem Isn’t Technical (Mark Ramm)
• Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
• Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
• For the End User, the Interface Is the System (Vinayak Hegde)
• It’s Never Too Early to Think About Performance (Rebecca Parsons)

Si vous connaissez un architecte logiciel ou un développeur ce livre doit être en bonne place dans votre prochaine commande !

Si je parle de ceci sur un blog à priori dédié à la modélisation des processus métier et à l’urbanisation du SI, c’est que je pense que les business analyst et les urbanistes du SI ont de nombreux défauts en commun avec les développeurs… et je sais de quoi je parle !

Pour le commander :

Popularity: 4% [?]

Qu’est-ce qu’un bon architecte ?

Dans les métiers liés aux systèmes d’information, il existe beaucoup de fausses idées qui circulent.

Commençons par définir ce qu’est l’architecture. Je ne vais pas me lancer dans des considérations philosophiques ici alors je dirais simplement de l’architecture que c’est du design appliqué au système d’information. C’est simplement le fait de penser et d’appliquer une idée sur un domaine virtuel qu’est le logiciel.

Une autre version sera de dire que l’architecture est la version un peu gaussée du design. Il s’agit de concevoir.

Si le logiciel est une construction de l’esprit, l’architecture est le niveau supérieur. C’est encore plus abstrait.

Le rôle d’un architecte est donc de guider l’entreprise, le projet ou l’équipe dans cette abstraction. Il se distingue par sa capacité de conceptualisation, sa capacité à prendre du recul et à imaginer ce que sera le futur contexte du développement actuel.

Typiquement dans un projet, les questions d’architectures sont toutes ces questions que vous auriez aimé avoir résolue correctement au début !

Il y a quelques années, l’architecture de la base de données était essentielle. Elle définissait largement ce qu’il allait être possible de faire dans l’application. Plus le temps passe, moins la base de données prend de l’importance. L’architecture arrive à s’affranchir des contraintes.

C’est peut-être là, l’une des clés d’un rôle d’architecte. Faire disparaitre les contraintes dont on sait qu’elles sont une source importante de problèmes dans les projets.

Pour résumer :

• conceptualisation
• projection
• bases techniques solides
• capacité de communication

Popularity: 2% [?]