← All technical work

Enterprise Architecture · Edge Deployment

Enterprise Edge Deployment Framework

A resilient enterprise architecture for deploying, managing, and observing software and configuration across a large distributed restaurant edge

A hub-and-spoke edge architecture that combined persistent local artifact distribution, metadata-driven deployment, independent endpoint execution, and centralized device-state visibility to reliably manage software and configuration across thousands of distributed devices.

1,200+
Restaurants at scale.
13,000+
Edge devices managed.
Minutes
Active estate deployment.

Problem & Constraints

Restaurant software deployments relied on point-in-time push processes that assumed devices would be online and reachable when a change was released. Across a large, intermittently connected edge estate, missed deployments accumulated over time, leaving hundreds of software versions in production and making consistency increasingly difficult to maintain.

Visibility was similarly point-in-time. Understanding what software or configuration existed on a device required targeted PowerShell queries followed by manual analysis, with no persistent enterprise view of device state. The architecture needed to make deployment resilient to endpoint availability while creating a continuously updated view of what was actually running across the estate.

Distributed edge
More than 1,200 restaurants and 13,000 devices spanning controllers, POS terminals, tablets, and other Windows endpoints.
Intermittent availability
Devices could be offline during a release and still needed to receive the correct changes when they returned.
Constrained WAN connectivity
Restaurant connectivity made repeatedly transferring deployment content from the enterprise to individual endpoints inefficient.
Multiple device classes
Controllers, POS terminals, tablets, and other device types had different roles and deployment requirements within each restaurant.
Operational continuity
Deployments could not introduce unnecessary dependency on enterprise connectivity or interfere with the restaurant's ability to operate.
Deployment flexibility
The solution needed to support software, scripts, files, configuration, and other edge changes without building application-specific deployment logic into the framework.

Architecture Overview

Hub-and-spoke architecture for deploying artifacts to restaurant devices with centralized status and device-state reporting
Hub-and-spoke architecture for resilient enterprise edge deployment

The enterprise framework used a hub-and-spoke architecture in which deployment packages were distributed once to each targeted restaurant and persisted by an Artifact Server on the POS Controller. Device Agents running across controllers, POS terminals, tablets, and other Windows endpoints independently discovered applicable artifacts, retrieved them over the local network, and executed ordered instructions defined through package metadata. This kept device-level artifact distribution within the restaurant network while allowing the same framework to deploy software, scripts, files, and configuration without application-specific deployment logic.

The architecture also established a continuous feedback path from the edge. Device Agents reported deployment results, health, device information, and component versions through the local Artifact Server to enterprise services, where observed state could be compared with expected state and exceptions surfaced centrally. Because artifacts persisted locally and agents evaluated their own processing history, devices did not have to be online when a release occurred. Devices that returned later could process missed changes and converge toward the intended state without requiring a separate deployment campaign.

Key Architecture Decisions

Localize artifact distribution

Deployment content crossed the constrained restaurant WAN once and persisted on the local Artifact Server, where Device Agents independently discovered and retrieved applicable artifacts over the restaurant network.

Separate transport, distribution, and execution

Service Bus and the POS Agent handled enterprise-to-restaurant transport, the Artifact Server provided local persistence and artifact access, and Device Agents independently determined and executed applicable changes.

Persist deployment intent at the edge

Deployment artifacts remained available within each restaurant rather than depending on endpoints being reachable during a point-in-time release, allowing devices that were offline to discover and process missed changes when they returned.

Drive deployment behavior through metadata

Generic Device Agents interpreted ordered manifest instructions packaged with each artifact, allowing the framework to deploy software, scripts, files, and configuration without embedding application-specific deployment logic in the agent.

Target stable device classes, not individual endpoints

Artifacts were organized and targeted locally by device class rather than physical device identity, allowing changing populations of terminals and tablets to consume applicable deployments without maintaining per-device distribution structures.

Separate execution from invocation

Deployment jobs defined the work to perform independently of when they ran, allowing the same job logic to execute on a schedule, at service startup, or immediately when a coordinated change required it.

Make deployed state explicit and observable

Applications, services, scripts, configuration, and other managed components were versioned and continuously registered, creating a consistent representation of what was actually running on each device. Observed versions could then be compared with the expected-state baseline so mismatches remained visible until corrected.

Treat rollback as another deployment

Reversal used the same generic framework as forward deployment, with compensating packages defining the application-specific steps required to restore previous state.

Engineering Approach

The engineering approach emphasized resilient edge operation, reusable deployment mechanisms, and persistent visibility across a distributed device estate. Lightweight services, metadata-driven execution, local artifact persistence, asynchronous messaging, and versioned state enabled devices to operate independently while remaining manageable from the enterprise.

Application & Services
.NET · Windows Services · RESTful APIs · Device Agents · JSON Manifests · Scheduled Jobs
Data & Messaging
Azure Service Bus · Publish/Subscribe · Queues · Azure SQL · Asynchronous Processing · Local Artifact Repository
Patterns & Principles
Hub-and-Spoke · Metadata-Driven Execution · Separation of Concerns · Loose Coupling · Local Persistence · Independent Endpoint Execution · Expected vs. Observed State
Release & Reliability
CI/CD · Versioning · Phased Deployment · Startup Recovery · Health Monitoring & Alerting · Deployment Validation · Compensating Rollback
Security
Microsoft Entra ID · Role-Based Access · Managed Service Accounts · Certificate-Secured Communications · Transport Layer Security

Results & Evolution

The framework transformed deployment and device management across more than 1,200 restaurants and 13,000 devices, replacing dependence on point-in-time endpoint availability with a persistent edge-management model. Centralized registration replaced point-in-time interrogation with persistent visibility into the software, configuration, health, and deployment state of the estate.

  • Scaled a common deployment model across the edge: Software, scripts, files, and configuration could be deployed through the same framework across controllers, POS terminals, tablets, and other Windows devices.
  • Reduced configuration drift: Persistent local artifacts allowed devices that missed a release to process outstanding changes when they returned, rather than remaining indefinitely on an older version.
  • Established enterprise-wide state visibility: Versioned component registration and expected-state baselines made mismatches, failed deployments, unhealthy agents, and other exceptions centrally visible.
  • Proven during a high-stakes enterprise cutover: A major loyalty-platform migration required the restaurant edge to transition within a tightly coordinated cutover. The vast majority of active devices completed the change within several minutes, and when issues elsewhere in the migration required rollback, the framework reversed the edge transition. The deployment was ultimately executed three times and reversed twice before the final cutover remained in production.

Architectural Perspective

My approach to architecture is grounded in creating clear boundaries, separating responsibilities, and using abstraction to keep complexity from spreading through a system. In this design, enterprise transport, local artifact distribution, and endpoint execution were deliberately separate concerns, while metadata allowed deployment-specific behavior to change without changing the execution framework itself.

I also believe resilient systems should be designed around the conditions they will actually encounter. At the restaurant edge, devices would sometimes be unavailable, connectivity would be constrained, and the environment would continuously change. Persisting artifacts locally, allowing endpoints to operate independently, and making versioned state observable turned those conditions into characteristics the architecture could accommodate rather than exceptions the operation had to work around.