openIDL Navigation
Page History
...
The use of Infrastructure as Code will make the system’s configuration self documenting. Anywhere this does not fully explain, extra documentation must be provided. This is generally found in the README.md files in git.
The Privacy of the Data Distributed Nodes is Paramount
The data made available to the openIDL system must have privacy managed by the data owner. The owner must control all "access" to the data and be confident that no data is shared with other nodes without their knowledge.
...
| SUBJECT | User Authentication for Application Access |
|---|---|
| STATUS | Open |
DECISION | User Authentication is Platform Specific or can it use Okta |
DISCUSSION | The authentication of users must be cloud specific for access to applications because there is no generic authentication provider. - start with aws strategy - cognito - want to offload identiy to identity provider - can we use okta as the main identity management and link it to the underlying provider thus acting as a common api for the applications? |
DATA ARCHITECTURE
| SUBJECT |
|---|
| Extraction Processing | |
| STATUS | Open |
|---|---|
DECISION |
Mongo DB is deployed inside Kubernetes
TBD | |
DISCUSSION | In openIDL when a data call (or a stat reporting) is "consented to" by the carrier, the data must first be accessed from somewhere and then transformed into the result format and lastly converted into a report that the target party (usually a regulator) can access or be sent. The transformation of the data from its "harmonized" state to the result state is called the "extraction", "extraction pattern" or "extraction process". Since accessing the data can take multiple forms (see other architecture decision "Harmonized Data", there is some variability in this decision while that decision is undecided. We can assume that the data being accessed for the extraction is "harmonized", meaning for every execution of the extraction on a single node or multiple nodes for a single carrier or multiple carrier, the schema and semantics of the data are known and consistent. |
|---|
| SUBJECT | Harmonized Data Access |
|---|---|
| STATUS | Open |
DECISION | ?? |
DISCUSSION | The data available for extraction must be normalized for multiple extractions across multiple use cases across multiple carriers. Is this one single model? Is this one database? Is this data at rest and/or available through an API? |
| SUBJECT | Harmonized Datastore DBMS Implementation |
|---|---|
| STATUS | Open |
DECISION | ?? |
DISCUSSION | If data is at rest in the harmonized datastore, what is the technology? Does it need to be a single dbms? Should it be noSQL? Can it just be an interface? |
| SUBJECT | Harmonized Data Model |
|---|---|
| STATUS | Open |
DECISION | ?? |
DISCUSSION | The data available for extraction must be normalized for multiple extractions across multiple use cases across multiple carriers. The data must be produced by the carrier from their original sources. Is this an ETL process? What is the format of the load data? Is it the schema of a standing HDS database or is it a messaging format? Is there just one "in transit" model or are there different ones for different contexts? Contexts might be the data call, the line of business, etc |
DISCUSSION
The default implementation for MongoDB is a cloud managed service.
In AWS this will be DocumentDB, as long as, it implements the API we need.
In other cloud providers it will be specific to that cloud.
For local deployments it will be inside the kubernetes cluster.
The Terraform to setup the mongo db will be pluggable so it can be replaced with the appropriate platform specific configuration.
Options discussed were:
- self-managed cloud implementation
- cloud-managed Infrastructure as a Service
- mongo db atlas - a mongo provided infrastructure as a service (requires separate account, so it was dismissed)
DocumentDB does NOT support mapreduce which is how we run the extraction patterns.
So we have two options:
- we use true mongodb compatible db that supports mapreduce
- we refactor the extraction pattern functionality to not use mapreduce
So, for the migration project we switch to a mongodb self managed db
For the longer term we'll reimagine the extraction pattern processing. |
APPLICATION DEVELOPMENT
| SUBJECT | Common UI Code Management |
|---|---|
| STATUS | Open |
DECISION | Single Application Angular UI Variations will utilize angular libraries |
DISCUSSION | The library will be a different kind of angular app located in the same super library as all apps that use it. This is the approach for the data-call-ui. (openidl-ui and openidl-carrier-ui) For common / shared libraries we will use an npm registry. |
...
Overview
Content Tools