Implementation Sizing

and Tuning - Values

A G U I D E W I R E W H I T E PA P E R

Introduction
Customers develop, test, and deploy Guidewire applications in various environments. These include Development, Quality
Assurance (QA), User Acceptance Testing (UAT), Data Conversion, Performance Testing, Production, and Disaster
Recovery (DR), among others. This document details the baseline hardware required to support such environments, with
stability and good performance. Some generic tunings for parts of the software stacks used in these environments are
also provided; these can be refined upon further understanding of the Guidewire platform, and of the tuning
considerations specific to a given Guidewire application and its supporting stack. Guidewire publishes other white papers
that document tuning recommendations, and explain how to further optimize them.
Guidewire application infrastructure requirements, as seen on the application server, database, and storage tiers, depend
upon the online or batch loads applied, as well as the data volumes accessed.
Generic deployment options, for various environments ranging from Development to Production, are discussed.
Recommendations for general purpose monitoring are also provided. Details about Guidewire's general approach to
determining sizing for environments, and a description of the performance tests used to derive sizings, are provided in a
separate white paper: Implementation Sizing and Tuning Basis (document reference 1). A detailed explanation of
terms, and the business metrics which are factored into sizing estimates, is provided in a separate white paper: Gathering
Guidewire Customer Sizing Information (document reference 2).
This document is primarily targeted to Infrastructure Architects, who are responsible for the sizing and design of the
various environments used to prepare and run Guidewire products.
Published 2.28.2014.

Guidewire applications and environments.

Guidewire distributions

Guidewire currently delivers ClaimCenter (CC), ContactManager (CM), PolicyCenter (PC), BillingCenter (BC),
DataHub (DH), InfoCenter (IC) and Standard Reporting (SR) products.
IBM Cognos Business Intelligence Server (Cognos, used for Reporting) is a component of SR and IC. For Guidewire
7.0 products only, Cognos can also be implemented separately. Cognos can be bundled with InfoCenter and
Standard Reporting products, or licensed separately.
SAP BusinessObjects Data Integration Job Server (DI) is a component of DataHub, InfoCenter, and Standard
Reporting. DI supports ETL, and can likewise be bundled with these Guidewire products, or licensed separately.
Depending on the product version, Solr search may be bundled with ClaimCenter, ContactManager, PolicyCenter,
and BillingCenter.

Classes of environments
Different environments experience very different levels of load on their infrastructure components. It is useful to describe
several classes of environments, whose members are typically loaded in a similar fashion.
Configuration class (includes Developer laptops and workstations, limited "Sandbox" environments for
demonstration, and, starting with PolicyCenter 8.0, Product Designer environments): these environments are
used to configure and demonstrate the product. A single user configures the product, and then unit tests it on a
single server instance. Product Designer, available starting with PolicyCenter 8.0, can be used standalone on a
developer laptop or workstation, or as multi-user server component.
Functional test class (includes Build, Quality Assurance AKA QA, and End User Training): these environments are
used to functionally test the product. Builds are created that include work from multiple developers, and
functional test and QA is performed upon them. Typically, at most a few users access the product concurrently.
Conversion/migration: these environments are used to convert production data from an outgoing legacy system.
There is typically no significant application tier load in terms of user requests (the active user count is minimal).
However the load on the database and storage tiers, due to the large volumes of data to be read and written, can
be significant.
Non-production class (includes Pre-production AKA Pre-prod, User Acceptance Testing AKA UAT, and System
Integration Testing AKA SIT): these environments support less severe non-production loads, but typically have
distributed architectures that resemble Production-class environments, albeit smaller. Pre-production is typically
used to test production changes and fixes before deployment, often against Production-class data in a preproduction database. Therefore in some cases pre-prod may be used more as a production-class environment.
Production-class (includes Production AKA Prod, Disaster Recovery AKA DR, and Performance Testing AKA Perf
Test): these environments must support maximum load, and so are sized to meet the loads expected, while
maintaining good online response and batch completion times.
Production-user (end user workstations): typical end users access the application through a web browser. Some
minimum requirements are needed to support the Guidewire User Interface (Web UI) with acceptable
performance.

Environment deployment timeline

A timeline for the establishment of the various environments during an implementation project is typically:
1. The end of Inception Build, QA, SIT, Migration (if in scope), all local developer Configuration environments
2. The end of Development (beginning of Testing phase/sprints) All of the above still in use, and add UAT
3. The end of Testing (beginning of Pilot/Production) All of the above still in use, and add Performance Testing, PreProd, Prod, and Disaster Recovery

Guidewire application components

Most Guidewire applications are typical JEE applications, and can be installed and used with, at a minimum, an application
server tier, a database tier, and a storage tier. It is also common in some environments to integrate Guidewire
applications with other external systems.
Guidewire applications are accessed by users through a web browser. Typically, requests are load-balanced using one or
more hardware devices, which forward into the application server tier. In some environments, customers may choose to
run an additional front-end web server tier to provide static content caching and compression. Occasionally, this tier may
also handle load balancing across the application server tier.
A development IDE called Studio is used by configuration experts to further adapt Guidewire applications to meet
Customer functional requirements. Studio is a standalone application that itself needs no external database. Studio is run
by a single user, and consequently has well-defined CPU and memory requirements.
Some customers choose to deploy a separate PolicyCenter implementation to handle high volume quote requests. Such
requests are typically from Quote Aggregator web sites that query multiple carriers for comparative quotes. This quoteonly PC implementation is also referred to as PolicyCenter Aggregator (PCAgg). PCAgg quotes may not be persisted, in
order to improve throughput.
InfoCenter (IC) and Standard Reporting (SR) use IBM Cognos Business Intelligence (Cognos Reporting or Cognos) to
provide reports based on enterprise data. There is a dependency between Guidewire applications and Cognos Reporting,
as Guidewire must provide a means for authenticating Cognos users. This is typically done by Guidewire running an
embedded (within the same JVM process) LDAP server. Although such LDAP services may run on multiple Guidewire
nodes, the calls into them (from Cognos) are not as easily load balanced. This is due to the Cognos plugin configuration
using a fixed location for the Guidewire LDAP service, and the lack of a means for Cognos nodes to determine the
available Guidewire cluster members.
Solr search is provided by a separate web application, which typically runs in the same type of application server as those
running the other Guidewire applications, but in a separate JVM process. Free text is typically read from one or more
Guidewire product databases and indexed.