Mule enables major business overhaul for insurance firm 

In 2010, Employers Direct, a major workers' compensation insurance provider, became Pacific Compensation Insurance Company. As part of this shift, the company fundamentally changed its entire model from direct sales to utilizing insurance brokers. This required a major systems overhaul and posed substantial integration challenges.  Pacific Comp chose Mule ESB to integrate their policy management, billing management and other systems and facilitate the re-launch of the company with its new business model.

“Mule provided immediate value to Pacific Compensation Insurance Company by enabling our critical business transition.  However, it also proved robust enough to meet our future needs and easy enough to learn to accommodate all of our developers.  We’re very happy we decided to choose Mule”

Erich Leipold (evosolutions LLC), Architect, Pacific Compensation Insurance Company.

In 2009, the Employer’s Direct Insurance Company had a problem.  When the company, a wholly owned subsidiary of Alleghany Corporation, first entered the market for workers compensation insurance in California, Nevada and Arizona it enjoyed strong margins on its policies.  Its direct sales model was well suited for a market with limited capacity.  However, the profitability of the California workers comp market drew several new entrants over the coming years.  More capacity caused rates to slowly drop.

Then, in 2008, the “Great Recession” hit.  California’s unemployment rate rose from as low as 5% in 2007 to over 12% by 2009.   With fewer workers in the active workforce the California workers comp market hit a new level of overcapacity.  Rates plummeted further.  With this catastrophic change to its primary market, the company’s direct sales model no longer provided a competitive cost structure.  A major transformation was required.

On June 30, 2009 Employers Direct stopped writing direct policies and let go of its entire direct sales staff.  In the months that followed the company completely changed its business model from one oriented around direct sales to a model of sales through independent insurance agents.  The change was so fundamental that even the corporate name changed.  The company was re-branded Pacific Compensation Insurance Company (PCIC) to reflect the abandonment of its original direct sales model.

While the shift from direct sales to channel sales was a wrenching change for the business, it allowed PCIP to regain a sustainable cost structure and work with brokers to properly position the company as a premium provider in the market with differentiated service.  It enabled the company to compete in a changed business environment.

Together with the shift in business model, a substantial change in the software infrastructure of the company was required.  Pacific Compensation Insurance Company needed to enable its systems to support this new business model.  It would also need to integrate several new applications to enable insurance brokers.  Furthermore, with the business dormant, Pacific Comp’s development team needed to deliver these integrations in a tight timeframe.  Every day of delay was a day the company was not generating revenue.

The Solution:  Mule ESB as an integration platform for legacy systems, internal apps and SaaS 

The overall goal of Pacific Comp’s business shift was to decrease overhead and increase flexibility.  This too became the mandate for the technical architecture Pacific Comp’s technical team began building.  As much as possible PCIP chose to invest in software as a service (SaaS) applications as these allowed the company to ramp up and down their usage as the market dictated.  However, they also had several existing systems so it was necessary to integrate both legacy and new, cloud and on-premise.

Pacific Comp made a conscious decision to embrace a best-of-breed model for their software architecture.  The main systems they employed were First Best for Underwriting Management, DCo for Policy Management, Guidewire for claim center applications, STG Billing for billing management and SpringCM for document and workflow management.  Some, like DCo, were existing choices, whereas others like STG Billing were employed as part of the new business model.  All components would need to be integrated as part of the architecture.

With such a heterogeneous environment, integration became one of the key challenges.  To drive a solution, Pacific Comp hired Erich Leipold as a contract architect.  “The first thing we had to do was select an integration platform.  While some point-to-point integrations had already been implemented, we found them difficult to manage for flexible and scalable environments” said Erich Leipold (evolsolutions LLC), architect at Pacific Compensation Insurance Company.  “We therefore decided utilizing an enterprise service bus was the right architecture for our needs.”

After deciding an ESB was the right choice, Pacific Comp then evaluated several ESBs.  “After an extensive evaluation of the options, we decided on Mule ESB.  As we were mostly a Java shop, our solution needed to be Java-based.  We also wanted an open, extensible integration framework with a proven track record.  We also were looking for an active community of developers so we would be sure we could find and employ developers going forward.  Finally, some of our legacy systems were difficult to access and required the use of FTP and file transports on data including CSV and fixed-width file formats.  Mule easily fit all of our requirements” said Leipold.

Achieving a cross-organization understanding of the role of an ESB was an early challenge.  “Integration development is involved and time-consuming and time was the one thing we didn’t have.  Mule provides a consistent development environment that all developers can understand.  Its architecture allows developers to keep each Mule application small and focused” said Leipold.  This greatly improved the effectiveness of Pacific Comp’s relatively small development team.  “We also appreciated the application hot-deployment capabilities of Mule.  This made automated deployments much easier to manage.  It saved us critical time during our project.”

From an architectural perspective, Pacific Comp used substantial numbers of both internal and SaaS applications.  “We decided the best architecture for our needs actually involved two Mule instances: a public and private instance.  This provided appropriate security models for both external and internal Mule ‘users’” said Leipold.

Using Mule, Pacific Comp began implementing the most critical and time-sensitive use cases required for their 2010 re-launch.  First amongst these was integration between DCo, a legacy policy management application for the AS/400 platform that managed all Pacific Comp policies, and STG billing, a billing application offered by MajescoMastek.  

To enable billing on policies, Pacific Comp chose to integrate to its AS/400 system via a Websphere MQ queue.  Mule ESB picks messages off the queue.  If the messages are part of a group, the workflow is ordered and processed synchronously.  If they are not part of a group, then they are processed asynchronously.  

While the DCo AS/400 application acts as the central system of record for all policies, additional information is needed for correct billing.  This information is pulled from a database using JDBC and added to the message.  Finally the request is sent to the STG billing application via CXF.  “The DCo to STG billing integration was not only the most complicated integration in our environment but also the most essential.  Mule made building this integration much quicker and easier to maintain” said Leipold.

Mule also provides integration in the reverse direction.  However, this follows a somewhat different path.  STG Billing sends a web services request containing payment schedule updates for policies to the public Mule ESB-hosted CXF Web service.  The ESB accepts the request and validates the incoming data.  The data is then put on a JMS queue and the response is sent back to STG Billing.

After validating the message, the queue message is bridged to the private Mule instance for further processing.  The request data is transformed into installment schedules for DCo.  DCo receives the schedules through WMQ, fixed-width messages.  DCo then invokes a secondary process, triggering another workflow.

With the integration between policy management and billing in place, the most critical blocker to Pacific Comp’s re-launch was removed.  However, the company also had several other needs that Mule ESB was well suited to solve.  For example, they chose to use SpringCM as their enterprise content management system and Mule provided a platform to integrate this with a number of internal applications that processed documents involved in the day-to-day operation of the insurance practice.

Given the large number of documents printed daily in the insurance practice and the substantial call volume the business entails, Pacific Comp also developed several smaller applications on Mule.  The first of these printed groups of files delivered to Pacific Comp from STG billing as part of their billing workflow.  A second logged calls to a database.  Still others moved data between SQL databases, AS/400 databases and file shares as needed.   “One of the advantages of Mule is once you have delivered your first application, you can organically grow from there.  It’s not a huge deployment project upfront but once complete, it simplifies each additional application, no matter how big or small” said Leipold.

With their key systems integrated via Mule ESB, Pacific Comp re-launched their business via an insurance broker sales model in 2010 cutting their cost structure substantially and making the firm more competitive in the marketplace.  However, even with the re-launch of the company plans are underway to use Mule for many more integration projects.  

“Today most of our integration revolves around the policy and billing management systems with a few exceptions.  However, all new integrations will be developed using Mule and existing integrations using point-to-point code will gradually be migrated to Mule.  This is part of our eventual plan to develop an enterprise data model that can be used by all applications” said Leipold.

Pacific Comp is continuously bringing new developers onboard their Mule integration efforts.  “Compared to most integration solutions, Mule is easy to learn for most Java developers” said Leipold.  “However, we made some strategic choices upfront that paid dividends in the end.  The first was to start small and get familiar with the ESB in a bottoms-up approach rather than imposing a top-down project.  The second was to define the integration endpoints, security requirements and naming conventions for flows, services and endpoints up front.  This made rolling Mule out in a controlled and low-risk fashion much simpler.”

“Mule provided immediate value to Pacific Compensation Insurance Company by enabling our critical business transition.  However, it also proved robust enough to meet our future needs and easy enough to learn to accommodate all of our developers.  We’re very happy we decided to choose Mule” said Leipold.