“It is a rock-solid system that can scale infinitely.”
“It is slow, complex, and impossible to tune.”
I have seen both stories play out, sometimes in the same region, and even within the same organisation.
The Paradox I've Seen in the Field
Here is what I have observed firsthand:
-
- A telecom operator in EMEA uses BRM to bill tens of millions of customers and is delighted with its performance.
- Another operator in APAC struggles to keep BRM stable with a fraction of that load.
- In one case, performance degradation started small but eventually disrupted the entire communications stack.
- Meanwhile, two more APAC operators manage much larger volumes without noticeable issues.
So why such a stark difference?
If you ask the traditional system integrator or the operations team, you’ll usually hear a list of familiar complaints:
-
- “BRM is slow.”
- “The database is too big.”
- “The infrastructure is not good enough.”
- “BRM is too complex.”
- “Oracle support is not helping.”
However, the truth is that none of those statements fully explains the picture.
The Real Truth About BRM Performance
Here is my firm belief, built from working closely with BRM across multiple large-scale implementations:
BRM can scale to extraordinary levels if it is deployed correctly and maintained with discipline. The product architecture itself is rarely the bottleneck. Performance problems usually come from how the system is implemented, maintained, and evolved.
For executives, poor BRM performance does not just mean slow systems. It shows up as delayed billing, lost revenue days, and frustrated customers.
Why “Performance Tuning” Rarely Happens Properly
I have often been brought into projects where BRM is underperforming, and where the problems are well known. Our team, together with the customer, performs analysis, finds dozens of opportunities, and presents recommendations.
Then something predictable happens:
-
- The team picks only the “easy wins.”
- The deeper structural recommendations are deferred, as they are often harder to justify in business terms.
It’s tough to put a clear value on “slow performance” or the risk of a future outage. So, someone signs off on the risk, and BRM continues to limp along.
The Hidden (and Sometimes Funny) Root Causes
Over the years, I have encountered some fascinating, and occasionally absurd, reasons behind BRM slowdowns.
Here are a few that stand out:
-
- A developer added a 1-second sleep statement in a loop to prevent a race condition. It worked fine initially, but as loads grew, that “tiny” delay turned into a massive performance drag.
- A database trigger was written to reject data from any unapproved application hosts. When some processes were later migrated to new servers, half the transactions silently failed, because no one checked the logs.
- Data wasn’t purged for years, which created massive tables.
- Partitioning was ignored, even though it’s a basic Oracle recommendation.
- Reporting queries were running directly on the production BRM database, slowing down live transactions.
Each issue might seem small in isolation, but together they create a perfect storm.
In Europe, regulators are taking note of these risks. For example, Ofcom has highlighted that poor billing accuracy and system inefficiencies directly impact customer trust and regulatory compliance. This makes BRM performance not just an IT concern, but a compliance and revenue issue as well.
The Knee-Jerk Reactions That Don’t Work
When performance issues surface, organizations often jump straight into one of these approaches:
-
- “Let’s move away from BRM.”
- “Let’s re-architect the solution.”
- “Let’s offload some functions to another system.”
- “Let’s reimplement BRM from scratch, this time we’ll get it right.”
These reactions are understandable, but they’re also expensive, risky, and unnecessary. In almost every case, fixing the fundamentals gives far better results at a fraction of the cost.
What Actually Works
If your BRM system is struggling, here’s what I’ve seen deliver consistent success:
- Bring in the right expertise.
-
- A BRM architect who understands the internals, architecture, and configuration.
- A database performance engineer who can optimise queries and schema design.
- Fix the basics.
-
- Do not use BRM as a data warehouse.
- Purge data on a regular schedule.
- Partition large tables as standard practice.
- Revisit your infrastructure.
-
- Consider Exadata if you need extreme performance.
- Use multi-schema deployments when appropriate.
When these steps are followed, BRM performs beautifully, and even at a massive scale.
How Synthesis Helps Turn It Around
At Synthesis Systems, we’ve seen these situations many times.
To make it easier for our customers, we have developed targeted services that directly address the issues most often seen in underperforming BRM environments:
-
- BRM Batch Performance Review – Identify and optimise inefficient batch jobs.
- BRM Operational Purge Review and Setup – Establish structured, automated purging.
- BRM Closed Account Purge – Remove inactive accounts safely to improve efficiency.
- BRM High Availability Review – Strengthen architecture for stability and failover readiness.
Each engagement is outcome-focused, designed to deliver measurable improvements in performance, stability, and cost efficiency.
Final Thoughts
Most BRM “performance problems” are not product limitations; they’re operational challenges. They come from forgotten tweaks, skipped best practices, and underestimated long-term maintenance needs. The good news is that they’re fixable.
With the right expertise and discipline, BRM can run fast, stay stable, and scale as much as your business needs it to.