Scaling What Works Without Erasing What Makes Each Site Different
A solution could work beautifully at one site and become expensive, brittle or irrelevant when copied to the next.
Jetson supported a growing network of warehouses with different equipment, vendors, signals, terminology and controls. Copying successful capabilities and modifying them locally created increasingly unique instances and repeated engineering effort.
I investigated the recurring problem behind those solutions: what could become a shared enterprise capability, and what needed meaningful site configuration?
IMPLEMENTED PATTERNS · STRATEGIC EXPLORATION · CONCEPT
Explore in Smart Warehouse →Reuse the problem, not the workaround.
- Site ASolves a local problem
- Site BCopies and modifies
- Site CStarts from a changed version
- Site DAdds another variation
Repeat this pattern and “reuse” creates more maintenance. Local workarounds were evidence of unmet needs, not specifications to copy.
Similar problems lived inside different warehouses.
“Can we have what that other building has?” could conceal differences in equipment, vendors, controls, telemetry, network access, layout, terminology, roles, thresholds and permissions. Rebuilding everything independently was equally wasteful when sites faced the same decision problem.
What represents a reusable capability—and what exists because Site A is Site A?
Some of the best product signals were things people built themselves.
Senior Site Engineers and other technically capable users created Splunk queries, Excel tools, dashboards, calculations, reports, documentation and scripts. Someone cared enough to work around a gap in the supported product.
Those artifacts exposed a real need and an early attempt to represent it. They did not establish the product requirement.
- What decision does the workaround support?
- Does the same problem exist elsewhere?
- Which parts recur?
- What technical conditions enable it?
- What belongs in the supported product?
The workaround showed us where to investigate. It did not dictate what to build.
A site request became a product question.
- Understand the requestWhat is the site asking for?
- Find the problemWhat decision or action is difficult?
- Compare environmentsDoes the need recur in another form?
- Identify the stable patternWhat remains the same across sites?
- Investigate feasibilityWork with Engineering on equipment, telemetry, controls, networks, integrations and data quality.
- Define the product boundaryShared behavior, configuration, integration, a site-specific implementation—or outside product ownership?
Standardization begins with understanding what is actually the same.
“Can I have this at my site?” was not always a yes/no question.
Reuse depended on physical workflow, installed equipment, vendor technology, available signals, consistent metrics, network/integration access and controls. Feature availability could become a question of prerequisites rather than a binary switch.
Compatible
Known prerequisites are present.
Likely compatible
Most requirements appear available; technical validation is needed.
Engineering review
Architecture or integration needs investigation.
Missing prerequisite
Required workflow, equipment, signal or integration is unavailable.
CONCEPT · Possible readiness states, not a shipped compatibility engine or automated technical assessment.
When does reuse stop being configuration and become a new implementation?
Standardize the repeatable pattern. Preserve the meaningful difference.
I initiated engineering feasibility discussions around a shared enterprise foundation instead of cloning an application for each facility.
- Site A implementationLocal starting point
- ↓ Copy to Site BModified behavior
- ↓ Copy to Site CAdditional local changes
- ↓ Copy to Site DAnother unique instance
Divergent UX, repeated engineering and improvements that are harder to maintain centrally.
Common behavior, with explicit configuration for real physical and technical differences.
PROJECTED ARCHITECTURE · NOT ACHIEVED ADOPTION
~90% Reusable enterprise foundation
Shared interactions, logic, components, capability definitions, product structure, common terminology and central improvements.
~10% Meaningful site configuration
Equipment, available signals, vendor systems, terminology, thresholds, controls and physical differences.
The approximate split was a feasibility direction for reducing duplicated implementations. It was not an achieved rollout, adoption result or impact metric.
Scaling capability also required scaling the knowledge around it.
I explored a monitored, question-and-answer community for operational knowledge: find previous solutions, share site learning, explain installation requirements and troubleshooting, and connect recurring problems across facilities.
Teams needed to distinguish a local workaround from a supported capability or approved practice. The concept encountered organizational and product-ownership constraints.
Knowing what happened did not establish who owned it.
Hardware, replacement parts, controls, telemetry, networking, Jetson and vendor software could have different support owners. A knowledge concept placed responsibilities, contacts, escalation paths, documentation, dependencies and site considerations closer to the relevant technology or capability.
If the technology cannot be unified, unify the knowledge around it.
Reusable capability needed a home.
My Hub could include a Solutions / Capability space: what exists, where it is used, what is available here, prerequisites, documentation, support contacts and when Engineering review is required.
The alternative to “copy what I saw at another site” was a supported capability with a clear path to readiness. This remained a product concept.
Three kinds of reuse.
Reusable by default
Same problem, logic and interaction. Build once and improve centrally.
Configurable
One capability with meaningful environmental differences. Share the product; configure the site.
Site-specific
Genuinely different physical or technical conditions. Do not force false standardization.
Consistency is valuable only when the underlying thing is actually consistent.
Evidence → decision → tradeoff
Evidence
Local tools and cross-site requests repeated while copied implementations accumulated modifications.
Decision
Investigate the recurring problem and explore a shared enterprise foundation with explicit site configuration.
Tradeoff
Reuse can reduce duplication. Excessive standardization can erase differences that materially affect the experience.
What moved forward. What remained directional.
Research and local experimentation
Cross-site comparison, recurring feedback, local tools, request investigation and engineering feasibility work. Some successful patterns expanded beyond their first location.
Reusable capability framing
Enterprise versus site configuration, capability readiness, shared knowledge, community, technology ownership and My Hub / Solutions.
A shared product foundation
The projected 90/10 architecture, enterprise repository, formal readiness experience, community platform and comprehensive ownership model.
The growing network and existing patterns are context. They do not establish adoption of the proposed architecture or concepts.
What supported reuse. What made it difficult.
What supported reuse
- Repeated problems and site experimentation.
- Shared product patterns and recurring SME relationships.
- Engineering collaboration and centralized product ownership.
- Network-wide visibility into requests.
What made it difficult
- Equipment, vendors, controls and telemetry differences.
- Network access, integration and site terminology.
- Local modifications and organizational ownership.
- Product boundaries beyond the Jetson team.
The hardest part was defining the boundary between shared and different.
From local success to reusable product capability.
- Observe the workaroundWhat has the team already built or changed?
- Find the underlying problemWhat job is it performing?
- Compare environmentsDoes the same need recur?
- Separate stable from variableWhat repeats? What genuinely changes?
- Validate prerequisitesWhat physical and technical conditions must exist?
- Define the reuse boundaryShared product, configuration, integration or custom implementation?
- Scale the knowledgeHow will the next team adopt, support and troubleshoot it?
Useful anywhere environments are similar enough to share a platform and different enough to break a template.
From original exploration to portfolio prototype
Original exploration
Site requests / local experiments → cross-site comparison → problem synthesis → engineering feasibility → architecture / product concepts.
Current portfolio reconstruction
Recovered patterns → capability model → AI-assisted systems exploration → connected Smart Warehouse prototype.
The current prototype explores a shared enterprise experience. It does not imply that the architecture was completed at Target.