System Integrators: You Are the Center of the Industrial Universe
The Center of the Industrial Universe
Skkynet’s two founders were control system integrators who ran into a integration problem that software vendors didn’t understand, or just ignored. So they had to create a product to do what they needed.
Not much has changed today except for maybe the speed of creating. Misaligned technology solutions often miss the mark of the actual problem, but we still get the nice sales presentations and bold claims announced daily on social media.
It seems every vendor in industrial automation wants to talk about their technology first. Protocols supported, latency figures, architecture diagrams, feature lists and the very latest AI products or features that will solve all your problems, magically. I understand the instinct — we build technology, we’re proud of it, and it’s the easiest thing to describe because we control every word of the description. In short, we fall in love with our technology and it’s perfect and beautiful in our eyes. But it’s not the center of the industrial universe.
Okay, well, if technology is not the center of the industrial universe, then what is? For the customer, it’s their problem—front and center.
A plant manager doesn’t wake up wanting a unified namespace, a Sparkplug-compliant broker, yet another HMI and set of device drivers, or the latest AI product or future technology buzz words. They wake up with a specific, ugly, expensive problem: a line that’s down, a compliance audit that’s coming, a ransomware attack that costs production and real capital expense, a supply chain that can’t see its own inventory, a merger that just doubled the number of incompatible historian systems they now have to reconcile. The problem comes first. It has a shape, a cost, a deadline, and a set of political constraints inside their organization that no requirements document or spec sheet will ever capture. Technology only matters to the extent that it resolves that specific shape, once installed, configured and customized in the hands of specialist.
So, you have technology on one side of the universe and the customers problem on the other. What’s between them, standing in the center? Who understands the customer’s problem better than the customer? And who understands the technology from the crowded space of technology providers? You do—the System Integrator.
You sit in the middle, between the customer and the technology provider
Here is my, our, core conviction: System integrators fully understand and can explain the problem to all parties, and then combine our technology and their expertise to solve it. We can all fall in love with a problem, but you need a well defined problem statement to really solve it.
Read that again, because the order matters. It is not “System integrators sell our product.” It is not “System integrators implement our product.” It is not “Before we fall in love with our technology we fall in love with the problem.” It is that system integrators sit inside the customer’s world or domain long enough, and close enough, to translate a messy, half-articulated operational problem into a solvable technical requirement — and only then do they reach for a toolkit or a magic wand, of which our technology is one component.
No software or hardware vendor, however well-run or experienced, has this vantage point. We sit too far away from the customers and their problems. We see request-for-proposals, feature comparisons, and win/loss reports. You, the SI, see the control room at 2 a.m. when the line actually goes down. You know the plant engineer who has been burned one too many times by promises from software companies and now trusts almost nothing on a beautiful product slide promising to solve all problems. You experience the real politics between OT and IT, between corporate mandates and plant-floor practicality, between what the budget says and what the machine or process actually needs. That proximity is not a nice-to-have. It is the entire value chain’s most scarce resource, and it cannot be dreamed up by better marketing or a bigger sales team.
This is why I view our whole SI community not as a distribution mechanism, not just an implementor or installer of our technology, but as a distributed sensing and translation network — an extension of our own understanding of the market that we ourselves could never build directly at that resolution. There are three main stakeholders in solving the customers problem: Technology Providers, Customers, and You.
This is not a humility exercise. It’s a strategic claim: the company that understands and articulates the customer’s problem most precisely wins, regardless of whose technology ends up inside the solution. And this is exactly why system integrators are not a channel partner in the conventional, secondary sense. You are our strategic infrastructure. Or, to say it another way, you are the center of the industrial universe.
Three Consequences of Taking This Seriously
If you are genuinely the center of the industrial world, best positioned to interpret the problem and see the technology or tools out there to solve it (along with their architecture, design, implementation, etc…. skillsets), three things follow for how we, a technology company, should behave.
- We have to build tools flexible enough to be someone else’s answer, not just our own.
If your job is to solve a problem that is specific to one plant, one merger, one compliance regime, then our technology has to function as a component in their solution architecture, and not insist on being the whole architecture. This is precisely why an outbound-only, firewall-friendly connectivity model matters more than it looks like it should on a feature comparison. For example, it removes your need to fight the customer’s IT security team just to get an open inbound “secure port” in the OT network to use a product feature. Any technology that wastes your political capital before you can even start solving the real problem is a technology that will lose to a worse one that doesn’t.
- We have to resist the urge to unify everything ourselves.
There is a real temptation in this industry to build a single, centralized platform that claims to solve every layer of the problem — connectivity, modeling, storage, analytics, visualization — and to position that as the value. It’s an understandable instinct, but it inverts the priority. It says, “adopt our worldview” instead of “tell me your problem.” A fractal, composite approach to a unified namespace is a good example too — one that lets each business unit, each site, each SI-led project define its own local structure while still interoperating. This respects the fact that you and the customer, not the platform vendor, is the one who actually know what the local problem requires. Centralization optimizes for the vendor’s narrative. Fragmentable, composite architecture optimizes for the SI’s ability to solve the actual problem in front of them.
- Our go-to-market strategy has to treat System Integrator enablement as a core discipline, not a support function.
If you are the translation layer between customer problems and our technology, then equipping you isn’t a matter of handing over a data sheet and a price list. It means giving you the language you need to diagnose a problem quickly (Preparation), the conviction to communicate why it matters now and to whom (Emotion), and the reason the customer can’t wait (Urgency) . It’s the same P+E+U discipline we ask of our own direct sales organization, because you are actually doing sales work on our behalf, except with far better information than we have. It means providing competitive battlecards that speak your operational language, not our marketing pitch. It means treating your feedback from the field as core market and development research, not anecdote.
Why This Matters More Now
The industrial automation landscape is going through a period where architecture decisions — SaaS transition, post-quantum security requirements, AI enabled bespoke applications or tools, the proliferation of protocols and platforms — are multiplying the number of ways a customer’s problem can be misdiagnosed or misunderstood. In a simpler era, a plant may have had one historian, one protocol, one integrator relationship, and the room for translation error was small. Today, a single manufacturing enterprise might have a dozen legacy systems, three cloud strategies competing internally, and a security mandate that changes the answer to “What’s even allowed here?” every eighteen months.
In that environment, the value of an entity that can walk into that complexity, listen long enough to understand what’s actually broken, and then assemble a working answer from available tools — including ours — goes up, not down.
Vendors who treat you as a strategic member of their overall community, including customers and technology providers, someone that provides problem definitions and translation of customer priorities by industry, verticals, and region—those vendors will out-diagnose, and therefore out-compete, the vendors who treat you as a distribution afterthought. Who would you rather work with?
Closing Conviction
From my side, I’d rather be the company whose technology is trusted enough, flexible enough, and whose value is explained well enough that the best system integrators reach for it first when they’ve finally understood what a customer actually needs — than be the technology company that insists customers understand their technology before they’re willing to hear the customers problem.
It starts with a customer’s problem, and you are the one who explains it to us. Our job is to build something worth handing to them.
