Public Page

2022-11-08 Architecture Meeting Minutes

Owned by Paulette Reed
Last updated: Nov 15, 2022
4 min read

Public Page

Date: Nov 8, 2022

 

 

 

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

  • Network/Welcome

  • Antitrust

  • Review Meeting Minutes

  • CAPIS Like Proposal feedback

  • Feedback of Restful services

  • Work on moving the rest of BMS Data Dictionary to JSON Schema Data Dictionary

  • Work on Parts and Procurement Services.

Meeting Minutes

  • Antitrust Accepted

  • Meeting minutes reviewed from old version because confluence version was lost

  • CIECA Membership

    • The Board meeting at SEMA was to discuss the access of CIECA Standards with the different membership types and Non members

      • What does a CIECA membership get a company? If you are not a member and never been a member, you have no right to the CIECA Standards. A member company may share a small subset of the data dictionary, for example, to illustrate the benefits of a CIECA membership to a potential customer.

      • A lot of time was spent reviewing the types of members CIECA has today and the rights to the standards that they have.

      • It was agreed that the Data Dictionary would be part of the CIECA Standard.

        • This would allow members to have CIECA Like Services as they do in the BMS and API services in the future. If they build the services using the CIECA Data Dictionary, they are CIECA like. The services are flexible and always has been with the BMS and will continue to be with CAPIS.

          • This would mean that we should convert the BMS Data Dictionary to a CAPIS Jason Schema.

            • This would be to continue with the zero-based budgeting concept and flattening of all BMS aggregates.

        • The constraint is you have to be a member to use the CIECA Data Dictionary and you use the information, and it is perpetual that you can use it forever.

    • The Membership and how to use the CIECA intellectual property is being moved back to the Board and Executive committees, as Architecture does not need to focus on all the details, just needs to know the plan of use so we can build the standards with that in mind.

  • CIECA License in an API

    • Do we need a License for CIECA so when the API ask what license we are using, it can be entered?

      • The License is only needed if it open sourced, CIECA is private source and does not need a license.

      • Instead of a license, the use of the word Private should be able to be used.

  • Feedback on Restful Services

    • The use of ID for claim number, would typically be provided by the client and when you are using a post, the server is going to create the ID. In CIECA post statement today, the server is not creating the ID, so we should be using it in the put.

    • Mike to provide Dan with some examples for Microsoft references to show how to use the post and the put.

    • 201 status is a response that we should probably add.

    • The concept to make it more restful, is sending a message that has multiple objects in int and typically or multiple resources to be restful.

      • An example is to send the claim and then send the party in a restful api.

      • The BMS would contain all 60 objects in a message, but with restful api we would have claim and then party and then the other objects used.

      • It is great to have individual objects available

        • but ultimately you have to have a transaction where you are tying these objects together.

        • we still need feedback from the industry that are doing Api development

      • We reviewed services that are being built today by members of the architecture Committee.

    • Do we have a standard if we allow then to use put claim number api, put party api and put vehicle api and then allow others to put claimsservice api that has all 3 objects?

      • CIECAs focus is more the interchange of data and not the API itself. CIECA provides examples of how to exchange the data with services, but that is not the standard.

    • Standards will be the Data Dictionary,

      • We wanted to find out how folks structure their Jason schemas, how they name their properties, and then when it came down to things that are truly standard or should be, we went looking for things that have already been defined. How do you render a day? How do you render a phone number?

      • data standards is probably more usable and readily accepted.

      • Reusing the data structures and their own web services. It's been happening for years and years and I think I personally think it's a great opportunity to kind of get our arms around that and adopt it, be open to it.

  • Architecture will focus on converting the BMS Data Dictionary to CAPIS Data Dictionary

    • We halted conversations on items before to get the release in on time, now we can resume conversations on things like Arrays.

    • We can review the JIRAS in the next meeting.

Up Next

  • Network/Welcome

  • Antitrust

  • Review Meeting Minutes

Action items

Decisions

 

Participants

  • Paulette Reed

  • Dan Webster

  • Paul Barry

  • Jeff Schroder

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