Les opérationnels font de l'architecture sans le savoir

Et le problème c'est qu'elle n'est que fonctionnelle.

Expliquons. Soit une compagnie. Avec le temps, elle a racheté des activités à l'étranger, qui ont chacune leur système pour traiter un "même" ou un proche business.
Puis le business évolue, la réalité du marché évolue. Des redondances s'accentuent et coûtent plus cher qu'avant, des évolutions sont nécessaires pour rester performant, etc.

Au niveau opérationnel, on cherche alors une solution pour aborder ces nouveaux biz avec le meilleur système : il coûte moins cher, il permet de traiter des nouveaux business qui representent des nouvelles rentrées $.

Ni une ni deux, les opérationnels vont comparer les "services rendus", les produits supportés, les fonctions disponibles, celui qui est le plus à même d'accepter les évolutions, pour choisir le plus "adéquat" (complet, évolutif, ...) pour ce "merge" ou autre.

Le problème c'est que c'est de l'architecture. Je veux dire, étudier le problème sur le plan du pur fonctionnel, regarder de loin les grosses caractéristiques du système (peut il fonctionner pour plusieurs filiales ? oui/non), c'est indispensable, et c'est très valuable, oui. Mais commencer à dessiner une cible avec des systèmes qui se scindent, qui fusionnent, qui collaborent, c'est faire de l'architecture.

Et donc une cible qui n'est en réalité valide que lorsque les autres axes d'architecture sont étudiés : pas que le fonc. Aussi le tech, la prod, l'orga humaine.

Une très forte culture dans nos DSI actuelles, c'est de faire des dessins sur ce "quoi" on veut, entre opérationnels d'abord, de prendre des décisions sur ces dessins, et de voir ensuite l'informatique pour creuser, pour décliner ce dessin choisi avec des budgets, solutions, des délais.

Mais ce "quoi" c'est pas du besoin. C'est une solution. Ils ont fait une architecture - un début - sans le savoir.