Guidewire InsuranceSuite overview

Three apps, one business

PolicyCenter

Policy administration: products, quoting, underwriting, binding, issuing, changes, renewals, cancellations. Module 10 →

BillingCenter

Billing and collection: charges, invoices, payment plans, payments, delinquency, commissions, disbursements. Module 11 →

ClaimCenter

Claims: FNOL, coverage, exposures, reserves, payments, recoveries, activities and assignment. Module 12 →

A shared ContactManager holds people and companies (customers, claimants, vendors) used across the suite. Insurers can buy the apps separately (many run Guidewire ClaimCenter with another policy system, or the reverse), so integrations between them use the same mechanisms as integrations with outside systems.

Simplified integration view. Each line is implemented through plugins, messaging and APIs.

The data model

Every Guidewire application is built on a data model of entities, persisted in a relational database. As a business analyst or developer you'll talk in entity names constantly.

Entity: A business object with fields and relationships, e.g. Account, PolicyPeriod, Claim, Exposure, Invoice. Defined in XML metadata (.eti files; customer extensions in .etx).
Typelist: A controlled list of codes (a dropdown), e.g. LossCause or Jurisdiction. Extended with .ttx files, for example to add Danish loss causes such as cloudburst.
Foreign key / array: Relationships: a Claim has an array of Exposures; an Exposure points to a Coverage.
Effective-dated entity: PolicyCenter-specific: entities whose values vary over time within a policy term. This is how PolicyCenter implements the policy versions from module 03.

Naming conventionCustomer-added fields and entities conventionally end in _Ext (e.g. BonusStep_Ext), so they're easy to separate from the base product during upgrades.

Building blocks for configuration

Building block	What it is	Example use
Gosu	Guidewire's statically typed, JVM-based programming language	Business logic, rules, integration code
PCF files	Page Configuration Format: XML that defines screens	Add a "Bonus step" field to the vehicle screen
Rules	Gosu rule sets that fire at defined points (validation, assignment, pre-update, events…)	Assign storm claims to the CAT team
Product model	PolicyCenter's definition of products, coverages, terms and questions (via Advanced Product Designer)	Model Danish husforsikring with optional svamp og insekt
Plans	BillingCenter's configurable business rules (payment, delinquency, commission plans)	Quarterly plan with Betalingsservice
Workflows, batch & work queues	Long-running processes and scheduled jobs	Nightly renewal run; delinquency processing
Plugins & messaging	Interfaces for calling out to, and receiving from, external systems	Send documents to Digital Post; post to the GL
Cloud API	REST APIs for each application	Web portal creates a quote; app reports a claim

The work is done in Guidewire Studio, an IntelliJ-based IDE. A principle of Guidewire projects is configure rather than customise: use the extension points (_Ext entities, rules, plugins) so the base product can still be upgraded.

Guidewire Cloud

Most new implementations run on Guidewire Cloud Platform (GWCP), a Guidewire-operated SaaS-style service on AWS. Customers still configure the applications, but deploy through Guidewire's cloud tooling and receive regular platform releases. Each cloud release has a name rather than only a number, so you'll hear people refer to "the X release". Around the core sit related products: digital portals built with the Jutro front-end framework, data and analytics offerings, and integration tooling such as Integration Gateway and App Events.

Versions differGuidewire changes quickly, and names, features and tools vary between on-premise versions and cloud releases. Treat this course as the conceptual map and use Guidewire's own documentation (docs.guidewire.com) and training for the version you work on.

A Danish implementation

Guidewire's base configuration is international (largely US-flavoured). A Danish project spends much of its effort on localisation and integration:

Area	Typical Danish work
Products	Danish lines and coverages, bonus ladders, full-value building cover, indexation at hovedforfald
Parties	CPR numbers for private persons (sensitive data: masking and access control), CVR numbers for companies, Danish address formats
Registers	DMR (vehicles), BBR (buildings), DAR (addresses), CVR (companies)
Billing	Betalingsservice mandates and collection files, FI payment codes, MobilePay, taxes and Naturskade levy as separate charges, legal reminder procedure
Claims	Danish loss causes (cloudburst, storm surge), AES for workers' injury, repair networks, inter-insurer motor recoveries
Output	Danish-language documents and letters, delivered via Digital Post / e-Boks; MitID login on portals
Finance	DKK, Danish chart of accounts, posting to the ERP/GL (often SAP), IFRS 17 and Solvency II data

Key takeaways

PolicyCenter = policies, BillingCenter = money in, ClaimCenter = claims and money out; ContactManager is shared.
Everything sits on a data model of entities and typelists; extensions end in _Ext.
Configuration tools: Gosu, PCF screens, rules, product model, plans, workflows, plugins, Cloud API.
Most new projects run on Guidewire Cloud; check the docs for your release.
Danish projects focus on localised products and integrations: CPR/CVR, DMR, BBR, Betalingsservice, Digital Post, AES.