Edit Note - Life OS

Title *

Domain *

Project

Content

### Action Items

- [ ]  Raghu to work with Grace to initiate the new tenancy creation process
- [ ]  Team to continue current development work in existing compartment while pursuing new tenancy approval
- [ ]  Team to get necessary permissions set up in current compartment for ongoing development
- [ ]  Team to prepare data-driven explanation of benefits vs costs for tenancy approval process, anticipating pushback

### Project Overview

- **Research Tools Modernization**: Building modern tools for researchers to ingest, process, and manage drug content, gradually replacing .NET desktop tools with scalable web-based solutions
- **Three-Phase Delivery Approach**:
    - Phase 1: MVT with basic database display and AI chatbot
    - Phase 2: Enhancements including annotation features (accept/reject/edit) and JIRA/support ingest integration
    - Phase 3: Automated structured data transformation to SQL database to enable full migration from legacy tools
- This represents an incremental modernization approach rather than a big-bang replacement

### Key Decision: Dedicated Tenancy Approved

- **Consensus Reached**: Team agreed to pursue creation of dedicated OCI tenancy for Multum instead of continuing with shared tenancy model
- **Scope Clarification**: Initial focus is on research tools pillar and OIC work, with future-proofing for other Multum services
- **Organizational Autonomy**: Decision driven by desire for Multum Engineering to have end-to-end ownership and responsibility for infrastructure deployment and operations
- **Greenfield Approach**: In a vacuum without historical constraints, dedicated tenancy would be the obvious choice for an autonomous service like Multum

### Technical Challenges with Current Shared Tenancy

- **Permission Constraints**: Team encountered repeated IAM and permission constraints in shared tenancy that significantly slowed experimentation during POC phase
- **Ticket-Based Workflow**: Every infrastructure change requires filing tickets and waiting for approval, taking weeks to complete simple tasks
- **Limited Administrative Access**: Current compartment doesn't provide autonomous control - IAM roles and policies managed at tenancy layer prevent prototyping
- **OIC Installation Issues**: Installation and setup in shared environment has been "an exercise in frustration"
- **Database Access Limitations**: Team lacks administrative access to Oracle 26 AI machine, preventing visibility into operations and custom configuration

### Benefits of Dedicated Tenancy

- **Faster Prototyping**: Enables rapid iteration without filing tickets for each change, maintaining cleaner implementation
- **Better Security Posture**: Full visibility and control over policies prevents accumulation of unnecessary permissions and leftover configurations
- **Development Speed**: Team can make infrastructure changes immediately rather than waiting for ticket approval
- **Operational Control**: Ability to troubleshoot and resolve production issues quickly without dependencies on other teams
- **Clearer Ownership Boundaries**: Separates Multum's internal drug content processing work from typical EHRC operations
- **Cross-Tenancy Communication**: Technically straightforward to enable via policies, not a barrier

### Tenancy vs Compartment Distinction

- **Organizational Decision First**: Whether to use dedicated tenancy or dedicated compartment is secondary to the organizational question of Multum having autonomy
- **Technical Equivalence**: Compartment within shared tenancy could provide similar benefits if Multum Engineering gets full administrative control
- **Current Limitation**: Existing compartment in shared tenancy doesn't provide true autonomy - permissions still managed externally
- **Deployment Definition**: Deployment means putting new infrastructure or code into production, distinct from data delivery between services

### Operational Considerations

- **Maintenance Overhead**: Managing own tenancy adds responsibility but maintenance is minimal - primarily responding to security central tickets
- **Already Handling Some Tasks**: Team already responds to security tickets, so operational burden isn't significantly higher
- **Learning Curve**: Main cost is onboarding and learning DevOps model, not ongoing maintenance
- **Not as Daunting as It Seems**: Can start small with limited scope and expand as team gains confidence
- **Infrastructure as Code**: Hard requirement for production deployments, optional for prototyping

### Approval Process Timeline

- **Not Quick**: Tenancy creation requires CSAP process approval, could take weeks or months
- **Expect Pushback**: Anticipate resistance questioning why Multum needs dedicated tenancy when others use shared model
- **Low Risk Decision**: Getting tenancy approved doesn't commit to using it - can be released if not needed
- **Benefits Future Work**: Even if not helpful for current project, will advantage future projects that would otherwise face same delays

### SKG and External Integration

- **SKG Interaction**: Team's interaction with SKG happens via REST APIs and TTL file uploads to common repository
- **Not Impacted by Tenancy**: SKG integration pattern (REST APIs) remains unchanged regardless of tenancy model
- **Deployment vs Data Delivery**: Important distinction - software deployment is separate from content updates, should follow different processes
- **Bi-directional Communication**: Desire for awareness of downstream mappings and failures to inform Multum's build process