SOA : approche systémique

IMHO une approche de type SOA, ou Herzum (peu importe) devrait essayer d’intégrer la nécessité, quand on conçoit une interface (un contrat) d’intégrer 2 types de contraintes :

• in : les contraintes internes : moi je veux bien fournir un service qui renvoie le nom du client mais pour ça il faut me donner l’id du client ou une autre manière de le retrouver
• out : les contraintes d’utilisation par l’extérieur : moi j’ai besoin d’un service qui me ramène la liste des dossiers du client, je ne veux pas appeler n fois le même service

Cela vaut aussi pour l’organisation des équipes qui gèrent une famille de services :

• in : pour intégrer au mieux les contraintes internes, il faut les connaitre, donc les membres de cette équipe gagnent à rester au sein de l’équipe un minimum, à tourner sur les différents services gérés par l’équipe pour connaître au mieux le métier, etc…
• out : pour adapter les services au mieux aux contraintes externes :
  • ne pas réaliser les services par anticipation. Ne pas décider maintenant des besoins futurs (ou de l’absence de besoins futurs). Réaliser les services pour un (idéalement 3) projets actuels qui en ont besoin tout de suite
  • les membres de l’équipe « services » devraient être détachés au sein du projet une partie de leur temps, pour concevoir avec le projet les interfaces, pour les assister dans l’intégration, les jeux de données (les fameux bouchons), … Ils seront d’autant plus conscients des contraintes du projet, sauront au mieux justifier celles de l’équipe. Et les projets seront naturellement synchronisés en terme de planning.