The ETRM trap: building complexity instead of capability

Effective ETRM extensions are grounded in strong design principles and built with a clear focus on usability, performance, and long-term maintainability. The following principles provide a foundation for designing solutions that solve real business problems while keeping systems scalable, adaptable and sustainable:

Figure 1: Key design principles for sustainable ETRM extensions

This figure summarizes foundational design principles that help ensure ETRM extensions are scalable, maintainable and aligned with business outcomes.

What goes wrong: common mistakes that create ETRM chaos

At Capco, we routinely encounter a variety of issues across client environments. While each case is unique, the patterns below represent some of the most common pitfalls that undermine ETRM system performance and sustainability. Although the intent is often good, poorly designed extensions introduce serious risks. The examples below are based on real-world implementations and show how overlooking key design principles can lead to long-term inefficiencies, maintenance headaches and avoidable business disruption.

• Environment-specific hardcoding. Scripts embedded environment-specific values (e.g., database names, user IDs, or file paths), leading to failures during testing or deployment across different environments. These hardcoded references caused frequent outages during migrations and increased support burden. Principle violation: configurable, not hardcoded
• Rigid custom workflows. A scheduling module enforced strict task sequences without exception handling, making it difficult to adjust processes during operational changes. This rigidity delayed end-of-day processing and created user workarounds. Principle violation: outcome-focused design; business-aligned design
• UI-driven logic creep. A reporting interface allows users to define calculation logic through free-text fields. While flexible, the logic became inconsistent and untraceable, making reports difficult to support or validate. Principle violation: user-centric configuration; maintainable structure
• Over-automated error handling. Auto-repair scripts attempted to silently correct broken trades or valuations. Instead of addressing the root cause, these routines masked real issues and introduced further data corruption. Principle violation: preserve native functionality; clean code practices
• Overriding native logic. One implementation altered native valuation table logic to embed a custom pricing adjustment. This caused repeated issues during upgrade cycles and made it nearly impossible to isolate root causes when valuation discrepancies occurred. Principle violation: preserve native functionality
• Dual sources of truth. In one case, a custom tax view allowed user entry into a front-end table that wasn't synced with the system's core configuration tables. The result was multiple downstream processes referencing conflicting data – causing confusion, errors, and significant troubleshooting delays. Principle violation: maintainable structure and configurable, not hardcoded
• Incomplete data handling. A common example involves extensions that only update existing records when correcting data but never remove erroneous ones – leading to duplicate entries and inaccurate results. Principle violation: clean code practices
• Excessive data retention. For instance, one solution logged every change in a pricing table – even minor updates already tracked by standard audit logs – cluttering reports and dragging down system performance. Principle violation: outcome-focused design
• Rewriting instead of integrating. One implementation replaced standard inventory valuation logic with a proprietary model that required rewriting core ETRM processes. The effort consumed months of development, struggled with accuracy, and ultimately had to be replaced. Principle violation: business-aligned and outcome-focused design; preserve native functionality
• Misguided defaults. For example, a system required users to populate a specific book structure field – even on automated trade feeds resulting in forced placeholders like 'Default' that skewed reports and introduced cleanup work downstream. Principle violation: configurable, not hardcoded

Why it happens: the roots of complexity

These types of breakdowns rarely stem from a single design decision. More often, they’re symptoms of deeper structural or organizational challenges. Understanding these root causes is key to preventing complexity from taking hold in the first place.

Figure 2: Root causes of ETRM complexity

The table below summarizes common organizational and technical causes behind ETRM system complexity. These factors often compound over time, leading to fragile architecture and inefficient operations.

Examples of value-adding extensions

The following examples showcase well-designed extensions that deliver tangible business value without compromising system integrity. These solutions reflect Capco’s approach to purposeful enhancement – adding functionality in ways that preserve flexibility, improve user experience, and avoid the long-term costs of technical debt.

• View manager. This tool allows users to save multiple view states rather than relying on a single saved view. It reduces user frustration, cuts down on clutter, and minimizes IT overhead during upgrades.
• Valuation criteria extension. Adds configurability to the valuation process by letting users define finalizer processes and filtering criteria. This results in faster valuation runs and smaller output datasets.
• Exposure management toolkit. A bolt-on reporting tool that uses custom tables and front-end config to support PnL and exposure without touching native valuation data. Simplifies troubleshooting and enables easier updates.
• EOD exposure volume sync. A front-end tool for reconciling logistical discrepancies when source data isn't available by end of day (EOD). Enables accurate hedging without delays.
• Price download extensions. Custom connectors to ICE/CME that pull prices directly into the system, reducing reliance on third-party feeds and manual processes.
• Reconciliation reports & alerts. Automated checks between ETRM and downstream systems (accounting, broker statements) that surface data mismatches in real time.

Conclusion: design for impact, not complexity

ETRM systems should enable growth, not inhibit it. Smart extensions enhance functionality without disrupting stability. Poorly designed ones, however, often become long-term liabilities – introducing technical debt, compounding support burdens, and reducing system agility.

Avoiding these pitfalls requires more than just technical knowledge. It takes thoughtful design, a clear understanding of business outcomes, and experience navigating the tradeoffs between flexibility and maintainability. The most effective solutions are those that quietly scale with the business, support change without disruption, and simplify decision-making – not complicate it.

Throughout this paper, we’ve outlined best practices based on real-world experience helping teams get back on track – whether by untangling legacy complexity or implementing scalable, future-proof enhancements. If these challenges sound familiar, you're not alone.