Architecture Data as a Service
Présentation réalisée lors du Mardi de l’Urba-EA du 15 Mars 2016
Retour d’expérience de SUEZ sur la mise en place d’une Architecture Data as a Service par Frédéric Charles, en charge de la stratégie et Gouvernance du SI, et d’Olivier Gavois, responsable de l’architecture, à la DSI de Suez Eau France.
Le retour d’expérience décrit la plate forme mise en œuvre par Suez Eau de France pour « digitaliser » ses relations avec
- Les collectivités locales dont elle assure le service de l’eau (relations de type B2B)
- Les usagers de ces services (relations de type B2C).
- Les tiers dont elle utilise des informations ou auxquels elle en fournit (relations d’Open Data)
La plate forme est construite selon deux principes d’une architecture de SI data centric :
- Découplage des données et des applications, ici, via un datastore
- Accès systématique aux données via des services et des API
L’architecture de la plate forme est constituée
D’un portail B2B pour servir les collectivités locales, et d’un portail B2C pour les usagers des services de l’eau,
D’une Open API pour les relations d’Open Data avec les tiers
- En back end, des applications du SI (SILDE)
- Entre les deux, d’une couche de données et services qui découple les portails des applications du SILDE et donne toute son agilité à la plate forme en permettant de construire très rapidement de nouveaux services.
La couche de données et services est constituée de plusieurs composants, notamment :
- Une plate forme API (API Gateway) qui fournit aux portails des services d’accès aux données. Pour les services B2B, cette plate forme s’appuie sur un annuaire des agents des collectivités locales et de leurs droits.
- Un Datastore, qui regroupe et structure les données de référence produites par les applications du SILDE, ce datastore servant de hub et republiant les données vers les applications.
- Un ESB qui orchestre les services demandés par la plate forme API.
L’architecture de la plate forme est le résultat d’évolutions du SILDE menées depuis plusieurs années, du développement de services web dans les années 2010 jusqu’à la mise en œuvre sur 2014-2015 d’une démarche API volontariste, en passant par la mise en place d’un ESB et du Datastore ainsi que par le remplissage de ce dernier.
Le projet TSMS de structuration des relations avec les collectivités locales (B2B) a eu un rôle décisif car il a permis de financer la mise en place de la plate forme et d’arrêter les choix d’architecture structurants.
La plate forme est évolutive et se complète au fil du temps : ajout de la GED, Search et Open Data en 2015, gestion des évènements et des mobiles prévus pour 2016.
Le développement de produits et services offerts par la plate forme comporte trois grandes étapes :
- En amont, dans le cadre de roadmaps, la définition des services est concrétisée par la réalisation de maquettes validées par les utilisateurs et accompagnées d’une définition des API utilisées, précise et pré requise à la phase de développement.
- La phase de développement réalise en mode agile les fonctionnalités des portails.
- La phase de livraison et de déploiement fournit aux utilisateurs les services attendus et en assure le support.
Parmi les enseignements du retour d’expérience, il faut retenir la nécessité
- D’anticiper les sujets de données, car ils avancent moins vite que les portails
- De structurer fortement les API dès le départ.
- De s’organiser pour gérer les versions des API (en 2015, 150 versions pour 60 API gérées).
Toutes les publications du club
