Le 2ème FORUM SOA a eu lieu ce 4 octobre.
L'année dernière ce forum était très orienté ''offre logicielle'' (type BEA Aqualogic) et se focalisait sur la constitution de services unificateurs.
L'année faisant ce nouveau forum a précisé le concept de SOA sur tous ces aspects:
Amont:
nécessité d'une véritable analyse BPM/BPA des processus à ''outiller''
Conception des services - BPMN
rationalisation des données/des référentiels: le MDM
rationalisation des règles des processus outillés: le BRMS
Central:
Référentiel de services
Authentification
Orchestration via l'ESB (BPEL/Rules)
Aval:
Monitoring des processus outillés parles services : le BAM
Exposition de type Mashup (Ajax)
Surtout c'est l'orchestration de cette partition du SOA qui importe pour arriver au succès (ROI SOA mesurable ?).
La distinction Mashup (SOA de ''facade'') / SOA de refonte/ extended a été précisée.
Présence des éditeurs majeurs cette année (ORACLE / SAP) pour montrer leurs approches globalisantes. Le maître mot est qu'avec le SOA il n'est pas nécessaire de tout acheter chez le même éditeur, chacun s'ouvre au concurrent comme intérêt global à en penser que le modèle économique IT serait à revoir ...
Côté cabinet de conseil, le maître mot est de commencer ''petit''.
Que ce soit au niveau de ce forum ou d'un road-show plus récent (IDS Scheer le 09/10/2007), l'approche de bout en bout (Process -> BPMN -> BPEL -> orchestration)semble encore laborieuse ...
Intervention de Pierre BONNET posant le risque de transformer un SI ''spaghetti'' (celui avant les EAI ...) en un véritable ''Risotto de services'' (imbrication, granularité inadaptée, morcellement du SI existant en bibliothèque sans refonte ''métier'' ... attendons son ouvrage collectif qui arrive en novembre.
La méthode PRAXEME est mise en avant mais cette méthode est-elle aussi bien adaptée au SOA d'applications ''maison'' qu'au SOA de démantellement des progiciels qui est l'évolution naturelle de ces solutions sur étagère.
Le SOA fait aussi naître de nouveau modèles économiques d'hébergement de ces services (vers le ''SOA grid'') et des coûts associés (offres de SAP et de Microsoft d'hébergement et de ''location'' de services). La gouvernance IT est donc très impactée.
Présentation des approches projet Open Source vers les produits commerciaux par IONA.
En cours de cartographie d'un S.I. (dit simple par la MOE !), le débat du profil de l'urbaniste refait surface ... tant la tâche est délicate ...
Si, dans la presse ou les sites de recrutement, l'urbaniste est un ''architecte applicatif senior'' au fait des solutions IT et des progiciels du marché, la démarche de cartographie du SI semble demander, surtout si le patrimoine applicatif est ''maison'', des compétences fonctionnelles certaines :
- connaitre les grands domaines de la gestion, de la comtabilité, de la supply chain ...,
- comprendre les grands enjeux de l'entreprise, ceux-ci étant traduits par les besoins décisionnels et les outils de pilotage mis en place le plus souvent,
- assimiler et respecter les démarches qualité, gouvernance du SI si celle-ci sont mises en place.
La difficulté ne réside pas seulement dans le poste de ''l'urbaniste'' lui même, poste dit ''stratégique'', sorte de bras droit du DSI (? !) en charge de construire un référentiel et apte à donner rapidement l'information à sa direction, mais, dans les membres de l'équipe d'urbanisme qui, telles des fourmis ouvrières, devront cartographier, motiver les chefs de projet (MOA, AMOA, MOE, partenaires, sous traitants en charge de la maintenance , ...), digérer une somme de documentation plus ou moins bien faite ou à jour, comprendre les architectures fonctionnelles, applicatives et techniques et ... instituer un cycle de vie pour être automatiquement informés des changements du SI ou de l'émergence de nouveaux projets ... mineurs voire même majeurs pour l'entreprise !! ... ce qui n'est pas gagné !
D'ailleurs, au quotidien, l'épreuve est amenée par la démarche intrusive de l'urbaniste ''de base'' qui, souvent en phase projet, mais aussi en maintenance, provoque une véritable ''peur'' des interviewés (chef de projet, responsable MOA ou maintenance, ...) qui devront restituer ou connaître leur S.I. dans les détails requis: ne seront-ils pas évalués sur la maîtrise de leur périmètre ? ...
Parmi ceux-ci, '' ''L'Architecte des Monuments du S.I.'' '' est celui qui doit déchiffrer l'histoire mouvementée du S.I. entre politique externe de l'entreprise (acquisitions, fusions, préparation de filiales...), politique des dirigeants et de l'évolution de leurs zones d'influence (le principal ?), politique externe de l'entreprise (son ''ouverture'', son image ...) tout celà en étant au fait des standards d'une époque (passée), d'un respect de normes, de cohérence ... là encore une analogie avec la pierre ...
Ne l'entend-on pas crier ''L'ERP arrive, mais attention ne detruisez pas tout !''. Si un ERP offre sur étagère beaucoup de fonctionnalités, à paramétrer, à modeler par des spécifiques, des acquis applicatifs de l'entreprise demandront des aménagements voire de nouveaux développements spécifiques (comptabilités auxilières, prévisions, planification des ressources ...).
Entre directions de programme et projets, parfois financés par des entités indépendantes, DSI et ''utilisateurs'', il faut donc un arbitre garant de la cohérence et suffisamment indépendant des partis pour pérenniser (voire maintenir ?) les services du SI dans l'entreprise.
Depuis février 2004, je mets en place, dans le cadre d'une mission de conseil, l'urbanisme du S.I. (architectures métiers, fonctionnelles, applicatives et techniques) au sein de la SNCF, pour le pôle ''Etudes ERP et Gestion'', dans une approche ''Outils et Méthodes'' avec MEGA.
Blog intéressant sur fondamentaux SOA / Architecture Orientée Services et ses satellites (web services, urbanisme, sécurité, design paterns , etc.):
http://soaj2ee.blogspirit.com/
Lionel
Si les termes ERP (ou PGI) ou encore CRM sont connus des sociétés dites "commerciales" des secteurs terciaires et des "services", le PLM (Product Lifecycle Management) issu des outils de PDM / SGDT (Product Data Management – Systèmes de Gestion de Données Techniques) reste encore trop cantonné dans les entreprises dites "industrielles".
Pourtant les entreprises de services ou commerciales gèrent de plus en plus de produits, d'évènements, de systèmes complexes... Les achats, rationalisant de plus en plus les articles et leurs fournisseurs, pilotent des référentiels de plus en plus imbriqués, versionnés, classés …
Il est vrai qu’avec deux ouvrages sur les SGDT, en 1995 (éditions HERMES et MASSON) puis, enfin, un ouvrage généraliste sur le PLM en 2004, toujours aux éditions HERMES, la littérature est bien pauvre sur le sujet face aux ERP (outils et méthodologies associées). Le PLM est pourtant intégré dans les connaissances générales des cursus d’école d’ingénieur et à l’université technologique. Les solutions sont pourtant peu présentes en travaux pratiques, les enseignants préférant les outils de simulation ou de design (CAO, calculs) dans les filières techniques appliquées.
Une autre différence avec les ERP est l’absence de démarche d'urbanisme (cartographie des processus, architectures applicatives et techniques) ou de BPM (Business Process Management) non systématique sur un projet PLM …
La notion de Produit des outils de PDM/PLM peut être d’ailleurs étendue à la notion de systèmes car en dehors des entreprises manufacturières classiques et/ou des industries majeures (automobile, aéronautique, biens de consommation, …) les outils PLM sont aussi utilisés dans la gestion de systèmes complexes (armée, ingénierie civile et pétrolière/chmique, médical, entreprises pharmaceutiques, …)
Pourtant moins rigides que les ERP (basés sur un mécanisme ‘’transactionnel’’), par leur paramétrage et leur modèle de données évolutif, il se concentrent sur des fonctions évoluées tournées sur la Gestion du Produit :
- la Gestion de Configuration, avec des configurations ‘’de travail’’ (le bureau de design, les bureaux d’études, …), ‘’applicables’’ (les méthodes) et plus ‘’physiques’’ (la production, la maintenance,…) tel que les configurateurs utilisable par les équipes de vente en bout de chaîne.
- Le Change Management ou la traçabilité des évolutions, l’historique, les solutions retenues ou écartées … dans la conception … la gestion de l’obsolescence …
- La Gestion de Nomenclatures, la classification chargée d’homogénéiser la donnée, de la stocker, de la rationaliser …
- Le Concurrent Engineering qui permet un travail collaboratif entre équipes pluridisciplinaires et en mode décalé pour améliorer le fameux TTM (Time To Market).
- L’intégration avec des outils techniques comme la CAO ou plus généralement l'IAO (Ingénierie Assistée par Ordinateur), pour concevoir en ‘’4D’’ le produit, le process, les ressources, le système.
- Gérer les données liées au produit/aux systèmes : les simulations, calculs, les ressources (l’usine, les moyens de production, l’outillage, les réseaux électriques, fluidiques, le convoyage …)
- Les Workflows ou le moyen de gérer et de tracer l’évolution, la validation, l’instruction d’un dossier technique ou documentaire (Qualité, normes, manuels …)
- des fonctions de GED/GEDT (Gestion Electronique de Documents Techniques) : attachement au produit/au système des documents de l’entreprise.
Les solutions PLM ‘’mangent’’ donc les platebandes de d’autres familles d’outils informatiques, source de confusion ou d’erreur sur leur statut:
- La Gestion de Configuration Produit n’est pas une Gestion de Configuration Logicielle …
- La GPAO (Gestion de la Production Assistée par Ordinateur) avec la notion de gamme est une configuration ‘’ultime’’ du produit. Les outils de PLM n’ont pourtant pas souvent les fonctions de planification nécessaire (MRP par exemple). Par contre pour la GMAO (… Maintenance …) ou le SLI (Soutien Logistique Intégré) leur spectre fonctionnel est souvent suffisant.
- La GED (Gestion Electronique de Documents) où le système- le produit est remplacé par le document mais les outils PLM n’ont pas par défaut les fonctions d’indexation et de gestion de contenu nécessaire (dont XGML).
Toutes ces fonctionnalités ouvertes aux utilisateurs font d’eux des utilisateurs ‘’avertis’’ à l’opposé de ceux des ERP beaucoup plus contraints dans des interfaces figées et des (trans-)actions guidées.
L’outil PLM laisse donc place à la création et à l’imagination nécessaire en phase de design, de conception, de tests, de configuration client alors que l’ERP cherche la standardisation des opérations (comptabilité, achats, logistique, planification oblige !)
La frontière est donc infime et les zones de recouvrements larges entre les grandes familles de progiciels du marché ...