BriteCore RFI

Technical Architecture

IWS has acquired the techical expertise and networking skills needed to establish, operate, and maintain an enterprise level IT environment that's both reliable and secure. We develop on a continuous cycle that allows us to meet the ongoing needs of our clients quickly and efficiently.


  1. 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 and the frontend is written in JavaScript, HTML, and CSS.

  2. 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.

    1. 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.
    2. 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.
    3. 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).
    4. 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.
    5. 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.
    6. 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 the change.
    7. 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.
    8. 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.
    9. 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.
    10. 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.

  3. Describe your current operating system.

    BriteCore currently runs on Ubuntu LTS (Long Term Support) release 14.04.

  4. Describe the supported database environment.

    BriteCore uses Oracle MySQL 5.5 on Amazon RDS.

  5. 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

  6. 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.

    Hosting includes:

    • 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

  7. 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
    • Web Browser: Mozilla Firefox 3.x or higher with JavaScript enabled, Google Chrome 24 or higher with JavaScript enabled. Internet Explorer 8 or higher for the BriteCore Agent Portal.
    • 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.
  8. 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.

  9. Describe your programming language model.

    We utilize a single programming language at each layer of architecture. We program in a sound mix of cutting-edge web application languages: Python, HTML, Javascript, and SQL. The result is a responsive user interface that’s both attractive and easy to use.

  10. 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.

  11. 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.

  12. 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.