What a Systems Integrator Actually Does (and When You Need One)

A systems integrator designs, builds, and commissions the connections between equipment, software, and networks that were never designed to work together, and takes single-point responsibility for the result behaving as one system. You need one when a project crosses vendor boundaries: when PLC data has to land in a database, a vision system has to talk to the line, or a new machine has to feed the ERP, and no single supplier owns the whole path. The equipment vendors each own their box. The systems integrator owns the space between the boxes, which is where most projects actually fail.

What does a systems integrator actually do?

The visible work varies by project, but the core scope is consistent. An integrator captures requirements from operations, maintenance, and management, who usually want three different things. They design the control and data architecture. They specify or build panels, program PLCs and HMIs, configure networking across the plant floor, and write the software glue that moves data between machines, historians, databases, and business systems. Then they commission it, document it, and train the people who'll live with it.

Notice how much of that list isn't programming. Requirements, architecture, documentation, and training routinely consume half of a well-run integration project, and they're the half that determines whether the system survives its first staffing change.

The real product, though, is accountability. When a bought-and-bolted-together system fails, the machine builder blames the network, the network vendor blames the software, and the software vendor blames the machine. An integrator signs up to own the outcome across all of it. You get one phone number, and the arguments happen on the other side of it.

The anatomy of a well-run integration project

Good integrators run a recognizable process, and it's worth knowing the shape so you can spot when it's missing.

It starts with a user requirements specification, even a short one: what the system must do, stated in the plant's language. From that comes a functional design specification, which says how the system will do it, in enough detail to be testable. If the URS says "track scrap by shift," the FDS says which signals define a scrap event, where the count lives, and what the report looks like. Arguments about the FDS are cheap. The same arguments during commissioning are not.

Then a statement of work with milestones that map to real gates: design approval, a factory acceptance test where the system runs against simulated I/O before anyone ships it, installation, a site acceptance test on the real line, and punch-list closure. Payments tie to those gates. If an integrator doesn't want a FAT, ask why. Simulating the line in the shop is how you find the logic bugs somewhere other than your production floor at 2 a.m.

The final deliverables should include as-built drawings, commented code, backups, and an operator-level runbook. A system without documentation isn't finished. It's just running.

When do you need a systems integrator?

A few reliable signals.

Two or more vendors are pointing at each other. If a problem has survived three vendor support calls because it lives between their products, it's an integration problem by definition.

Your data is trapped. The machines know cycle times, fault codes, and counts, and your decisions still run on clipboards and month-old spreadsheets. Getting machine data into a usable database is bread-and-butter integrator work.

The machine builder stops at the panel. Plenty of excellent OEMs deliver a machine with great controls and no interest in your ERP, your historian, or your quality system. Someone has to own that last mile.

You're expanding brownfield. New equipment has to cooperate with a 15-year-old line, a legacy SCADA package, and an IT department that has never seen the plant network. That collision of old and new, and of OT and IT, is exactly the terrain integrators work.

And the honest inverse: you probably don't need an integrator for a single machine from a single OEM with good support and no connections to anything else. Don't buy integration where there's nothing to integrate.

Where integration projects go wrong

The recurring failure modes are boringly predictable, which is good news, because predictable risks can be priced and managed.

As-built drawings that aren't. Brownfield plants accumulate a decade of undocumented changes, and the panel never matches the print. Undocumented legacy logic is worse: nobody remembers why rung 400 exists, and it turns out to be load-bearing. The mitigation is a paid discovery phase before the fixed bid, so surprises get found at study prices instead of change-order prices.

The IT/OT gap. IT wants patches, credentials, and network segmentation. Operations wants nothing touched that's currently running. Both are right, and a project that hasn't planned for that negotiation will stall in the middle of it.

And the most expensive one: no acceptance criteria. Without a testable definition of done, commissioning never ends, the punch list becomes a lifestyle, and the relationship sours on both sides. This is a document problem, and it's fixable before the PO is cut.

How to choose an integrator

Judge integrators less by their answers and more by their questions. A good one asks about failure modes, about who maintains the system after handoff, about your electricians' comfort with the platform, about who actually consumes the data downstream. An integrator who quotes without a site walk, or whose proposal lists no documentation deliverables, is telling you how the project will end.

Ask for specifics on your stack. "We do everything" is not experience with your PLC platform, your SCADA package, and your database. And note that the best integrators are honest about edges: strong shops routinely partner for out-of-discipline scope like cloud, vision, and application software rather than improvising it, a model covered in Overflow Engineering for Integrators.

Willowark's systems integration practice sits deliberately across that OT/IT boundary, covering the controls side and the software, database, and cloud infrastructure side under one roof, because the gap between them is where projects go to die.

FAQ

What's the difference between a systems integrator and a machine builder?

A machine builder designs and delivers a machine, including its controls, and their responsibility typically ends at the machine's panel. A systems integrator connects machines, software, networks, and business systems into one working whole, and takes responsibility for the connections. Many projects need both, with the integrator owning everything between the boxes.

How much does systems integration cost?

Small, well-defined projects, such as connecting a handful of machines to a database with basic dashboards, typically start in the tens of thousands of dollars. Line-level or plant-level projects run into six figures. The biggest cost driver is usually discovery: undocumented brownfield systems make everything more expensive, which is why a paid assessment phase before a fixed bid tends to lower the total.

How long does a typical integration project take?

A focused data-collection or machine-connectivity project typically runs six to twelve weeks from kickoff to site acceptance. Larger multi-system projects run six months or more, usually gated by equipment lead times and production windows for commissioning rather than by engineering hours.

Do systems integrators work on software, or just controls?

It varies widely, and it's worth asking directly. Traditional integrators are strongest on PLCs, HMIs, and SCADA; the database, cloud, and application layers are a separate skill set that some shops carry in-house, some subcontract, and some quietly improvise. If your project's value lives in the data, make sure someone on the project genuinely owns the software side.

If you've got a project stuck between vendors, or machine data you can't get to, that's integrator territory, and scoping it usually takes one conversation and a site walk. Willowark takes on integration work under flexible engagement models, from assessments to full projects. Contact us and tell us what's not talking to what.