eCommunications Industry | Day 1 - Topic 1

🏗️ 5a. Siebel Architecture

Sub-topic 5 of 6
83% Complete

Siebel uses a classic 3-tier architecture: Presentation Layer, Application Layer, and Data Layer.

Siebel 3-Layer Architecture
Siebel's 3-Layer Architecture: Presentation → Application → Data

Three Architecture Layers

1. Presentation Layer (User Interface)

Purpose: Provides user interaction and displays business data

  • Web Browser Client: HTML/JavaScript interface accessed via standard browsers (Chrome, Edge, Firefox)
  • Mobile Applications: iOS and Android apps for field users and mobile workforce
  • Open UI Framework: Modern JavaScript-based UI for customization and enhanced user experience
  • Thin Client: No installation required on user devices, all processing server-side

Key Benefit: Users can access Siebel from anywhere - office desktops, home laptops, tablets, or smartphones - with consistent experience.

2. Application Layer (Business Logic)

Purpose: Processes business rules, workflows, and application logic

  • Siebel Application Server: Core processing engine that handles all business transactions
  • Object Manager (OM): Manages business objects (Accounts, Contacts, Opportunities) and enforces business rules
  • Workflow Process Manager: Executes automated workflows (approval processes, SR routing, order fulfillment)
  • Assignment Manager: Intelligently routes work items to appropriate users or teams based on rules
  • Business Services: Reusable code components for integrations and custom logic
  • EAI (Enterprise Application Integration): Connects to external systems (billing, ERP, provisioning)

Key Benefit: Centralized business logic ensures consistency across all channels and enables easy updates without touching UI or database.

3. Data Layer (Database)

Purpose: Stores all business and configuration data persistently

  • Supported Databases: Oracle Database, Microsoft SQL Server, or IBM DB2
  • Data Model: Comprehensive schema with 1000+ tables covering CRM entities:
    • S_ORG_EXT - Accounts/Organizations
    • S_CONTACT - Contacts/People
    • S_OPTY - Sales Opportunities
    • S_SRV_REQ - Service Requests
    • S_ORDER - Orders
    • S_PROD_INT - Products
  • Repository: Stores Siebel metadata (views, applets, business components, workflows)
  • Indexes & Partitioning: Optimized for high-volume data access and reporting
  • Audit & Archive: Historical data tracking and compliance features

Key Benefit: Enterprise-grade database ensures data integrity, security, and supports millions of customer records with high performance.

How the Layers Work Together

Example: Agent Creates a Service Request

  1. Presentation Layer: Agent fills SR form in web browser → Clicks "Save"
  2. Application Layer:
    • Object Manager receives request → Validates data (required fields, format)
    • Workflow engine triggers → Assigns SR to appropriate queue based on issue type
    • Business rules apply → Sets priority, SLA deadline, escalation rules
    • Notification service → Sends email to assigned agent
  3. Data Layer: SR record inserted into S_SRV_REQ table → Committed to database
  4. Response: Application Layer sends confirmation → Presentation Layer displays "SR #12345 Created Successfully"

Advantages of 3-Layer Architecture

🔄 Scalability

  • Add more application servers to handle increased user load (horizontal scaling)
  • Database can be clustered for high availability
  • Load balancers distribute traffic across multiple servers

🔧 Maintainability

  • Update business logic without changing UI or database schema
  • Deploy new features to application layer only
  • Separate teams can work on different layers independently

🔒 Security

  • Users never directly access database (application layer enforces security)
  • Data encryption at rest (database) and in transit (SSL/TLS)
  • Role-based access control applied at application layer
  • Firewall isolation between layers

⚡ Performance

  • Application layer caching reduces database queries
  • Connection pooling optimizes database connections
  • Static content (images, CSS, JS) served by web server, not application server

🌐 Flexibility

  • Support multiple UI types (web, mobile, API) using same application logic
  • Swap database vendors (Oracle → SQL Server) without changing application code
  • Deploy across multiple data centers for disaster recovery
Estimated reading: 3 minutes