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.
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.
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.
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.
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.
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.
No comments:
Post a Comment