Five decisions before selecting or replacing an ETRM platform
ETRM programmes rarely fail because a platform lacks a feature. They fail because the operating model was never agreed, the data foundation was underbuilt, and change was attempted as one unsteerable monolith. This guide sets out the decisions that actually matter.
The programme that ossified
Somewhere in every energy and commodity trading organization there is a memory, or a live example, of an ETRM programme that went wrong. It was not chosen carelessly. A serious selection process ran, a capable vendor was picked, a substantial budget was committed, and integrators were engaged. And yet, two or three years later, the platform is late, over budget, resented by the desk, and so heavily customized that upgrading it is unthinkable. It has ossified: frozen in place, expensive to run, and impossible to change.
The instinct afterward is to blame the platform. It lacked a feature; the vendor over-promised; the integrator underdelivered. Occasionally that is true. But far more often the platform was capable and the programme failed for reasons that had nothing to do with software features and everything to do with decisions that were never made, or were made implicitly and wrongly, before a single line of configuration was written.
This guide is about those decisions. It is written for the CIO, the head of trading technology, or the transformation lead who is about to select or replace an ETRM platform and wants to avoid joining the long list of programmes that ossified. The decisions it describes are unglamorous, and precisely because they are unglamorous they are the ones that get skipped. Skipping them is how capable platforms become expensive monuments to a programme that lost its way.
ETRM programmes rarely fail because a platform lacks a feature. They fail because the decisions that determine success were never made explicitly.
Five decisions before selecting or replacing an ETRM platform in one view
Why feature comparisons mislead
The center of gravity in most ETRM selections is the feature comparison: a vast spreadsheet of requirements, scored against each vendor, tallied into a recommendation. This artifact feels rigorous, and it absorbs enormous effort. It is also, on its own, one of the most misleading instruments in the whole process, and understanding why is the first step to a better selection.
The problem is that modern ETRM platforms are broadly capable. On a feature checklist they converge, because any serious contender can capture a trade, keep a position, value a book, and compute a risk number. The checklist therefore discriminates poorly on the things that actually matter and discriminates strongly on things that do not, the presence of a checkbox rather than the quality of the workflow behind it. Two platforms can both tick a requirement while offering wildly different experiences of meeting it, and the checklist cannot see the difference.
Worse, the feature comparison distracts from the decisions that genuinely determine success, which are not about features at all. It lets a programme feel diligent while avoiding the harder questions of operating model, data foundation, and change strategy. A selection that produces a beautiful comparison matrix and never resolves those questions has optimized the wrong thing, and it is heading for the ossified outcome regardless of which capable platform it picks.
The five decisions that actually determine the outcome
Beneath the selection process sit five decisions that determine whether an ETRM programme succeeds or ossifies. None of them is about which vendor to choose; all of them shape whether any chosen vendor will succeed in your environment. Make them explicitly, early, and honestly, and the platform choice becomes almost secondary. Skip them, and the best platform in the world will still ossify.
Decision one: agree the operating model first
An ETRM platform implements an operating model, how trades are captured, who owns positions, how P&L is struck, how risk is governed, how the front, middle, and back offices interact. If that operating model is not agreed before implementation, the platform becomes the place where unresolved organizational disagreements go to fight, and configuration becomes a proxy war between functions that never aligned. The result is endless customization as each function bends the system toward its own unspoken model.
Agreeing the operating model first is the single highest-leverage decision in an ETRM programme, and it is the one most often skipped because it is organizational rather than technical and therefore uncomfortable. The desks, risk, finance, and operations must agree how the business will actually run before the platform is configured to run it. A programme that configures first and aligns later is building on sand, and it will feel the movement for years.
Decision two: build the data foundation deliberately
An ETRM platform is only as good as the data flowing through it: reference data, market data, curves, and the trades themselves. Underbuild that foundation and the platform inherits the weakness, producing positions that do not reconcile, valuations no one trusts, and risk numbers that are quietly wrong. Most of the pain attributed to ETRM platforms is in fact data pain, surfacing through the platform rather than caused by it.
The decision, therefore, is to treat the data foundation as a deliberate build in its own right, not an afterthought bolted to the implementation. Reference data needs ownership and quality. Market data and curves need validated, governed pipelines. The trade capture path needs to produce clean, complete records at source. Programmes that invest here get a platform that can be trusted; programmes that skip it get a platform that is blamed for the data's sins.
Decision three: choose a change strategy, not a big bang
The instinct on a large ETRM programme is to attempt everything at once: all desks, all instruments, all functions, in one great cutover. This is the change strategy most likely to fail, because it maximizes risk at exactly the moment the organization understands the new platform least. A big-bang cutover asks a business to trust an unproven configuration with its entire trading operation on a single day, and when something is wrong, and something is always wrong, there is no fallback.
The alternative is to slice: deliver the platform in increments that prove value and build confidence, a desk or an instrument class at a time, with each slice reducing the risk of the next. Slicing is slower to reach the final state and far more likely to reach it at all. It also produces something a big bang never does, a series of working milestones that keep sponsors engaged and let the organization learn the platform gradually rather than all at once under maximum pressure.
Decision four: control customization ruthlessly
Every customization is a promise to maintain that customization forever, and an obstacle to every future upgrade. The platforms that ossify are almost always the ones that were customized without discipline, each request accommodated, until the system diverged so far from the vendor's product that upgrading became a reimplementation. The heavy customization that felt like getting exactly what the business wanted becomes the chain that freezes the platform in place.
The decision is to control customization ruthlessly, treating the vendor's standard capability as the default and requiring every deviation to justify its lifetime cost. Often the right answer is to change the process to fit the platform rather than the platform to fit the process, because a standard configuration upgrades cleanly and a customized one does not. This is unpopular with users who want the system to match their habits, but it is the difference between a platform that stays current and one that ossifies.
Decision five: plan for the platform's whole life
A platform is not selected for its first day in production; it is selected for the decade it will run. Yet many programmes optimize entirely for the implementation and give no thought to the life beyond it: how it will be upgraded, how it will absorb new instruments and regulations, who will own it, and how it will avoid ossifying. A platform chosen and configured without regard for its whole life is a platform being set up to ossify on schedule.
The decision is to plan for the lifetime from the start, to choose and configure with upgradeability, extensibility, and ownership in mind, so the platform can evolve with the business rather than freezing at the state it launched in. This is where the discipline of the previous decisions pays off: a clean operating model, a solid data foundation, an incremental delivery, and controlled customization together produce a platform that can be maintained and evolved, which is the only kind of platform that survives its whole life without ossifying.
Working the numbers: the cost of ossification
The ossified outcome has a cost, and putting a number on it helps a sponsor understand why the unglamorous decisions matter. The cost has two components. The first is the ongoing tax of a heavily customized platform: the additional effort to maintain customizations, the delayed or abandoned upgrades, the workarounds the desk lives with. The second is the opportunity cost of a platform that cannot evolve: the instruments it cannot support, the regulations it struggles to meet, the analytics the desk cannot get because the system is frozen.
The calculator below lets you explore how these costs scale with the degree of customization and the pace of change in your business. It is a thinking tool, not a precise forecast, but it makes visible a relationship that programmes routinely ignore: the more you customize and the faster your business changes, the more ossification costs you, and the more the discipline of standard configuration is worth.
The cost of ossification
See how customization and the pace of change in your business combine into a lifetime cost that the initial build never shows.
Customization's cost is paid later, in maintenance and forgone evolution, and rises with the pace of change in your markets. In a fast-moving business, heavy customization is the mechanism of ossification.
The calculator's lesson is that customization is not free even when the vendor performs it at no charge, because its true cost is paid later, in maintenance and forgone evolution, and that cost rises with the pace of change in your markets. In a slow, stable business, heavy customization is merely expensive. In a fast-moving trading business, it is the mechanism of ossification, and the discipline to avoid it is worth far more than it appears at the moment each customization is requested.
The architecture underneath a platform that lasts
The decisions above express themselves in an architecture, and it is worth picturing the shape of one that lasts. At the base sit the sources: the trades captured at the desk, the market data and curves, the reference data that gives everything meaning. Above them sits a foundation whose whole job is trust: position keeping that reconciles, curve building that is validated, controls that catch errors before they propagate. On that foundation sit the analytics the business actually consumes: P&L that the desk believes, risk and limits that the middle office governs, the carbon and other exposures that increasingly matter. And at the top sit the consumers: the desk, the risk function, and management, each seeing a view they can act on.
The reason to picture this as layers is that ossification usually begins when the layers are violated, when analytics are wired directly to raw sources bypassing the foundation, when trust-critical logic is scattered into customizations rather than concentrated in the foundation, when consumers reach around the platform because it does not give them what they need. A clean layered architecture, defended over the platform's life, is what keeps a platform maintainable. A tangled one is what ossifies.
This is why the operating-model and data-foundation decisions come first and matter most. They determine whether the foundation layer is solid, and a solid foundation is what lets everything above it stay clean. A programme that gets the foundation right can add desks, instruments, and analytics for years without the architecture degrading. A programme that gets it wrong finds that every addition tangles the system further, until the platform is the ossified monument this guide exists to help you avoid.
Reading the vendor relationship honestly
A final decision, less a single choice than a posture, concerns the vendor relationship itself. An ETRM platform is a decade-long partnership, not a purchase, and the health of that partnership matters as much as the platform's features. Yet selection processes evaluate the product intensely and the relationship barely at all, discovering only years later that the vendor's roadmap does not match their needs, that support is thin, or that the vendor's incentives pull toward customization revenue rather than the customer's clean upgrade path.
Reading the relationship honestly means asking questions the feature matrix does not: where is the vendor taking the product, and does that direction match where your business is going? How do they make money from you after the sale, and does that align with your interest in a lean, upgradeable configuration or against it? How do their other customers, especially those like you, experience the long-term relationship? These questions are harder to score than features, but they bear more directly on whether the platform will serve you for its whole life or become a source of friction and eventual ossification.
None of this makes the platform choice unimportant. It makes it secondary to the decisions and the relationship that determine whether any capable platform will succeed. Get the five decisions right, defend the architecture, and read the relationship honestly, and a wide range of platforms will serve you well. Get them wrong, and no platform will save you. The ossified programmes are not the ones that chose the wrong software; they are the ones that never made the decisions that software success depends on.
An ETRM platform is a decade-long partnership, not a purchase. The relationship matters as much as the features.
Where to start
If you are at the beginning of an ETRM selection or replacement, resist the pull of the feature matrix, at least until the five decisions are on the table. Convene the desks, risk, finance, and operations, and agree the operating model before you evaluate a single platform. Treat the data foundation as a deliberate build. Commit to an incremental change strategy rather than a big bang. Set a customization discipline before the requests start arriving. And choose and plan for the platform's whole life, not just its first day.
Do this, and the selection becomes what it should be: the choice of a capable partner to implement an operating model you have already agreed, on a data foundation you have deliberately built, through an incremental delivery you have planned, with a customization discipline you have set. That is a programme designed to succeed. The alternative, a magnificent feature comparison sitting atop a set of unmade decisions, is a programme designed, however unintentionally, to ossify.
The platforms are capable. The programmes are what fail. Make the decisions that programmes succeed on, and you will not join the long list of expensive monuments to the ones that did not.
Case study: two programmes, one platform
The clearest way to see why the decisions matter more than the platform is to consider two organizations that selected the same capable ETRM platform and reached opposite outcomes. This is a composite, but every element of it recurs in real programmes, and the contrast isolates exactly what determines success.
The first organization treated the selection as a technical procurement. It ran a thorough feature comparison, chose the platform that scored highest, and moved into implementation. It had not agreed its operating model, so as configuration began, the desks, risk, and finance each pushed the system toward their own unspoken assumptions, and every disagreement was resolved by customization. The data foundation was treated as an implementation detail, so positions did not reconcile and the desk lost trust in the numbers. The programme attempted a big-bang cutover, which slipped repeatedly. Three years in, the platform was live but resented, heavily customized, and already spoken of as something to replace. It had ossified.
The second organization treated the selection as the last of several decisions rather than the first. Before evaluating platforms, it convened the desks, risk, finance, and operations and agreed how the business would run, resolving the organizational disagreements as organizational questions rather than deferring them into configuration. It treated the data foundation as a deliberate build, so positions reconciled and the desk trusted the numbers from the start. It delivered incrementally, one desk at a time, each slice building confidence. And it controlled customization ruthlessly, changing process to fit the platform far more often than the reverse. Three years in, the same platform was trusted, lean, upgradeable, and quietly extending to new desks and instruments. It had not ossified, and no one was talking about replacing it.
Same platform, opposite outcomes. The variable was not the software but the decisions, and specifically the discipline to make the unglamorous organizational and data decisions before the exciting technical one. This is the entire thesis of the guide, and the two programmes make it concrete: capable platforms succeed or ossify according to the decisions made around them, and the feature comparison that dominates most selections is nearly irrelevant to which outcome you get.
The data foundation, in more depth
Because most ETRM pain is really data pain surfacing through the platform, the data foundation deserves closer attention than selection processes usually give it. It has several distinct components, each of which can undermine the platform if underbuilt, and understanding them helps a programme invest where the risk actually concentrates.
Reference data, the instruments, counterparties, books, calendars, and units that give every trade its meaning, is the quiet foundation of the foundation. When reference data is inconsistent or ungoverned, trades mean subtly different things in different places, positions fail to aggregate correctly, and no amount of platform capability compensates. A programme that does not give reference data an owner and a quality process is building on shifting ground, and the platform will be blamed for the movement.
Market data and curves are the second component, and they determine whether valuations and risk numbers can be trusted. A curve built from unvalidated inputs, or assembled inconsistently across books, produces valuations that differ for reasons no one can explain, and a desk that cannot explain its valuations will not trust them. Validated, governed curve construction is unglamorous and essential, and it is exactly the kind of foundation work that big-feature-focused selections neglect.
The trade capture path is the third component, and it determines whether clean, complete records enter the system at source. Errors introduced at capture propagate through positions, P&L, and risk, and are expensive to detect and correct downstream. A capture process that produces clean records at source, with validation at the point of entry, prevents a whole class of downstream pain that would otherwise be attributed to the platform. Together, these three components, reference data, market data and curves, and trade capture, constitute the foundation whose quality determines whether the platform can be trusted, and each rewards deliberate investment that feature-focused programmes routinely skip.
Customization discipline in practice
Controlling customization ruthlessly is easy to endorse and hard to practise, because every individual customization request is reasonable in isolation, and refusing it feels like refusing to meet a legitimate need. The discipline therefore has to be structural rather than heroic, built into how requests are evaluated rather than depending on someone repeatedly saying no.
The core structural move is to make the lifetime cost of a customization visible at the moment it is requested. A customization is not a one-time build; it is a permanent maintenance obligation and an upgrade obstacle carried for the platform's whole life. When that lifetime cost is made explicit, and weighed against the benefit of the customization versus simply adapting the process to the platform's standard behavior, many requests that looked reasonable in isolation reveal themselves as poor trades. The discipline is not to refuse all customization but to require each one to justify its lifetime cost, which most cannot.
A second structural move is to establish a strong default in favor of standard configuration and to place the burden of proof on deviation. When the standard is the default and customization is the exception that must be justified, the natural drift of a programme is toward a lean, upgradeable configuration. When customization is easy and standard behavior must be argued for, the natural drift is toward the ossified state. The direction of the default determines the destination, and setting it toward standard configuration is one of the highest-leverage governance decisions in an ETRM programme.
The hardest part is cultural, because users understandably want the system to match their established habits, and telling them to change their process to fit the platform feels like the technology tail wagging the business dog. But the alternative, a platform customized to preserve every existing habit, is a platform that cannot upgrade and will ossify, ultimately serving the business worse than a standard configuration that stays current. The discipline is a service to the business, even when it does not feel like one, and making that case is part of the work of an ETRM programme that intends to last.
Governing the programme itself
Beyond the five decisions and the architecture, an ETRM programme needs governance of itself, a way of steering that keeps it aligned to the decisions rather than drifting away from them under the pressure of delivery. Many programmes make the right decisions at the outset and then abandon them under deadline pressure, accepting customizations they had resolved to refuse, skipping the data foundation work to hit a date, attempting a bigger cutover than they planned. The governance of the programme is what holds the line.
This governance has a few essential features. It keeps the operating model decisions visible and refers configuration disputes back to them, so that the system implements the agreed model rather than becoming the venue where the model is renegotiated by stealth. It enforces the customization discipline, ensuring that lifetime costs are weighed and defaults respected even when a deadline makes accepting a customization tempting. It protects the incremental delivery strategy against the recurring pressure to accelerate by attempting more at once. And it keeps the data foundation from being sacrificed to hit a date, recognizing that a platform delivered on time atop a weak foundation is a platform that will be distrusted and eventually replaced.
The point of this self-governance is that the decisions made at the start of an ETRM programme are only worth what the programme's discipline preserves of them under pressure. A programme that makes the right decisions and then abandons them is barely better off than one that never made them, because the ossified outcome arrives either way. The steering that holds the decisions through the inevitable pressures of delivery is what turns good decisions into a good outcome, and it deserves as much attention as the decisions themselves.
The decisions are only worth what the programme's discipline preserves of them under the pressure of delivery.
The people question the platform cannot answer
An ETRM programme is often framed as a technology programme, but its hardest constraint is usually people: who understands the platform, who owns it, who can extend it, and who carries the institutional knowledge that keeps it aligned to the business. A platform that no one deeply understands is a platform that ossifies by neglect, because no one can safely change it, so it freezes at whatever state the original implementers left it. The people question is therefore inseparable from the platform's whole-life success.
This shows up most sharply in the transition from implementation to operation. During implementation, integrators and vendor consultants carry much of the knowledge, and the platform is understood, if at all, by people who will leave when the project ends. If that knowledge does not transfer to a permanent internal team that owns the platform, the organization is left operating a system it does not fully understand, unable to extend it confidently or diagnose its problems, and increasingly dependent on external help for changes that ought to be routine. The platform ossifies not because it cannot change but because no one inside the organization can safely change it.
The decision, made too rarely and too late, is to build the owning team deliberately, and to treat knowledge transfer as a first-class deliverable of the implementation rather than an afterthought. The organization that ends the implementation with a capable internal team that understands the platform, owns it, and can extend it has bought something more valuable than any feature: the ability to keep the platform aligned to the business over its whole life. The organization that ends the implementation dependent on external help for every change has, whatever the platform's capabilities, set itself up for the ossified outcome, because a platform that only outsiders can change is a platform that changes rarely and expensively, which is another name for ossification.
How regulations test the foundation
Energy and commodity trading operates under regulation that changes and tightens, and each new regulatory requirement is, in effect, a test of the platform and the foundation beneath it. A platform on a clean foundation absorbs a new reporting or risk requirement as a manageable extension; a platform on a weak foundation experiences the same requirement as a crisis, because the data it needs is not trustworthy, not reconciled, or not available in the form the regulation demands. Regulation, in this sense, does not create the weakness; it reveals it.
This is why the data foundation decisions pay off in ways that are hard to see at the outset but become obvious under regulatory pressure. When a new requirement arrives, the organization with governed reference data, validated curves, and clean trade capture can produce what is asked because the underlying data is trustworthy and available. The organization that skipped the foundation work finds that meeting the requirement means first fixing the data, under time pressure, which is the worst possible condition for foundation work. The regulation that was a routine extension for one organization is an emergency for the other, and the difference traces directly to the foundation decisions made years earlier.
The lesson is that the foundation is not only about the desk's daily trust in its numbers, important as that is, but about the platform's ability to absorb the steady stream of regulatory change that trading businesses face. A platform selected and configured for whole-life success, on a deliberately-built foundation, treats regulatory change as manageable. A platform optimized for its first day, on a weak foundation, treats each regulatory change as a fresh crisis, and the accumulation of these crises is another path to the ossified, resented, replacement-bound state this guide exists to help you avoid. Building the foundation is, among other things, an investment in regulatory resilience that pays off every time the rules change.
Bringing it together
The argument of this guide has been consistent throughout: ETRM programmes succeed or ossify according to a small set of decisions that have little to do with which capable platform is chosen, and everything to do with the operating model, the data foundation, the change strategy, the customization discipline, the whole-life plan, the people who own the platform, and the discipline to hold these through the pressures of delivery. The feature comparison that dominates most selections is nearly irrelevant to the outcome, and the programmes that fail are not the ones that chose the wrong software but the ones that never made the decisions software success depends on.
For a CIO or transformation lead standing at the start of an ETRM programme, the implication is liberating rather than daunting. You do not need to find the one perfect platform, because a wide range of capable platforms will succeed if the decisions around them are made well. What you need is the discipline to make the unglamorous decisions before the exciting one, to build the foundation before the features, to agree the operating model before the configuration, to control customization before the requests arrive, to plan for the whole life before the first day, and to hold all of this through the pressures that will push you to abandon it. That discipline, not the platform, is what determines whether you join the organizations whose platforms serve them well for a decade or the long list of expensive monuments to programmes that ossified.
The platforms are capable. The decisions are what matter. Make them explicitly, defend them through delivery, and you will have done the thing that actually determines success, and the platform, whichever capable one you choose, will serve the business as it was meant to.
You do not need the one perfect platform. You need the discipline to make the unglamorous decisions before the exciting one, and to hold them through delivery.
A checklist for the programme's start
It helps to distil the guide's argument into the concrete questions a programme should answer before it commits to a platform, because these questions, answered honestly at the outset, are what separate the programmes that succeed from the ones that ossify. They are deliberately not feature questions; they are the decisions that determine whether any capable platform will thrive.
Have we agreed the operating model? Before configuring anything, have the desks, risk, finance, and operations agreed how the business will actually run, so the platform implements an agreed model rather than becoming the venue where an unresolved model is fought out through customization? This is the single most important question, and a programme that cannot answer it affirmatively is not ready to select a platform, however thorough its feature comparison.
Have we planned the data foundation as a deliberate build? Do reference data, market data and curves, and trade capture each have an owner and a quality process, so the platform inherits trustworthy data rather than the data's weaknesses? Have we chosen an incremental change strategy rather than a big bang, so we prove value and build confidence a slice at a time rather than betting the whole operation on a single cutover? Have we set a customization discipline, with standard configuration as the default and every deviation required to justify its lifetime cost? And have we planned for the platform's whole life, including the internal team that will own it and the knowledge transfer that will equip them?
A programme that can answer these questions affirmatively is a programme designed to succeed, and the platform selection that follows becomes what it should be: the choice of a capable partner to implement decisions already made well. A programme that cannot answer them, however impressive its feature matrix, is a programme heading for the ossified outcome, because it is selecting a platform before making the decisions that platform success depends on. The checklist is short, and none of its questions is about features, which is precisely the point: the decisions that determine the outcome are not feature decisions, and a programme that starts by answering them honestly has already done the most important work.
None of the questions that determine an ETRM programme's outcome is a feature question. Answer the real ones honestly at the outset, and the platform choice becomes almost secondary.
The guide has argued throughout that ETRM programmes fail not because platforms lack features but because the decisions that determine success were never made explicitly, and this checklist is the practical expression of that argument. For a CIO or transformation lead, the invitation is to resist the gravitational pull of the feature comparison long enough to answer these questions first, because they, not the comparison, determine whether the programme joins the organizations whose platforms serve them for a decade or the long list of expensive monuments to programmes that ossified. Make the decisions, defend them through delivery, and the platform will serve the business as it was meant to.
It bears repeating, as a final thought, that this whole argument is ultimately optimistic for the CIO who takes it seriously. The reason so many ETRM programmes ossify is not that the platforms are bad or that success is a matter of luck; it is that the decisions that determine success are skippable, unglamorous, and therefore skipped. A CIO who simply refuses to skip them, who insists on the operating model, the data foundation, the incremental delivery, the customization discipline, the whole-life plan, and the internal ownership, has within reach an outcome that eludes the many programmes that chase features instead. The path is demanding but clear, and walking it is entirely a matter of discipline rather than luck or genius.
Get the PDF of this insight
Enter your name and corporate email and we will send the download link to your inbox. We send the link to the address you provide, so it must be a real, corporate email. Free providers are not accepted.
Check your inbox
If the address is valid, the download link is on its way. It can take a minute to arrive.
Your next step, whatever your role
If you are about to select or replace an ETRM platform, here is how to make the five decisions well, whether you want an independent advisor, a platform built on these principles, or to build the capability in your team.
Get an independent assessment
See it operationalized in a product
Build the capability in your teams
Bring this thinking to your organization
Scope an engagement with a senior practitioner.