Describe BriteCore's techical architecture.
BriteCore is a highly robust SaaS product. We offer a perpetual software license that provides
ongoing access to BriteCore as a web service. The backend of our software is written in Python 2.7
Describe BriteCore's development process.
IWS strives to keep BriteCore above the industry standard so that our system remains current
and flexible. For that reason, we make improvements to BriteCore's code base on a regular basis.
We've successfully implemented an agile release process that allows our engineers to effectively
manage code changes through a continuous release process.
Below is an outline of BriteCore’s current development cycle. It's consisted of ten core
phases we’ve put in place to help manage the daily release of BriteCore code contributions.
- Initiation: A change is initiated either by an existing / implementing client
or internally at IWS. A need is identified and submitted through BriteIdeas or Trac. All change requests are
eventually entered into Trac as a control activity. This ensures that communications are
logged, procedures are followed, and the change is properly introduced into our live environments.
- Requirement Gathering: Sometimes performed as a part of Initiation, this is the phase
in which we reseach and identify the business requirements and success conditions of a change. This ensures
changes introduced to the system meet their intended purposes.
- Concept Development: This phase involves gathering the technical requirements of the
change and creating the overall concept of the development required. This phase is often a part of
Requirement Gathering but can be a standalone effort on very large changes. In this phase, ideas
are generated and solutions are proposed. This phase can be lengthy and often requires company-client communication via Trac,
client forums, and BriteIdeas and sometimes requires the generation of a comprehensive GAP Analysis and SRS (Software Requirement Specification).
- Design: Design is the phase in which the software change begins to take shape.
During this step, mockups are created as-needed and the UX/UI proposals are made. A qualified developer
begins creating the actual HTML/CSS required for the change request. These files will be
then integrated into the code branch as part of the overall change.
- Development: This is where the change is actually created. Our development process
can be visualized as another cycle entirely that encompasses the “Development”, “Sentinel”, and “Testing”
phases of the overall SDLC.
- Sentinel: A Sentinel is an SE-II level engineer (or higher) who looks over every single
code change that goes into BriteCore. This is a rotating position, and Sentinels are always a different engineer
from the one who did the programming on a change. In the event of a multi-programmer change, sentineling will be
performed by an engineer who was not involved in developing the code changes of the pull request.
The Sentinel will paste the “Sentinel Checklist” into a comment on the Github pull request and make sure that
all items are in a passing state before signing off on the change. If the pull request is updated after Sentinel approval, explicit approval is required again in order to merge
- Testing: In this phase automated and manual tests are run to ensure the quality of the
overall change as well as to prevent regressions. IWS is very proud of its low defect rate and we attribute
this low rate to our SDLC and our testing procedures. Changes to BriteCore require either new or modified test cases that fully (or at least as fully as
reasonably possible) test the change using repeatable, deterministic tests.Manual testing is encouraged by engineers and is required for most changes by Client Services.
- UX/UI Review: After the testing is complete, the proposed change is given a final
UX/UI review to ensure that nothing was lost during the design phase in terms of the overall beauty or
usability of the change. At this stage of the process, it would not be unusual for an engineer to receive
requests for small changes or tweaks. These changes are often for consistency, usability, and the overall
feel of the product.
- Documentation: During this phase, documentation is created and release notes are generated.
These pieces are then added to the BriteCore Wiki for posterity and ease of access by our clients.
The release notes are then sent out to all clients.
- Release: If no reason exists to reject or delay the change, the pull request is merged
and the change is then queued for the automated nightly release. The next morning the new features, fixes, or
updates are available to the clients to utilize or enable.
Describe your current operating system.
BriteCore currently runs on Ubuntu LTS (Long Term Support) release 14.04.
Describe the supported database environment.
BriteCore uses Oracle MySQL 5.5 on Amazon RDS.
What open source products or vendors are included in your offerings?
NGINX: 2 Clause BSD License, Gunicorn: MIT License, Python: PSF (GPL-compatible) License,
Oracle MySQL: Licensed to Amazon for use in AWS, Supervisord: BSD-derived, Twitter Bootstrap: BSD License,
KnockoutJS: MIT License, jQuery: MIT License are all included in our offerings
List the technology used to host your system and the advantages of using that technology.
BriteCore is a web-based solution built on the Amazon Web Services Cloud and is the cloud technology leader in
insurance software. We partner with Amazon Web Services to provide clients with a hosting package that is tailored
to the specific and unique scalability and durability requirements of their company. AWS applications are deployed
across multiple availability zones and are extremely durable. We currently use CloudFormation to build EC2 server
clusters with Auto Scaling and Elastic Load Balancing. Data is stored in RDS, while files reside in EBS volumes and
S3 buckets with long term storage in Glacier.
All clients run on independent instances that are managed through auto-scale groups. We have invested heavily in
automation scripts to deploy an unlimited number of BriteCore instances quickly through a web interface. One of the
biggest advantages of our model is the ability to provide clients with test sites that are perfect clones of their
live production site with a release applied. Since AWS allows an unlimited number of server clusters, we can launch
as many BriteCore environments as needed so you can explore and validate features with live data before they are
deployed in your site.
- EC2 Auto Scale Instances
- RDS Data Store
- S3 File Storage
- EBS Volumes
- Hourly Backups
- Clone Test Sites
- 99.9% Uptime
- Disaster Recovery Across Multiple Availability Zones
- Elastic Search
- Database Copy Back to Client Site
Provide a list of your system's requirements.
Requirements for running our system are minimal. The admin side of BriteCore can run in any modern standards
compliant browser including: Firefox, Chrome, or Safari. IE10 is trivial to support since Microsoft has been
improving standardization, but we currently lock it out just to prevent a maintenance fork. This includes the
browsers on all modern mobile devices that run Android or iOS.
All public and agent facing screens in BriteCore additionally support IE8 and IE9 as carriers cannot control
which browsers are utilized outside of their own company. Our contractual language is as follows:
- Hardware: Any desktop, tablet, or mobile device with at least 512mb of memory
- Display: Set to a minimum resolution of 1024x768
- Operating System: Mac OS 10.x, Windows XP, Windows Vista, Windows 7, or Windows 8
- Internet Connection: Any broadband Internet connection that, on average, provides bandwidth commensurate
with at least 512 kbps downstream per concurrent user and 256 kbps upstream per concurrent user.
Does the system support mobile technologies (smartphones, tablets, etc.)?
BriteCore currently works on all mobile devices including smartphones and tablets. Users access
the site through a web browser just as they would on a personal computer.
Describe your programming language model.
We utilize a single programming language at each layer of architecture. We program in a sound mix
user interface that’s both attractive and easy to use.
How is the UI of the base system modified/maintained?
Our development team uses Git for our VCS (Version Control System). All modifications and maintenance items are
performed by system engineers in coordination with Client Services personnel.
Can the UI be customized to create a unique experiences for agents?
Yes. Any part of BriteCore can be customized to create a unique experience for your agents, including the UI.
Describe the browsers and associated versions you support
For the administration portion of BriteCore, we currently support the latest versions of Chrome
(Currently 36.0.1985.125), Firefox (Currently 31), and Safari (7.0.5). It is important to note that
BriteCore works with most older versions of these browsers as well. It is possible that much of BriteCore
works with Internet Explorer 10 because of the recent improvements that Microsoft has been making to
their browser in supporting web standards.
You do not have control over what browser an agent will be using and ease of doing business is key to success.
For that reason, we support Internet Explorer 8 and above as well as all Chrome, Safari, and Firefox for BriteQuote,
the Public Payment Gateway, and Agent Inquiry.