Three apps, one business
Every P&C insurer does the same three things: it agrees to cover a risk, it collects premium for that cover, and it pays when something goes wrong. InsuranceSuite gives each job its own application, with its own database, its own users and its own release cycle.
PolicyCenter
Policy administration. Products, quotes, underwriting, binding and issuing, mid-term changes, renewals, cancellations and audits.
BillingCenter
Billing and collections. Turns premium into charges and invoices, takes payments, chases arrears, refunds money and pays producer commission.
ClaimCenter
Claims management. First notice of loss, coverage checks, exposures, reserves, payments, recoveries, litigation and fraud flags.
Around the core three sit supporting products. You will meet some of them on most projects, even though this course does not cover them in depth:
- ContactManager — a shared address book so a customer, garage or lawyer is one record, not three.
- Digital portals — customer, agent and claims portals built on Guidewire's front-end framework (Jutro) that call into the core apps.
- Data and analytics products — warehouse and reporting layers fed from the core databases.
One policy's journey
The easiest way to understand the boundaries is to follow a single car policy from first quote to a paid claim.
- PolicyCenterSubmissionAgent quotes, underwriting rules run, policy is bound and issued.
- PC → BCBilling instructionPolicyCenter sends the issued premium to BillingCenter.
- BillingCenterInvoicesCharges are split into instalments and invoiced.
- ClaimCenterFNOLCustomer reports an accident; ClaimCenter pulls the policy snapshot.
- ClaimCenterPaymentReserves are set and the garage is paid.
Three things are worth noticing:
- PolicyCenter is the system of record for cover. BillingCenter and ClaimCenter both hold copies of policy information, but they get it from PolicyCenter.
- Money moves in one direction per app. BillingCenter is mostly money in (premium). ClaimCenter is mostly money out (indemnity and expenses). Neither app posts to the general ledger directly in most designs; both feed a finance system.
- The apps talk to each other through integration points, not a shared database. That's why the developer track ends with a module on how the messages and plugins work.
Concepts every app shares
Because all three apps are built on the same platform, a lot of vocabulary carries across. Learn these once and they'll serve you everywhere.
| Concept | What it means | Covered in |
|---|---|---|
| Entity | A business object defined in metadata (Account, Claim, Invoice) that becomes a database table and a Gosu type. | Module 02 |
| Typelist | A controlled list of codes (claim states, coverage types) used for dropdowns and logic. | Module 02 |
| Activity | A task assigned to a user or queue with a due date: "call the insured", "review referral". | Module 03 |
| Role & permission | What a user is allowed to see and do. | Module 03 |
| Rules | Gosu logic the platform calls at fixed moments: validation, assignment, pre-update. | Module 15 |
| Plugin | A Java/Gosu interface where the app calls out to custom or external code. | Module 15 |
| Batch process | Scheduled background work: invoicing, aging activities, sending messages. | Module 15 |
How the platform is built
You don't need to be a developer to benefit from a rough picture of what's under the screens.
- Configuration, not code changes to the product. Insurers don't edit Guidewire's base source. They add configuration — extended entities, new screens, rules, plugins — in layers on top of the base product. That's what keeps upgrades possible.
- Gosu is Guidewire's JVM language. Rules, plugin implementations and screen logic are written in it. The developer track starts with it in module 12.
- Guidewire Studio is the IDE developers use to edit configuration, run the server locally and debug.
Newer implementations usually run on Guidewire Cloud, where Guidewire operates the infrastructure and releases arrive on a regular cadence. Older ones are self-managed on the insurer's own servers. The business concepts in this course are the same either way; what changes is how you deploy, which APIs you prefer and how strict the upgrade rules are.
Who does what on a project
A typical InsuranceSuite programme mixes business and technical roles. Knowing who owns what saves a lot of misplaced questions.
| Role | Typical work | Track here |
|---|---|---|
| Business analyst | Workshops, user stories, product definitions, fit-gap against base product | Functional |
| Product / rating analyst | Coverages, terms, rate tables and rate routines | Functional |
| Configuration developer | Entities, typelists, PCF screens, rules, Gosu | Developer |
| Integration developer | Plugins, messaging, web services, finance and document feeds | Developer |
| Tester | Functional, regression and integration testing across the apps | Both |
Both tracks share modules 01–03. Then business analysts and testers follow PolicyCenter, BillingCenter and ClaimCenter (04–11). Developers can jump straight to 12–16, but will understand the integration module much better after skimming the functional modules first.