I outline the transformation of our warehouse operations system, focusing on the new codebase, staff impact, development and deployment changes, and solutioning challenges.
From Legacy Patchwork to Modeled Solutions
After persuading management and technical veterans for radical changes, they ran interference while I built a new codebase and system design model. The goal: an opportunistic system for order-requirement demand satisfaction, unlike the deterministic, brittle legacy processes that grouped orders into rigid, daily releases unable to handle exceptions or reprioritizations.
The new system centered-on aggregate demand, fungible inventory, and continuous flow. We developed a cross-customer inventory schema with customizable item-master and container properties. Using Entity Framework (EF) with generic DbSets, we enabled customer overrides for specific scenarios while maintaining core operations like CreateContainer, AddInventory, and MoveInventory. This allowed reuse across projects, with customers adding fields via virtual overrides.
I realized we needed – and then built – an operations system to track devices, log interactions, and maintain durable states, based-on but superceding our legacy “transaction logs”. Performance helpers—generic lookups, transaction wrappers, and SQL retry logic—formed the foundation, unified by dependency injection and an ASP.NET HttpHost.
We reused legacy hardware libraries for routing, conveyors, PTL, and shuttles, replacing SQL calls with API endpoints and JSON-marshaled C# classes to minimize rewriting major integration components. A recurring operation brokerage system with scalable task agents addressed scheduled task needs identified in the first project.
Challenges
Developers, accustomed to SQL stored procedures and NOLOCK hints, struggled with EF and snapshot isolation. They had to learn the nuances of IQueryable vs. IEnumerable distinctions amongst other things.
Legacy deterministic plans worked by aggregating data into temp tables, causing locking and dirty-read issues. The new system pre-summarized decisions in C# during inventory and order operations, using denormalized data synced via transactions. SQL stored procedures handled in-place field-level updates within snapshots.
Automating Logistics
We moved core and hardware libraries to NuGet feeds, streamlining workflows. Customer implementations referenced these packages, using them to extend functionality, and initialize the system via dependency injection.
We adopted Docker on Alpine Linux for .NET Core, though some legacy components required Windows. Build pipelines allowed us to automate deployments. DB schemas entered Git, with deltas generated via compares – EF migrations would come in a future product version.
Envisioning Project Requirements
The new system had a “model-first” paradigm, emphasizing discrete inventory states, container types, and location types. Operations managed movements or state changes, replacing legacy flags with queryable summaries.
Unfortunately, sales and implementation teams mixed legacy pitches with assumptions that “product” covered all needs, complicating scope definition.
Consequently, state-diagram mapping was often retrofitted after documents were signed-off. Topological warehouse models contextualized operations and flows, yet this discipline never fully reached implementation teams before company challenges emerged.
Overall
Over three years, we made significant technical and operational strides. Organizational scope issues persisted, but unrelated medical and legal problems ultimately halted progress.
Pursuit of Value 