Optimizing SimCorp Dimension

Get Visibility and Act

Optimization should never begin with assumptions. The first and most important step is gaining full visibility into your current environment.

Key questions to answer:

• What is the actual usage of databases, application servers, and batch processes?
• Which modules, portfolios, and historical datasets are actively used?
• Where are the real performance bottlenecks (database, application tier, interfaces, or reporting)?

This visibility must be grounded in metrics rather than intuition. Monitoring tools, capacity and growth reports, workload analysis, and historical trend data all play a critical role. Once you understand how your SimCorp Dimension landscape is truly behaving, you can move from passive observation to informed action.

Visibility alone has no value if it does not lead to decisions. The goal is not to generate reports for their own sake, but to use insight to drive concrete optimization steps.

Putting Visibility into Practice

The process should start with the creation of a structured audit report that reviews multiple areas of the SimCorp Dimension environment. This audit typically covers database growth, data retention, batch processing, application server utilization, and end-user activity.

A common challenge emerges during this phase: end users often believe they need everything. Historical results, old portfolios, and legacy configurations are rarely questioned. This is where IT must take an advisory role and support the business with data-driven recommendations.

Based on the audit results, teams can:

• Propose data retention periods aligned with regulatory and business needs
• Identify data that should be archived rather than kept online
• Clearly define data and configurations that can be safely deleted

Keeping all historical data in the production environment inevitably leads to an unnecessary increase in costs. This impact is not limited to production alone. Any environment refreshed or cloned from PROD, such as test, UAT, training, high-availability setups, or disaster recovery environments, inherits the same data volume.

As a result, every additional terabyte stored in production is effectively multiplied by the number of lower environments and resilience solutions. This drives higher infrastructure costs, longer refresh times, extended batch windows, and increased operational risk.

True visibility allows IT teams to clearly demonstrate this cost multiplication effect and turn optimization discussions from opinion-based debates into fact-based decisions.

Work Smart, Not Hard

Optimization does not mean adding more hardware or endlessly tuning symptoms. It means working smart, systematically, and with intent.

In many SimCorp Dimension environments, performance or capacity issues are addressed by simply adding more resources. While this may provide short-term relief, it rarely solves the root cause and often increases long-term complexity and cost.

Examples of Smart Optimization

Reducing database size instead of scaling storage

Before investing in additional storage, review what actually drives database growth. Historical results, unused portfolios, and obsolete reference data often account for a significant share of the volume. Reducing the database footprint improves performance, shortens batch windows, and lowers costs across all environments.

Simplifying batch schedules instead of extending processing windows

Over time, batch landscapes often become overly complex. New batch jobs, dependencies, and parallel solutions are added without a holistic review of what already exists. Project teams focus on delivery, not reuse or consolidation.

The result is duplicated logic, fragile batch chains, and extended processing windows. Regular batch reviews help remove redundancies, consolidate jobs, and restore control.

Right-sizing application servers based on actual load

Rather than permanently scaling out infrastructure, application servers should be sized based on real usage patterns. By analyzing when services are under pressure and when they are idle, teams can:

• Scale up resources only when needed
• Adjust the dependency model
• Use available processing power more efficiently

This approach allows the environment to be more flexible and responsive, instead of continuously adding servers that remain underutilized for large parts of the day.

Eliminating unused interfaces, jobs, and reports

Legacy components are one of the most underestimated sources of complexity. New interfaces, reports, and jobs are added regularly, but they are rarely reviewed afterward. Documentation is often incomplete, and when people change roles or leave, their implementations remain.

Regular reviews help identify what is no longer used, no longer needed, or no longer understood. Removing such elements reduces operational risk and simplifies future upgrades.

Each of these actions reduces complexity and operational overhead. Fewer moving parts lead to fewer incidents, faster recovery, and significantly easier upgrades while still meeting business needs.