Guidewire Software Insurance product review
Last Updated: March 2014
This review is for Guidewire Software products, including BillingCenter, PolicyCenter, and ClaimsCenter.
This is a product review of the Guidewire platform and its modules for Insurance Billing, Claims, and Policies.
This review of the Guidewire Software Insurance platform is from a developer that has had experience integrating new Guidewire applications as well as maintaining Guidewire applications for the insurance industry.
If you are considering using the Guidewire applications for your insurance Billing, Claims, or Policies, then please take the time to read the important details in this review.
----------------------------------------------------------------------------------------------------
Overall Grade: C
Pros: Good platform for building insurance applications for small
to medium businesses.
Scales well and handles a large number of concurrent users.
Cons: Support and Consulting Services are extremely weak and expensive
and do not offer any appreciable value for the cost.
Upgrades will cause a significant level of functionality loss and
take weeks or months to rectify.
----------------------------------------------------------------------------------------------------
The Guidewire platform, defined
The Guidewire platform is a java-based application that is designed to be quickly customized for each customers' line of business.
The ability to support numerous different types of policies with just a few changes of the configuration makes Guidewire a good tool to get your insurance business up and running quickly.
Guidewire offers modules that support the different facets of the insurance business, such as the Billing, Claims, and the issuance of Policies. By supplying the insurance platform as a set of modules, each company can implement the platform over time in any order that best serves the company.
Integration with the Guidewire products is generally done via web-services messages and/or JMS messages. The web-service messages are XML-based and are sent over HTTP/HTTPS, and JMS is the standard Java Messaging service. What this means for you is that if you want your Guidewire platform code to talk to other systems you may need to implement web services or JMS-like services in those other systems. There are other means of integration as the product can be extended in multiple ways.
Guidewire platform technologies
The platform utilizes a java-like language called Gosu, and anyone who is developing code for Guidewire will need to know Gosu. For most Java programmers, understanding Gosu is not too difficult. Gosu is very similar to Groovy and Javascript.
What is important to know about Gosu is that it creates a requirement for all your Guidewire developers.
Guidewire sales representatives seem to try to play-down the requirement to know Gosu to its customers. This is actually a misrepresentation of the skills required to create a successful implementation. The need to understand Gosu is key to being able to create good implementations with Guidewire Software. Additionally, many Gosu functions are deprecated between version upgrades, and only someone with a good grasp of the language will know how to make changes to existing code.
Guidewire platform performance and scalability
The Guidewire platform is just a java application hosted in a web application container such as Tomcat or JBoss. As such, it is a function of the application server configuration that dictates the performance and scalability of the Guidewire modules.
The Guidewire documentation provides guidelines for the setup and use of Tomcat, WebSphere, and JBoss application servers. With each application server Guidewire recommends running a 64-bit implementation for a production environment.
In my experience, if you have good hardware and know how to setup and harden a Java application server you can make the Guidewire application process scale to your needs. To key to scalability and performance with Guidewire is to know your app servers.
With Guidewire applications, getting the database to perform and scale is a completely different issue. When it comes to database performance, the Guidewire applications start out ok, but they get very large over time.
The primary issue is that Guidewire applications use a database persistence strategy which is based on dynamic table creation and management. Similar to a JPA solution or Hibernate, the Guidewire databases are not well-normalized and appear to just grow quickly in size over a short time. The selected technology means that for any given Guidewire product there can be large differences in performance from day to day. We have had issues with systems which were released over a year ago. Suddenly we would find a process or processes that had changed from a few minutes of run time to a number of hours of run time. When these problems occur, Guidewire isn't very helpful and does not provide any useful assistance.
In your Guidewire applications do not be surprised if you need an enterprise-class database setup that seems to grow in size, and yet provides differing performance levels for no apparent reason. If you can afford the DB server and have the infrastructure to perform very large database backups, then you should have few hurdles.
One example of the scale of the underlying database technology in Guidewire applications is with a BillingCenter installation we recently completed. The company has one line of insurance business in one state. After 18 months there were over 260000 policies in BillingCenter with two contacts per policy and a number of monetary transactions per contact. The database on SQL Server is a 10GB backup without compression and without the DB logs being backed up.
This level of scale for a single-line billing system infers that the database needed for a company with multiple insurance lines across multiple states must be incredibly massive. Remember that for each Guidewire application (Billing, Policy, Claims) you will have to run a separate database. If you have all products, then you will have at least 3 database instances and they will need plenty of room to scale.
INTERESTING NOTE: I found that for SQL Server the drivers supplied with the Guidewire platform had a lot of scalability problems. Guidewire was shipping the Microsoft JDBC driver for SQL Server with BillingCenter and PolicyCenter. This driver has a lot of known problems leaking connections under high load. To make Guidewire products scale to a high number of connections with SQL Server, I recommend that you replace the Microsoft JDBC driver with the jTDS driver for SQL Server.
Guidewire Business Rules
It won't be long after you start looking at the Guidewire applications before someone starts talking about the Business Rule engine. I have witnessed this feature being hard-sold to the upper management team, and touting its benefits over other platforms.
Guidewire applications don't really have a rules engine. Guidewire applications have events that are fired when class objects are changing or have been changed. By responding to the fired events before, during, or after updates, you can create a hierarchy that is comprised of Gosu code. But Gosu code is about all the feature really brings to the table.
Since the events are firing after some other action takes place, using the events as a rule engine cannot be realized. By the time an event is fired, something already happened, and you cannot validate it, or even determine what actually happened. Essentially, you have to code your business processes into the UI and the product model and then you can react to the changes they make when you are notified of an event.
Guidewire and existing Insurance Data
This is one place in the Guidewire software offering that seems to have a very large hole.
Guidewire will tell you not to look at, or read/write directly from the database. So the only means to import data into a Guidewire product is via a application called Import Tool. Import tool is a program that can take XML files in a certain format and read them into database staging tables, and then ultimately import them into the database proper.
But, when you cannot read/write the database directly, then loading ANY data will take hours at the least, and days more often than not. You also have to convert your data to the Guidewire XML format, and that is not a trivial exercise in itself.
Guidewire does not support a process where you can import hundreds-of-thousands of insurance records into its applications rapidly. The process Guidewire does support would take multiple days to achieve that level of throughput.
Now that I have implemented a number of Guidewire applications I can say that if you just take the time to get the data into the Guidewire database directly, you will save days of importing time.
Using Guidewires' import tool, the best throughput we could get was about 1500 policies per hour. That was only policy data, and not contact data, payment details, or anything else.
When we went directly into the database with one Guidewire application we loaded 750,000 complete policy records with contact details and payment transactions in 6 hours.
For a company with millions of policies and multiple insurance lines, getting existing data into a Guidewire application will be the hardest part of the entire project. To be honest, in all the Guidewire installations I have seen, I have to wonder if it is even feasible to import that much data.
I have used PolicyCenter, BillingCenter, and ClaimCenter, and all versions from 2 through 7, and this import issue is always a major problem with any new Guidewire application.
Guidewire professional services
Guidewire offers professional services to assist with the implementation of BillingCenter, PolicyCenter, and ClaimsCenter. You can have someone from Guidewire offer to help your team with the integration of a new product, or you can have someone from Guidewire come over and help you implement a new product.
In my interactions with Guidewire professional services I have worked with integrators and developers on BillingCenter and PolicyCenter.
In my experience, the people supplied by Guidewire were not fit for the roles they were given.
With BillingCenter and PolicyCenter at my last employer, we got the same person from Guidewire to help us develop an integration plan. The person I have worked with on these new Guidewire integrations was not helpful in any way.
In fact, I would say that had we not used someone from Guidewire we may have been able to complete the development work a little sooner.
The Guidewire contractor sent for integration support was pushy, and was not customer-focused. He insisted on driving the product integration meetings, and was inflexible in his approach to developing the integration plan and in how BillingCenter or PolicyCenter would be configured for a given task.
We found that the Guidewire contractor was unable to take the needs of our business and turn that into development tasks to configure the product. Every time we asked about implementing a component of our business in BillingCenter or PolicyCenter we were told how Guidewire handles that component 'out of the box' and how we should change our business to match the Guidewire product.
The individual sent by Guidewire professional services was not very good with people, and was very poor at listening to customers. Its my opinion that people which perform professional services need to be good with people and need to listen to the customers. Guidewire has not been able to provide what I consider to be good professional services people on projects I have been involved with.
On one Guidewire project we asked for the assistance of two Guidewire developers to help us implement a product. The two developers they sent actually worked well with people and were able show they were customer-focused, but the code they created was a nightmare. 3 months after the two Guidewire developers left we were submitting customer support issues to Guidewire and being told that some of the ways things were implemented were bad or wrong. As a result, that implementation of the Guidewire product is a giant mess and extremely difficult to maintain.
When we told the people at Guidewire support that their own developers created our nightmare code we were not given any guidance on the best ways to fix the code and to avoid the issues.
If you plan on using Guidewire for your insurance platform, plan on forcing Guidewire to do some things different for you. If not, it may appear that they are taking a lot of money from your company that you are not getting any value from.
I would not recommend Guidewire Software professional services based on my experiences. For what it costs, the money is better invested in training your own employees. With the training you will be able to configure BillingCenter, PolicyCenter, or ClaimCenter to do whatever you need.
Do not let Guidewire tell you that any professional services are required for any of its products. If you know your insurance line of business, you can send your developers to training and they will have the skills reqired to implement the product.
If you avoid Guidewire professional services you will save a significant amount of money, and you will be more likely to get your project delivered on-time with the features you want.
Guidewire Support
Guidewire offers support for all its users. Each developer in your company that is working on the Guidewire product will be given access to the Guidewire support portal. The Guidewire support portal is a fairly good self-help, web-based portal with a lot of information to help develop your Guidewire platform. When support is needed you can log a support request via the portal and email is sent out as the support case is handled.
Guidewire support is great for questions about how to do something with the platform.
But, I discovered an unspoken issue with the support offered by Guidewire that most customers would probably want to know about.
Guidewire does not support any customizations of its product. Guidewire does not tell you this until you log a support issue.
If you customize BillingCenter, PolicyCenter, or ClaimsCenter and then have an issue with the software you may not be happy with the support you receive from Guidewire Software. When you make a support request on any issue, the support people will install the base product you have and attempt to see if the issue is repeatable. This means that the support people are not testing your issue using your customized version of the product, but they are testing your issue on a new, unmodified version of the product.
In my opinion, this is an extremely bad practice on the part of Guidewire software. While I would hope my experiences were unique, Guidewire support seemed to omit this critical information until we were well into our Guidewire application roll-out.
The reason this is such a poor practice is that the BillingCenter, PolicyCenter, and ClaimCenter software require its users to make numerous customizations. Out of the box the Guidewire applications don't really offer any specific functionality. It is up to each customer to make customizations that meet the needs of their business.
Guidewire customers are told to upload all product customizations to the support portal so that the support people have a copy of the code you are working on. This leads one to believe that Guidewire Software Support will look at the customized code when you open a support incident.
Guidewire Software would not look at the customized code when we open support incidents at two separate employers.
After a few months, most Guidewire customers at my past employers began to wonder why they are asked to upload anything if the support department would not look at it.
In the past I also witnessed a lot of problems getting answers from Guidewire support in a timely fashion.
As of 2013 I noticed the support responses only took one or two days on average.
But in previous years, many support incidents we opened sat for at least a full week before being worked, or sat a week or more before we were told that Guidewire could not reproduce our issue. Our average support wait time on cases in 2012 and prior was about 7 business days.
I don't know if our service in 2013 improved due to our complaints, or if all support has improved.
Similar to my experiences with Guidewire professional services, I have found Guidewire Software Customer Support to offer very little value.
Guidewire Product Updates
Guidewire offers patches and upgrades as part of its product offerings for BillingCenter, PolicyCenter, and ClaimCenter. Guidewire Software also asks that its customers try to stay current on product revisions, and suggests that a customer never be more than one major version away from the most recent.
In my experience, the problem with requiring customers to stay up to date is that upgrades to a new major version of Guidewire products cause a near total loss of functionality.
I have been through a number of upgrades, major and minor, with BillingCenter and with PolicyCenter, and all of the upgrades didn't go well.
After all major version (3 to 4, etc) upgrades we had lost more than 50% of all our customized product functionality.
After all minor upgrades we had a some feature regression and usually a few 'new' UI issues.
The problem with upgrades to Guidewire Software products has nothing to do with how BillingCenter or PolicyCenter was customized. The problem with upgrades to BillingCenter, PolicyCenter, and ClaimsCenter is that upgrade process causes massive feature loss and regression.
In their documentation Guidewire states that its customers should take 6 months for a major upgrade.
With the major upgrades I was involved in, one took 8 months just to complete and upgrade of PolicyCenter. We spent 6 months after the upgrade process trying to get all our product functionality working again, and another 2 months of testing was needed to get acceptance to release to production. One of our BillingCenter instances lost so much functionality between releases that after 5 months we gave up and went back to the previous version.
If you want to have a measurable return on investment (ROI) using Guidewire products it is recommended that you NEVER upgrade any Guidewire product from any version to any other version. Even point releases (like v.7.0.1 to v.7.0.2) will have significant changes, only a few of which are documented, that will cause you to take a few weeks to fix and verify that there has been no loss of functionality.
If you push through and try to do an upgrade of any product/version you should expect large amounts of product functionality to need to be re-coded. The cost to upgrade a Guidewire product is extremely expensive after you have invested the appropriate development resources.
In 25 years of being a programmer I have never seen a product that loses so much core functionality and configuration after an upgrade as Guidewire BillingCenter and PolicyCenter did.
Minor Guidewire software upgrades will take a day to run, and 2 to 4 weeks to test and re-code.
Major Guidewire software upgrades take one day to run, 6 to 12 months to re-code your working system, and when you are done you may find you have no new features or performance enhancements.
Between the cost of developers and the cost of the upgrade and recurring maintenance fees, your company has put out large sums of money to upgrade to a new version of a Guidewire product and for all your efforts you may have gained very little.
