An Enterprise Data Model (EDM) is traditionally designed as an OLTP (Online Transaction Processing) database structured in Third Normal Form (3NF) (or higher), rather than a dimensional model.
Here is how it breaks down in enterprise architecture:
1. Enterprise Data Model (EDM) = 3NF / OLTP Structure
Purpose: An EDM (like the life insurance model discussed above) serves as the single source of truth for an entire enterprise's operational processes. It is designed to capture, process, and store atomic, transaction-level data with minimal redundancy.
Life Insurance Enterprise Data Model
│
├── 1. Party Management Domain
│ ├── T_PARTY
│ ├── T_PARTY_ADDRESS
│ └── T_PARTY_CONTACT
│
├── 2. Product & Policy Domain
│ ├── T_PRODUCT
│ ├── T_POLICY
│ ├── T_COVERAGE
│ └── T_BENEFICIARY
│
├── 3. Underwriting & Risk Domain
│ ├── T_UNDERWRITING_CASE
│ └── T_MEDICAL_REQUIREMENT
│
├── 4. Billing & Premium Domain
│ ├── T_BILLING_ACCOUNT
│ └── T_PREMIUM_TRANSACTION
│
├── 5. Claims Management Domain
│ ├── T_CLAIM
│ └── T_CLAIM_PAYMENT
│
├── 6. Agent & Commission Domain
│ ├── T_AGENT
│ └── T_COMMISSION_TRANSACTION
│
└── 7. Reference & Lookup Domain
├── R_POLICY_STATUS
├── R_CLAIM_STATUS
└── R_PRODUCT_TYPE
------------------------------
PHASE 1 : Client meeting
( How client shares his OLTP requirement )
Client Meeting Transcript / Summary
Client: "Hi team. We are modernizing our core systems for our life insurance business. Right now, our data is heavily fragmented across legacy apps, spreadsheets, and third-party vendor tools. When a customer buys a policy, updates an address, or files a claim, things don't sync properly, and we run into data duplication and consistency issues. We need a centralized, rock-solid core database that can handle live, day-to-day transactions accurately without errors."
Architect / Technical Lead: "To make sure I understand correctly, you need a single source of truth that acts as the operational backbone for all live transactions—handling high-frequency data entries, rigorous data validation (like making sure a policy can't be issued without a valid insured party), and strict record-keeping?"
Client: "Exactly. It needs to capture every single operational detail cleanly. Specifically, we need to manage:"
Parties: Comprehensive profiles for our customers, agents, and beneficiaries, including their history of addresses and contact details.
Products & Policies: The actual life insurance products we sell, active policy contracts, riders/coverages attached to them, and designated beneficiaries.
Underwriting: Tracking the medical and financial risk assessment cases before a policy gets approved.
Billing & Premiums: Managing payment accounts, frequencies, and logging every single incoming payment transaction.
Claims: Handling the full lifecycle of a claim from the initial date of loss, through investigation, to final payout.
Agencies & Commissions: Tracking which agents sell what and calculating their commission payouts.
Architect / Technical Lead: "That gives us a complete picture. Based on what you've described—handling high-volume, concurrent operational transactions with zero redundancy and strict referential integrity—we should not build a reporting or analytical structure right now.
Instead, we need to design an Enterprise Data Model (EDM) built as an OLTP (Online Transaction Processing) database in Third Normal Form (3NF). This will ensure atomic data storage, eliminate anomalies for your daily operations, and cleanly organize everything into the core subject areas you outlined: Party Management, Product & Policy, Underwriting, Billing & Premium, Claims Management, and Agent & Commission. Once this operational foundation is live, we can feed it downstream into analytical star schemas for your executive dashboards."
Client: "That makes total sense. Let's proceed with that architectural approach
1.1 . Questions asked by Data Architect
Phase 1: Understanding Business Processes & Operational Pain Points
These questions uncover how the business runs day-to-day and why the current system is failing.
1)"Can you walk me through the lifecycle of a life insurance policy—from the moment a customer applies, to when it gets approved, billed, and eventually paid out or claimed?"
2) "Where are you experiencing the most friction or data inconsistency today across your current legacy systems or spreadsheets?" (Identifies operational bottlenecks and data silos).3) "Do you need multiple systems to write data simultaneously, and how critical is it that a change in customer details updates across everything instantly?" (Justifies the need for an OLTP transactional backend rather than a batch-loaded data warehouse).
