Les profils de développement liés à une architecture orientée service

L'abandon de la structure traditionnelle en silos fonctionnels profite surtout aux architectes.

Nouvelle architecture, nouveaux composants, mais aussi nouvelle organisation et nouveaux rôles. Trop souvent résumé à l'adjonction des seules briques technologiques (ESB, annuaire UDDI, outils de BPM, etc.), le déploiement d'une architecture orientée service (SOA) nécessite de remanier les équipes de développement. Avec notamment la création de postes jusque-là inexistants dans les architectures traditionnelles, calées sur les fonctions de l'entreprise (comptabilité, marketing...).' Dans une approche classique, ces fonctions servent à définir les processus, mais aussi les types de données de l'entreprise. Avec une certaine redondance, des types de données identiques pouvant être définis dans plusieurs fonctions ', explique Sébastien Delayre, consultant SOA chez Unilog. Les SOA, elles, exigent un découpage qui entremêle les fonctions - toujours existantes - et des objets métier. L'élaboration de ce maillage est de la responsabilité de trois nouveaux profils discernés par Unilog : le modélisateur métier, le modélisateur de processus et l'architecte logique.

La fonction chef de projet affectée

' La principale victime de cette évolution organisationnelle est le chef de projet. En effet, il perd du pouvoir au profit des architectes ', explique Malhar Kamdar, vice-président consulting Europe chez BEA. Quant au gagnant, c'est sans conteste l'urbaniste traditionnel, auquel revient naturellement le rôle d'architecte logique. Selon Sébastien Delayre, ' cette évolution est salutaire pour les urbanistes, jusqu'ici trop souvent enfermés dans leur tour d'ivoire, et coupés des équipes projet '[e-mail]

Les nouveaux métiers discernés par Unilog

1. Le modélisateur de processus
Il se révèle comme le mouton à cinq pattes. Il lui revient de maîtriser parfaitement les rouages métier de l'entreprise, tout en sachant les cartographier. Une capacité rare au sein des maîtrises d'ouvrage. L'une des solutions que préconise Unilog consiste à fonctionner en binôme - avec un spécialiste métier et un informaticien.

2. Le modélisateur métier
Il spécifie les objets métier de l'entreprise : un ordre de Bourse, un prix, une offre commerciale... Concrètement, il modélise en UML des classes d'objets, des attributs et des diagrammes de classes, en définissant un périmètre commun de métadonnées et en décrivant les relations entre objets. Cette modélisation métier se met en branle après l'esquisse des premiers processus. S'ensuit un échange itératif entre les deux modélisateurs. A ce stade, il n'est pas encore question de codage.

3. L'architecte logique
Son rôle s'avère central. A l'aide des équipes de développement, il traduit en services les modélisations des objets métier et des processus. Précisément, en deux familles de services. Les uns s'appliquent aux activités qui échelonnent les processus (par exemple, de l'émission du bon de commande à la réception de la facture). Les autres remontent les données, en combinant éventuellement plusieurs objets métier (commande, facture, etc.). La méthodologie Praxeme, exploitée par Unilog, encadre le découpage des objets métier et la composition des services associés.

4. Le responsable de processus et celui de domaine de services
Deux rôles de management. L'un supervise une chaîne de processus et l'autre, un regroupement cohérent de services. Si une procédure métier est modifiée, le premier joue un rôle de chef de projet vis-à-vis du second, chargé de la modification des services. Le profil de responsable de processus n'a pas d'équivalent. Dans une architecture classique structurée en silos fonctionnels, personne nassume cette tache transversale, primordiale lorsque des changements se répercutent sur plusieurs applications.