Risk Is a Performance Metric

Performance isn’t only about speed. It’s also about reducing data movement, complexity, and inconsistency that can put businesses at risk.

For years, performance management has focused on technical indicators: CPU utilization, response times, batch windows, and storage consumption.

These metrics remain important, but they tell only part of the story. 

What I’m talking about is that the most significant performance issue facing many organizations today may not be system speed. It may be operational risk.

Every unnecessary database read adds latency. Every movement of data outside the system of record creates the potential for inconsistency. Every replication point introduces another opportunity for data drift. Every distributed copy of critical information increases the number of places where something can go wrong.

Viewed through this lens, risk itself becomes a performance metric.

The Cost of System Disagreement

Consider a typical banking transaction.

A customer sees an account balance on their mobile device. The call center sees it in a CRM application. Fraud systems evaluate the transaction. Analytics engines generate recommendations. Finance teams use the same information for reporting and revenue recognition.

The more copies of that data that exist, the greater the chance that one of them is incomplete, outdated, or simply wrong.

When systems disagree, organizations pay a price that doesn’t appear on a CPU utilization report:

• Customers lose trust. 
• Employees make poor decisions. 
• Regulatory exposure increases. 
• Revenue recognition becomes less certain. 
• The business spends valuable resources reconciling differences rather than creating value.

Yet many modernization initiatives unintentionally increase this risk. In pursuit of performance or easier access, organizations move data away from the system of record and create copies across data lakes, warehouses, cloud environments, and operational databases.

Individual workloads may run faster, but the overall architecture becomes more complex.

Complexity and risk tend to travel together. The safest copy of data is often the copy that never had to move.

Keep Processing Close 

The mainframe remains the system of record for many of the world’s most important transactions because it excels at one critical capability: maintaining trusted, authoritative data.

The closer business processing remains to that authoritative source, the lower the operational risk.

This does not mean organizations should abandon modern architectures. Far from it. Data lakes, cloud platforms, and analytical environments serve important purposes.

It does mean, however, that organizations should carefully evaluate which data truly needs to move and which business functions can be performed where the data already reside. Each time information is copied, synchronized, transformed, or replicated, the organization creates another point of potential delay or failure.

The question is not whether data should ever move. It is whether the business value of moving it justifies the complexity and risk created along the way.

How In-Memory Processing Changes the Tradeoff

Historically, organizations could either process directly against the system of record and potentially incur performance penalties, or they could move data elsewhere and accept greater complexity and operational risk.

Fortunately, modern in-memory technologies narrow that tradeoff.

By keeping frequently accessed data in memory close to the transaction-processing environment, organizations can reduce I/O activity, improve response times, and accelerate business processing – without creating another distributed database that must constantly be synchronized with the system of record.

Consider a Db2 for z/OS application that repeatedly accesses a relatively small, frequently used table or index—perhaps product rules, interest rates, customer classifications, or transaction limits. 

Assigning that object to an appropriately sized in-memory buffer pool can keep its data pages resident in memory. The application gains faster access and performs less I/O, while the authoritative data remains under Db2 control. 

IBM describes the same fundamental benefit: assigning frequently accessed objects to in-memory buffer pools can reduce both internal processing costs and I/O. 

That presents far less risk than exporting the data to another operational database, building and monitoring a synchronization process, securing the additional environment, and reconciling differences when something goes wrong.  

The result of in-memory technology can be an architecture that is both faster and safer:

• Less I/O
• Less data movement
• Fewer synchronization failures
• Fewer reconciliation challenges
• Greater confidence in the outcome

Reduce Risk Through Simplicity

One of the most overlooked benefits of in-memory optimization is simplification.

Technology teams often think about performance tuning as a way to make existing processes faster. The greater opportunity may be to eliminate unnecessary processes entirely. Consider:

• If an in-memory solution allows a reporting or operational workload to run efficiently against trusted data, would you need a separate replicated database?
• If applications can access current information in real time, could you retire nightly synchronization jobs?
• If multiple applications can work from a common source of truth, could you eliminate duplicate data pipelines?

Not every workload will fit this model. Large-scale historical analytics, cross-platform analysis, and specialized data-science workloads may still require data to move. But organizations should make that decision deliberately rather than assuming that replication provides the only path to performance.

Each component removed from an architecture reduces the number of things that must be operated, secured, governed, and repaired. As a result, performance improves – not because the organization added more technology, but because it removed unnecessary complexity.

Ask a Better Tuning Question

The traditional tuning question has been: How can we make this application run faster?

The modern tuning question should be: How can we make this application faster while reducing business risk?

Organizations that answer both questions simultaneously will:

• Build a significant competitive advantage
• Spend less time reconciling data and more time acting on it
• Reduce operational complexity while improving responsiveness
• Strengthen governance without slowing innovation

Most importantly, they will preserve the integrity of the system of record while delivering the speed modern business requires.

In the years ahead, the most successful performance teams will not simply become experts in CPU optimization. They will become experts in risk optimization.

Because in an economy increasingly driven by data, trust is performance. And there is still no platform better suited to protecting that trust than the mainframe.

Next

• Explore technical performance tuning: Read the Cheryl Watson Tuning Letter
• Interested in Db2? Join the next Planet Mainframe Db2 Virtual User Group session