Le métier d'abord (ne pas se tromper d'ordre)

Je prends l'encart central du Monde Informatique du 5 octobre, consacré aux SOA, à la page III. Paroles d'expert, consacrées à la méthodologie. "Deux approches sont possibles, technique et métier. Dans le premier cas, on cherche à rénover son SI, dans le second, on répond à un besoin d'utilisateurs en couvrant un périmètre en général orienté e-business".

Aïe ! Il me semble que c'est généralement le métier qui tire l'investissement d'innovation. S'il faut donc "premièrement" répondre à quelque chose, c'est d'abord à un besoin métier. La pérénnité d'une technologie, la force d'une organisation, l'émergence d'autres besoins couverts par cette même technologie, enracinent alors celle-ci dans le système informatique et pérénnisent l'investissement.

Heureusement, notre expert se rattrape in extremis. "Quelle que soit la démarche, le moteur doit rester le métier"... c'est bien ce que nous disions. Mais alors, quid des deux approches ? SOA n'est pas une démarche technicienne, mais une démarche portée par l'IT. C'est d'abord au métier qu'elle rend des services. Si la valeur apportée au métier profite ensuite à l'IT, parce qu'elle urbanise notamment le SI, très bien. Mais il ne faut pas se tromper d'ordre : les deux approches sont en réalité complémentaires.

"La première étape [de mise en oeuvre des SOA] relève avant tout de la communication : il faut réunir autour de la table les fonctionnels et les équipes informatiques pour cerner les objectifs, voir comment SOA peut y répondre et voir comment procéder."

Encore un problème d'ordre ! S'agit-il réellement de la "première étape" ? Quels "fonctionnels" vont accepter de s'asseoir "autour de la table" pour discuter de SOA ? Pour quoi faire ? S'il s'agit réellement de "communication" (personnellement j'appellerais cela du conseil), ce ne sont pas les fonctionnels qu'il faut convaincre, mais leurs patrons ! S'il s'agit du démarrage d'un projet, ce n'est certainement pas la "première étape".

Asseyons-nous autour d'une table pour voir si SOA est la bonne techno pour votre projet, non. Comment SOA peut apporter une valeur différenciante à un métier et à une stratégie, oui. Mais à ce stade et compte tenu du public, mieux vaut ne pas parler de SOA, parce qu'un choix technologique n'aura finalement que peu d'intérêt pour les "fonctionnels".

J'achève ces jours-ci pour un DSI une mission dont l'intitulé est "Comment SOA peut permettre à mon entreprise de doubler les ventes de son canal e-Commerce". Ce DSI ira ensuite voir sa direction financière pour la convaincre de l'importance de cette innovation. Alors seulement démarreront peut-être des projets, et alors seulement nous nous assoierons entre gens de bonne compagnie, métier et IT, autour d'une table, pour concrétiser la vision. Mais il ne faut pas se tromper d'ordre.

Je concluerais en citant Werner Vogels, vice-president, worldwide architecture executive et CTO d'Amazon.com, dont on peut diffilement douter de la pertinence du propos lorsqu'il parle de B2C et de SOA : "It doesn’t matter if a partner uses REST or SOAP. Our developers don’t care if it’s REST or SOAP. It’s all about customers" (http://blogs.zdnet.com/service-oriented/?p=648).