Indian Energy Exchange voit la puissance dans un partenariat et une architecture basée sur les services

Indian Energy Exchange (IEX) exploite une plate-forme où les producteurs d'électricité, les services de distribution et les grands acheteurs industriels échangent de l'électricité avant qu'elle ne soit livrée aux utilisateurs finaux. Il a travaillé avec des partenaires pour moderniser son infrastructure et répondre aux changements du marché.

Aucun flux d'électricité via la bourse, juste des données représentant des offres de production, de consommation et de paiement de l'électricité. Étant donné que cette électricité doit être consommée dès qu'elle est produite, la bourse organise régulièrement des enchères pour faire correspondre la demande, qui n'est pas constante mais au moins quelque peu prévisible, et l'offre.

Les échanges avaient lieu sur le marché day-ahead, avec une vente aux enchères organisée chaque jour pour la fourniture de l'électricité du lendemain par blocs de 15 minutes. La plupart des opérations de comptabilité reposaient sur des processus manuels qui pouvaient prendre quatre ou cinq heures. marché (RTM) le 1er juin 2020, avec 48 enchères par jour pour une livraison d'électricité une heure plus tard. variantes. Il intègre les énergies renouvelables de manière efficace et efficiente et fournit le mécanisme permettant de soutenir des opérations de réseau sûres et fiables », déclare Sangh Gautam, directeur technique d'IEX depuis août 2019.

Pour arriver à ce point, il a fallu un changement dans les compétences et le développement d'IEX. culture. Avant l'arrivée de Gautam, dit-il, « Nous faisions en partie ou en grande partie notre développement en interne. Et je pense que nous pouvions clairement voir que si nous voulions passer à une future architecture à la pointe de la technologie, nous devions alors nous orienter vers la création de partenariats technologiques. C'est là que nous avons commencé à travailler avec des entreprises comme Capgemini. Ils ont donné une idée très complète des échanges d'électricité dans le monde, quel type de technologie utilisent-ils ? Dans quelles directions vont-ils ? »

Interfaces ouvertes

Cela a conduit Gautam à conclure qu'IEX devait remplacer son logiciel d'enchères monolithique, en adoptant une architecture basée sur les services plus modulaire connectée via des API ouvertes avec ses membres et la charge nationale. Centre de répartition en charge du réseau électrique. La bourse, ses membres et le NLDC ont également dû automatiser les processus manuels afin de terminer chaque phase de comptabilité dans les 30 minutes disponibles entre les enchères.

« Au niveau du logiciel, nous avons dû relever de nombreux défis car dans notre système existant architecture tous nos marchés utilisaient les mêmes composants… gestion des commandes, gestion des risques, back office, etc. Tous ces composants utilisaient le même logiciel, de sorte que de nombreux calculs d'autres segments de marché se produisaient dans le système en même temps que les tâches RTM étaient en cours », explique Gautam.

Le projet a nécessité un changement de rythme non seulement dans les transactions, mais aussi dans le développement : « Nous pouvions clairement voir que notre culture est différente de celle des start-ups », dit-il. « Nous avons créé un exercice de formation très complet pour notre équipe, sur les nouvelles technologies…. Nous avons dû passer d'une méthodologie de type cascade traditionnelle à une méthodologie agile. Nous avons intégré des outils tels que Jira et les pipelines CI/CD, de sorte que chaque fois qu'un changement se produit, notre équipe est capable de s'adapter très rapidement à ce changement. Nous pouvons allouer notre équipe d'un projet à un autre en un minimum de temps. »

Il a fallu environ huit mois pour construire le marché en temps réel avant son lancement, puis encore trois ou quatre mois pour terminer une partie de l'automatisation des processus et résoudre quelques-uns des problèmes rencontrés au lancement, a déclaré Gautam.

IEX a tiré d'autres avantages de la rupture du logiciel monolithique et de l'ouverture des API. Il a pu intégrer la plate-forme de négociation à son système financier dans SAP, éliminant les éléments manuels de certains processus de règlement de back-office et lui permettant de payer les participants du marché en quelques minutes, et non en quelques heures, dit-il.

Gautam a tenu à intégrer commentaires des clients dans le processus de développement. « Nous enracinons cela dans notre culture, en recueillant les commentaires des clients. Ainsi, même notre équipe technique est impliquée dès le premier jour. Nous parlons à un client, afin qu'il comprenne exactement ce que sont les processus de pensée du client, de sorte que la culture devait également être intégrée à l'équipe. avec les nouvelles API, les participants aux enchères n'étaient pas limités à l'interface utilisateur fournie par IEX : ils peuvent créer la leur. « Un système intuitif pour un client peut ne pas l'être pour d'autres. Avec les API membres, nous avons également donné cette liberté, qu'ils peuvent facilement les créer eux-mêmes », explique Gautam.

Ajout de redondance

Il y a eu des évolutions dans l'infrastructure sous-jacente, pas seulement dans l'interface utilisateur. Le système d'échange est construit sur un environnement virtualisé avec une redondance matérielle au niveau de la machine pour une haute disponibilité, et une redondance supplémentaire dans le logiciel et même au niveau des tâches. Il existe également des machines de sauvegarde de sorte que même si un composant d'un processus RTM particulier échoue, il peut basculer vers la machine de sauvegarde de manière automatisée, en quelques secondes. Cela a été fait pour assurer une disponibilité à 100%, dit-il.

Sur les grandes transformations comme celle-ci, Gautam dit qu'il est important de commencer par la vision technologique, puis de commencer à combler les écarts entre la réalité actuelle et cette vision, un par un. , en s'appuyant le cas échéant sur l'expertise des partenaires.

Il est également important de prévoir quand les choses tournent mal, car elles le feront inévitablement. "Lorsque nous concevons le système, il doit être conçu dès le premier jour en pensant à l'auto-guérison", dit-il.

Alors que les technologies d'auto-guérison peuvent sembler lointaines dans certains domaines, un autre mot d'ordre de Gautam, la surveillance, aide à faire le pont. cet écart : « Tous les systèmes que nous avons, du matériel au logiciel en passant par chaque processus que nous avons, presque, nous les surveillons tout le temps. Des alertes sont mises en place. Dès qu'il y a une alerte, notre équipe système reçoit l'alerte, alors ils sont au courant. »

« Nous réfléchissons même à la façon dont nous pouvons intégrer ces alertes dans un système d'auto-guérison. Certains d'entre eux ont été intégrés, et maintenant nous nous dirigeons vers la façon dont nous pouvons faire plus », dit-il.

Ce ne sont pas toujours des humains à la recherche de problèmes : dans certains cas, c'est un bot logiciel, dit Gautam. « En cas d'échec, notre système détecte automatiquement qu'il y a un problème et déclenche une alerte. Il y a des instructions spécifiques pour le bot sur la façon de résoudre ce problème, que le bot est capable d'exécuter. »