Recommandé
Contenu connexe
Similaire à Région Bretagne - du développement classique au modèle "low code": un retour d'expérience
Similaire à Région Bretagne - du développement classique au modèle "low code": un retour d'expérience (20)
Région Bretagne - du développement classique au modèle "low code": un retour d'expérience
- 1. Simplicité pour la DSI : un retour d’expérience Du développement « classique » au modèle « low code » à la Région Bretagne Benjamin Buffereau – Rosanne Quily (prenom.nom@bretagne.bzh)
- 2. 2 Préambule Le « low code », tout le monde en parle Gartner, Forrester, Le journal du Net, ZDNET, … Dois-je y aller, quels sont les bénéfices, les limites ? Notre expérience peut vous aider à vous faire votre opinion
- 3. 3 Sommaire Contexte Pourquoi Simplicité ? Mise en œuvre Bilan & perspectives
- 4. Contexte
- 7. 7 La DSI Les besoins 17 directions clientes 141 dispositifs d’aide 130 applications 70 demandes de projet / an 30 sites (+ 15 lycées / an) 1600 PC, 500 téléphones 23 000 demandes d’intervention/an Les ressources 53 agents (1,2%) 4 M€ (0,25%) Démarche qualité Orientation client Organisation en processus Amélioration continue Stratégie de maîtrise du SI Industrialisation, productivité Technicité Innovation Urbanisation
- 8. 8 Une offre de services alignée sur la stratégie d’urbanisation Usagers Agents Partenaires Applis métiers - produits éditeur - « no code » - « low code » - dev spécifique Portails : JCMS Interconnexion d’applications - Bus de services Blueway - ETL Pentaho Data Integration
- 9. 9 Le développement à la DSI 1 ingénieur, 3 techniciens Développement : 5 à 10 applications / an Maintenance : 51 applications en production Intégration au SI, interconnexion d’applications Urbanisation, conseil, expertise technique Sous-traitance capacitaire
- 11. 11 Les limites du développement « from scratch » Répéter tous les 2 ans : Choisir une pile de frameworks JEE Les packager dans un template adapté à nos besoins Former les développeurs AppFuse 1.9, AppFuse 2.0, EJB+Flex (Play!, Jhipster, …) Ca marche, mais … On réinvente la roue Pas de mutualisation des fonctionnalités « avancées » Parc applicatif hétérogène Maintien de compétences coûteux Frilosité à faire évoluer les « vieilles » applis Plus de maintenance, moins de nouvelles applications Moins de valeur ajoutée pour nos clients
- 12. Mise en œuvre à la Région Bretagne
- 13. Chronologie 2 3 3 5 8 4 2 2 1 1 2013 2014 2015 2016 2017 Applications Développeurs Vir’volt Agenda des manifestations Karta Gestion des dispositifs Evaluation des besoins Carte des formations Préparation budgétaire Fréquentation des points Région Gestion des ressources Equipement des lycées Gestion des risques Gestion de la qualité Gestion des marchés Extranet recherche Evaluation des organismes Agrément des formations Aide à la création d’entreprises … - Formation - Intégration - Chartage - Modules communs - 1ère application d’envergure - Audit ergonomie & évolutions éditeur - 1ère application paramétrable - Tests de charge & évolutions éditeur - Mort de Flash => refonte du parc d’applications Flex - Début de refonte du parc d’applications AppFuse
- 14. mai 17 14 Une Démo ! http://dev.region-bretagne.fr/crbsimplicite/ http://rec.region-bretagne.fr/crbsimplicite/ http://applications.region-bretagne.fr/crbsimplicite/
- 16. 16 Simplicité vs. Développement JEE classique Avantages Plus vite : réactivité, productivité Mieux : maintenabilité (patches Simplicité), fonctionnalités mutualisées, fiabilité Différemment : agilité, prototypage>implémentation, métiers mieux associés Maturité & adaptabilité de la PF La relation à l’éditeur ! Inconvénients Les développeurs restent indispensables ;-) Montée en compétences Pénurie de prestataires L’expérience utilisateur ! L’opacité (effet « boîte noire ») La communauté encore balbutiante
- 17. 17 Simplicité vs. Force.com Points forts de Simplicité Modèle de données Intégration au SI Technologies standards (JEE, relationnel) Réversibilité source : journalDuNet
- 18. 18 Nos attentes Modernisation de l’UX Effet « wahou » Orientation grand public, « zéro apprentissage » Meilleure intégration au SI SSO Amélioration du multi-app en cas d’accès direct à une application Développement d’un réseau d’intégrateurs DevOps Intégration continue, déploiement continu Gestion du code source des modules Simplicité Documentation / communauté
- 19. 19 Conclusion Les bonnes raisons d’y aller maintenant Une DSI qui veut aller de l’avant Un besoin d’industrialiser les développements et la maintenance de nombreuses applications Des besoins de type « back-office » assez répétitifs Des capacités de développement en interne (ou une volonté d’y revenir!) Les freins possibles Des besoins majoritairement « front-office » Des développements entièrement externalisés (et vous êtes en province ;-)