Hundsun O32 to O45: A Financial Architecture Revolution

#

From tightly coupled three-tier systems to service-oriented distributed architecture, the evolution from O32 to O45 represents one of the most significant architectural transformations in China’s financial IT history.

1. Introduction: Why O32 Had to Evolve

#

In the early 2000s, China’s asset management industry entered a rapid expansion phase.

Fund companies, securities firms, insurance companies, and institutional investors were building centralized investment management platforms. At that time, the mainstream architecture was the classic IOE model:

Client
|
Application Server
|
Oracle Database
|
IBM / HP / SUN Server + EMC Storage

The database was the center of the universe.

Business logic, transaction processing, risk calculation, and settlement logic were deeply connected with database operations.

This architecture worked extremely well during the early stage of financial informatization.

However, as financial business became more complex, limitations gradually appeared:

• More asset classes
• More trading channels
• More regulatory requirements
• More real-time risk control needs
• More external system integrations

The traditional architecture began to face challenges:

• Business modules were tightly coupled
• System upgrades became risky
• Performance depended heavily on database scaling
• Cross-system integration relied heavily on database tables
• Real-time processing capability was limited

This became the historical background for the evolution from Hundsun O32 to O45.

2. The Birth of O32: The Database-Centered Era

#

2.1 The O32 Background

#

Before O32, Hundsun’s asset management systems evolved through several generations:

The letter “O” represented Oracle.

The transition from SQL Server to Oracle reflected the industry’s migration toward enterprise-class IOE architecture.

3. O32 Architecture Model

#

The classic O32 architecture was:

+----------------+
| Client Terminal|
+----------------+
|
|
+----------------+
| Application    |
| Server         |
| (Tuxedo/CRES)  |
+----------------+
|
|
+----------------+
| Oracle Database|
+----------------+

3.1 Three-Tier Architecture

#

O32 adopted the classic three-tier model:

Presentation Layer

#

Responsible for:

• User interaction
• Trading operations
• Query functions

Application Layer

#

Responsible for:

• Business processing
• Transaction control
• Workflow execution

Technologies:

• Tuxedo middleware
• Later migrated toward CRES

Database Layer

#

Responsible for:

• Data persistence
• Transaction consistency
• Historical records

Technology:

• Oracle Database

4. The Strength of O32

#

O32 was extremely successful because it matched the market requirements of that era.

4.1 Stability First

#

Financial systems prioritize:

• Reliability
• Data consistency
• Transaction correctness

O32 inherited the traditional financial architecture philosophy:

The database is the ultimate source of truth.

Oracle provided:

• ACID transaction guarantees
• Mature backup mechanisms
• Enterprise support

4.2 Strong Business Coverage

#

O32 supported:

• Fund investment management
• Portfolio management
• Trading instructions
• Settlement
• Accounting
• Risk management

It became one of the most widely deployed investment management platforms in China’s financial industry.

5. Why O32 Started Showing Limitations

#

After years of operation, new requirements emerged.

5.1 Business Coupling Problem

#

In O32:

Business Module
|
|
Database Tables
|
|
Other Modules

Many modules communicated through database structures.

A change in one module could affect:

• Trading
• Settlement
• Risk
• Accounting

The system became increasingly difficult to evolve.

5.2 Integration Problem

#

The traditional approach:

System A
|
Database Table
|
System B

caused:

• Tight coupling
• Poor real-time capability
• Difficult maintenance

Modern financial ecosystems required:

System A
|
API / Service
|
System B

5.3 Performance Bottleneck

#

As business volume increased:

• More accounts
• More products
• More transactions

Database pressure increased dramatically.

The architecture needed to move:

From database-centric processing
To distributed service-oriented processing

6. The O45 Revolution

#

O45 was not simply a product upgrade.

It represented a fundamental architectural transformation.

The core idea:

Move from a tightly coupled application system into a service-oriented financial platform.

7. O45 New Architecture

#

The O45 architecture moved toward:

         Client
           |
           |
    Access Gateway
           |
           |
     Service Layer
           |

+————-+————-+ | | |

Portfolio     Trading       Risk
Service       Service       Service
|             |             |
+-------------+-------------+
|
Data Service
|
Database

8. From Module-Based to Service-Based Architecture

#

O32 Model

#

Investment Module
Trading Module
Risk Module
Settlement Module

|
|

Shared Database

Characteristics:

• Large application
• Strong coupling
• Database-driven

O45 Model

#

Trading Service

Risk Service

Portfolio Service

Settlement Service

|
|

Service Platform

|
|

Database

Characteristics:

• Loose coupling
• Service reuse
• Independent evolution

9. Middleware Evolution Behind O32 → O45

#

The product evolution was supported by Hundsun’s middleware evolution.

9.1 AR/AS Era

#

Early securities systems:

Client

|

AR
(Application Router)

|

AS
(Application Server)

|

Database

Characteristics:

• Three-tier architecture
• Routing separation
• Application server model

9.2 CRES Era

#

Hundsun introduced:

Client

|

CRES

|

Business Components

|

Database

CRES provided:

• Communication
• Routing
• Transaction processing
• Business component loading

It gradually replaced Tuxedo-based architecture.

9.3 Light-JRES Era

#

Modern architecture:

Client

|

Gateway

|

Light-JRES

|

Micro Services

|

Database / Cache / MQ

Characteristics:

• Java ecosystem
• Cloud-native
• Service governance
• Distributed deployment

O45 was built on this new generation architecture philosophy.

10. O32 vs O45 Architecture Comparison

#

11. The Performance Transformation

#

The architectural change also brought significant performance improvements.

Traditional O32:

• Hundreds of transactions per second
• Database-heavy processing
• Limited horizontal expansion

O45:

• Distributed processing
• Service parallelism
• Real-time risk processing
• Higher concurrency

The improvement was not simply hardware acceleration.

The fundamental reason:

The workload model changed.

From:

Database does everything

to:

Distributed services share processing

12. Why This Was a Revolution

#

Many people view O45 as a new product.

Architecturally, it was much more.

It represented three major transitions:

12.1 From IOE Architecture to Distributed Architecture

#

Old:

IBM
Oracle
EMC

Centralized System

New:

Cloud Infrastructure

Distributed Services

Multiple Data Components

12.2 From Database-Centric to Service-Centric

#

Old:

Database = Business Center

New:

Service Platform = Business Center

12.3 From Software Delivery to Platform Engineering

#

Old:

Deliver Application

New:

Build Financial Technology Platform

13. Comparison with Other Financial IT Evolutions

#

Hundsun’s path was similar to global financial technology evolution.

Examples:

IBM Mainframe Era

#

Mainframe
|
CICS
|
DB2

Tuxedo Era

#

Client

|

Tuxedo

|

Database

Modern Cloud Era

#

API Gateway

|

Microservices

|

Message Bus

|

Distributed Database

Hundsun’s O32 → O45 evolution followed this global trend.

14. The Strategic Meaning of O45

#

O45 solved a fundamental problem:

How can a financial system survive decades of business evolution?

The answer:

Not by creating a bigger application.

But by creating a platform that allows continuous evolution.

15. Conclusion: From System to Platform

#

The history from O32 to O45 is a story of architectural transformation.

O32 represented the peak of the traditional financial IT era:

• Stable
• Reliable
• Database-centered
• Enterprise-class

O45 represents the next generation:

• Distributed
• Service-oriented
• Cloud-ready
• Continuously evolving

The evolution can be summarized as:

O32

Database-Centered Financial System

  ↓

O45

Service-Oriented Financial Platform

The most important change was not technology replacement.

It was a change in architecture philosophy:

O32 built a powerful financial application.
O45 built a platform capable of continuously evolving with financial business.

This transformation is one of the most important milestones in China’s financial IT architecture evolution.