Public Page

2021-02-9 Architecture Meeting Minutes

Public Page

 

      
   CIECA 500 Westover Dr  #11617; Sanford,  NC  27330 

 

Date

Feb 9, 2021

ANTITRUST STATEMENT

As participants in this meeting, we need to be mindful of the constraints of antitrust laws. There shall be no discussions of agreements or concerted actions that may restrain competition. This prohibition includes the exchange of information concerning individual prices, rates, coverages, market practices, claims settlement practices, or any other competitive aspect of an individual company’s operation. Each participant is obligated to speak up immediately for the purpose of preventing any discussion falling outside these bounds.

Agenda

  • Antitrust and Meeting minutes acceptance

  • Discuss Swagger Meeting

  • Continue to work on the CAPIS.

    • FNOL Use Case

  • Standardize Percentage definitions question (Becky)

Meeting Minutes

  • Antitrust Accepted

  • Meeting Minutes approved

  • Swagger

    • We have been researching the Swagger documentation to determine if CIECA would need a Team or an Enterprise License. This would be who can access and who needs to make changes.

    • Questions on how our members would get to the information.

    • Best recommendations on how to use with GitHub development

    • How do we want to continue to show our members the standards

      • Today we use Box, however, that is something that we see moving away from with the new direction of cieca.com.

    • Everyone in the meeting would like to be in the meeting with Swagger.

      • It was recommended to set the meeting in the same time frame as the meeting we already have.

  • CAPIS

    • The team was shown the new confluence page for Product Information that the CIECA staff is working on moving our services to. This concept will help people navigate through our services and find information.

    • The FNOL Page was created with the history documentation that Charley had created. It has information from the BMS, Appendix C and Implementation Guides, and even the Test instances.

      • The diagram is the same as Charley’s diagram, just in the new drawio format instead of Visio.

    • The XML FNOL add service page was reviewed quickly to show how each of the services could be its own page.

    • Post FNOL to be created in this committee to use for CAPIS project.

      • We named the page Post FNOL

    • Discussion about how to move forward and some possible guidelines

      • We need to stay consistent with the Open API Verbs, POST, Get, DELETE, and PUT. (Swagger documentation example was reviewed on how this looks in Swagger). https://petstore.swagger.io/

        • Andy showed some other tools that can be used to write YAMAL

          • Stoplight Studio tool https://stoplight.io/studio

          • Insomnia Designer https://insomnia.rest/download/

      • We reviewed the Schemas for FNOL and the test instances

        • We have several Trojan Horses in FNOL, these aggregates are huge and repeating values.

          • Claim Info

          • Admin Info

        • We just need an Address, we really don’t need Admin Info, so how will we break these large aggregates down?

          • If we can reuse names, that exist in the XML and the EMS, we should reuse the name to have a common naming process.

        • A number of our large aggregates, such as Admin Info, is optional

          • Can we create micro aggregates and do we need to start from the ground up?

      • A possible Guiding Principal would be when do we need to expand a message or create a new one?

        • Today we have messages that can be for Property, Vehicle or Glass. Would we need to split?

          • It is recommended that anytime there is a decision that we split, because the decisions is what made it hard to implement the JSON messages created from XML.

      • We need a naming convention to help keep the services easy to find.

        • Example Post Assignment Rental and Post Assignment Glass

      • We looked at the Richardson Maturity Model

        • Our messages was a request and response and we added the name Add, Cancel and Change to our XML services names.

        • The open API will use POST, PUT, GET, DELETE.

          • Verbs have different sizes, the PUT is normally the largest because it is creating an object, where the GET is small because it sends information to retrieve an object or list of objects.

      • We need to break down Admin Info and get the data types and aggregates that we need for FNOL in the next meeting.

Have a great week everyone!

Up Next

  • Antitrust and Meeting minutes acceptance

  • Continue to work on the CAPIS.

    • FNOL Use Case

      • Look at ADMIN INFO and break it into the Data Types and Aggregates that we need.

    • Do we want to add a new section to the Architecture Guidelines for CAPIS guidelines or should we have a separate document?

  • Standardize Percentage definitions question (Becky)

Action Items

Decisions

 

 

Participants

  • @Paulette Reed

  • Paul Barry

  • Jeff Schroeder

  • Dan Webster

  • Andy Bober

  • Mike Hastings

  • Cindy Chapman

  • Aaron Daniele

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. https://cieca.atlassian.net/wiki/spaces/ARCH