TOGAF & Architecture logicielle

Modifié le 27/2/17

J’ai récemment obtenu la certification TOGAF Foundation. C’est chouette de réussir du premier coup un examen certifiant, mon premier examen depuis au moins 25 ans ! Je parlerai de TOGAF dans d’autres billets mais, comme vous le savez, quand on vient d’apprendre quelque chose de nouveau et de découvrir une nouvelle facette du monde qui nous entoure on a tendance à tout regarder depuis ce nouveau point de vue. Est alors arrivé ce qui devait arriver, et j’ai malheureusement placé le terme TOGAF dans une conversation où il n’aurait pas du avoir sa place :

L’Architecture Logicielle ce n’est pas l’Architecture d’Entreprise. C’est une chose certaine puisqu’un Logiciel n’est pas une Entreprise. Cependant… à quoi rime de parler de modélisation d’Architecture Logicielle si aucune Architecture d’Entreprise n’a été définie, et éventuellement modélisée, au sein de laquelle on peut situer cette Architecture Logicielle ? Est-ce qu’une Architecture Logicielle porte par elle même suffisamment de valeur pour justifier qu’on consacre du temps à la modéliser ? D’ailleurs, qu’appelle-t-on Architecture ? Et qu’appelle-t-on Architecture Logicielle ?

Architecture

Je dois reconnaître que, bien qu’ayant été moi même un Architecte Logiciel pendant de nombreuse années et peut-être encore maintenant, le concept « Architecture » n’a jamais été totalement clair pour moi. Et à la réflexion pas non plus pour toutes les personnes avec qui j’ai pu travailler. J’ai toujours pensé que ce concept concernait la manière dont les choses sont liées les unes aux autres, mais comment rattacher ça à une base solide et stable ?
Et puis, grâce à mes cours TOGAF, j’ai découvert le Graal de la définition du terme Architecture emprunté à ISO/IEC 42010:2007 : « L’organisation fondamentale d’un système, constitué de ses composants, de leurs relations les uns aux autres et avec l’environnement, et les principes et modalités régissant sa conception et son évolution » (traduction perso).
La définition plus étendue de TOGAF est également intéressante : « Une description formelle d’un système, ou un plan détaillé du système au niveau de ses composants pour guider son implémentation ET/OU La structure des composants, leurs relations, et les principes et modalités régissant leur conception et leur évolution dans le temps ».

Cela montre que l’Architecture a deux facettes : la façon concrète dont les choses sont liées, et un plan abstrait de cette réalité matérielle. Wahou ! Ca paraît chouette… mais un peu bizarre quand même, non ? Revenons à l’Architecture Logicielle. Quand on y pense, beaucoup de monde dans l’IT considère, consciemment ou pas, que le code source est intrinsèquement une parfaite Architecture Logicielle. En effet :

• Le code source décrit parfaitement ce qu’un logiciel est : le code exécutable est, en essence, ce code source
• Et le code source, au sens large, contient aussi par lui même comment le logiciel est fait : le code et les paramètres de build sont auto-descripteurs puisque lisibles par un développeur

Je vous épargne la discussion sur les différences, ou pas, entre code source et modèle pour aller directement à une conclusion pragmatique. En considérant que le code source peut parfois (!) ne pas représenter le meilleur exemple de « principes et modalités régissant sa conception et leur évolution dans le temps », de quelle sorte de description a-t-on besoin pour maintenir un logiciel et pouvoir le faire évoluer ?
Comme souvent, ça dépend de ce qu’on veut faire…

L’Architecture logicielle pour un développeur

Un développeur, pour développer, va généralement s’en sortir avec : des principes d’architecture généraux et simples, des règles de codage simples, des patterns de code, des exemples de code, du support technique. Une sorte de recette de cuisine, pourvu que cette recette soit organisée en fonction de son utilisation par le développeur. De nos jours, la meilleure recette de cuisine pour développeurs que je connaisse s’appelle… Google ! Le problème avec Google c’est qu’il ne tient absolument pas compte des règles d’architecture définies par l’entreprise.

Une alternative très efficace au codage « Google-isé » s’appelle MDD (Model Driven Development). Mais il y a tellement de prérequis et de précautions à prendre avec l’approche MDD que très peu d’entreprises osent s’y lancer.

Est-ce que la modélisation de l’Architecture Logicielle peut aider ici ? Je ne pense pas. En tout cas pas de manière nécessaire et décisive. L’approche MDD est censée s’appuyer sur la modélisation pour aider les développeurs mais, sans même mentionner UML et son nécessaire apprentissage dans ce cas, le problème n’est pas la pertinence de la notation mais l’adéquation entre la potentielle solution (modélisation) et le problème (canaliser le développement).

Donc du point de vue d’un développeur l’Architecture est essentiellement l’Architecture Logicielle, et sa modélisation est sans intérêt particulier. Sauf quand ce média « modèle » est la façon la plus simple de faire comprendre des règles à respecter. Cette Architecture Logicielle doit être transmise par d’autres medias : ceux qui permettent au développeur de se concentrer sur le développement en répondant à des questions souvent très terre à terre.

L’Architecture logicielle pour un architecte

Pour un architecte la question est toute autre… attendez. Est-ce que ça ne devrait pas être la même question justement ? On parle de Logiciel, ça ne devrait pas être un autre problème : l’objectif et de maintenir et faire évoluer des applications logicielles. Puisque ces applications sont développées par des développeurs, parmi les objectifs d’un architecte devrait figurer celui d’aider les développeurs et donc de leur apporter les réponses qu’ils attendent !

D’un autre point de vue, au niveau Entreprise, on a généralement besoin de définir des règles générales pour la conception logicielle. Le but est ici de contribuer aux économies sur les coûts IT, de mettre en place les règles de sécurité, d’optimiser les temps de réponse et de pouvoir avancement de manière organisée et réactive. Ces règles de conception IT font partie à coup sûr de l’Architecture d’Entreprise. On est ici à un niveau logiciel « meta », où les Building Blocks (vocabulaire TOGAF) ne sont pas du code source. On est à un niveau où la modélisation est un bon moyen de représentation. Pas complètement auto-descriptif mais suffisamment pour être utilisé.
Au fait, la notation de modélisation qui semble mise en avant par TOGAF s’appelle Archimate. Mais de fait on peut probablement arriver au même niveau de modélisation avec  UML et BMPN…

Enfin, l’architecte doit se soucier d’une part de la traçabilité des décisions d’architecture et de leurs évolutions dans le temps (gouvernance), mais également de la compatibilité avec l’architecture d’entreprise y compris sur des volets non IT.

Le métier d’architecte IT est finalement assez simple à définir : traduire en continu l’Architecture d’Entreprise en Architecture Logicielle d’une part, et d’autre part décliner cette Architecture Logicielle sous une forme concrète recevable par les développeurs.
Plus simple à dire qu’à faire !

Architecture et modélisation

L’architecture du SI, au sein de l’architecture d’entreprise, recouvre plusieurs domaines : métier, données, logiciel, infrastructure notamment. Modéliser cette architecture est un moyen de la décrire mais pas le seul moyen. En particulier la modélisation n’est probablement pas un moyen efficace lorsqu’il s’agit de traduire des règles d’architecture en règles de développement.

Entre architectes et développeurs il y a toujours eu un hiatus, encore accentué avec les approches agiles. Ce n’est pas étonnant finalement : ils n’ont pas les mêmes préoccupations immédiates, ni les mêmes outils de travail. Et ce qui est tout à fait clair, pour moi, c’est que c’est aux… architectes de s’adapter ! Notamment en travaillant davantage sur la manière dont ils rendent services aux développeurs tout en faisant passer leurs messages. Et ce d’autant plus que, on le sait tous, un développeur n’a pas besoin d’un architecte pour écrire du code ! Le rôle de l’architecte c’est que ce code soit optimal pour l’entreprise et durable. Et ça ce devrait être l’objectif de de l’entreprise…

Crédits:
– image empruntée sur http://www.sei.cmu.edu/dependability/consulting/. Un site sympa d’ailleurs, complètement en rapport avec le sujet de ce billet
– merci beaucoup à Rich Hilliard ‏(@dJdU) pour m’avoir tweeté le lien vers la définition ISO complète du terme « Architecture »