Would anyone ever argue that nowadays energy trading companies are heavily reliant on IT?

The answer is probably “No”. The challenge is how to make sure that the IT landscape of an energy trading company serves its constantly evolving business demands. On one hand, it is a matter of making the appropriate and timely technology choices, given the multitude of components, interactions and dependencies in the IT landscape. On the other hand, it is all about designing and establishing just the right operating model to manage, run, maintain and improve that IT ecosystem in an optimal way.

Where would the IT function of an energy trading company start from in setting up its operating model? It is both unrealistic and unreasonable to start from scratch and nobody would actually do that. It is also unrealistic to expect that even the most well-designed and well-functioning operating model will remain set in stone forever. It may and will most probably change – why? Because the market would force it to.

Source: Consulting Hexaware, 2021: Shifting from Traditional to NextGen IT Operating

So, what is the starting point? A detailed and honest assessment of where we stand. We must produce a comprehensive snapshot of the technological solutions we have in place, the business needs they are there to meet, and the resources we have allocated to run and maintain those solutions. What comes next is a clear understanding and agreement between all stakeholders on where we want to be. We must be on the same page as to what new/changed/expanded business needs we have to meet – and when. And then comes the gap evaluation: where are we lagging behind and due to what constraints – technological, skills and competencies, capacity, etc.

Let’s assume we have done our gap analysis and identified our bottlenecks. What would drive the decision on how to set up a new, modify or improve the existing IT operating model?

1)    Sourcing strategy

There are multiple factors which influence a trading company’s IT sourcing strategy. From the corporate perspective, it depends on whether or not the trading company is part of a larger holding organization. This would set the priority and importance of the trading activities over other business areas. The parent organization would have a say in the trading company’s long-term strategy, mid- and short-term direction of development, objectives and particular projects in the pipeline. It would also provide the overall vision, secure shared resources, allocate and approve budgets, and set limitations. If the trading company is on its own, that might make decision-making easier but could be a challenge from the budgeting and overall resource allocation perspective.

The choice of a sourcing strategy is also strongly dependent on the company’s internal IT knowledge. We must assess to what extent technical expertise exists internally in terms of scope and depth. We must also be aware whether such expertise is concentrated in the hands and heads of a few key experts, being a black box for the rest of the team, or the knowledge is shared among the IT team, so it can be made explicit, accessible and available to all.

Finally, we must be able to distinguish whether the internal IT expertise brings or helps retain a competitive advantage for the company or not. If it does, how much would it cost – timewise, effort-wise and budget-wise – to keep, update and enhance it. If internal IT expertise is not a core competence yet, is it worth building it, or is it more beneficial to hire external IT service providers who already have the knowledge and experience we need, and who can take responsibility for running our systems and processes with due care.

IT security is another strong influencing factor for the design of a trading company’s sourcing strategy. It involves identifying critical IT systems and components, assessing the risks of outsourcing their maintenance and support, and deciding on the level of control to keep in-house. Loosely coupled architecture is becoming increasingly common for companies with complex business processes and multiple dependencies. It helps limit vulnerabilities and increase the overall resilience of the IT systems and processes. Designing, implementing and operating loosely coupled architecture, however, requires broad knowledge and deep technical expertise which may not be fully or even at all available in-house.

2)    IT landscape complexity

However preferable for security and resilience considerations, loosely coupled IT ecosystems inevitably introduce a lot more complexity in a company’s IT landscape, compared to monolith ones. They normally encompass multiple independent components which need to be integrated and communicate seamlessly with each other, and with the external world.

The level of complexity is determined by various factors in combination, including, but not limited to:

• Do we choose to integrate out-of-the-box IT solutions or to have them custom-developed for us, or do we build them in-house;
• What are the company’s trading business specifics that require dedicated and jointly integrated IT processes for asset management, algo trading, intra-day optimizations, deal booking, scheduling, etc.
• What types of data objects flow in all directions throughout our IT landscape; what source and destination systems are there; how do we carry and transform data along the way;
• What volumes of data do we process at what processing speed; what data management and storage solutions do we use;
• What external systems and platforms does our IT world interact with, what interfaces and interdependencies do we have in place, and how do we manage them to ensure compatibility and smooth communication;
• What monitoring tools do we use and how do we manage error handling;
• What is our IT function’s change management approach and appetite for continuous improvement?

Source: Architectural Thinking Community: complex IT landscape

3)    Vendor competencies and experience

Once we have the big picture of our IT landscape and comprehension of its complexity, we have to choose our vendors in compliance with the company’s outsourcing strategy. The choice of vendors depends first and foremost on their competencies and experience. We need to answer the following questions:

• Do potential vendors know more about the systems and processes we are running than we do?
• Do they have a past record of successful operating experience elsewhere; can we get references?
• How can we test them – via small project/change implementations, testing tasks, particular issue/error investigation and handling?

Other vendor selection criteria would include:

• ETRM domain knowledge
• Understanding of customer’s IT landscape, alongside business-critical processes, and how they fit together
• How do they ensure consistency or continuity of operational competencies and transferability of system, component or process knowledge? Is their operations/support service dependent on individuals’ expertise or on shared knowledge; is it scalable
• Transparency, delivery on promises, expectations management approach
• Past experience/ relationships with our company – trustworthiness and reliability, established communication patterns, vendor company development, etc.

Finally, organizations are made of people. No systems would function and no processes would run without people to use them and people to take care of them. And people make up the organizational culture. No operating model will last without the ‘click’, respect and transparency among all the players in it 😊