Systems
For controls integrators: the half above the historian
You have the plant relationship, the certifications and the site access. This is the work we do above that line, the work we will never quote on, and how the two fit together.
In short
- We do not do PLC, HMI or SCADA configuration, panel building or commissioning, and we do not quote on them. That is a permanent exclusion rather than a current gap.
- The seam is not that integrators cannot build browser-facing applications. They can, and platform tooling ships exactly that; the seam is what a platform structurally cannot give.
- Those four things are a current language and dependency stack, real automated test and release discipline, identity and audit trails that satisfy an external reviewer, and a failure domain that is not the OT network.
- Consolidation work is the clearest case: welding several plants' historians together produces an application-layer and data-modeling problem on a board deadline, which is a different discipline from the controls work that created it.
- The teaming shape that works is subcontract, with the integrator holding the client relationship. We will work under your name, and we will not approach your client.
This one is addressed to controls and systems integrators rather than to plant owners. If you are reading it because a client has asked you for something that lives above the historian and you are deciding whether to subcontract it, hire for it, or decline it, that is exactly the conversation this is for.
What we will never quote on¶
It is worth putting this first, because it is the part that decides whether the rest is worth reading. We do not do controls work, and we do not intend to start:
- No PLC programming, on any platform.
- No HMI or SCADA configuration.
- No panel design, building or wiring.
- No commissioning, no site acceptance testing, no startup support.
- No safety-instrumented work of any kind.
This is not modesty about a gap we are working on. Those disciplines rest on certifications, on years in specific vendor ecosystems, and on being the firm that answers when a line is down at two in the morning; a moat we are not going to cross and have no ambition to. A software firm that is vague about this boundary is a software firm that turns up on your site next year quoting against you, and you would be right to assume it.
What the seam actually is¶
The version of this pitch you usually hear is that integrators cannot build applications. That is false, and anybody who has shipped a Perspective project knows it is false. Modern platform tooling builds genuine browser-facing operational applications, mobile-first, and there are a great many integrators who do that competently. We are not going to pretend otherwise in order to sell around it.
The real line is not capability, it is what a platform can structurally provide. An application built inside the platform inherits the platform's answers to four questions, and for a long time those answers are fine. They stop being fine at a predictable point:
| Property | What it looks like when it starts to matter |
|---|---|
| A current language and dependency stack | The application needs a library, a protocol or a cryptographic primitive that the embedded runtime does not have, and the roadmap for getting it belongs to the vendor. |
| Automated test and release discipline | The application has become important enough that changing it is frightening, and there is no test suite, no staged environment and no pipeline to make it unfrightening. |
| Identity and audit trails | Somebody outside the plant (a customer, an auditor, a regulator, corporate) needs access or evidence, and the platform's user model was designed for operators on a shared terminal. |
| A separate failure domain | The application is now reachable by people who should never touch the OT network, and its exposure and the control system's exposure need to stop being the same thing. |
None of these means the platform work was wrong. They mean a particular capability has grown out of the platform, and it is usually one capability rather than the whole system.
Where this comes up most¶
Consolidation is the clearest case. When several plants are brought under one owner, the systems that ran them were specified independently, and the request that follows is almost always for reporting across all of them on a deadline that was set in a board meeting. The controls work to get data out of each site is yours. What sits on top (reconciling models that disagree about what a unit of production is, giving people outside each plant a way to see it, and being able to show where a number came from) is an application-layer and data-modeling problem, and it is a different discipline from the one that produced the data.
The others are recognizable from the trigger column above: a customer portal onto plant data, an audit that requires evidence the historian cannot produce, or an operator application that has quietly become the system of record for something and now needs to behave like one.
How teaming works, concretely¶
The arrangement that works is straightforward, and the parts of it that protect you are the ones worth stating plainly:
- You hold the client relationship. We subcontract to you, and we are content to be invisible; we will work under your name and your project management if that is what the account needs.
- We do not approach your client. Not during, not afterwards, and not for the controls work we do not do anyway.
- The scope boundary is written down before anything starts, in both directions: what runs on your side of the line, what runs on ours, and what the interface between them is.
- We will say when the work does not need us. If the honest answer is that this belongs inside the platform you already deploy, that is a cheaper answer for your client and we would rather give it than win a bad project.
- Whatever we build is handed over with its source, its tests and its deployment path, so it is maintainable by you or by anyone you choose.
If that fits something currently on your desk, the contact form reaches an engineer rather than a salesperson, and a first conversation about scope costs nothing.
Related reading
- Strategy5 min read
Low-code, and where the ceiling is
The app the operations manager built is usually the right first move, and the objection to it is almost never that it should not exist. It is what happens at the ceiling, and who is standing under it.
- Strategy4 min read
Should your ERP partner build it?
It is the first question to ask and the one most often skipped. How to tell what a partner will take on, what they will decline, and why the answer is rarely about their ability.
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether what you already have can be made to work.