Insurance Brokerage System

CST499-30_FA18:Directed Group Capstone

Trammel May, Gene Evans, Kyle Luoma
August 22nd, 2018
 2

Executive Summary
This is the project proposal for the Insurance Brokerage System (IBS). The IBS is a

business-focused system that provides insurance management solutions to insurance agents and

brokers, particularly those who own and operate their own insurance businesses as LLCs, sole

proprietorships, or small corporations. The system will consist of a web-based management

interface that brokers can use to interact with the server-based back end that will include a secure

database.

The main objectives of this project are to develop a customer management utility, an

employee management utility, a transaction and invoice management utility, a policy certificate

management utility, a secure database system and a web-based user interface.

While there are existing management systems that target the same user group as this

project, none of them are leveraging existing technology to provide a more efficient and

automated business solution that this project aims to provide.

The project team consists of three members. The team will employ the agile software

development approach when building this system. This approach includes test-driven design and

enjoys the benefits of the Kotlin programming language that makes integration of object oriented

design principles and low coupling fairly convenient. Two insurance professionals have agreed

to participate in user testing, which the group will facilitate using video chat and prepared

questionnaires.

There are limited ethical and legal considerations that apply to this project. The majority

of considerations revolve around the consequences of poor security design and implementation.

The highest risk associated with this project is the spillage of sensitive customer information.
 3

The group mitigates this by developing the software using dummy data that includes no actual

information about customers.

The project development process will occur over a period of eight weeks. The group will

divide this time period into four agile sprints, culminating in a finished ​minimum viable product

near the end of week eight. The group consists of three members, and the division of labor is

based primarily on feature development, and secondarily on the front end / back end paradigm

common in many projects. Project performance metrics include scenario completion, presence

and frequency of critical errors, presence and frequency of non-critical errors and subjective

evaluation by insurance professionals. The project will be considered complete when the status

of minimum viable product has been reached.

 4

Table of Contents

Introduction 5

Project Goals and Objectives 6

Future Project Improvements 7
Contributor Objectives 8

Environmental Scan / Literature Review 8

Community and Stakeholders 9

Approach/Methodology 11

Ethical Considerations 12

Legal Considerations 15

Project Scope 16
Timeline / Budget 16
Resources Needed 16
Milestones 17
Risks and Dependencies 18

Final Deliverables 18

Usability Testing / Evaluation 18

Methodology 18
Participants 19
Procedure 19
Metrics 20
Scenario Completion 20
Critical Errors 21
Non-critical Errors 21
Subjective Evaluations 22

Team Members 22

References 23

Appendix 23
 5

Introduction

The Insurance Brokerage System (IBS) is a web-based tool designed to meet the needs of

insurance brokerage companies. It provides the ability to manage customers, perform

bookkeeping functions and store insurance certificate data. While there are several similar tools

on the market, there is a lack of understanding the groundwork that many insurance brokers go

through. There are numerous tasks that could and should be automated that could save hundreds

of human hours a year, and the marketplace is completely blind to those features. The major

components of the system include:

1. A web-based management system that presents client, account and certificate

information to brokers and allows appropriately privileged users to make changes and updates

to client databases, input transactions and manage both client and employee accounts.

2. A secure database management system that stores client information, transactions,

financial data and insurance certificates. The design and implementation of this DBMS has yet

to be resolved, but must be sufficiently secure and conform with X Y and Z practices governing

the storage of sensitive information.

There is currently one Client (of whom asked not to be identified in any documentation) to this

application who has agreed to assist with QA, beta testing, feature requests, and hopefully, to use

this product professionally.

 6

Project Goals and Objectives

1. Customer management utility: This utility maintains records of all customer (client)

businesses and associates each business with an insurance broker. The records will include, at a

minimum, contact information, insurance policy data, and billing information.

2. Employee management utility: This allows a brokerage owner or mid-level manager to

maintain records of subordinate broker employees. The manager will be able to set privilege

levels associated with each employee’s responsibilities and scope of duties within the brokerage

company.

3. Transaction and invoice management utility: Maintains records of transactions

performed in support of policy actions including establishing new policies, cancellations,

renewals and changes. It generates invoices using line items that represent individual

transactions and purchase items.

4. Policy certificate management utility: This generates certificates that are official

documents describing a customer’s insurance policies and specific coverage stipulations. The

certificate management utility couples with endorsement functionality and has the capability to

transmit certificates and endorsements directly to interested businesses to whom the broker’s

customer is providing services (i.e. a construction company purchases an insurance policy from

the insurance broker. The insurance broker transmits the certificate and endorsement to the

construction company’s customer.) The proper implementation of this feature is entirely

unexplored by the marketplace, especially when concerning non-boilerplate policies and

endorsements. This feature will bridge this gap and mary common concepts for the end users,
 7

allowing them to automate tasks such as updating related certificates/endorsements in mass,

issue/reissue/renew policies, as well as notify clients and named insureds.

5. Secure database: The data described in the previous four paragraphs will be stored in a

secure object relationship model (ORM)-type database. Ideally, this database will be local in

implementation to achieve the status of minimum viable product. This provides an additional

layer of security be keeping the database separated from world wide web access. It may be

possible to implement the database on a local network, so long as the network is protected by a

firewall.

6. Web-based front end management system: Insurance brokers will be able to access all of

the software’s utilities through a web-based interface. This will ensure maximum portability of

the software system and give brokerage companies the freedom to update and change their

computing environment without significant concern for “breaking” their insurance management

ecosystem.

Future Project Improvements

1. The minimum viable product will have limited PDF editing functionality. This is

important for publishing certificates. The objective system will provide brokers the ability to

modify PDF files directly in the browser for more efficient job processing.

2. The objective system will implement a database secure enough to allow for a “cloud

based” data access system. This will enable brokers to operate from remote locations or in a

distributed manner. It is critical that this feature be implemented carefully with well-established

security protocols to prevent intrusion from criminals.

 8

Contributor Objectives
The main objective of this project, from the contributor standpoint, is to create a functional

software system from start-to-finish and provide a useable and marketable product as the

end-state.

The ancillary team objective is to gain familiarity (and ideally mastery) of a relevant

technology stack that will enhance hireability and team contributions. Kotlin is an

up-and-coming programming language; and it seems that it is a good language to learn. An

additional benefit of learning Kotlin is that it is very similar to the Scala and Swift programming

languages.

Environmental Scan / Literature Review

There is no shortage of competition within the sphere of customer management software,

even when considering the more niche realm of software catering specifically to insurance

brokerages. Large companies such as Salesforce have share within the marketplace as well as

smaller, more affordable competitors such as Agency Pro. The wide assortment of options also

include cloud based solutions as well as centralized on-premise solutions. This is definitely not a

new type of software, however there is a severe lack in features by all competitors.

The insurance brokerage we are working with has showcased several of the existing

software solutions within this marketplace, as well as the one they are currently subscribed to.

With over forty years of experience in the industry, our volunteer client has gone over several of

the issues with the existing solutions. There has been little thought by the existing tool sets with

structuring data ergonomically. This oversight in software architecture and data design

accomplishes only the minimum requirement of capturing and displaying desired records. There
 9

is a clear lack of understanding of the problem-space the end-users exist. More specifically, there

is a lack of features which allow the transformation of records into automatable tasks. Currently,

insurance brokers must perform manual data transformations in order to renew boilerplate

policies, couple additional coverage and bonds expressed in endorsements, and engage directly

with clients and named insureds. The net result is a proliferation of manual data entry directly

linked to the size of the brokerage. The more successful the brokerage by virtue of having more

clients or large clients, results in an increase in the amount of administration.

In this sense, there is no software on the market that directly competes with our software.

Our design yields minimal administrative costs via the supplementation of a domain oriented

data model and foot-on-the-ground features.

Community and Stakeholders

The target end-use of this software is insurance brokerage companies. Insurance brokers

typically assist customers with finding the right insurance policy for specific needs. This

particular system will be initially tailored toward brokers who provide insurance policy services

to companies (i.e. a business-to-business service). This software should be particularly attractive

to insurance brokerage companies who require the ability to package policies and endorsements

together and automatically distribute them to multiple businesses. Our goal with the project is to

consolidate the features these brokerages need from several softwares into one single product

that can perform all of the functionality they need. These companies will gain the ability to a

multitude of management tools to organize several sections of data such as customer, employee,

transaction, and policy certificates. By having these stored in a local database, they are also
 10

gaining another layer of security which is one of the top priorities for these companies.

Depending on how the company’s infrastructure was created, they stand to lose the current flow

of updating their database. We intend to make this process more automated, thus easier for

performing CRUD (create, read, update, delete) functions, however the company would have to

allocate business hours to train their staff on how to use our software. Also, since we are

intending on implementing database as a local method, these companies will also need to

configure a local firewall to protect their data if it was not necessary beforehand. Lastly, if our

software is not able to perform the functionalities we pose, then the brokerage risks being a

trustworthy business to its target community. This is potentially the most critical loss to the

brokerage because businesses thrive off of their reputation and customer base.

The community that would be affected by our software if used by these brokerage

companies would be the companies requesting policies from the brokers, as well as the

customers that are either already (or in the process of becoming) insured. Having an insurance

policy in place is one of a company’s sources for a considerable amount of profit. While these

policies will cover a significant amount of costs for unforeseen damages or something of similar

magnitude, the amount covered is calculated by statistics and probability of such an event

occurring. If the variables and numbers are well defined, then their policies almost guarantee a

profitable income from instilling an insurance system alone. Not only that, but it gives their

customers a sense of trust as it can be seen as the company actively supporting its community.

By establishing a sense of trust like this, not only does the company have a potential customer

for life, but the also the opportunity for future customers as the power of word-of-mouth

advertising is significantly more effective than billboard or commercial ads. A potential

 11

customer is more likely to choose a particular business if it is recommended by someone they

already know and trust. If our system provides the services these companies need in order to

create a secure bond with their current and future customer base, then they will have a lot of

potential gain in terms of expanding their business, and in turn their margin of profit. As we aim

to have an system set where updating the database is more automated, as well as transactions of

policy requests, these businesses may also garner more reputation if these customers are able to

receive their insurance in a more effective manner than before. On the other hand, similar to the

brokerages, if our software does not perform to the standards we advocated, then these business

are subject to losing numbers in their both their customers and profits as the idea of trust will

become shaky and potentially severed.

Approach/Methodology

The iteration of this product that exists in an MVP is merely a web application. The

architecture must be flexible, robust, and easily express abstract concepts within its protocol. We

have opted to employ the Kotlin programming language as the primary dialect for the

infrastructure. More specifically, we have decided to lean on the JVM architecture for our web

servers. The tooling available in Kotlin allows for a highly object oriented and highly functional

solution to the problem-space. We have also opted to use Apache Maven as both our build tool

and dependency management tool as opposed to Gradle, Ant, etc. We intend to write highly

cohesive code with as little coupling as possible by expressing every concept as an interface and

always inverting control. In particular we are going to utilize Google Guice to manage our

dependency injection layer. We are also going to strive for idempotent functionality with high
 12

immutability. This will allow for reactive architecture to be employed at scale. Although not

intended for the MVP, we are working towards the goal of utilizing protocol buffers instead of

traditional RESTFul API solutions with JSON payloads. This protocol layer will become more

relevant when desktop and mobile iterations of the application are required.

Inversion of control also grants us high testability of isolated feature sets. This allows for

true unit testing of every unit in the application. In theory, unit tests become integration tests

only when concepts are two tightly coupled with one-another. As a design decision, we intend on

avoiding this, and such blunders can and will be avoided by requiring pure unit tests for all

functionality. All coupling will be mocked using PowerMock/EasyMock and JUnit will be used

as our primary unit testing framework.

The intended client application for the MVP is user experience within a web browser. We

intend to implement MVP/MVVM design patterns. We have opted to leverage Glassfish Jersey

as an implementation of the JAX-RS specification. HTML templating will also be utilized in

order to increase front end code reusability and minimize bloat and technical debt proliferation.

Standard frontend libraries such as JQuery, Bootstrap, and Fontawesome will also be leveraged

to minimize the amount of time the development team focuses on front end polish, and maximize

the focus on feature development.

Ethical Considerations
There are several ethical considerations for this project. The most obvious considerations

are related to user data. End users are going to to accumulate data for their clients, companies,

subsidiaries, and other named insured, as well as data for various insurance agencies. Any data

breaches could have huge ramifications for clients. Any breach could cause end users to lose
 13

their clients and sully their reputations. There is also ethical concern in providing reliable, atomic

services that ensure that transactions are handled properly, and more importantly, error handling

properly notifies the end users that errors occurred. If users were to rely on the success of a

transaction and had improper or unclear error handling, they may falsely assume they have

achieved a successful state which could result in data loss, or miscommunication with clientele.

Insurance at its core is a consensual business transaction where many companies pool

resources in the event of one of the participants to leverage in the event of a major loss. While

there are ethical concerns, especially towards underprivileged groups, concerning insurance

claims adjustment, these ethical concerns exist in a domain external to the problem-space of this

project. With that in mind, and the definition of insurance provided above, it can be concluded

that insurance brokers exist in a realm where they are incapable of doing harm and can only

perform ethical actions, especially with regards to underprivileged groups. Privileged groups

who have the resources to survive in the event of a loss do not require insurance unless required

by law (such as auto, workers compensation, etc.) It is specifically underprivileged groups who

have the most to gain by participating in insurance. Tools such as the one this project aims to

create, will make insurance easier and faster to broker and administer thereby lowering rates and

making insurance easier for underprivileged groups to participate.

There is concern with environmental impact directly correlating to the potential of

infinite growth of this software. There is a one-to-one relationship between the growth of clients

using this software and the data usage of the backend. More users also means greater app-engine

instance counts, etc. This increases in cloud computing and storage equate to a larger carbon

footprint this project is directly responsible for. This is a long term concern only, however. In the
 14

short term, there are dangers with providing support and security for early adoption. There is no

concern for social justice within this problem-space.

In order to mitigate and eliminate these ethical concerns there must be a strong focus on

security. This may result in having user data stored on premise and providing remote support to

end-users. Most issues can be mitigated by having 100% branch coverage in our testing. It is also

important to design and utilize atomic transactions, immutable data objects, and idempotent

architecture. These design principles will cover the majority of issues such as failure cases,

brittle design, etc. With regards to environmental concerns, the only method we can currently use

to mitigate the environmental footprint of the software is to utilize optimized algorithms, small

domain value objects, custom datastores, and protocol buffers. This will mitigate the carbon

footprint as much as physically possible with today’s computing technology.

Since the goal of our product will be to provide insurance broker companies with tools

they need to issue policies to their customer base, we must ensure that we take precautions to

ensure that we abide by CSUMB’s Policy on Human Subjects in Research. Although we may not

be interacting with real customers directly, in order to provide the services we outlined

previously, we will need to be able to integrate a broker’s database into our software.

Consequently, this means that we will need access to private information the broker needs in

order to give the desired insurance to their clients. Since we will be using mock data during the

development of our product, we need to take the time to ensure that our processes are secure

before attempting to use any real information as data leakage can result in dire consequences to

our product, the broker, and most importantly the customer.

 15

Legal Considerations

1) The team is currently using development tools with student licenses. If we decide to

monetize this project in the future, we need to ensure we are complying with all applicable

terms of use agreements. It is fairly typical for student-licensed software to include stipulations

preventing the commercialization of projects created and curated using the software under such

a license. We would likely need to update our license agreements and pay a commercial

licensing fee if we choose to continue using the software.

2) Using external libraries for various functions in the codebase, the team must be mindful

of each library’s usage terms. We must understand each libraries specific terms of use,

copyright, trademark, etc. stipulations. Basically, we need to respect the intellectual property

rights of the libraries’ authors.

3) It is essential that we use dummy and/or de-identified data in the test environment to

avoid harmful leakage of personally identifying information. Failing to do this would make us

vulnerable to liability in the event of a data breach. This is more likely in a test environment

where the software has not yet been proven to be secure.

4) If we make the decision to bring the product to market, we must establish a limited

liability corporation (LLC) or incorporate the business in order to avoid personal liability

associated with sole proprietorship or partnership businesses.

5) The future LLC or corporation would be obligated to purchase some sort of errors and

omissions insurance in order to accommodate end users in the event of breaches in trust.
 16

Project Scope
Timeline / Budget
The project will be completed within eight weeks. We have opted to divide the eight weeks into

four two-week sprints. Each sprint will coincide with major milestones (listed below). In order to

keep on task, a project scrum board will be leveraged. The team will also partake in weekly

scrum meetings and daily standups.

In order to maintain a low budget, the application will be hosted on a developer owned server for

now. The ultimate goal is to have hosting through GAE, Azure, or AWS. We are also avoiding

the use of Accord insurance forms in order to dodge licensing fees. These are the standardized

forms that clientele will desire, however we will provide custom forms for the scope of this

project.

Resources Needed
There are many resources that are going to be required for this project. This project requires a

hosted code repository to serve as the team’s canonical code repository. The team will also

require student copies of IntelliJ IDEA Ultimate with several free plugins. Each team member

will need access to a computer and the internet, as well as access to the Maven Central

Repository. The project itself has many dependencies on open source libraries and frameworks,

all of which are free and open source (more details in the appendix). Primarily, the project

requires a physical server to host the web application. Alternatively, if the budget expands, the

application can be hosted on one of the above mentioned cloud hosting platforms.
 17

Milestones
The project, as noted above, will be divided into four two-week sprints. Below is an expression

of the expected high level accomplishments during each sprint assuming we don’t encounter

notable slippage.

Sprint 1 (8/25 - 9/7): Backend Interface Completed

The goal of this sprint is to have a well defined, flexible, non-brittle api surface

implemented. This will allow front end development to work quickly. No interfaces should

change beyond this point, although implementation may change throughout the project.

Sprint 2 (9/8 - 9/21): UX/GX Completion

The goal of this sprint is to have the UX/GX layer of the application completed. This

does not include market-ready stylings, however it does include a user-friendly experience, and

front end solutions to all the api entry points.

Sprint 3 (9/22 - 10/5): Finalized Sewing of Seams

The goal of this sprint is to finalize all the seams between domain level concepts thereby

fully realizing and implementing the complete proof of concept feature set.

Sprint 4 (10/6 - 10/19): Fully Working Prototype

This sprint is intended to be used to polish the existing features, implement bug fixes, and

catalog features for the future.

 18

Risks and Dependencies

There are many risks for this project. Due to the tech stack being used, there is a very real

possibility that there will be slippage in the sprints as team members familiarize themselves with

the technologies being used. There are also potential security risks with the database solutions

we choose that could risk slippage. All risks for this project happen to exist in the domain of

known unknowns, and with this in mind the tasks can factor in risk to the level of effort

assignment. There are no real external dependencies on this project which greatly reduces the

amount of possible risk to endure.

Final Deliverables

The final deliverables for this project include a minimal but durable feature included in a

working Web Application. This includes the ability for users to store and access information

related to clients, insurance agencies, policies, endorsements, certificates, and invoicing. In

addition to the more standard CRUD-like features centered around data, users will be able to

print, email, update, and link domain level objects with one-another on the fly. This will also

allow for insurance policy renewals to be completely automated, as well as automating the

process of notifying named insureds, agencies, and policyholders about updates and changes.

Usability Testing / Evaluation

Methodology
There are two volunteer participants for the usability session. The volunteer participants are

anticipated to be the first customers of the product and work as insurance brokers. As such, they

are armed with years of experience as users of comparable software and are the ideal candidates
 19

for usability testing. Usability test sessions will be achieved over remote screen share sessions

using team viewer and/or google hangouts. Usability metrics will be collected and used to

increase the usability rating of the product.

Participants
The participants' responsibilities will be to attempt to complete a set of representative task

scenarios presented to them in as efficient and timely a manner as possible, and to provide

feedback regarding the usability and acceptability of the user interface. The participants will be

directed to provide honest opinions regarding the usability of the application, and to participate

in post-session subjective questionnaires and debriefing.

Procedure
Participants will take part in the usability test via remote screen-sharing technology. The

participant will be seated at their workstation in their work environment. Verbal communication

will be supported via telephone.

The facilitator will brief the participant and instruct that he or she is evaluating the Web site/Web

application, rather than the facilitator evaluating the participant. Participants will complete a

pretest demographic and background information questionnaire. Sessions will begin when all

participant questions are answered by the facilitator. The facilitator will inform the participant

that time-on-task will be measured and that exploratory behavior outside the task flow should not

occur until after task completion.

 20

The facilitator will instruct the participant to read aloud the task description from the printed

copy and begin the task. Time-on-task measure will begin. The facilitator will encourage the

participants to ‘think aloud’ and that a verbal record will exist of the task-system interaction. The

facilitator will observe and enter user behavior and comments, and system interaction in a data

logging application.

After each task, the participant will complete the post-task questionnaire and elaborate on the

task session. After all tasks have been attempted, the participant will complete a post-test

satisfaction questionnaire.

Metrics
Usability metrics refers to user performance measured against specific performance goals

necessary to satisfy usability requirements. Scenario completion success rates, adherence to

dialog scripts, error rates, and subjective evaluations will be used. Time-to-completion of

scenarios will also be collected.

Scenario Completion

Each scenario will require, or request, that the participant obtains or inputs specific data that

would be used in course of a typical task. The scenario is completed when the participant

indicates the scenario's goal has been obtained (whether successfully or unsuccessfully) or the

participant requests and receives sufficient guidance as to warrant scoring the scenario as a

critical error.
 21

Critical Errors

Critical errors are deviations at completion from the targets of the scenario. Obtaining or

otherwise reporting of the wrong data value due to participant workflow is a critical error.

Participants may or may not be aware that the task goal is incorrect or incomplete.

Independent completion of the scenario is a universal goal; help obtained from the other usability

test roles is cause to score the scenario a critical error. Critical errors can also be assigned when

the participant initiates (or attempts to initiate) an action that will result in the goal state

becoming unobtainable. In general, critical errors are unresolved errors during the process of

completing the task or errors that produce an incorrect outcome.

Non-critical Errors

Non-critical errors are errors that are recovered from by the participant or, if not detected, do not

result in processing problems or unexpected results. Although non-critical errors can be

undetected by the participant, when they are detected they are generally frustrating to the

participant.

These errors may be procedural, in which the participant does not complete a scenario in the

most optimal means (e.g., excessive steps and keystrokes). These errors may also be errors of

confusion (ex., initially selecting the wrong function, using a user-interface control incorrectly

such as attempting to edit an uneditable field).

 22

Noncritical errors can always be recovered from during the process of completing the scenario.

Exploratory behavior, such as opening the wrong menu while searching for a function, [will, will

not (edit Procedure)] be coded as a non-critical error.

Subjective Evaluations

Subjective evaluations regarding ease of use and satisfaction will be collected via questionnaires,

and during debriefing at the conclusion of the session. The questionnaires will utilize free-form

responses and rating scales.

Team Members

Trammel May
● Technology stack integration
● Feature development
● Customer/ target audience coordinator
● Architecture Engineering
● Documentation
Gene Evans
● Feature development
● UX/GX Design
● Documentation
● Scrum Master
Kyle Luoma
● Model design
● Database / server setup & administration
● Feature development
● Documentation
● Security Solutions Engineer
 23

References

Appendix
Project Languages
Kotlin
Jade/Pug
Javascript
CSS/SASS

SCM
Git

Build / Dependency Management

Maven

Project Dependencies
Jersey Common
Jersey MVC
Jersey MVC Mustache
Jersey Media JSON Jackson
Jersey to Guice Implementation
Jersey Container Servlet Core
Jersey Servlet API
Jade for Java
Guice Servlet
WebJars Servlet
Lightbend Config

Test Dependencies
JUnit
Hamkrest
Kotlin Test JUnit
Powermock Module JUnit4
Powermock API Easymock
EasyMock