AAIS Stat Reporting using openIDL internal Project (PeterA)
ND Uninsured Motorist POC (KenS)
AWG Next Steps (Team Discussion)
Identify work threads and identify leaders for each
Does everyone need to be in every meeting or task forces that do work and bring it back
Satish process: enterprise arch framework (rather than app or system)
Considerations - priority and footnotes, addition to ETL topic
List of features and deliverables for each
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
Arch possible approach
Mon-Tues reconciliation, following monday opportunity to define functional breakdown, decide how we attack functions
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
week from Mon strive to do functional breakdown, streams then deliverables then volunteers
2-3 max, break down to manageable
want to get somewhere, define where that is, all und there is something between us and destination
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
good to get to the point trying and doing to get to deliverables to make it work (writing code)
inc topic of sanity checks, etc.
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
after define threads to work on, first thing to org those brainstorming ideas into subsets
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
ref arch applies to some threads, some can be just design
plan for Mon 9/19 Arch WG to start identifying workable threads and define how to move forward
AOB
? 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
biggest fear, who is staffing?
tricky escalation path, who is going to develop this, if staffed by carriers, as opposed to hiring Infra Partner...
strategy - use funding to have Infra Partners to work at our direction, like to encourage participation
customer sign off not the same as being more involved
makes sure it works for carriers
accrediting Infra Partners, reviewing, understanding
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
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
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
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
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
cloud environment - config and deploy - diff environments have diff methods, org arch discussion into zones of whats on Carrier vs participant,
tenets there: what must run inside carrier, whats ok not inside carrier - will guide us into how we establish
flexibility around tech stack - weird place, how do you run if you don't know
found cant be prescriptive on some things (carriers all have diff) - or trim tech stack to where CAN be prescriptive
has to be variable tech stack or trimmed down to agreement
sandwich between var of AWS vs types of things fabric itself - we want consistency for how things work with network
given discussion, we have to right-size the effort, having mult ways to do same thing, expensive and complex
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
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
what remains in boundaries of carrier has to be prescribed, standards
how engineering thing, resourcing, pay someone (infra partner, do a whole lot) carriers will have to do testing and signoff
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
Gen list of things, keep design in context with tools to implement
Reconciliation for Mon-Tues (9/12 - 9/13) Arch WG
all about making sure numbers going to NAIC match numb going thru stat reporting
requires data that doesn't necc come from HDS, may be data elsewhere, maybe a carrier loads 2 tables,
why we need to talk it thru, expansion of scope of what would be provided?
probs with reconciliation is headache at the top, put back to sourcing
ent data - systems of record with contracts, other systems report, diff worlds
submit data, pull back data Or put both in HDS then do EP that doesn't interface w/ 3rd party data