L’esprit TOGAF

Durabilité

Quand j’ai découvert TOGAF, il n’y a pas si longtemps, ça a été pour moi une révélation : une nouvelle perspective sur la façon de construire et maintenir un Système d’Information (SI) durable. Durable dans le sens où on peut envisager de l’actualiser régulièrement avec un effort minimal.

Attendez… je ne suis pas en train de dire que TOGAF apporte une solution sur étagère, je dirais même que ce n’est pas le cas ;)
TOGAF ne dit pas de quoi doit être constitué le SI, ni même comment le déterminer. Mais en tant que meta-solution à la question de l’Architecture, qui est un point essentiel pour la maintenabilité durable, TOGAF propose une façon très honnête de répondre à la question centrale du cycle de vie du SI : comment organiser des fondations architecturales durable (donc vivantes) ?

Je vois TOGAF comme une sorte de nouvelle approche pour organiser la démocratie autour du SI. A partir de besoins métier, TOGAF induit une façon d’organiser une processus collectif pour bâtir et enrichir l’architecture du SI. Le cycle de l’ADM (Architecture Development Method, au cœur de TOGAF) prend aussi en compte les contraintes existantes. C’est une condition nécessaire à la maintenabilité puisque chacune des parties prenantes métier et IT prendra part au cycle de décisions.

TOGAF me fait penser au moment où l’agilité (= démocratie) arriva dans le panorama IS/IT il y a quelques dizaines d’années. Et maintenant, avec TOGAF, l’agilité s’applique également à l’architecture ! On peut même dire que cette agilité de l’architecture inclut également les préoccupations DevOps puisque les équipes d’infrastructure matérielle et logicielle sont autour de la table lors de la phase Architecture Technologique tandis que les équipes de développement y sont également tout au long de la phase Gouvernance.

Approche boîte blanche

Je vois aussi TOGAF comme une boîte à outil blanche. Par exemple, TOGAF propose un canevas complet pour un cycle de vie de l’Architecture mais propose aussi une phase Préliminaire dont le but est… d’adapter ce cycle de vie au contexte. Il paraît très clair qu’on n’attend d’aucun architecte de lire et d’appliquer chacune des 692 pages du document TOGAF 9.1. Pour autant, on peut certainement y trouver des réponses si on en cherche. Et ceci d’autant plus quand on sait que les contributeurs à TOGAF ne prétendent pas avoir réinventé la roue. TOGAF est clairement une compilation organisée des meilleures pratiques d’architecture? Et c’est ce qui fait sa grande force.

D’un autre côté, je ne vois pas grande valeur opérationnelle dans les Modèles de Références de TOGAF. Je n’en vois pas non plus dans Archimate, une nouvelle notation destinée à faciliter la modélisation de l’Architecture d’Entreprise. Ce n’est pas parce ces contributions ne sont pas de qualité en elles-mêmes, c’est juste que je pense que ce dont on a le plus besoin en entreprise c’est de parler d’Architecture tous ensemble. D’une façon Lean : moins on s’encombre d’artefacts descriptifs artificiels, plus vite et plus loin on ira. On a certainement besoin d’artefacts pour enregistrer les idées d’Architecture, et des modèles peuvent aider à les organiser, mais ils devraient être le plus simple possible (mais pas plus simple !). La mouvance NoUML montre certainement un exemple à suivre sur la manière de s’adapter à l’usage en matière de modélisation.

Centré sur le SI

Une chose cependant me laisse un goût de trop peu dans TOGAF. Il est clair que la notion d’Architecture d’Entreprise embrasse d’autres horizons que le seul SI, même si bien sûr le SI est une pièce centrale dans la conduite du business.

TOGAF peut aider à bâtir une architecture du SI qui répond aux attentes mais, comme précisé en page 70 du document principal TOGAF 9.1 : « Normalement, les principes business, les objectifs business, et les motivations stratégiques de l’organisation sont déjà définis ailleurs dans l’entreprise » (ma traduction).

Cela signifie, sans aucun doute, que TOGAF n’adresse pas cette question fondamentale directement. Tiens, d’ailleurs, TOGAF ne propose pas non plus une méthode pour gérer les exigences. Alors même que les exigences sont au cœur des préoccupations dans l’approche TOGAF.

A posteriori, je pense que c’est mieux ainsi finalement. Et j’espère même que TOGAF ne se développera pas dans cette direction. Comme on dit en France : « Qui trop embrasse, mal étreint ».

Architecture d’Entreprise (AE)

Sur l’Architecture d’Entreprise j’ai lu un bouquin exceptionnel, que je recommande vivement : « Enterprise Architecture As Strategy », de J.W.Ross, P. Weill et D.C.Robertson. C’est probablement ma meilleure lecture professionnelle ces 20 dernières années. Ce livre décrit exactement ce que veut dire Architecture d’Entreprise. L’AE est la manière dont l’entreprise, et donc son SI mais pas seulement, s’organise pour sécuriser la réalisation de son business plan.

L’Architecture d’Entreprise est « Une Fondation pour l’Exécution du Business Plan »

Et je saisis l’opportunité de ce billet pour remercier la personne d’Arismore qui m’a recommandé cette lecture :)