Below is the 1st of 11 Novarica Research Council Impact Award nominee case studies, which INN is presenting in no particular order. The awards will be presented at the research and advisory firm’s August 13th event in New York and honor best practices in insurance industry IT initiatives and strategy.

Amica, a mutual insurer that provides auto, home and life insurance, wanted to improve the effectiveness of its application development process. The company realized that unrelated code changes and improperly configured environment settings had led to build failures that prevented Amica from hitting project deadlines.

Amica addressed the challenge by creating an application configuration management section, a new practice that incorporates DevOps best practices into its software development cycle.

The application configuration management section centralizes application build master responsibilities, provides education and formalizes environment procedures. It allows the company to improve the maintenance of test data and alleviate developer roadblocks.

The initiative supports Amica’s IT goals of modernizing its technology and identifying and implementing process efficiencies. It was overseen by an IT sponsor who worked through issues including staffing challenges, adoption of new procedures by the development team and obtaining purchase approval for DevOps software.

The sponsor worked under the direction of senior IT managers, who reviewed the business case for the project. Nine dedicated IT team members and one part-time person responsible for client server infrastructure handled product installation and server setup. Of the nine team members, four were dedicated to buildmaster DevOps and five were focused on mainframe functionality.

The project took more than six months to complete, with the first three months dedicated to assessing gaps and conducting request for proposals for software tools. The section was created using DevOps best practices, and purchased software specifically designed to handle quality gates, metrics and artifact retention. The team applied best practices to auditing and separation of duties.

Code issues, including missing repository code and inconsistent code standards, were one of the main challenges the team faced. It resolved these by clarifying standards and making corrections along the way.

Anther significant challenge had to do with finding appropriately skilled staff to support the project. Amica resolved this by reprioritizing initiatives, working extra hours and borrowing resources.

The creation of the application configuration management section resulted in significant enhancements to the company’s IT development environment. Amica decreased non-code related build failures from 20 percent to less than 1 percent for a key project, reduced deployment of new web services from several days to two hours and improved developer software setup from one and a half days to 25 minutes.

In addition, the section allowed IT to plan for the 2014 projects that identified a gap in the number of environments needed. Knowing this, the team then used available Java developers for project work and improved code deployment turnaround time.

In his own words, Greg Calderiso, Information Systems Officer at Amica, shares lessons learned from this project.    


Change management

For this project, change management was almost unavoidable. It was the epitome of, “You don’t know what you don’t know.” Each section had previously been responsible for the structure and deployment of its own applications and services. Once the Application Configuration Management (ACM) section took over, it became clear how differently it was all being done, and it increased the scope of the effort to bring them into a common pattern.


Project management

The project was managed very tightly by the section manager of the ACM, and it included a project plan that had milestones and dedicated resources assigned.



This effort was not easy to staff. We were attempting to implement a new paradigm, with very specific skill sets and ways of thinking. We needed to take high-demand resources away from key strategic initiatives that would not deliver direct business value until the efficiencies were realized.



The project required some new tools that allowed the team process automation, guaranteed consistency of artifacts and fulfilled auditing requirements in the sign off of code. An RFP was done, and several tools were looked at until we ultimately made our decision to work with UrbanCode.


What would you do differently?

The challenge, which in the current environment will always be a challenge, was that we were trying to change core/fundamental architecture in the middle of ongoing major strategic initiatives. Attempting to make such a foundational change in the middle of concurrent projects proved to be very, very difficult. 

A project like this needs very strong buy-in from the highest levels of sponsorship, which we had. I would love to say that if we were going to do it again we would pick a better time, but the fear is that there is never a good time. Looking back, I would set expectations differently and do a better job of communicating the benefits of this effort to all parties throughout the life of the project. 

Ultimately, I’d make sure everyone who was impacted by it understood why we were doing it, what it would take to get it done and how we, as a department and a company, were going to benefit from it in the long run.

Register or login for access to this item and much more

All Digital Insurance content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access