5. Technical Architecture
Technical Architecture Overview
The proposed technical architecture for MOW 2.0 is centered on a custom-built, Azure-hosted application platform designed to support VNA's operational, reporting, integration, and security requirements as a single coordinated solution. The architecture is intended to provide a stable production foundation for Phase 1 while preserving the modularity and extensibility needed for later platform consolidation and future commercialization.
At a high level, the solution consists of a central C#-based web API and shared application core, a SQL Server-backed data platform, a browser-based single-page application, a native mobile application, a dedicated reporting and dashboard environment, and Azure Functions-based background-processing services. Together, these components form a purpose-built platform architecture that can support the functional scope defined in the VNA requirements while maintaining clear separation of concerns across application, data, integration, reporting, and operational service layers.
Cloud and Hosting Architecture
The MOW 2.0 platform will be hosted in Microsoft Azure and deployed as a cloud-based solution aligned with VNA's stated preference for Azure-compatible architecture. The hosting model is intended to provide a secure, scalable, and operationally resilient foundation for the core application platform, integrations, reporting workloads, and supporting service components.
At a minimum, the cloud architecture will support separation of production, test, and training environments; secure hosting of the API and supporting services; managed data storage; secure integration paths to internal and external systems; and infrastructure patterns that can scale with increased usage over time. This Azure-first approach also supports VNA's broader goals around operational control, future platform growth, and long-term movement toward a more commercialization-ready solution architecture.
Core Application Architecture
The core application architecture will be built on .NET 10 LTS and centered on a custom C# application layer exposed through a central web API. That API will serve as the primary system boundary for browser, mobile, reporting, and integration workloads, with all requests flowing through a consistent Command/Request/Response pattern. This approach provides a predictable execution model for validation, business rules, auditing, error handling, and response shaping across the platform.
The application tier will remain fully stateless so that it can scale horizontally in Azure without reliance on server-local session state or machine affinity. Shared business logic will be concentrated in reusable application and domain services rather than duplicated across channels. This allows the web application, mobile application, background-processing services, and reporting-oriented service components to rely on the same core rules and workflows while maintaining clean separation between presentation, orchestration, persistence, and integration concerns.
Authentication will use Azure Active Directory for SSO sign-on so that the security model aligns with client standards from the outset. Authorization will be enforced separately and flexibly based on user roles and assigned locations, allowing the platform to support practical operating boundaries across programs, service areas, kitchens, depots, and administrative functions. This model is intended to support both strong security and the operational realities of distributed Meals on Wheels workflows.
The data-access layer will use a pragmatic poly approach within the Microsoft stack. Entity Framework Core will be the default access pattern for most transactional application behavior, while stored procedures and other targeted mechanisms will be used where they are the better fit for complex reporting, bulk operations, import/export workloads, or performance-sensitive database activity. Caching will be applied selectively where it provides measurable value, particularly for reference data, repetitive lookups, and other read-heavy operations that would otherwise create unnecessary database load.
In line with a robust Microsoft implementation, the core platform will also follow standard engineering patterns such as dependency injection, centralized configuration, structured logging, health checks, environment-specific settings, and clear service contracts between internal modules and external integrations. The result is an application core that is maintainable, testable, operationally observable, and ready to support future scale without requiring architectural rework.
Web Application Architecture
The browser-based application will be implemented as a React single-page application that serves as the primary user interface for administrative, operational, clinical, intake, billing, reporting-access, and support workflows performed from desktop and tablet-class devices. The web application will consume the central API rather than embedding business rules directly in the frontend, keeping the user interface focused on presentation, workflow guidance, validation feedback, and efficient interaction with the core platform services.
The React application will be structured as a modular frontend with clear separation between pages, reusable UI components, API client services, state management, routing, and shared utility layers. This approach supports maintainability as the system grows and allows functional areas such as referral intake, clinical assessments, scheduling oversight, billing operations, reporting access, and administration to evolve independently. It also supports role-sensitive navigation and location-aware user experiences aligned with the underlying authorization model.
From an engineering perspective, the web application will follow the expected patterns for a robust modern enterprise SPA: component-based UI composition, centralized API communication, consistent error handling, environment-based configuration, secure token handling, client-side route protection, form validation, and reusable patterns for grids, dashboards, workflows, and document-oriented screens. The UI will be designed to provide responsive performance for data-heavy operational use while preserving clear accessibility, usability, and consistency across the platform.
Mobile Application Architecture
The mobile application will be implemented in React Native and will provide the native device experience required for field-based workflows such as route execution, delivery confirmation, task completion, issue capture, and other operational activities that occur away from a desk. Like the web application, the mobile application will consume the central API rather than owning independent business rules, ensuring that mobile workflows remain aligned with the same validation, authorization, and process logic used throughout the platform.
Because mobile operations often involve inconsistent connectivity, the mobile application will be designed with practical resilience patterns such as retry handling and protection against duplicate submission or incomplete transaction states. These patterns are important for maintaining operational continuity and a positive user experience.
From a security and operational standpoint, the React Native application will follow the same platform standards as the rest of the solution: authenticated access using Azure Active Directory, role- and location-aware authorization, secure token handling, encrypted local storage where needed, controlled session behavior, structured error handling, and versioned deployment practices. This allows the mobile channel to function as a first-class part of the MOW 2.0 platform rather than as an isolated field tool.
Reporting and Dashboard Architecture
The reporting and dashboard architecture will have two distinct layers: operational dashboards embedded directly within the application experience, and aggregate executive reporting delivered through Power BI. This separation allows the platform to support immediate user action at the workflow level while also providing management and leadership with broader analytical visibility across programs, service activity, financial performance, and operational trends.
Within the web application, operational dashboards will surface the items that require user attention based on role, location, and workflow state. Tasks awaiting action, unresolved exceptions, pending reviews, scheduling gaps, documentation issues, billing follow-up items, and other work queues will be designed to bubble up to the user's landing page so that the system actively guides day-to-day operations instead of requiring staff to search for problems. These in-app dashboards are part of the core transactional platform rather than a separate reporting tool, which keeps operational guidance close to the underlying workflow.
For aggregate and executive reporting, the platform will use Power BI dashboards and drill-down reporting over the centralized data foundation. This reporting layer can support broader visibility into KPIs, census and referral trends, route and service metrics, billing and collections performance, volunteer and staffing activity, compliance indicators, and other management-level views required by VNA leadership. Drill-down capability will allow users to move from summary measures into supporting detail while preserving appropriate security boundaries around role and data access.
This combined approach provides a practical reporting architecture for both frontline operations and executive oversight. The transactional application remains responsible for real-time operational guidance and queue-driven user action, while Power BI provides the aggregate, cross-functional, and analytical reporting layer needed for monitoring, decision support, and long-term performance management.
API and Integration Architecture
The API and integration architecture will be centered on the same .NET 10 web API that serves the browser and mobile applications, allowing integrations to be treated as first-class parts of the platform rather than as isolated utilities. This API-first model supports reliable exchange of operational, financial, identity, and healthcare-related data across VNA and third-party systems while preserving one governed execution path for validation, business rules, auditing, and security enforcement.
In practical terms, the integration layer is expected to support connectivity with Business Central, payroll-related endpoints, Salesforce VP, Bamboo Health, Trio Kitchen, the retained MOW Back Office Portal (BOP), external EHR and healthcare systems, and selected file-based interfaces where scheduled import/export remains the most practical pattern. Routing is the clearest example of a deliberately integrated best-of-breed service: the platform will orchestrate around a routing engine accessed through defined APIs rather than treat route optimization as custom-built intellectual property. This reduces delivery risk while keeping routing workflows embedded in the broader MOW 2.0 operating model.
The result is an integration architecture that is both disciplined and adaptable. Real-time APIs can be used where immediacy and transactional integrity matter most, while managed scheduled exchanges and governed file flows can support systems that are not designed for direct synchronous interaction. By keeping the central API as the primary system boundary, the platform preserves consistency across internal workflows, downstream reporting, and external coordination over time.
Background Processing and Azure Functions
Background processing will be implemented through Azure Functions and related Azure-hosted service components so that scheduled jobs, asynchronous processing, and integration orchestration can run independently of the interactive application tier. This pattern is well suited to workloads such as import/export handling, scheduled synchronization, interface polling, notifications, data propagation to dependent systems, route-related integration jobs, and other non-interactive processes that should not block user-facing transactions.
Using Azure Functions also creates a clean separation between real-time user actions and longer-running or event-driven work. The platform can therefore keep the core API focused on transactional workflows while background services handle retries, transformation, file movement, reconciliation, exception capture, and other operational tasks required to keep integrations and recurring processes stable at production scale.
Where appropriate, these background services will rely on the same shared business logic and service contracts used by the main application core rather than duplicating rules in isolated scripts. That approach improves maintainability, keeps audit and validation behavior aligned across execution paths, and allows background-processing behavior to evolve as the broader platform matures.
Data Architecture and SQL Server Design
The core operational data platform will be based on SQL Server and will function as the system of record for client, referral, scheduling, service-delivery, billing, workflow, audit, and reporting-support data across the MOW 2.0 platform. The proposal materials consistently position this database as the shared foundation for web, mobile, integration, reporting, and background-processing workloads, allowing the solution to operate from one coordinated operational record rather than from disconnected application silos.
The database design will support a shared operational data model spanning core entities such as referrals, clients, households, payers, authorizations, schedules, routes, depots and drop sites, service events, volunteer and driver assignments, billing state, and reporting and audit signals. This common model is important not only for transactional integrity, but also for preserving a consistent foundation for embedded dashboards, Power BI reporting, migration reconciliation, and downstream integrations.
The database layer should support both transactional processing and reporting-oriented workloads while preserving clear boundaries between live operational workflows, document and file references, and aggregate analytical outputs. Consistent with the broader Microsoft-stack approach, Entity Framework Core will be the default access path for most application behavior, while stored procedures and other targeted patterns remain appropriate for high-volume imports, complex transformations, reconciliation workloads, and performance-sensitive operations where they are the better fit.
Security Architecture
The security architecture is intended to be platform-wide rather than module-specific, with controls applied consistently across the API, web application, mobile application, reporting environment, integration services, and Azure-hosted infrastructure. The proposal record supports a HIPAA-regulated design posture built on Azure-native controls plus application-layer safeguards, including encryption of data at rest and in transit, structured audit logging, environment-specific secrets management, and monitoring for failures or abnormal behavior.
From a control standpoint, the current proposal language already supports explicit commitments to AES-256-equivalent encryption at rest through Azure-managed data and storage services and TLS 1.2+ for data in transit across API and web endpoints. Security boundaries will also be reinforced through role-based access control, governed API behavior, controlled session handling, and the ability to audit meaningful user and system activity throughout the platform lifecycle.
More broadly, the architecture should be understood as aligned with the RFP's expectations around HIPAA, NIST-oriented control discipline, auditability, and protection of sensitive operational and client data. This includes an operating posture that can support incident response, breach notification obligations, and secure handling of PHI without treating compliance as a separate overlay disconnected from day-to-day system behavior.
Identity, Access Control, and Authentication
Authentication will use Azure Active Directory / Entra ID so that the platform aligns with VNA's Microsoft-oriented identity environment and supports single sign-on from the outset. This approach provides a strong enterprise identity foundation for the web application, reporting access, administrative tooling, and mobile authentication flows, while also supporting consistent token-based access to the central API.
Authorization will be enforced separately from authentication and managed within the application based on role, assigned location, and operational responsibility. That distinction is important because the platform must support practical operating boundaries across programs, service areas, kitchens, depots, supervisors, field staff, volunteers, billing users, and administrative users without assuming that identity-provider membership alone is sufficient to govern application behavior.
The access-control model is intended to support need-to-know access patterns at multiple levels, including application areas, workflow surfaces, reporting access, and more sensitive record elements where the operational or privacy context warrants tighter control. This allows the solution to support both secure enterprise governance and the practical flexibility needed for real-world Meals on Wheels operations.
Environments, Deployment, and Promotion Model
The solution will be deployed through a controlled multi-environment model rather than a single shared stack. At a minimum, the proposal supports Development, Testing / QA, Training, and Production environments, with the ability to add temporary UAT, sandbox, release-candidate, or troubleshooting environments where project conditions justify them. This separation supports disciplined testing, safer promotion of code and configuration, training readiness, and reduced risk to live operations.
The deployment and promotion model will rely on repeatable automation rather than manual environment assembly. The Azure footprint will be defined through version-controlled infrastructure templates and promoted through controlled CI/CD pipelines, allowing application services, Azure Functions, configuration, storage, and related infrastructure to be recreated consistently across environments. This approach improves delivery discipline during implementation and also strengthens long-term support, auditability, and disaster-recovery readiness.
Promotion into higher environments should follow managed readiness gates rather than informal calendar-based movement. In practice, that means code, configuration, integrations, reporting changes, and related operational assets progress through validation, migration readiness, training readiness, and go-live approval in a structured way so that the production environment remains stable and governed over time.
Performance, Availability, and Operational Resilience
The proposed architecture is designed for practical enterprise resilience by combining stateless application services, managed Azure platform components, centralized monitoring, structured logging, and repeatable deployment automation. Because the API and application tiers are intentionally stateless, the platform can scale horizontally as usage, reporting demand, and integration traffic increase without relying on server-local session state or machine affinity.
Performance will also be supported through selective caching, efficient API design, targeted database optimization, and pragmatic separation between interactive and background workloads. The intent is to improve responsiveness for common operational workflows while avoiding unnecessary complexity or premature optimization. Standard engineering controls such as health checks, telemetry, alerting, and failure visibility will help the team identify issues quickly and support stable production operations.
Operational resilience should be framed in terms of recoverability as well as uptime. The Azure hosting model supports backup and restore for managed data and storage services, reproducible environment rebuilds through infrastructure as code, controlled redeployment of application components, and documented recovery procedures for integrations, reporting, and scheduled jobs. Final recovery targets such as recovery time objective (RTO) and recovery point objective (RPO) should be confirmed during implementation design because they affect both cost and operating posture, but the architectural direction is to support controlled and auditable recovery rather than depend on ad hoc reconstruction.
Multi-Tenant Readiness and Future Commercialization Architecture
The proposal positions Phase 1 as a production-ready implementation that is architected for multi-tenant use from the beginning, even if the initial production rollout serves a single client environment. From the outset, the underlying data model, service boundaries, configuration approach, and Azure-hosted architecture should be designed so that tenant separation, reuse, and broader platform expansion can be supported without requiring later architectural rework.
That multi-tenant posture is important both commercially and technically. The custom MOW 2.0 core platform is the primary long-term asset in the proposed solution, while third-party products such as routing remain integrated supporting capabilities rather than the basis of the commercialization model. By preserving a strong central API, a shared operational data model, modular service boundaries, configurable application behavior, and tenant-aware design patterns from the outset, the platform can support broader reuse without requiring architectural reinvention.
In practical terms, this means Phase 1 should be understood as a VNA-first implementation delivered in a cloud-based, SaaS-style operating model, but with the solution engineered for multi-tenant readiness from day one rather than deferred as a later architectural concern. If the production deployment remains single-client for business reasons, that does not undermine the architecture; it simply means the platform is being built with broader tenant capability available when and if VNA chooses to use it.