Summary of Meeting

### 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