7. Hosting

Hosting Overview

The proposed MOW 2.0 solution will be hosted in Microsoft Azure and aligned to VNA's stated Azure preference. The preferred deployment model is to host the production solution within VNA's own Azure tenant so that VNA retains direct control over the cloud environment, subscriptions, resource ownership, billing visibility, security oversight, and long-term operational portability.

Under that preferred model, 3Wrkz will design, deploy, and support the application platform within VNA's Azure environment, while the underlying Azure consumption charges are incurred directly by VNA rather than marked up or rebilled by 3Wrkz. This keeps hosting costs transparent, avoids unnecessary pass-through pricing, and gives VNA direct ownership of the production cloud footprint from the outset.

As an alternate option, 3Wrkz is also willing to host the solution in a 3Wrkz-managed Azure tenant if VNA prefers a more outsourced operating model. In that scenario, the application architecture and deployment pattern would remain Azure-based. Hosting costs will be discussed later in pricing section of this RFP response.

Proposed Hosting Model: VNA Azure Tenant

The primary recommended hosting approach is:

1. production deployment in a VNA-owned Azure tenant
2. application and data services provisioned in Azure under VNA-controlled subscriptions or resource groups
3. 3Wrkz deployment, configuration, and application-support responsibilities performed within that tenant
4. Azure infrastructure and platform consumption billed directly to VNA
5. no separate 3Wrkz hosting charge for Azure consumption when hosted in VNA's tenant

The Azure implementation would be right-sized to the actual workload and would center on managed Azure services appropriate to the solution architecture. At a practical level, that includes Azure-hosted application services for the web API and browser application, Azure Functions for background processing and integrations, Azure SQL-managed data services for the operational database, managed storage for documents and integration-file handling, and Azure-native monitoring, logging, and secrets-management capabilities.

Environment Strategy

The hosting model will include multiple right-sized environments rather than a single shared stack. At a minimum, the solution should include:

1. Development

   Used for active engineering work, configuration changes, and internal technical validation.

2. Testing / QA

   Used for formal testing, defect validation, regression testing, integration verification, and pre-release certification.

3. Training

   Used for user training, rehearsals, demonstrations, and operational readiness activities. Where appropriate and permitted, this environment should be refreshed with representative data so that training remains realistic.

4. Production

   Used for live operational processing, integrations, reporting, and day-to-day business use.

Additional environments can be provisioned as needed for implementation and support activities, such as UAT, temporary sandbox environments, release-candidate validation, or isolated troubleshooting. Non-production environments should be sized appropriately for their purpose so that the hosting model remains cost-conscious without compromising testing quality or deployment discipline.

This environment model supports controlled promotion of code and configuration changes, clear separation between live and non-live operations, and a safer release process across the life of the platform.

Mobile Application Deployment

The mobile application will be distributed through the Apple App Store and the Google Play Store. Mobile users will install the app through the standard public or managed enterprise distribution mechanisms supported by those platforms, while the application's backend services, synchronization endpoints, authentication flows, and operational data access remain anchored in the Azure-hosted MOW 2.0 environment.

This means the mobile client itself is delivered through the device-platform app stores, but the operational system of record, business logic, integrations, and supporting services remain within the Azure hosting model described in this section.

Operational Responsibilities and Cost Position

In the preferred VNA-tenant model, Azure hosting consumption is a VNA cost rather than a 3Wrkz-hosted pass-through service. 3Wrkz's role is to implement and support the application environment, not to resell Azure consumption back to VNA.

That distinction is important commercially:

1. VNA pays Azure directly when the platform is hosted in the VNA tenant
2. 3Wrkz does not add separate hosting charges for Azure consumption in that model
3. 3Wrkz pricing would instead focus on implementation, support, maintenance, and any separately scoped managed services
4. if VNA selects the alternate 3Wrkz-tenant model, hosting and environment-management costs would be priced explicitly

This approach keeps the financial model straightforward while preserving a clear separation between cloud-consumption ownership and application-delivery services.

Monitoring, Security, and Operational Controls

Regardless of which tenant hosts the solution, the Azure environment should support the normal controls expected for a HIPAA-regulated application platform. That includes:

1. centralized logging and telemetry
2. environment-specific configuration and secrets management
3. backup and recovery controls for data and critical storage
4. role-based administrative access
5. monitoring and alerting for availability, failures, and abnormal behavior
6. secure encryption of data at rest and in transit

The exact service mix can be finalized during implementation design, but the hosting pattern is intended to rely on Azure-native operational controls rather than custom infrastructure administration wherever possible.

Scalability and Resilience Approach

The hosting design will be sized to current operational demand while preserving the ability to scale as usage, reporting workloads, and integration volume increase. Because the application and API layers are designed to be stateless, the environment can scale horizontally when needed without major architectural change. Managed Azure services also provide a practical path for backup, failover, patching, and operational resilience without requiring VNA to maintain bespoke infrastructure.

In short, the hosting strategy is designed to give VNA a secure, Azure-aligned production foundation with direct ownership of cloud costs in the preferred model, while still preserving a viable vendor-hosted alternative if that proves operationally preferable.

Disaster Recovery and Environment Rebuild Approach

The Azure hosting model should also be designed with disaster recovery in mind so that VNA can restore operations in the event of a major outage, regional disruption, or other production-impacting incident. In an Azure environment, that requires more than simple backups. It requires a repeatable recovery design covering infrastructure recreation, application redeployment, database recovery, configuration restoration, secrets handling, external integrations, and validation steps needed to return the platform to an operational state.

The proposed approach is to rely on Azure-native disaster-recovery patterns combined with disciplined deployment automation. A key part of that strategy is that the environment will be defined and reproducible through infrastructure as code using Bicep files, executed through a controlled CI/CD pipeline. That allows 3Wrkz to stand up new environments quickly, recreate Azure resources consistently, and reduce recovery risk caused by manual infrastructure configuration.

At a practical level, a credible Azure disaster-recovery approach for this solution should include:

1. infrastructure definitions for the core environment captured in version-controlled Bicep templates
2. automated deployment pipelines capable of recreating application infrastructure, networking, storage, identity dependencies, and environment configuration in a repeatable manner
3. database backup and restore procedures for the Azure SQL environment, including point-in-time restore and, where appropriate, geo-restore or secondary-region recovery options
4. recovery procedures for document storage, integration-file storage, and other persistent assets required for resumed operations
5. restoration of application configuration, secrets references, certificates, and connection settings through controlled environment management rather than ad hoc manual steps
6. redeployment procedures for the web API, browser application, Azure Functions workloads, and related supporting services
7. validation checklists for integrations, authentication, scheduled jobs, reporting, and operational data integrity after recovery

This means that recovery is not dependent solely on preserving one live environment. If a production environment becomes unavailable, the target approach is to be able to rebuild the necessary Azure footprint, redeploy the application stack, restore data and configuration, and re-establish external connectivity in a structured and auditable way.

The exact recovery design should ultimately define recovery objectives such as RTO and RPO, backup-retention policies, regional failover expectations, and the specific Azure services used for replication or restoration. Those details should be finalized during implementation design because they affect both cost and operational posture. Even so, the architectural direction is clear: disaster recovery should be based on reproducible infrastructure, automated deployment, recoverable managed data services, and documented recovery runbooks rather than one-off manual reconstruction.

Because the environment will be deployed through Bicep and CI/CD, VNA will also have a stronger operational position for broader disaster scenarios. New environments can be created quickly for recovery, validation, or temporary failover use, and the resulting Azure footprint will remain consistent with the approved production design. That approach materially improves resilience and shortens the path from a disruptive incident to a controlled restoration of service.