Versions Compared

Old Version 1

changes.mady.by.user Sean Bohan

Saved on

compared with

New Version Current

changes.mady.by.user Nathan Southern

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

...

Thursday, September 8th at  9am PT/12pm ET


Join Zoom Meeting

https://zoom.us/j/

...

7904999331

Meeting ID:

...

790 499 9331


Attendees:

  • Sean Bohan (openIDL)

  • Ken Sayers (TSC Chair, AAIS)
  • Peter Antley (AAIS)
  • Jeff Braswell
  • James Madison
  • Allen Thompson

TSC Voting Members Attendance:

  •   Ken Sayers (AAIS)
  •  Allen Thompson (Hanover)
  •  James Madison (Hartford)
  •  David Reale (Travelers)

Meeting Agenda:

  1. Call to Order (KenS)
  2. Anti-Trust, Review of TSC Meeting format and Participation by TSC Chair
  3. TSC Activity Desk (TSC - Activity Tracking)
    1. Architecture Working Group (KenS)
    2. RRDMWG Update (PeterA)
    3. NAIC Update (JeffB)
    4. AAIS Stat Reporting using openIDL internal Project (PeterA)
    5. ND Uninsured Motorist POC (KenS)
  4. AWG Next Steps (Team Discussion)
    1. Identify work threads and identify leaders for each
    2. Does everyone need to be in every meeting or task forces that do work and bring it back
    3. Satish process: enterprise arch framework (rather than app or system)
    4. Considerations - priority and footnotes, addition to ETL topic
    5. List of features and deliverables for each
    6. Nature of interface and nature of request/call, how specified, how responded to, pre-extraction, how described, how adapter (APIs) play, how apis interface with node - needs closer look
    7. Arch possible approach 
      1. Mon-Tues reconciliation, following monday opportunity to define functional breakdown, decide how we attack functions
      2. not too many big areas, looking at orchestration, what threads in what detail, also works because some at HGF next week, following week good time to regroup
      3. week from Mon strive to do functional breakdown, streams then deliverables then volunteers
      4. 2-3 max, break down to manageable
      5. want to get somewhere, define where that is, all und there is something between us and destination
      6. medium term - how take stuff being done now with ND POC, how merge-fit with general threads, plan transition, more info on whats going on there, how does it inform things in the gen arch - using Mongo, not necessarioy a choice for HDS, does everyone need to use the same DB, types of questions
      7. good to get to the point trying and doing to get to deliverables to make it work (writing code)
      8. inc topic of sanity checks, etc.
      9. hints there is pre-work, make sure all und what we wrote down, review of Scenarios and Requirements, refine, administrative aspect of what we did, getting consensus 
      10. after define threads to work on, first thing to org those brainstorming ideas into subsets
      11. useful and productive to have something to try things out on, prototyping, capability where diff parties in community have a platform to participate, rationale for openIDL to have a community testnet avail, doesn't impact ND, can be used by group, stood up, torn down, evaluate
      12. ref arch applies to some threads, some can be just design
      13. plan for Mon 9/19 Arch WG to start identifying workable threads and define how to move forward
  5. AOB
    1. ? for AT, JM, BH - as we begin to define things, are there other resources you would want to involve, might be interested, could help with arch prototyping, code, arch, good to have folks together who could contribute resources
      1. biggest fear, who is staffing?
      2. tricky escalation path, who is going to develop this, if staffed by carriers, as opposed to hiring Infra Partner...
      3. strategy - use funding to have Infra Partners to work at our direction, like to encourage participation
      4. customer sign off not the same as being more involved
      5. makes sure it works for carriers
      6. accrediting Infra Partners, reviewing, understanding
      7. what are we asking technical staff of carriers to do - want to be able to RUN the thing, agree to put folks on shared infra at AAIS, would lIKE to get to poiint where build in their lab for development, inside sandbox
      8. working internally at AAIS, intend to open source stuff, large audit of deployment documentation, get dep docs in good shape, easy to stand up nodes
      9. critical - building the ability for teams not the orig coders to test it - using Cloud Formation scripts, have prod in service catalog, build ref implement from scratch, engineer core product AND scaffolding to get up to speed, can test thoroughly
      10. Infra as code cleanup intends, try it out, lot of carrier side on data loading/ETL, but network side should be way folks can contribute, out of process a way for carriers to do for their benefit
      11. Learned a lot from carriers, kicked off Arch WG, policies and choices not 100% across carriers (deep tech stack), more than just getting it working 
      12. cloud environment - config and deploy - diff environments have diff methods, org arch discussion into zones of whats on Carrier vs participant, 
      13. tenets there: what must run inside carrier, whats ok not inside carrier - will guide us into how we establish
    2. flexibility around tech stack - weird place, how do you run if you don't know
      1. found cant be prescriptive on some things (carriers all have diff) - or trim tech stack to where CAN be prescriptive
      2. has to be variable tech stack or trimmed down to agreement
      3. sandwich between var of AWS vs types of things fabric itself - we want consistency for how things work with network
      4. given discussion, we have to right-size the effort, having mult ways to do same thing, expensive and complex
      5. Effectively a vendo (openIDL) - deal with it all the time, fundamentally standard headache, have to support mult stacks or smaller one, can't sidestep it
      6. describe: x doesnt have to be in your cloud, could be "the network", things not running inside a carrier's world, network stuff, no security, we limit the stack running
      7. what remains in boundaries of carrier has to be prescribed, standards
      8. how engineering thing, resourcing, pay someone (infra partner, do a whole lot) carriers will have to do testing and signoff
      9. we have to design, have architects who make decisions ahead of when we engage and some based on feedback from Infra Partners, we need to have an Arch footprint to help define arch, diff between design and implementatiuon
      10. Gen list of things, keep design in context with tools to implement
    3. Reconciliation for Mon-Tues (9/12 - 9/13) Arch WG
      1. all about making sure numbers going to NAIC match numb going thru stat reporting
      2. requires data that doesn't necc come from HDS, may be data elsewhere, maybe a carrier loads 2 tables, 
      3. why we need to talk it thru, expansion of scope of what would be provided?
      4. probs with reconciliation is headache at the top, put back to sourcing
      5. ent data - systems of record with contracts, other systems report, diff worlds
      6. submit data, pull back data Or put both in HDS then do EP that doesn't interface w/ 3rd party data
      7. spirited conversation
    4. Inviting Regulators to Arch WG next week (tbd)


FOLLOW UP:

  •  

Recording/Meeting Minutes

...