Some Things Never Change
When I first started working in the ETRM space, some 10 or so years ago, the issues of the day were reporting and integration.
No customers of vendor supplied systems were happy with the reports offered with the systems and their architectures were such that writing custom reports was difficult and painful. System vendors spent a significant amount of their time preparing custom reports for their clients, often “one offs” - rarely reusable for other clients. While it could be a great source of revenue for the vendors, it didn’t lend itself to high levels of customer satisfaction. Vendors were sincere in their efforts to make their systems more report friendly, packaging reporting apps with the systems, creating “reporting databases”, and working with user groups to try to define canned reports that would be of the most value. Still, as every client had (and has) unique requirements that reflect their business processes and culture, there was rarely common ground.
Integration was, in the mid 90’s, certainly a less complex problem than it is today. The early clients of “canned” software had relatively simple requirements. These early adopters didn’t have particularly high expectations of wiring their ETRM system into a complex of multiple price feeds, on-line exchanges, and massive ERP systems. In most cases they were content with file transfers to and from their ETRM systems, or even manual data entry. However, once the middleware vendors discovered the energy space, expectations began to change. The promise of Tibco and its competitors was that you could “seamlessly” ship data around to your various systems like so much gas through a pipeline network. Of course the reality was much more complex than the promise, but the idea of accelerating information had caught on and had raised the bar for ETRM vendors to make their systems more integration friendly. Many started imbedding middleware code with their systems or they created broad, wide ranging API’s for moving data and information back and forth to the many ancillary systems that needed to interact with their ETRM systems.
Fast forward to this week…not much has changed. I had the pleasure of attending Deloitte’s ETRM roundtable event in Las Vegas (one of the best events of its type for bringing together IT leaders in energy) earlier this week. At the opening of the event, each attendee was asked to describe their biggest ETRM issue. Without fail, each of the 30+ attendees described the same issues that have persisted for more than a decade. Despite improvements in architectures, technologies, and code quality, reporting and integration are still at the top of the list of issues for users of ETRM systems.
So the question has to be asked - Why are we today faced with the same issues that dogged ETRM users in the early and mid 90’s? Probably the best answer is that while the description of the issues remains the same, reporting and integration, the underlying expectations have changed. The advent of middleware, data warehouses, n-tier architectures, xml, business intelligence tools, dynamic report writers with Excel export capabilities imbedded in applications, and a raft of other technology advances have raised the bar for users of ETRM systems. The one-way price feeds of 10 years ago have become duplex communication channels from multiple transaction management systems, on-line exchanges, and global multi-commodity risk management systems. The gas position and P&L reports of yesteryear have become the multi-commodity, multi-currency propriety “information cubes” providing ad-hoc “slicing and dicing” by time period, desk, and strategy with multi-scenario stress testing.
Despite the advance of technology, time and time again, a simple truth emerges in energy trading and risk management…technology will always lag business requirements. It’s the nature of beast. Technology advances in fits and starts, with new solutions requiring development, testing, and implementation. Business advances constantly and consistently; everyday an imaginative trader will create a new derivative pricing scheme or the head of a trading floor will see an opportunity in a new commodity. Regulations, corporate governance, and business conditions change without regard to the IT impacts. Evolving business require evolving systems. New systems are introduced into the trading information chain, either replacing old or incremental to what was there, necessitating difficult integration updates. New trading strategies, evolving “best practices” in risk management, and new requirements in regulatory or corporate governance will require new ways of looking at information and, therefore, new reports.
Despite the best efforts of any IT shop and the quality of the tools they deploy, they will always be playing catch up, running as fast as they can to try to keep even with business requirements.