Demoing table with multiple filters on OLGA at net AWG
Cognito doesn't pass spec with Hartford, would like to find auth service everyone likes
AWG Goals
Consider setting goals, open questions, using Architecture Decisions to guide it
Couple tech components are challenging for diff carriers (Hanover + AWS, Hartford + Cognito)
Goal of this team - define arch of the 1.0, does or doesn't take into account these concerns
Carriers concerned about whats going in and out of their clouds
whats inside, what has to go out, what ports, what do we need to know about ingress and egress points
high level doc/diagram to represent it
need a doc that clearly answers question
One of the more challenging areas to deploy, "Whole Enchilada", installing whole node into carrier cloud - lot of CI/CD and IOC involved
while maybe same tools, maybe using open source vers and carriers use enterprise vers, config is an issue
seems like there is concern on IAC and CICD tech
supporting inside a carrier
Configuration options/ deployment options
whole enchilada vs split
adapter that listens for request for EP and then returns results
System as a service approach, everything hosted
multi-tenant approach
Step back and redefine some things our arch is founded on
get diagrams AND OPTion analysis
best place to start, goal of arch doc telling what ingress/egress are, ID tech causing issues, CI/CD, config options
goals this team could establish and work towards, sense of moving forward and it is time to establish to guide us in our work
too much reporting out and not enough moving forward
What do we think about setting goals, are these good goals?
Point about access is the right thing - multi level/multi layer
Cognito vs Olga - a lot of cognito is for AWS space to get access - would OLGA be managed interface for data
OLGA as alt to cognito?
Validation in OLGA is validating data coming in
Cognito logs into OLGA
Cognito also for logging into AWS? No that's IAM (services in console), Cognito for app access, services underneath
Cognito gets you user access to certain roles, give you access to specific resources
On OLGA, going into this, season of building, idea - pretty much cloud agnostic app from user perspective, have button and modal to upload file, no dirext access to AAIS
GUI to send files, anything that requires access - app auth
intent of looking at OLGA as app to provide access, seems like carrier orgs would have other reasons for access to their AWS spaces
Way we will set up Cognito, no auth to do random things for AWS
Carriers use other tools than Cognito, not done that they wont allow Cognito at Hartford, but they dont want to, point there - ID tech causing issues, if 20 of them, then that tells you one thing, 4-5 is something else
Extra effort to make them abstract, openAPI (like OAuth)
OAuth recognized enterprise standards (instead of 20 diff things across carriers)
Broader Objective - und diff types of access to services and roles in the scope of what we are doing
AWS access: Kub, Fabric, etc.
often with access to DB apps, diff people have logins and inside the db there are logins, one of the issues to explore - where creds are verified and where others are group creds
Take the 4 configs on the bottom (SaaS, Multi-Tenant, Split, Whole Enchilada) what is in vs out for the carriers cloud?
because there is a lot of security, sec teams need to be able to und what is coming in and out
Picturing 4 diagrams with some lines that go in and out of the carrier cloud, documenting whats going across
Travelers documented pain points
retro of some kind on nodebuilder
list of places where things are difficult
place to get the first level of identifying technologies that cause issues
if things like AWS or Cognito cause trouble, this needs to be a pure SaaS offering
simple or it doesn't work
feels like a more general statement
get it defined and why it is like that
"install in your cloud" - not that easy
thinks we still have a lot of challenges there, try to bring into a cohesive statement
"this is why SaaS makes so much sense"
new wrinkle - not old tech, will have bifurcations of Azure vs AWS, OKTA vs ?, so many it will have to be, no stack amenable to more than a few people at any given time
gotta be packaged, how to articulate it
all have issues
even if biz folks on board, still having an internal challenge going to arch org to get an exception
so much easier to say "here is a SaaS platform"
Goal of ent control of their own data, objective
want a variety of diff ways of connecting to a network like system so there is choice (not all or nothing)
aggregate makes sense, but any given carrier that optionality isn't a value, only want to do it one way (their way)
in theory - over indexing how valuable
get to point where all see where risks and probs are
first and last bullet - optional footprints, level of ID where ins and outs are
meat on these bones, have opinions but need to substantiate them
if you are going to be a SaaS offering, who offers it?
if standard was established, not single SaaS, implementation diff from deciding how it would happen
model has been to have a senofi, chainyard, be avail
AAIS and LF dont run infra, build, setup and maintain nodes on behalf of carriers
depends which parts of value prop want to maintain
standardize SaaS or set of standards?
how much of original value prop you want to maintain
Pictured the split - a hybrid - everything you dont want in your cloud is SaaS, rest in carrier node (adapter)
"why do i trust another entity any more than AAIS, what did I just solve?"
AAIS needs to find another model, feeling comfortable with raw data, where trust moves
very few times run their own cloud environments for corp data outside of workloads
most of the time, when time to productionalize, will be in carrier-owned pub cloud or pure saas offering
referring to carrier-owned cloud where IP are helping to maintain, providers with skillsets to make it easier
even though a carrier might use IP, having them work within their cloud infra need to go thru tech governance, security and setup
if you dont you are letting them live in their environment
doesnt save much to outsource the work b/c still needs to support in their cloud
diff ways to access diff services
our specific issue for T, looking at it from an Arch perspective, have concerns
dont think in the long run they wil be the only ones, more we get ahead and think through, easier to talk to other carriers
gonna run into similar issues with other Carriers
make it cleaner, dont go with a laundry list, "how to I set this up?" they want a clean answer, SaaS is cleaner
need a yardstick, how are we doing convincing a carrier -
Time
Item
Who
Notes
Documentation:
Notes: (Notes taken live in Requirements document)