Sector: Government – Shared IT Services Capability: Oracle Database, Oracle Exadata, Oracle Database In-Memory, Oracle Business Intelligence Applications
ABOUT THE CUSTOMER
A NSW state government organisation providing shared ICT services to entities across the state. Its Oracle environment underpins Finance, HRMS and Payroll, and Procurement and Supply Chain operations for those entities – core systems where availability and performance directly affect public-sector service delivery.
To support business decision-making and statutory reporting, the organisation rolled out Oracle Business Intelligence Applications (BI Apps) across its full user base, spanning multiple business units and subject areas.
THE PROBLEM
A large-scale BI Apps rollout with no margin for slow dashboards.
The deployment carried real constraints:
- Reporting and analytics had to span every subject area and every business unit on day one – Finance, HR, Payroll, Procurement, and Supply Chain – not staged in over time.
- Underlying data volumes were significant, with reporting workloads running concurrently against transactional systems already at scale.
- A clear performance target had been set: dashboard response times under five seconds, end-to-end, across the full user base.
Standard BI Apps tuning approaches were not getting the architecture to that target. With users already onboarded and reporting commitments already made to the entities the platform serves, the project needed engineering judgement, not another round of incremental tuning.
THE SOLUTION
Use what’s already in the Oracle stack – properly.
BSC was engaged to work alongside the customer’s database and BI teams. Our position from the outset was that the customer had already invested in an Oracle platform capable of meeting the performance target. The work was to unlock that capability, not to layer additional products or rebuild the analytics tier from scratch.
Working with the customer’s senior database stakeholders, we shaped a solution around three Oracle capabilities the organisation already had access to:
- Oracle Exadata – to give the BI workload the I/O bandwidth, smart scan, and storage indexing needed to handle large concurrent reporting queries against transactional data.
- Oracle Database – properly configured for mixed transactional and analytical workloads, with the right partitioning, parallelism, and resource management to keep reporting from interfering with the systems of record.
- Oracle Database In-Memory – applied selectively to the dashboard data paths where columnar in-memory access materially changed query performance, rather than enabled wholesale.
The architecture decisions came out of detailed analysis of the actual reporting workload – which dashboards, against which subject areas, in which usage patterns – rather than a generic BI Apps reference architecture.
THE OUTCOME
The first-phase rollout met the response-time target across the in-scope dashboards. With performance no longer the constraint, the platform was able to absorb a substantial increase in subsequent reporting demand without architectural rework or net-new infrastructure spend – extending the useful life of the existing investment and improving return on the original platform decision.
The engagement reinforced something we believe is broadly true of Oracle environments: most performance and scalability problems are solved by understanding the platform deeply, not by buying more of it. That’s the work BSC does.
Capabilities demonstrated: Oracle Exadata architecture · Oracle Database In-Memory · Oracle BI Applications · large-scale workload analysis · production-grade performance engineering.
