Skip to content
willowark

One trustworthy view of your data, no matter how many systems produce it

Data integration consolidates information scattered across databases, historians, SaaS platforms, and spreadsheets into consistent, queryable form. It removes the Monday-morning problem: three reports that should agree and do not, and an hour of arguing about whose number is right before anyone can discuss what the number means.

Willowark begins with data archaeology — profiling what each source actually contains, not what its documentation claims. Part numbers formatted three ways, timestamps in mixed time zones, a status field whose meaning changed in 2019: these discoveries drive the design. From there we define explicit mappings and validation rules, and build pipelines that move data on a schedule or in near real time, with every transformation written down and testable.

Illustrative: a plant floor dashboard on a wall-mounted TV beside production equipmentSystems Integration

How the work gets done

The same way every time: scope, build, hand over.

The engineering involves ETL or ELT pipelines built on tools fitted to your stack — SQL-centric transformation, Python services, or streaming pipelines where latency matters — landing in a warehouse or operational store your reporting tools can reach. Schema mapping is the heart of it: reconciling keys across systems, deduplicating entities, converting units, and encoding business rules like which system wins when two sources disagree. Manufacturing data adds its own texture: historian time series that must align with transactional lot records, shift calendars, and machine states that need interpolating onto production events.

In production, pipelines run under orchestration with lineage and freshness monitoring: you can see when each dataset last updated and trace any value to its source. Data quality checks — row counts, referential integrity, out-of-range detection — run on every load and fail loudly rather than passing bad data through. Success is measured in report reconciliation time going to zero and decisions being argued on interpretation instead of arithmetic.

Before pipelines are built, discovery produces an integration map: every source system, the datasets that leave it, the destination they land in, the refresh cadence, and the person who owns the data on each side. That last column matters most. A pipeline without a named owner for its source becomes an orphan the first time a schema changes. Where a source is a vendor-managed SaaS or a locked-down application, we extract only through the interfaces the vendor supports — APIs, scheduled exports, read replicas — so nothing we do jeopardizes their support or their upgrade path.

Each pipeline is tested on its own before being trusted in a report. Extractions are reconciled against source-system counts, transformations are unit tested against hand-verified examples, and the landed data is compared with the report your team already believes. Cutover is phased: new datasets run in parallel with the existing reporting until the numbers agree or the disagreements are explained, and only then does the old process stop. Rollback is simply reverting to the previous report while the pipeline is fixed. The delivered documentation lists every feed, its schedule, its checks, and who to call when one fails.

  1. Scope it in writing

    What we agree before work starts

    • Source system data profile and quality assessment
    • Documented schema mappings with business rules and conflict resolution
  2. Build with checkpoints

    Working results, not slide decks

    • Automated ETL/ELT pipelines with orchestration and scheduling
    • Data quality checks with alerting on failures
  3. Hand over something you own

    Documentation, source, and training

    • Warehouse or reporting layer structured for your BI tools
    • Phased cutover plan with parallel-run reconciliation and per-feed ownership register

Sound familiar?

Where data integration earns its keep.

Production counts from the historian that never quite match shipment counts from the ERP

A merger that left two ERPs, two item masters, and one management team needing one report

Quality lab results in Excel that should join lot records in the MES automatically

A capacity planning model that needs machine states, orders, and staffing from three separate systems

Common questions

Asked before every data integration project.

Do we need a data warehouse, or can we integrate directly between systems?

For one or two point connections, direct integration is fine. A warehouse or central store earns its cost when several systems feed shared reporting, because it gives you one place to enforce definitions and quality rules instead of re-fighting them in every connection. We recommend based on your actual query and reporting patterns, not by default.

How do you handle the data quality problems you find in our source systems?

We surface them rather than silently patching them. Systematic issues get documented transformation rules; genuine errors get flagged back to the owning system for correction, because fixing data downstream while the source stays wrong just creates a fourth version of the truth. The profiling report early in the project sets that agenda.

Can the integrated data update in real time?

It can, but real time costs more than hourly, and hourly costs more than nightly, so we ask what decision the data feeds. Line-status dashboards justify streaming; financial reconciliation rarely does. Most projects land on a mix, with a fast path for the handful of datasets where minutes matter.

Can you work with our existing BI tool, or do we need a new one?

We work with what you have whenever it can do the job. The integration layer lands clean, documented tables that Power BI, Tableau, Grafana, or a plain SQL client can read, so the reporting tool is a separate decision from the pipeline work. If your current tool is genuinely the bottleneck we will say so, but replacing it is rarely the first problem to solve — most reporting frustrations trace back to the data underneath it.

How do you handle sensitive or regulated data in the pipelines?

By treating it as a design constraint from the first conversation. We identify which fields are sensitive during profiling, then apply the appropriate handling — masking, tokenization, restricted schemas, encrypted transport and storage, access logs — so that only the people who need a field can see it. Where you operate under a specific regulatory framework, we design to its requirements and document how each control is met, so your compliance reviewers have something concrete to examine rather than our assurance.

Where this sits

Data Integration, inside a systems integration system.

The lit component is the part of the system this service delivers; the rest is what it has to work with.

Four systems behaving as oneserialRESTRESTSQLRESTLegacy machineserialERPVision cellIntegration layerthe seamUnified dataPeopledashboards, alerts

Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.

A legacy machine, an ERP, a vision cell and a quality database are joined by an integration layer so the data exists once and the people who need it see it.

Components:

  1. Legacy machine (serial): A 1998 controller with an RS-232 port and no documentation.
  2. ERP: Orders, inventory, costing.
  3. Vision cell: Inspection results per part.
  4. Integration layer (the seam): Translates, validates, and stores once. This is the work.
  5. Unified data: One record per part, per order, per event.
  6. People (dashboards, alerts): Production, quality and the office see the same numbers.

Connections:

  • Legacy machine to Integration layer over serial
  • ERP to Integration layer over REST, both directions
  • Vision cell to Integration layer over REST
  • Integration layer to Unified data over SQL
  • Unified data to People over REST
A typical architecture, drawn to explain the pattern — not a specific client's system.

Strategy. Software. Systems.

Have a system that should exist?

Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.