Siebel on OCI

Oracle Siebel CRM is a large, multi tier customer relationship management application that has often been running for many years, and it runs well on Oracle Cloud Infrastructure when its tiers are mapped deliberately to OCI services rather than copied from the on premises layout. Siebel separates its work across the web, gateway, server, and database tiers, and a thoughtful OCI design gives the estate the performance, resilience, and manageability that fixed on premises hardware struggled to provide.

This article sets out how to run Siebel on OCI: the tier architecture and how it maps to OCI services, the network design, high availability, disaster recovery, and the operating model. It is part of the running Oracle applications on OCI series and relates closely to our PeopleSoft on OCI architecture guide for those running both.

The Siebel tiers

Siebel separates its work across several tiers. The web tier serves the browser based interface and handles user requests through a web server. The Siebel gateway manages the configuration and coordinates the enterprise. The Siebel server tier runs the business logic, the object managers, and the batch components. The database tier holds the data. Each tier has a distinct role and distinct resource demands, which is why mapping them deliberately to OCI matters as much for Siebel as for any other multi tier Oracle application.

Understanding these tiers is the starting point for a Siebel architecture on OCI, because the right design follows from the role each tier plays. The web tier serves interactive users, the Siebel server tier handles the application logic and batch work, the gateway coordinates the enterprise, and the database is the most sensitive and performance critical asset. Mapping these deliberately to OCI is the foundation of a healthy estate.

Mapping the tiers to OCI

On OCI, the Siebel database tier maps to a managed database platform, typically a Base Database service or VM cluster sized to the database, with Exadata Cloud Service available for the largest estates. The Siebel server tier maps to compute instances sized to the logic and batch demand. The web tier maps to compute instances behind a flexible load balancer, which gives users a single stable entry point and distributes traffic across web nodes. The gateway maps to a compute instance, configured for resilience where the estate requires it.

This mapping gives each tier a platform suited to its role, which is the core advantage over a straight copy of the on premises layout. The web tier gains the ability to scale to user load, the Siebel server tier gets compute sized to its real demand, and the database gets a managed platform that simplifies patching and backup. The estate performs better and costs less than an undifferentiated lift of the old servers, which for a long running Siebel estate were often bought for a peak that rarely occurs.

Network design for Siebel

Siebel tiers communicate heavily, so the network design directly affects performance. The reference design places the tiers in separate subnets within a virtual cloud network, with the database tier in a private subnet that is not reachable from the internet, the Siebel server, gateway, and web tiers in private subnets, and only the load balancer exposed to users. Network security groups express the rules in terms of the tiers, so the database accepts connections only from the Siebel server tier and each tier only from the tiers that need it.

Keeping the tiers close in network terms, within the same availability domain or carefully across domains for resilience, matters because the inter tier latency is part of the performance equation. Administrative access is routed through a bastion rather than exposed directly. This layered design keeps the database isolated as the most sensitive asset while giving the interactive and batch tiers the low latency paths they need to perform well.

High availability for Siebel

High availability for Siebel on OCI is built at each tier. At the database tier, Real Application Clusters on a VM cluster or Exadata provides resilience against a node failure. At the web and Siebel server tiers, running multiple nodes means the loss of one node does not take the function down, with the load balancer steering user traffic to surviving web nodes. The gateway should be made resilient so it is not a single point of failure for the enterprise. OCI fault domains let you place these nodes so they do not share underlying hardware.

This in region high availability handles the common case of a component failing and is distinct from disaster recovery, which protects against the loss of a whole region. Designing high availability at each tier gives Siebel the resilience it often lacked on premises, where redundancy was constrained by hardware. On OCI the redundancy is a design choice rather than a hardware budget question, which lets a Siebel estate be made more resilient than it ever was on fixed hardware.

Disaster recovery for Siebel

Disaster recovery for Siebel on OCI combines a database standby with the ability to bring up the web, Siebel server, and gateway tiers in a second region. The database is protected with Data Guard, which maintains a continuously updated standby copy in the second region, so the recovery point is small. The application tiers are defined as infrastructure as code so they can be stood up in the standby region, either kept warm or built from code on failover depending on the recovery time the business requires.

As with other multi tier Oracle applications, the trap to avoid is protecting only the database and neglecting the application tiers, which leaves the estate unable to actually serve users after a regional event. A sound Siebel disaster recovery design protects all the tiers and is rehearsed regularly so the recovery time is known rather than assumed. The recovery targets set by the business drive how much of the application tier runs warm between disasters.

The operating model and licensing

A well architected Siebel estate still needs a sound operating model to stay healthy, covering database patching, Siebel server and web tier patching, backup and recovery across the tiers, monitoring, disaster recovery rehearsal, and cost management. Defining the whole environment as infrastructure as code makes the estate reproducible, which is what enables reliable disaster recovery, repeatable patching, and clean environment cloning for testing. For a long running Siebel estate, this discipline replaces years of hand built fragility with a version controlled asset.

A Siebel move to OCI also involves database licensing decisions that interact closely with the architecture, particularly the database platform choice and the way existing Oracle licenses transfer to OCI. These decisions affect the total cost substantially, and because the rules are intricate this is an area where independent expertise pays for itself. We work alongside independent licensing specialists so the architecture and the licensing model are decided together. Our Siebel on OCI workload service builds and runs Siebel estates this way, and the wider context is in the running Oracle applications on OCI pillar.

Sizing the tiers to demand

A Siebel setup on OCI should size each tier to its measured demand rather than to the on premises hardware, which for a long running Siebel estate was almost certainly bought for a peak that rarely occurs. The database tier is sized to its real performance profile, the Siebel server tier to the object manager and batch component load, and the web tier to the concurrent user load. Because these demands vary through the day, the design can size the tiers to typical demand and scale them for known peaks rather than running peak capacity all year, which is where much of the cost saving on a Siebel move comes from.

This demand based sizing should be evidence based rather than a guess, which is why an assessment measures real demand rather than reading the hardware specification. Long running Siebel estates are particularly prone to over provisioning, because capacity was added over the years and rarely removed, so the gap between the provisioned footprint and the real demand is often large. Sizing to demand at setup time captures that gap as a saving from the start.

Backup and recovery design

Backup for Siebel on OCI covers the database and the application tiers in different ways. The database is protected with regular backups, which OCI managed database services largely automate, and these backups can be replicated to a second region to support disaster recovery. The application tiers, defined as infrastructure as code, are rebuilt from code rather than backed up at the file level, with the configuration and customizations held in version control. This split is faster and more reliable than the on premises model of backing up hand built servers.

The recovery design combines a database restore or standby promotion with an application tier rebuild from code, and the whole sequence should be tested so the recovery time is known rather than assumed. For Siebel, with its several tiers and the gateway that coordinates the enterprise, this testing confirms the order in which the components come up and connect during a recovery. A recovery that has been rehearsed is a capability; one that has only been designed is an assumption.

Monitoring the estate

A Siebel estate on OCI needs monitoring across its tiers so that problems are caught before users notice them. The monitoring covers the database, the Siebel server and its components, the web tier, the gateway, and the load balancer, watching both the health of each component and the performance users experience. Because Siebel spreads its work across tiers, effective monitoring correlates across them, so a slowdown experienced in the browser can be traced to its real cause in the Siebel server, the database, or the gateway.

Good monitoring is also what makes capacity management possible, because the demand data shows whether the tiers are sized correctly and where there is room to scale down or a need to scale up. This connects the monitoring to the cost management that keeps the estate economical, and it sits naturally within a managed service where the monitoring is watched and acted on rather than merely configured. Our OCI monitoring and observability service covers this across Oracle application estates.