How to Connect Disparate Systems Without Disrupting What Already Works
A leading upstream operator in the Western Anadarko Basin had spent over a decade building a sophisticated operational infrastructure. The SCADA landscape spanned multiple vendors. Production accounting ran through Aries. Equipment maintenance tracked through a CMMS. Routing and spatial context lived in GIS. By any measure, this was a world-class technology foundation.
But the systems didn't talk to each other. Data flowed in isolated streams. A SCADA telemetry point lived in its vendor's historian. Production forecasts lived in Aries. Work orders lived in the CMMS. GIS had route data but no operational context. The operator had invested millions in these individual systems, but the investment was fragmented.
This fragmentation had a direct cost: the operator couldn't answer the simplest but most important question in field operations: "What should we work on right now?" The answer required manual synthesis—pulling data from multiple systems, building context in spreadsheets, and making subjective decisions based on incomplete pictures.
The problem wasn't data collection. The problem was data integration. And the solution had to be non-invasive—WorkSync couldn't disrupt SCADA operations or replace existing systems. It had to sit alongside them, read from them, and contextualize their data into operational intelligence.
The Technical Challenge
The operator's SCADA environment was typical of mature upstream fields: heterogeneous, distributed, and evolved organically over decades.
Multiple SCADA vendors had been deployed across different regions and facility clusters. Some sites ran traditional SCADA with local historians. Others used cloud-based telemetry platforms. The data formats, collection intervals, and quality varied. One historian logged data at 5-minute intervals; another at 15 minutes. Some measurements used field-standard units (e.g., tank level in barrels); others in metric. Alarm definitions differed by site. Data quality issues (sensor drift, missing values, outlier noise) were location-specific.
On top of SCADA, the operator ran Aries for production accounting and forecasting. Aries models well decline curves, estimates future production, and computes cash flow forecasts based on commodity pricing. These forecasts were the gold standard for economics—but they operated independently. A SCADA anomaly that foreshadowed actual underperformance wouldn't surface until Aries recalculation happened hours or days later.
The CMMS (maintenance management system) tracked equipment history, failure codes, and work orders. But it had no real-time connection to SCADA. A compressor failure prediction from a machine learning model trained on SCADA vibration data would never reach the CMMS workflow that could schedule preventive maintenance.
GIS systems held route data, private road maps, and spatial asset information—invaluable for routing optimization. But GIS data was static, uploaded quarterly. It had no dynamic context. A well marked as "visitable" in GIS might actually be inaccessible due to weather or a recent equipment issue. But GIS wouldn't know that.
Solving this integration challenge required a different approach than traditional enterprise integration. The operator couldn't afford to:
- Disrupt SCADA operations. These systems run 24/7, monitoring critical infrastructure. Any disruption has production consequences.
- Mandate system replacements. The existing SCADA vendors, Aries, CMMS, and GIS platforms were performing their core functions adequately. Rip-and-replace would take years and billions of dollars.
- Build custom integration for every vendor. New SCADA versions, Aries updates, or GIS platform migrations would require constant rework.
The solution had to be read-only, non-invasive, and vendor-agnostic.
The Approach: Intelligence Layer Architecture
WorkSync was deployed as an intelligence layer—sitting above existing systems, reading from them, and synthesizing their data into a common operational language.
Real-Time Telemetry Ingestion
SCADA integration began with the principle that WorkSync reads from SCADA; SCADA never reads from WorkSync. This one-directional dependency ensured zero risk to production monitoring.
For sites running cloud-based SCADA platforms, WorkSync connected via REST APIs and consumed telemetry streams directly. For legacy historians with MQTT brokers, WorkSync subscribed to published streams. OPC UA connections (a standard in industrial automation) provided access to local servers at sites where cloud integration wasn't feasible.
Data normalization happened immediately upon ingestion. A pressure reading at 5-minute intervals from one site, and 15-minute intervals from another, were time-aligned. Unit conversions were applied (PSI to bar, barrels to cubic meters). Outliers were flagged. Missing values were interpolated. The result was a canonical telemetry stream—consistent, time-synchronized, and quality-controlled—flowing into the data platform.
This architecture respected existing SCADA deployment models. A site running a specific vendor's system didn't have to change anything. WorkSync simply connected to the telemetry interface that was already there.
Production Forecast Integration
Aries forecasts were pulled daily via REST APIs. The system read:
- Well-level production projections (oil, gas, water)
- Economic assumptions (commodity prices, lifting costs)
- Decline curve parameters and confidence intervals
Rather than using these forecasts in isolation, WorkSync compared them against real-time SCADA trending. A well's 48-hour SCADA trend was extrapolated using regression analysis. If this short-term trend deviated from the Aries forecast, the delta was computed. A well expected to produce 100 barrels but trending at 85 barrels represented a $3,000/day cash flow loss (at $150/bbl). This cash flow delta became the foundation of economic prioritization.
This hybrid approach—combining statistical short-term trending with financial long-term forecasting—gave the system both immediate responsiveness and economic grounding.
Maintenance and Work Order Contextualization
CMMS work orders were ingested as structured events. Each work order carried metadata: equipment type, failure code, priority classification, assigned crew, estimated duration, cost. WorkSync correlated these work orders with SCADA data and asset metadata.
A compressor repair work order could be cross-referenced against:
- SCADA vibration data leading up to the failure
- Historical failure patterns for that equipment type
- Production impact of the compressor being down
- Liquid management impact (tank fill rates change when a compressor is offline)
This contextualization transformed work orders from administrative records into operational intelligence. Priorities could be recalibrated based on downstream impacts that the work order system itself couldn't see.
Spatial Data and Dynamic Routing
GIS data—well locations, private road maps, facility coordinates, accessibility information—was imported and maintained as geographic layers. But static GIS data wasn't enough. Real-time operational context made routes dynamic.
A well marked as visitable in GIS might be temporally inaccessible due to:
- Recent weather (flooding that made private roads impassable)
- Equipment issues (a downed power line, a flooded tank farm area)
- Regulatory constraints (a permit that expired, a zoning restriction during certain hours)
- Schedule constraints (another crew already there, a facility planned shutdown)
WorkSync maintained a dynamic accessibility layer that merged GIS static data with real-time operational status. Route optimization algorithms could then use this current view rather than yesterday's map.
Data Normalization and the Unified Data Model
The most critical technical achievement was establishing a unified data model that allowed heterogeneous sources to be queried as a single system.
The model was organized around five core dimensions:
1. Production Telemetry (Real-Time and Historical)
- 5-minute to hourly SCADA measurements (pressures, temperatures, rates, volumes)
- Curated for consistency, quality, and time-alignment
- Stored with full historical depth for trend analysis
2. Economic Forecasts
- Aries well-level projections
- Commodity price assumptions
- Cash flow deltas (actual trending vs. forecast)
- Confidence intervals and sensitivity ranges
3. Asset Metadata
- Equipment inventory (compressors, pumps, meters, separators)
- Component relationships and dependencies
- Operational status (online, offline, maintenance mode)
- Design specifications and performance baselines
4. Spatial Context
- Well locations and facility coordinates
- Private road networks and drive-time matrices
- Accessibility constraints and seasonal variations
- Route history and crew-specific patterns
5. Task and Work History
- CMMS work orders and completion records
- Field crew notes and real-time updates
- Outcomes and resolution times
- Equipment failure codes and patterns
This multidimensional model enabled contextualized queries that no single source system could answer:
- "Which wells have had <5% forecast variance for 14 days and now show early deviation signals?" (Combines Aries forecasts, SCADA trending, and statistical pattern detection)
- "What's the production impact if the compressor at Facility A goes offline and can't be repaired for 48 hours?" (Connects equipment status, downstream production impact, facility topology)
- "Which high-priority wells are geographically unreachable today?" (Merges priority scores, GIS accessibility, and real-time weather/status constraints)
These weren't questions any single system could answer alone. But with unified data, they became simple queries.
Non-Invasive Deployment: Zero Production Risk
The deployment strategy emphasized risk minimization. The operator had no appetite for SCADA disruption. The implementation plan reflected this.
Week 1-2: Read-Only Integration WorkSync connected to SCADA, Aries, CMMS, and GIS APIs in read-only mode. No writes to any system. Telemetry flowed in. If any connection failed, WorkSync gracefully degraded—losing that data stream but not disrupting the source system.
Week 3-4: Data Validation The ingested data was validated against known baselines. SCADA pressure readings were compared against historical ranges. Aries forecast updates were checked for sudden shifts. GIS spatial data was validated for completeness. Any anomalies were logged for review, but no corrective action was taken—the source systems remained the source of truth.
Week 5-8: Intelligent Processing Once data validation passed, processing pipelines were activated. Regression trending, cash flow delta computation, and route optimization ran against the unified data model. The output—daily priorities and routes—were generated but initially used only for analysis, not operational direction.
Week 9-12: Operational Rollout Only after operators and engineers verified that the prioritization and routing logic made operational sense did live deployment occur. The 6:00 AM mobile app was activated. Operators began using prioritized routes. But at this stage, if something went wrong, a supervisor could override the system recommendation and fall back to manual scheduling. The system was advisory, not mandatory.
By week 12, confidence was sufficient that override rates dropped below 5%. The system had become the primary operational orchestrator—but only after proof of concept and operator buy-in.
This phased approach meant that even if the data integration had surfaced unexpected issues, the operator would have caught them before they impacted field execution. In practice, none arose—but the structure existed to handle them safely.
Technical Specifications and Scalability
The integration architecture was designed for scale and resilience.
Real-Time Data Ingestion
- MQTT brokers: 50,000+ messages/second capacity per node
- OPC UA connections: 100+ simultaneous client connections per gateway
- REST API polling: 10,000+ endpoints at 5-minute intervals
- Cumulative: 2+ million telemetry data points daily ingested and time-aligned
Data Processing Pipeline
- Stream processing: Apache Kafka for pub/sub message distribution
- Batch processing: Nightly model retraining on 90+ days of historical data
- Latency: <3 minutes from SCADA update to prioritization recalculation
- Downtime: <0.1% (99.9% availability SLA)
Data Storage and Querying
- Time-series database: 100+ TB capacity, optimized for dimensional queries
- Retention: 24 months hot storage, 7 years cold storage
- Query performance: <500ms response for 14-day look-back queries across 1,800 wells
Security and Compliance
- API authentication: OAuth 2.0 with token rotation
- Data in transit: TLS 1.3 encryption
- Data at rest: AES-256 encryption
- Access control: Role-based permissions by asset and function (operators, engineers, supervisors, executives)
- Audit logging: All data access and modifications logged for compliance review
Deployment Model
- Hybrid: Cloud-native core with edge gateways for low-connectivity sites
- Flexibility: Customers run on AWS, Azure, private cloud, or on-premises infrastructure
- Scaling: Horizontal scaling—adding nodes increases capacity without system redesign
Operational Outcomes from Technical Excellence
The technical architecture directly enabled the operational results reported in the case study.
Real-Time Responsiveness: Because SCADA data flowed in at 5-minute intervals and prioritization recalculated every night, field teams always had current context. A well's status change at 3 AM would be reflected in the 6:00 AM route.
Forecast Accuracy: By comparing short-term SCADA trending against long-term financial forecasts, the system identified wells whose economics had changed materially but not yet surfaced in formal accounting processes. This enabled faster corrective action.
Route Optimization Precision: The unified data model meant route optimization could account for real-time accessibility, equipment constraints, crew expertise, and liquid management urgency simultaneously. Single-optimization algorithms that optimized only for drive time without economic or operational context would have generated inferior routes.
Scalability Without Fragility: The modular architecture meant that if one SCADA vendor's API changed, only the connector for that vendor needed updating. The rest of the system remained unaffected. This prevented the typical enterprise integration problem: each system update cascading into months of rework.
Key Technical Learnings
1. Read-Only Integration Eliminates Risk The decision to read from existing systems rather than write to them or replace them was foundational. It enabled the operator to adopt the system incrementally, with clear rollback paths at every stage.
2. Data Normalization Is 60% of the Work The technical effort split roughly as: 60% on normalization and quality assurance, 20% on processing and optimization algorithms, 20% on mobile application and UX. The unsexy work of making disparate data sources speak a common language was the highest-value activity.
3. Modular Processing Pipelines Accelerate Iteration Because cash flow delta computation, risk scoring, and route optimization were independent modules, enhancements could be deployed without full system retest. A new risk scoring formula could be deployed while route optimization continued running unchanged. This agility shortened feedback loops from months to days.
4. Hybrid Stream/Batch Processing Balances Latency and Accuracy Real-time stream processing (MQTT, OPC UA, REST polling) provided sub-minute responsiveness. Nightly batch processing (Aries forecast reconciliation, machine learning model retraining, 90-day trend analysis) ensured accuracy and long-term learning. Neither alone would have been sufficient.
5. Security-by-Design Doesn't Compromise Speed OAuth 2.0 authentication, TLS encryption, and AES-256 data at rest were implemented from day one, not retrofitted. This required upfront design investment but prevented the typical pattern where security becomes an afterthought.
Making the $10M SCADA Investment Actionable
The operator had invested substantial capital in SCADA, Aries, CMMS, and GIS over the previous decade. These systems were performing their designed functions—collecting data, managing maintenance, tracking financials, providing spatial context.
WorkSync didn't deprecate these investments. It completed them. It answered the question that no individual system had been designed to answer: "Given all this data, what should the field team work on right now?"
By connecting the investments into a unified intelligence layer, the operator transformed infrastructure investments from data collection tools into operational decision engines. The result was 15% cash flow improvement not through new capital deployment, but through better utilization of the intelligence already embedded in the systems they'd already built.
The Unified Namespace Principle
The architecture WorkSync deployed in the Western Anadarko Basin reflects an emerging industry principle: the Unified Namespace (UNS).
Historically, operational technology (OT) and information technology (IT) systems developed separately. SCADA lived in the OT domain—real-time, deterministic, vendor-specific. ERP, forecasting, and business intelligence lived in the IT domain—asynchronous, eventually consistent, cloud-native. They rarely talked.
WorkSync bridges this gap by establishing a common operational language—a unified namespace where:
- SCADA telemetry is contextualized with financial forecasts
- Equipment status is visible to work order systems
- Spatial data is dynamic and responsive to operational state
- All perspectives (production, maintenance, financial, spatial) are accessible to decision engines
This pattern—read from OT systems without disrupting them, normalize into a unified model, synthesize into actionable intelligence—is increasingly the standard architecture for industrial operations. It respects the purpose-built nature of existing systems while unlocking their collective power.
Building on This Foundation
The operator is now planning Phase 2 expansion, which will extend the unified data model to include:
- Artificial lift optimization data (pump-off controller status, motor performance, lift efficiency metrics)
- Chemical injection systems (corrosion inhibitor and demulsifier volumes, injection rates, cost per barrel treated)
- Facility throughput data (separator capacity utilization, processing bottlenecks, export-constraint flags)
Each of these will be integrated the same way as SCADA and Aries: read-only, normalized into the unified model, contextualized into prioritization. The incremental expansion of the data model compounds the value of the intelligence layer.
How Organizations Can Replicate This Approach
If your operation has substantial investment in SCADA, production accounting, maintenance management, and GIS systems but hasn't connected them into a unified intelligence layer, the opportunity is immediate and significant.
The technical requirements are modest: read-only API access to each source system, basic data normalization, and a cloud-based processing platform. The bottleneck is rarely technical—it's organizational: deciding to move from independent system optimization to integrated operational intelligence.
Let's talk about how to make your operational data stack actionable.
