FIS: The Evolution from Legacy ETRM to Modern Cloud-Native, AI-Powered Solution by CTRM Center

CHAPTER 1: THE RISE OF CLOUD-NATIVE ETRM AND ITS CRITICAL IMPORTANCE

Migrating ETRM solutions to the cloud has become standard practice in today’s market. Almost every tender for ETRM/CTRM implementations now requires cloud deployment, often alongside a Software-as-a-Service (SaaS) offering. However, it’s important to understand that cloud deployment alone doesn’t equate to being cloud-native, nor does it enable solutions to fully capitalize on the cloud’s potential benefits.

What Does Cloud-Native Really Mean?

Cloud-native doesn’t simply refer to where an application is hosted, but rather how it is built and deployed. According to IBM, cloud-native applications are composed of discrete, reusable components known as microservices , which are designed to integrate seamlessly into any cloud environment. Here’s what makes cloud-native different:

• Microservices Architecture: A cloud-native application consists of independent microservices, each designed to perform specific tasks. These microservices are packaged in containers and serve as modular building blocks.

• Containerization: Containers allow microservices

Why Should Energy Companies Prioritize Cloud-Native ETRM Solutions?

Cloud-native solutions are built to maximize the advantages of cloud infrastructure, offering greater scalability, flexibility, performance, and costefficiency than simple cloud-hosted solutions. Here’s

to run independently, ensuring greater efficiency and resource optimization. This containerized environment enables applications to scale quickly and easily.

• Automation and Orchestration: Cloudnative applications leverage automation tools like Kubernetes for managing and orchestrating containers. This streamlines operations, allowing continuous delivery, scalability, and high availability.

• Flexibility and Agility: The modularity of microservices allows for rapid iteration, continuous improvement, and independent scaling of components, making cloud-native applications more flexible and agile than traditional applications.

why this is important for energy companies:

1. Dynamic Scalability: Cloud-native applications are built to scale dynamically. As energy markets fluctuate and demand spikes, these applications can automatically scale resources vertically or horizontally. Containerized environments optimize resource usage, ensuring that each service only

uses what it needs, when it needs it. Resources can be spun up or down in seconds, making cloudnative solutions highly responsive to changes.

2. Resilience and Fault Tolerance: Cloudnative architectures are distributed and use containerization, which ensures that the system remains operational even if some components fail. Kubernetes and other orchestration tools can automatically monitor and restart failed services, ensuring high availability and reducing downtime.

3. Cost Efficiency : By optimizing resource usage and enabling dynamic scaling, cloud-native solutions can significantly lower operational costs. Since services consume only the necessary computing resources, companies avoid over-provisioning, leading to more efficient spending.

4. Simplified Infrastructure Management: With tools like Kubernetes automating much of the infrastructure management, it becomes easier to deploy and manage complex, distributed systems. Cloud-native solutions eliminate many manual processes, increasing operational efficiency and reducing the risk of errors.

5. Enhanced Security : Container-based isolation adds an extra layer of security by minimizing risks related to inter-process communication. Each microservice operates independently, reducing the surface area for attacks and improving overall system security.

6. Continuous Integration and Continuous Delivery (CI/CD): Cloud-native development allows for faster, more frequent deployments. Developers can push updates, implement new features, and fix bugs without disrupting the entire application. This speed and agility give energy companies the competitive advantage of quickly responding to market changes or regulatory updates.

In other words, while simple cloud deployment moves applications to the cloud, cloud-native solutions are purpose-built to take full advantage of cloud infrastructure, offering unmatched scalability, resilience, cost savings, and security. For energy companies running ETRM systems, transitioning to cloud-native solutions is a crucial step toward achieving long-term operational efficiency and technological innovation.

In addition to these advantages, cloud-native solutions offer access to cutting-edge tools, including GEN AI capabilities provided by leading cloud vendors. Established providers like Amazon, Microsoft, and Google are at the forefront of technological advancements, continuously enhancing their cloudbased services. By adopting cloud-native architecture, energy companies can tap into these innovations, positioning themselves for future growth and competitive advantage.

CHAPTER 2: TRANSITIONING LEGACY ETRM SYSTEMS TO MODERN CLOUD-NATIVE SOLUTIONS

If developing an ETRM system from scratch today, vendors would naturally opt for a cloud-native architecture. However, ETRM systems cover highly complex processes across the front, middle, and back office, and building all the functionality needed to properly support these processes takes years, as experience shows. Established, legacy ETRM systems, especially those used by major multi-commodity trading companies and large utilities, offer an enormous functional scope and the flexibility to model complex workflows and custom analytics. Rebuilding this level of functionality from the ground up would take years.

Newer entrants to the ETRM/CTRM market are offering cloud-native solutions that, while limited in functionality, provide great flexibility and toolkits for custom developments. This approach is gaining traction, especially among energy companies with large development teams who can build additional functionality themselves. However, many energy companies still require extensive out-of-the-box functionality and would prefer a cloud-native solution.

So, how are software vendors with large, legacy ETRM systems responding to this demand? There are a few common approaches:

1. Lift and Shift: Deploy the existing software in the cloud without fundamentally changing the architecture.

2. Build a New System from Scratch: Develop a new cloud-native system in parallel, eventually replacing the legacy solution in a “big bang” approach.

3. Phased Approach: Gradually rebuild the legacy architecture, step by step, while preserving existing functionality.

Let’s explore the pros and cons of each strategy.

1. Lift and Shift

The Lift and Shift approach enables vendors to offer a cloud-based solution without making it cloud-native. While this might satisfy customers for whom the cost of replacing their legacy systems is prohibitively high, they would miss out on the full advantages of cloud-native environments, at least in the short term. For vendors, this approach is relatively straightforward and low risk, but it limits the potential for attracting new customers seeking modern, cloud-native solutions.

2. Building a New System from Scratch

Developing a completely new ETRM system while maintaining the legacy one is highly challenging.

Vendors must continue to implement new functionality in both systems to keep up with market changes and customer needs. The longer it takes to develop the new solution, the more “double work” is required. The vendor must maintain and enhance both solutions until all customers have migrated off the old solution to the new solution.

Convincing customers to migrate to the new solution is another challenge. If the vendor doesn’t offer an easy, automated migration process, the cost of upgrading might be so high that customers could decide to explore market alternatives rather than sticking with the same vendor.

This approach also creates organizational hurdles. Development teams must be split between maintaining the legacy system and building the new one. As time passes, maintaining the legacy system becomes more labor-intensive, particularly due to the need to keep up with third-party software updates and to security patches. As a result, the team working on the legacy system may grow, slowing progress on the new solution. Given that it can take years to build a fully functional replacement, there’s a risk of a never-ending development.

Additionally, long development times bring financial risks. Throughout the development process, the company incurs costs without seeing any revenue from the new system. Changes in company’s ownership, shifts in management objectives, or economic downturns could lead to budget cuts or even the termination of the new project.

3. Phased Approach

The Phased Approach offers a more gradual transition and comes with several advantages over the “big bang” strategy:

1. Incremental Technical Upgrades: New developments can be rolled out incrementally and customers will see immediate improvements, providing additional reasons for customers to upgrade along the journey.

2. Minimizing redundant development: While some development effort may be duplicated across versions to address market changes, it is substantially reduced when compared to the big bang approach.

3. No Organizational Split: The same team can work on both new developments and legacy system maintenance as part of the regular release cycle.

4. Continuous Improvement: Each release brings incremental improvements. Even if the transition is delayed the system will be continually improving towards the end goal.

However, this approach also has challenges. Until the full transition is complete, the system may exist in an intermediate state that is less user-friendly for some customers. Therefore, it is important to adopt such steps of the transition that would minimize the potential issues with user experience.

The phased approach can also take longer than the big bang strategy due to the complexity of the process. Moreover, when customers upgrade from an older version to the latest release with architectural changes, the process could be just as costly as in a big bang

scenario. Therefore, it is especially important to move customers to newer releases along the journey.

In summary, while each approach has its pros and cons, the best strategy depends on the vendor’s resources and customer needs. For companies looking for quick wins, a lift and shift may suffice temporarily. For those seeking a modern, cloud-native experience with minimal disruption, a phased approach offers the most practical path, balancing gradual improvements

with continuous customer engagement. For smaller ETRM systems, used by companies with simpler business tasks, the big bang approach can prove more reasonable, as vendors may be able to finish the new solution rather quickly. The more limited scope of functionality allows for a faster rebuild, minimizing most of the risks of this approach. Ultimately, the choice of strategy should be aligned with the complexity of the system and the customers’ appetite for change.

CHAPTER 3: FIS CLOUD JOURNEY: SUCCESSES AND LESSONS LEARNED

The FIS decision to start the phased approach was taken in the early days of cloud technology. It was based on the understanding that cloud technology would continue to evolve rapidly during this journey. The journey started with the main component / services moving into containers ensuring they could run on multiple platforms leveraging all the benefits of container orchestration. The code update allowed FIS to take advantage of self-healing, high availability, elasticity and cloud services like serverless computing, relational database services, integration with datalakes and reporting tools, etc.

As cloud architecture standardized, the way forward became clear. FIS adopted the best available cloud technology as it matured, and this naturally resulted in a step-by-step implementation approach. The evolutionary process included externalization of all configurations to start with, and then the full adoption of containers. FIS later moved to Deployment as Code where all configurations are gathered in one repository. This was followed by system wide horizontal scalability and as well as high availability support. With

the latest release, FIS offers managed deployments, fully automated environment provisioning along with database setup and application installation.

The process involved not only a desire to adopt the latest technology but also a careful evaluation of options to align the FIS Energy Group’s strategy with the broader FIS corporate direction. For a large software company like FIS, leveraging synergies across various business units and ensuring support at a

corporate level is essential. Each phase of this evolution included revisiting earlier decisions, making necessary adjustments, and navigating future steps to balance both corporate strategies and customer requirements.

Collaboration with customers and professional service teams has been crucial in this journey. Technologically advanced customers, also striving for a cloudnative solution, played a key role by sharing their experiences, providing detailed requirements, offering recommendations, and testing new software versions. This partnership helped shape the development process and ensure alignment with real-world needs.

Security is paramount in cloud solutions, and naturally, access to cloud servers is more restricted compared to on-premises installations. FIS offers full management of customer environments through its Azure-based tenant, which includes extensive security measures in addition to those provided by the cloud itself. However, this enhanced security also brings limitations, especially for customers accustomed to full control over their onpremises environments. For instance, tasks such as modifying service folders, running queries, creating users, and defining access rules now require submitting requests to FIS and waiting for the service team to accomplish the work, potentially leading to delays and reduced flexibility compared to on-premises solutions.

To address these challenges, FIS introduced the Client Control Panel , which empowers customers with selfservice capabilities for efficiently managing their FIS cloud-hosted platforms. This tool allows users to handle key tasks independently, without needing to wait for FIS

intervention. These tasks include managing users (e.g., creating and editing users, resetting passwords, and unlocking accounts), handling SFTP via GlobalScape for FTP processing, managing folder access, monitoring storage usage, and running database queries through a query manager. The control panel is an example of FIS’s corporate-wide technology that benefits various products and is maintained exclusively by FIS.

One of the key lessons learned, as the Head of Product Development for Energy at FIS Fernando Guzman pointed out, was the human factor. Implementation teams were accustomed to working with VMs (Virtual Machines), network drives, Windows schedulers, and batch files. Transitioning to containers marked a fundamental shift in how they approached their work. This change, combined with the more stringent security protocols required in cloud environments, was a significant adjustment for many teams. There was a learning curve for everyone—from development to services and support teams—as they adapted to the new container-based architecture.

The learning process was twofold. On one hand, the development team needed to gain a deeper understanding of implementation challenges to provide tools that would simplify the work of professional service teams. On the other hand, implementation teams had to adapt to a new way of working, realizing that containers, unlike VMs, come with both unique advantages and considerations that required a fresh approach.

When asked what factors indicate the strategy’s success, Fernando highlighted two key points:

• Successful Major Version Upgrades: Early cloud adopters are currently undergoing a “major version upgrade,” including the latest software version. This process serves as a validation of FIS’s success in delivering a cloud-native solution. It will demonstrate how well the system has been automated, its resilience, and the efficiency of the upgrade process.

• Customer Satisfaction with Containers:

Several customers are already running containerized

versions of the software and are pleased with their operation and the seamless application of service pack upgrades.

Overall, this journey has shown that adopting a cloudnative strategy requires more than just technical changes—it demands alignment with customer needs, adjustments to customer’s integration, a willingness to learn and adapt, and a continuous focus on delivering practical, scalable solutions.

CHAPTER 4: THE ROLE OF AI IN MODERN ETRM SYSTEMS

AI is generating significant interest in the industry as companies see potential for substantial improvements in user experience and automation. Many vendors offering ETRM systems are either actively integrating AI tools or at least exploring future integration possibilities.

AI has broad applicability across energy trading, spanning front-, middle-, and back-office operations. The most notable applications are in the front- and middleoffice, where AI is being utilized for natural language interfaces, enabling seamless software interaction for tasks like reporting or deal entry. Additionally, AI plays a key role in predictive analytics, market data analysis, and decision support, offering robust tools to analyze vast amounts of data—areas where AI adoption is particularly strong today.

In the back office, AI has the potential to automate laborintensive tasks such as reconciliation and regulatory compliance reporting and significantly facilitate user

training processes. Furthermore, AI can streamline interface-building by automatically transforming incoming formats and importing data based on API documentation.

One of the key benefits of using cloud-based ETRM solutions is access to advanced, cloud-native AI tools offered by major cloud providers. This enables companies to leverage AI services without the need for costly in-house development, a strategy that FIS has embraced. FIS began by utilizing an AI service for Power BI reporting available through Azure.

Reporting is one of the most complex aspects of ETRM

systems for several reasons. Reports are typically highly customized, requiring flexibility and tools that allow clients to create reports independently of the vendor. Furthermore, reports can be complex, often demanding a deep understanding of the data model and development skills for writing queries, creating views, and performing calculations within the report. Azure’s AI services allowing natural language-driven report creation made this process more accessible. FIS has adopted this service as a “low-hanging fruit” due to the high demand for flexible, user-friendly reporting.

FIS is enhancing the reporting capabilities by feeding Azure AI services with a semantic model, which interprets the data tables and views used for reporting. Users can simply request data using natural language

and format it into tables or graphs via Power BI, without needing any development expertise.

Data security is a critical concern, particularly when using AI services. FIS addresses this by employing Microsoft Copilot to connect with Power BI, ensuring that the data is strictly used for reporting purposes.

As Fernando notes, AI-based reporting is just the beginning. The most advanced AI tools provided by major cloud platforms can and should be utilized to extend the capabilities of ETRM systems across all areas—from front to middle to back office—paving the way for a more efficient and intelligent energy trading ecosystem.

CHAPTER 5: FUTURE OUTLOOK – THE PATH AHEAD

The next steps on FIS’s roadmap revolve around achieving continuous delivery (CD) as the ultimate goal of the cloud transformation. Continuous delivery automates the entire lifecycle— from build to testing, configuration, and deployment—ensuring new code moves seamlessly from development to production with minimal delay. By automating infrastructure creation and deploying builds across successive testing environments, CD allows for rapid iteration and testing, keeping production systems up to date with the latest features and fixes.

In practice, this means shorter, more frequent upgrade cycles, with automated deployment and testing of each patch. FIS has already implemented automated deployment processes for patches and releases, achieving a key milestone in its journey toward

continuous delivery. The next focus is expanding test automation to cover a wider scope of functionalities, ensuring the reliability and efficiency of future releases.

Another significant direction for FIS’s research and

development is the broader integration of GEN AI services. Currently, FIS is leveraging existing AI offerings from Microsoft, such as Copilot and Azurebased services. The next step would be to improve user training processes using AI tools. AI can significantly enhance user experience by improving user guides, conducting training tasks, responding to queries, and providing fast, context-sensitive answers from documentation. AI can also play a game changer role in predictive analytics, Monte Carlo simulations, and other advanced functions—areas where FIS will explore further applications. There are many AI vendors offering such services in the cloud and possible integration would significantly enhance ETRM analytical capabilities, Fernando told me.

For a complex cloud-native ETRM solution, a vast array of cutting-edge technologies is now available, offering numerous paths for innovation. The key focus for FIS is to carefully assess the options, select the most appropriate technologies, and integrate them in a way that aligns with both customer needs and FIS’s broader corporate strategy. As Fernando notes, the cloud journey will never end. However, FIS has already completed the foundational steps toward creating a fully cloud-native solution. With this groundwork laid, the team is now poised to fully embrace and capitalize on the latest advancements in cloud technology, AI, and automation, setting the stage for continuous improvement and long-term innovation.

ABOUT

Commodity Technology Advisory LLC

Commodity Technology Advisory (ComTech Advisory) is the leading analyst organization covering the Energy and Commodity Trading and Risk Management (E/CTRM) and Energy Transition technology markets. Led by Dr. Gary M. Vasey, along with affiliate analysts Dr. Irina Reitgruber and Kevin Mossop, ComTech Advisory provides invaluable insights, backed by primary research and decades of experience, into the issues and trends affecting both the users and providers of the applications and services that are crucial for success in markets constantly roiled by globalization, regulation and innovation.

For more information, please visit: www.comtechadvisory.com

ComTech Advisory also hosts the CTRMCenter and the ETTCenter your online portal with news and views about commodity / energy markets and technology as well as a comprehensive online directory of software and services providers

Please visit the CTRMCenter at: www.ctrmcenter.com

Please visit the ETTCenter at: www.ettcenter.com

Vyhlidalova 823/19

625 00 Brno Czechia

ComTechAdvisory.com

Phone: +420 775 718 112

Email: info@comtechadvisory.com