Industrialisation de la production d applications

Transcription

1 Jeudi de l objet Industrialisation de la production d applications Didier GIRARD Directeur Technique d IMPROVE Réf ITF0010 Page 1 B IMPROVE Santé : Éditeur B Résurgences depuis 1996, 15 Hôpitaux B Interconnexion d hôpitaux depuis 2003 B SMUR depuis 2004 B 10% du CA IMPROVE - Activité B IMPROVE Services : SSII B Depuis 1991 B Expertise technologique B Architecture et modernisation SI B Réalisation de projets critiques (délais qualité) B Transfert de compétences auprès d équipes internes B Contrôle de la qualité des réalisations sous-traitées B 50% du CA B IMPROVE Foundations : Éditeur B Depuis 2002 B Industrialisation des développements J2EE B Licences, Services, Formation B 40% du CA Réf ITF0010 Page 2 1

2 Besoin d industrialisation des développements B Les constats B Les projets fonctionnels sont des projets technologiques B Coûts de réalisations non maîtrisés B Coûts de maintenance importants B Exploitation difficile B Besoin d expertise dans la durée B Le rythme technologique condamne à l obsolescence B Les spécifications fonctionnelles ne prennent pas en compte les coûts de production B La MOA et la MOE ne se comprennent pas Réf ITF0010 Page 3 La nième révolution industrielle B Pourquoi industrialiser? B Réduire les coûts B Augmenter la productivité B Augmenter la qualité B Augmenter la réactivité B Adresser la complexité B B Obstacles B Les peurs : «Les temps modernes», «l Offshore», B Les freins : certains acteurs (méthodologistes, développeurs, architectes, ) se considèrent/se veulent artistes, divas, indispensables, Réf ITF0010 Page 4 2

3 Tout n est pas industrialisable B Le Potager du Roi - Versailles Réf ITF0010 Page 5 Industrialiser B La production d applications aujourd hui B Amusant, beau, poétique, artisanal, désorganisé, fun, enrichissant, Réf ITF0010 Page 6 3

4 Industrialiser B La production d applications demain B Pas fun du tout B Et pourtant, la production d applications doit s industrialiser Réf ITF0010 Page 7 Besoins d industrialisation B Simplicité B Faciliter l intégration de développeurs Métier, non experts B Mixer les équipes (internes / externes) et piloter ses sous-traitants B Aider/formaliser le dialogue MOA/MOE B Productivité B Minimiser le temps de réalisation d écrans et du métier B Faciliter le travail en équipe B Aider la MOA comprendre le cadre de développement B Maintenabilité B Assurer une approche systématique quels que soient les intervenants B Garantir la qualité de service B Évolutivité B Faciliter les nécessaires montées de versions de produits B Garantir la même qualité pour des projets hétérogènes : B2E, B2B, B2C B Réutilisabilité B Capitaliser B Exploitabilité B Garantir le fonctionnement B Accélérer la mise en production Réf ITF0010 Page 8 4

5 Les phases B Il ne s agit pas d industrialiser uniquement les phases de développement. B Toutes les phases de l élaboration d une application doivent être industrialisées B Les développeurs ne sont pas la cible de l industrialisation B La chaîne de production doit être cohérente Capture des besoins Spécifications Analyse Conception Développement Maintenance Intégration, Recette Production Réf ITF0010 Page 9 Les moyens B L industrialisation de l élaboration des applications peut s appuyer sur trois briques indépendantes B Un socle n est pas un framework! Réf ITF0010 Page 10 5

6 Qu est-ce qu un framework B Le framework répond à un problème technique B Navigation, Persistance, Sécurité B Plus il y a de frameworks plus on se pose de questions B Struts, Tapestry, JSF, Spring, Hivemind, Log4J, B Quel framework choisir? B Un framework amène des degrés de liberté aux développeurs B Comment utiliser.net? B Comment utiliser J2EE? B Comment utiliser Struts? B Comment utiliser Spring? B Comment utiliser Hibernate? Réf ITF0010 Page 11 Socle technique versus framework B Le socle technique est une vue des frameworks B Le socle technique impose B Un socle technique supprime des degrés de liberté aux développeurs B Un socle impose des règles de développement B Un socle impose une architecture B «Plus le socle technique est bon moins les acteurs se posent de questions» Réf ITF0010 Page 12 6

7 Exemple 1 B De la méthode, des outils (?), pas de socle B Le socle garantit que les développements sont industrialisables Réf ITF0010 Page 13 Exemple 2 B Un socle, de la méthode, pas d outils B Les outils améliorent la productivité Réf ITF0010 Page 14 7

8 Exemple 3 B Un socle, des outils, de la méthode B Mais qu est-ce qui est industrialisé? Réf ITF0010 Page 15 Matrice de la plateforme d industrialisation Simplicité Productivité Maintenabilité Evolutivité Exploitabilité Réutilisabilité Capture des besoins Spécifications Analyse Conception Développement Socle Outils Méthode Maintenance Intégration, Recette Production Réf ITF0010 Page 16 8

9 Un exemple B Comment garantir que la MOA se préoccupe des contraintes de productivité de la MOE? Réf ITF0010 Page 17 Pourquoi impliquer la MOA? B Exemple de spécifications de la MOA : B Je souhaite de mon champ Qu il soit bien placé Qu il soit facile à moissonner Qu il soit accessible Qu il soit productif Qu il soit fertile Qu il soit bien ensoleillé Qu il soit bien irrigué Qu il soit pas cher Qu il ait le label BIO Qu il soit exploitable dès le printemps Réf ITF0010 Page 18 9

10 Pour éviter ça B Et je souhaite que mon champ ressemble à ça B Vous y croyez? Réf ITF0010 Page 19 Alors comment faire? B Pour décrire les écrans qu elle souhaite, la MOA utilise Word/PowerPoint/DreamWeaver B La production des spécifications fonctionnelles détaillées est longue et laborieuse B La MOA n est pas contrainte, elle dessine ses écrans, elle peut donc produire tous les écrans qu elle veut B De plus la MOA a toujours le temps : elle produit en début de projet, B Solution B Proposer à la MOA des outils qui lui permettent de produire ses spécifications fonctionnelles Ces outils devront être simples à utiliser Ces outils devront lui mâcher le travail Ces outils devront la contraindre dans l espace de faisabilité de la MOE B L idéal serait même que la MOA produise pour la MOE ;-) B Ne parlez plus d UML à la MOA Réf ITF0010 Page 20 10

11 Conclusion B Dans le domaine de l industrialisation de la production des applications il y a tout à faire B L industrialisation de la production d applications ne doit pas se focaliser sur le développement B Attention à ne pas vous trouver coincé chez un éditeur : restez sur des standards, si ils en existent B Par exemple : évitez les outils produisant du code propriétaire Le code est java, mais pour le maintenir il me faut les outils de bidule B L offshore est un axe d investigation, ce n est pas une solution Réf ITF0010 Page 21 Du framework au socle B Architecture et SOA : Orientée Service B Frameworks et socle technique B Stratégie Réf ITF0010 Page 22 11

12 S.I. : au début tout est simple B La technologie est uniforme et propriétaire B Les applications sont propriétaires et centralisées Achats, Paie, Gestion de stock, Gestion de production, Mon métier Spécifiques B Pas besoin d architecture, pas besoin d architectes Réf ITF0010 Page 23 S.I. : les contraintes B Il faut satisfaire l utilisateur B Il faut dialoguer avec les partenaires B Il faut contrôler les coûts B Passer sur des technologies «ouvertes» B Progicialiser B Externaliser Réf ITF0010 Page 24 12

13 SI : la cacophonie Paie, Mon métier ASP Spécifiques Partenaires ERP, CRM, Achats Site Web Progiciels Applications Internes Applications Externes Réf ITF0010 Page 25 Projets d intégration B Pourquoi intègre-t-on? B Pour unifier le système d information : on ne s est pas remis de l éclatement du S.I. B 1995 : phase 1, le data warehouse B 2000 : phase 2, l EAI B 2005 : phase 3, le portail B 2010 :? Réf ITF0010 Page 26 13

14 SI : La cacophonie Paie, Mon métier ASP Spécifiques ERP, CRM, Achats Data WareHouse, EAI, Portail Intégration Partenaires Progiciels Site Web Applications Internes Applications Externes Réf ITF0010 Page 27 Cacophonie : les technologies B La technologie n est plus uniforme, ni propriétaire ;-) B Delphi, J2EE, VB, Java, PowerBuilder, Cobol, LAMP,.Net, B Windows, AS/400, Solaris, Aix, HPUX, Linux B Oracle, DB2, Sybase, SQL Server, MySQL, B CICS, IMS, Tuxedo, J2EE, B La prolifération des technologies dans l entreprise est un centre de coûts! Réf ITF0010 Page 28 14

15 SI : SOA B Actuellement le S.I. ne devrait plus être pensé en terme d applications mais en terme de services B Le S.I. peut devenir un ensemble de services réutilisables intégrés via des processus métiers Validation Commande Vérification Facture Réservation produits Réservation Logistique Envoie Facturation Services ERP, CRM, Achats Mon métier Paie, Progiciels Spécifiques ASP Site Web Partenaires Applications Internes Applications Externes Réf ITF0010 Page 29 S.I. : SOA B Il est donc important de construire des applications qui soient «SOA compatible» Réf ITF0010 Page 30 15

16 Architecture SOA : orientée services B Un service est une fonction qui reçoit des messages et qui les restitue après traitement. Application1 Application2 Application3 Contrat Service Implémentation Service1 Service2 B Un service est réutilisable et «thread safe» B Un service respecte un contrat B Un service est sans état B Un service est indépendant de la plateforme d exécution et du langage de programmation Réf ITF0010 Page 31 Architecture SOA : orientée services B Une architecture orientée services est une infrastructure permettant de diffuser des services. B SOA n est pas un concept neuf B Les sites centraux utilisaient déjà la notion de services. B Attention à bien distinguer B SOA Service Oriented Architecture B WSOA Web Services Oriented Architecture Réf ITF0010 Page 32 16

17 Une architecture SOA? B Il n existe pas "une" architecture orientée services ou même des techniques caractérisant une SOA. B La mise en place d'une architecture orientée services répond à un besoin : la réutilisation des traitements B Le contexte de réutilisation de ces traitements va dicter des besoins fonctionnels : interopérabilité, fiabilité, sécurité, hétérogénéité, pérennité, adaptabilité, ACIDité... B De ces besoins fonctionnels vont découler des choix technologiques : couplage lâche pour garantir interopérabilité, asynchronisme pour garantir la fiabilité,... B Les technologies sont au service de l architecture et pas l inverse. Réf ITF0010 Page 33 NON aux objets métiers! B Les objets métiers ne conviennent pas dans le cas des SOA B Les objets métiers sont avec état B A chaque nouveau développement, le fonctionnel évolue, et les objets métiers sont sollicités différemment, ce qui oblige à migrer tous les développements déjà réalisés! Application Application Objets Métiers Physique «Don Box says SOA paradigms will eclipse OO programming» Réf ITF0010 Page 34 17

18 Un Contrat «Objet Métier» Contrat identifiantclient montantht numero recherchercontrat Facturation Contrat identifiantclient couverture numero typedecontrat recherchercontrat Gestion de sinistres Contrat identifiantclient couverture montantttc numero typedecontrat recherchercontrat CRM Réf ITF0010 Page 35 Un service métier ServiceContrat recherchercontrat Contrat identifiantclient couverture montantht numero typedecontrat Réf ITF0010 Page 36 18

19 Un service métier réutilisable ServiceContrat recherchercontrat Facturation Contrat identifiantclient montantttc numero ServiceContrat recherchercontrat Gestion des Sinistres Service Réutilisable ServiceContrat recherchercontrat Contrat identifiantclient couverture montantht numero typedecontrat Données Stockées Contrat identifiantclient couverture montantht numero typedecontrat Contrat identifiantclient couverture numero typedecontrat Application Entreprise Physique Réf ITF0010 Page 37 Construire une application «SOA Compatible» Client Application Objets métiers Entreprise Interfaces : WEB, C/S, PDA ou encore XML Le fonctionnel de mes applications Mon métier réutilisable Mapping Physique Lié à ma structure de données SGBD, CICS, LDAP Réf ITF0010 Page 38 19

20 Inconvénients des modèles à couches B Surcoût de conception B Chaque couche est indépendante, et demande donc une documentation qui définit ses interfaces avec les autres couches B Surcoût de réalisation B Pour une fonctionnalité, il faut impacter plusieurs couches, et coder plusieurs éléments (éventuellement par des personnes différentes) B Surcoût de compétences B Pour palier ces surcoûts la mise en place d un «socle»est indispensable. Réf ITF0010 Page 39 Les motivations d un socle B Éviter que les projets fonctionnels ne deviennent des projets technologiques B Diminuer les pré requis techniques des développeurs fonctionnels B Éviter le besoin d expertise dans la durée sur les projets B Diminuer les coûts de réalisation, de la maintenance et des évolutions B Affranchir les applications du rythme technologique qui condamne les applications à l obsolescence B Canaliser la fantaisie des développeurs B Assurer le dialogue entre le concepteur et le développeur Réf ITF0010 Page 40 20

21 La pile du développement d applications De plus en plus simple Applications Socle technique Architecture J2EE/.Net/LAMP Code procédural Code objet : architecture SOA compatible proposant des meilleures pratiques packagées et prêtes à l emploi Code objet très technique. Réf ITF0010 Page 41 Qu est-ce qu un framework B Le framework répond à un problème technique B Navigation, Persistance, Sécurité B Plus il y a de frameworks plus on se pose de questions B Struts, Tapestry, JSF B Quel framework choisir? B Un framework amène des degrés de liberté aux développeurs B Comment utiliser Struts? Réf ITF0010 Page 42 21

22 La naissance des frameworks B Les frameworks sont nés du retour d expérience sur l utilisation des technologies Application1 Applications Application2 J2EE/.Net/LAMP Application3 J2EE/.Net/LAMP Application4 J2EE/.Net/LAMP J2EE/.Net/LAMP Retour d expériences (capitalisation) Frameworks persistance, IHM, logs,.. J2EE/.Net/LAMP Réf ITF0010 Page 43 Le socle technique package des frameworks B Un socle technique package des frameworks et propose une manière de les utiliser Application1 Applications Application2 Frameworks Application3 Frameworks J2EE/.Net/LAMP Frameworks J2EE/.Net/LAMP J2EE/.Net/LAMP Retour d expériences (capitalisation) Socle technique Architecture SOA Frameworks J2EE/.Net/LAMP Réf ITF0010 Page 44 22

23 Socle technique versus framework B Le socle technique impose B Un socle technique supprime des degrés de liberté aux développeurs B Impose des règles de développement B Impose une architecture B Impose des frameworks «Plus le socle technique est bon moins on se pose de questions» Réf ITF0010 Page 45 Services offerts par un socle technique B Aide contextuelle B Authentification B Habilitation B Configuration B Gestion des erreurs B Internationalisation B Gestion de contexte B Impression B ing B Tests Unitaires B Mapping : Hibernate, LiDO B Existant : CICS, IMS, Tuxedo, PacBase B Client léger B Client riche B Audit B Supervision B Workflow Réf ITF0010 Page 46 23

24 Comment construire son socle technique 1. Développer un socle technique propriétaire 2. Rechercher un socle technique open source 3. Acheter un socle technique à un éditeur Réf ITF0010 Page 47 Développer un socle technique propriétaire? B C est possible, il faut B Un décideur qui a une bonne vision B Une équipe d experts avec un esprit «éditeur» B Du temps B Les pièges B Se lier à une équipe d experts B Réinventer la roue B Manquer de retour d expérience B Manquer de temps B Devoir garder la compatibilité ascendante avec la première application développée avec le socle : on ne peut pas bénéficier du retour d expérience Réf ITF0010 Page 48 24

25 Rechercher un socle technique open source B Il n existe pas de socle technique open source B Il n y en aura certainement jamais, le socle technique est contraire à l esprit open source : le socle technique impose. B Spring, Hivemind ou Pico peuvent être de bon candidat pour construire son socle technique. Réf ITF0010 Page 49 Acheter un socle technique à un éditeur B Aie-aie-aie : Choisir son socle technique chez un éditeur, c est comme choisir son premier FAI B On sait qu il nous en faut un, B On ne sait pas ce dont on a besoin, B On ne comprend pas ce qu ils nous proposent. B C est la solution qui va dans le sens de la réduction des coûts. Réf ITF0010 Page 50 25

26 Que doit apporter un socle technique? B Simplicité B Un développeur fonctionnel ne doit pas avoir besoin de maîtriser les concepts objets, il a un niveau technique faible, il est opérationnel en quelques jours. Un développeur développe du fonctionnel en application le pattern «Transaction Script» Le développement doit être de type procédural. B Martin Fowler : «Transaction script organizes business logic by procedures where each procedure handles a single request from the presentation.» Réf ITF0010 Page 51 Que doit apporter un socle technique? B Qualité B Une application est maintenable si le code produit par un développeur est immédiatement compris par un autre développeur B Votre socle doit canaliser la créativité des développeurs. B Un développeur fonctionnel ne doit pas être confronté à des décisions techniques B Un développeur fonctionnel ne doit pas avoir à retoucher les modèles de conception pour des raisons techniques «Comment je fais pour véhiculer ma connexion base de données entre les couches?» Réf ITF0010 Page 52 26

27 Que doit apporter un socle technique? B Evolutivité B Votre socle technique doit imposer une architecture qui permet de faire évoluer les applications sans remise en cause majeur des développements réalisés B Votre socle technique doit masquer les évolutions des frameworks et des technologies qu il encapsule B Votre socle technique doit lui même être évolutif et proposer une architecture qui lui permette d évoluer. Réf ITF0010 Page 53 Que doit apporter un socle technique? B Industrialisation B Votre socle technique doit pouvoir intégrer la mise en œuvre d outils d industrialisation : assistants et générateurs de code B La mise en production d une application basée sur votre socle technique doit être aisée. Réf ITF0010 Page 54 27

28 Que doit apporter un socle technique? B Exploitabilité B Le code supporté par votre socle technique doit être facilement «exploitable» : Une application basée sur votre socle doit pouvoir produire des indicateurs sur son fonctionnement Temps de réponses Qualité de services Réf ITF0010 Page 55 Adoption B Le problème général lié aux socles techniques vient de leur adoption : les développeurs détestent les socles techniques. B En général les équipes rejettent les socles techniques, elles les considèrent comme mauvais et inutiles B Pire le socle technique est vu comme une aliénation B La gestion de ce conflit est à mener par le chef de projet, il doit toujours motiver les bienfaits du socle technique. Réf ITF0010 Page 56 28

29 Les gains B Réduit le coût journalier du développeur B Standardise B Garantit une qualité dans le cadre de projet au forfait B Rassure le chef de projet et les développeurs B Accélère le démarrage du projet B Améliore la maintenabilité Réf ITF0010 Page 57 Questions? didier Réf ITF0010 Page 58 29

30 Questions? Réf ITF0010 Page 59 Contacts IMPROVE 74/80, rue Roque de Fillol PUTEAUX Tél. : URL : URL : URL : Resp. Commercial : Stève SFARTZ Réf ITF0010 Page 60 30