Three Semantic Models, Not Three Environments: Understanding OAC Resource Groups

Oracle Analytics Cloud has traditionally allowed one semantic model to be deployed within an OAC instance. That model might contain multiple subject areas, serve several business functions and connect to numerous data sources, but it was still managed as a single metadata deployment.

For many organisations, that approach works well. It provides one governed semantic layer through which measures, dimensions, hierarchies and security rules can be shared.

It can also create architectural compromises.

Independent teams may become tied to the same release cycle. A heavily used operational workload can compete with executive reporting. Departments that have little in common may find themselves contributing to an increasingly large enterprise model simply because OAC provides only one deployment slot.

Oracle has now changed that with the introduction of Resource Groups.

An OAC administrator can configure up to three Resource Groups within an instance, with one semantic model deployed to each group. Additional Resource Groups are assigned dedicated OCPU capacity, allowing their query workloads to consume compute more independently.

This is a significant improvement, but it is important to understand exactly what it provides.

Resource Groups introduce multi-model deployment and workload isolation within a shared OAC instance. They do not create semantic integration, and they certainly do not turn one OAC instance into three separate environments.

Breaking the single-model constraint

Every OAC instance continues to include its built-in default Resource Group. Organisations that only require one semantic model can continue using OAC in exactly the same way as before.

Where multiple models are required, administrators can create two additional Resource Groups and allocate OCPU capacity to them. Model developers and deployment administrators can then choose the Resource Group into which a semantic model is deployed.

This creates several useful boundaries:

• Each Resource Group has its own deployed semantic model.
• Additional Resource Groups receive dedicated query-processing capacity.
• Models can be deployed and replaced independently.
• Different teams can own models with separate development and release schedules.
• Subject areas from all deployed models can be made available within the same OAC environment.

Oracle describes Resource Groups as combining a semantic-model deployment target with assigned compute capacity. The feature is therefore about more than storing several models. It provides a way to consolidate governed semantic models while maintaining clearer workload and operational boundaries.

Oracle’s original announcement and deployment walkthrough can be found in Deploy Multiple Semantic Models in Oracle Analytics Cloud with Resource Groups.

How Resource Groups are configured

Resource Groups are managed against the OAC instance in the Oracle Cloud Infrastructure Console. An administrator begins by opening the relevant Analytics Cloud instance.

The Analytics Instances page in the Oracle Cloud Infrastructure Console.

The instance now includes a Resource groups tab. The built-in default group is shown alongside any additional groups, together with their capacity and current status. New groups can be created from this page.

Resource Groups are configured at the OAC instance level, with capacity displayed for each group.

When creating a Resource Group, the administrator supplies a resource name, display name and optional description, then selects the OCPU capacity to allocate. The display name subsequently identifies the deployment target to semantic-model developers and deployment administrators.

Creating a Resource Group combines a semantic-model deployment target with dedicated capacity.

The process itself is straightforward. The more important decisions concern which models should be separated, how much capacity they require and which analytical dependencies must remain within the same model.

Coexistence does not mean integration

The term “multiple semantic models” could suggest that OAC now joins separately developed models together at query time. It does not.

Users can select subject areas from different deployed models and add them to the same workbook. A workbook might therefore contain a finance visualisation sourced from one model and a sales visualisation sourced from another.

However, fields originating from different semantic models cannot be combined within the same visualisation.

If revenue from the finance model and pipeline from the sales model must appear together in one chart, those fields need to be represented within the same semantic model. Resource Groups do not create relationships, logical joins or shared calculations between independently deployed models.

The distinction is important:

Resource Groups allow semantic models to coexist, but they do not integrate those models.

They allow independently governed models to coexist in one OAC instance. They do not remove the need to design integrated business semantics where cross-domain analysis is required.

The tempting Development, Pre-production and Production interpretation

When people first see three semantic-model deployment targets, an obvious question arises:

Could the three Resource Groups contain Development, Pre-production and Production versions of the same model?

It is an understandable interpretation. On the surface, it appears to offer an attractively simple architecture:

• one OAC instance;
• three versions of the semantic model;
• a convenient promotion path; and
• potentially lower infrastructure costs.

Technically, versions of a model could be deployed side by side, subject to OAC’s deployment restrictions. However, Resource Groups should not be treated as a substitute for separate lifecycle environments.

The most immediate complication is naming. Oracle requires subject area names to be unique across all semantic models deployed within an instance. Subject area alternate names must also be unique.

Three copies of a model could not all expose a subject area called Sales. They would need names such as:

• Sales – Development
• Sales – Pre-production
• Sales – Production

The deployed models would consequently no longer be identical artefacts. Reports and workbooks would also need to reference the appropriate environment-specific subject areas, making content promotion unnecessarily complicated.

More fundamentally, all three models would remain inside the same OAC service.

A Resource Group does not create a separate OAC instance, service boundary, maintenance cycle or failure domain. An instance-level outage or administrative problem could affect every Resource Group. Development activity would also take place alongside production content rather than within a genuinely independent environment.

Resource Groups should not be treated as security or administrative isolation boundaries either. Users, application roles, content administration and service-level configuration continue to operate within the shared OAC instance.

A pre-production environment should resemble production closely enough to provide meaningful assurance before a release. A renamed model operating beside development and production workloads in the same service is not a true representation of the eventual production deployment.

The architectural distinction is straightforward:

Resource Groups isolate semantic-model deployments and query workloads inside OAC. Separate OAC instances isolate the environments themselves.

A conventional Development, Pre-production and Production topology therefore remains the safer enterprise architecture. Resource Groups can exist within each of those environments, but they do not replace them.

What Resource Groups genuinely isolate

Resource Groups still provide several valuable forms of separation.

Semantic-model deployment

Each Resource Group contains one deployed semantic model. A model can be replaced without requiring every other model in the instance to be rebuilt or redeployed.

Dependencies must still be managed carefully. Undeploying a model or deleting its Resource Group will affect the analyses, dashboards and workbooks that depend on its subject areas.

Query workload

Additional Resource Groups receive dedicated OCPU capacity. This can reduce contention and prevent one semantic model’s query demand from consuming all the capacity available to another.

This is particularly useful where workloads have very different characteristics. Executive dashboards, high-volume operational reporting and embedded analytics may have distinct concurrency and performance requirements even when they are delivered through the same OAC instance.

Ownership and release schedules

Models representing independent business domains can be owned by separate teams and follow different development schedules.

A change to a finance model does not automatically require the sales or supply-chain models to be released at the same time. This can reduce the coordination overhead associated with a large, centrally managed semantic model.

These are meaningful operational boundaries, but they remain boundaries within a shared OAC environment.

Where Resource Groups fit best

The strongest use cases are based on business-domain or workload separation.

Domain-aligned semantic models

Finance, sales and supply chain might each maintain a separate model where they have different data sources, security requirements, query patterns and delivery schedules.

This works best when the domains are genuinely independent. If they depend heavily on the same dimensions, measures and calculations, separating them can introduce inconsistency rather than autonomy.

Workload separation

A high-concurrency operational model might be placed in a separate Resource Group from a model supporting less frequent but highly complex executive queries.

Dedicated capacity gives administrators greater control over the effect each workload has on the other.

Consolidating existing models

An organisation may already operate several governed semantic models across departmental or inherited analytics environments. Resource Groups provide an opportunity to consolidate some of those models without immediately combining their metadata or forcing every team onto one release cycle.

Packaged and custom analytics

A packaged semantic model could coexist with a separately maintained enterprise or departmental model. This may avoid extensive modification of the packaged model while allowing the custom model to evolve independently.

Temporary side-by-side testing

A non-production OAC instance could temporarily host a current model, a candidate release and an experimental redesign. This may be useful for regression testing, performance comparisons or user evaluation.

That can be a legitimate testing technique. It should not be confused with a permanent Development, Pre-production and Production architecture.

When models should remain together

The arrival of Resource Groups does not mean every large semantic model should be divided.

Closely related subject areas generally belong in the same model when users require:

• shared conformed dimensions;
• common calculations and business rules;
• cross-domain measures;
• fields from different domains in the same visualisation;
• consistent definitions of customer, product, revenue or margin; or
• queries that traverse relationships between the domains.

A useful decision rule is:

Separate models when ownership, release independence and workload isolation matter more than cross-domain analytical integration.

If the business expects seamless analysis across the proposed boundaries, retaining an integrated semantic model will usually provide a better user experience.

Governance becomes more important

Moving from one model to several does not reduce the need for enterprise governance. In some respects, it increases it.

Oracle explicitly requires unique subject area names and alternate names across all deployed models. Organisations should extend that requirement into a wider governance framework covering:

• model and subject-area naming;
• business-domain ownership;
• metric definitions;
• access and security responsibilities;
• deployment approvals;
• capacity allocation;
• dependency management; and
• model retirement.

Without this governance, several independent models may define concepts such as revenue, customer or margin differently. OAC would then present these subject areas together without resolving their semantic inconsistencies.

Resource Groups make decentralised ownership more practical, but decentralisation without coordination can simply produce several competing versions of the truth.

Oracle’s deployment constraints are documented in Considerations for Deploying Multiple Semantic Models, while the intended workload and governance scenarios are described in Set Up Resource Groups for Multiple Semantic Models.

A more deliberate architectural choice

Resource Groups remove an important limitation from Oracle Analytics Cloud. Organisations can now deploy up to three independently managed semantic models within one instance and provide dedicated capacity to additional workloads.

This creates new options for domain ownership, model consolidation and performance management. It can reduce the pressure to place every subject area into one increasingly monolithic model or operate a separate OAC service for every independent workload.

However, the boundaries of the feature matter.

Resource Groups do not merge semantic models, enable cross-model joins or create separate lifecycle environments. They provide operational isolation within a shared OAC service.

The recommended architectural approach is therefore:

• use separate OAC instances to isolate Development, Pre-production and Production;
• use Resource Groups within those instances to separate appropriate semantic models and workloads; and
• retain integrated semantic models wherever shared calculations and cross-domain analysis are required.

The value of Resource Groups is not that every semantic model should now be divided. It is that OAC architects finally have a more deliberate choice between semantic integration and operational isolation.