Integrating inmation: Why flowing data alone creates no value
The connections are live, the data model is in place, the interfaces are documented. From the project's point of view, the integration is complete. From production's point of view, it has not started. Why this gap appears systematically – and why it is not a quality problem in the integration.
There is a moment in data projects I have come to expect. Sign-off is done, the project's own metrics are met: every planned source is connected, the model is consistent, historization runs, the interfaces respond within the agreed time. Solid work, often at considerable effort.
And then someone from operations asks: "So how do I get to the numbers now?"
The question sounds harmless, but it is not. It shows that two parties worked with different definitions of "done" – and both were right. For the integration, done means data flows reliably. For operations, done means someone gets an answer without asking anyone. Between those two states sits work that appears in no integration proposal.
What an integration project actually covers
Before the gap, a word about the work itself. An integration built on AspenTech Inmation is not a configuration exercise. It consists of four blocks, each demanding its own expertise.
Connectivity
Controllers, historians, control systems, databases, legacy equipment with no documented interface. Every source with its own protocol, its own behavior on connection loss, and its own quirks around timestamps.
Modeling and context
"Temp_01" becomes a measurement with an asset reference, a unit and a meaning. This step later determines whether cross-site analysis is possible at all – and it is hard to correct after the fact.
Historization
Retention periods, aggregation, recoverability, traceability for audits. Whatever was not considered here goes missing years later, precisely when it is needed.
Interfaces
Open APIs, database links, connections to ERP, MES and analytics tools. Technically the most visible part – and the point at which the project is usually considered fulfilled.
This is demanding work, and it is necessary — without these four blocks there is nothing to use. The point is therefore not that too little gets delivered, but where the line is drawn.
Why the line sits where it sits
The obvious explanation would be convenience on the supplier side, and that is not the case, at least not as a rule. The line has a substantive reason: to its left is data engineering, to its right is application design. Those are two disciplines.
Someone building a data model consistently across four sites thinks in structures, time series and consistency rules. Someone designing a view for the night shift thinks in visual scanning, misoperation, and the question of what has to be recognizable at a glance at three in the morning. Both are demanding tasks, and they rarely live in the same person.
Historically the split also made sense. Views used to come out of the control system and were part of that delivery. As the data layer emerged as a separate tier, that responsibility was quietly orphaned. It was not abolished – it was assigned to nobody.
Three things an integration cannot deliver
These are not services you could have ordered along with it. They are properties that cannot come into existence at the data layer at all, because they only exist in the application.
The third point comes up least often in project reviews and weighs most in operations. How it gets solved technically – through ready-made, configurable compilations instead of self-built ones – is covered in the first article in this series.
The second project nobody planned
What sits beyond the project boundary does not disappear. It only gets paid for later, out of a different budget, and usually without the name that would fit.
Typically it goes like this: after go-live somebody on the team builds a first view, because it is needed. It works. Six months later there are four of them, built by two or three people, each assembled differently. Then one person is out, one requirement changes, and the change takes longer than the original build. At that moment a second project begins – except it is not called that. It is called "cleaning up."
That effort appears in no investment case. It spreads across running capacity, across overtime, and across service requests that each look small on their own. Which is exactly why it never gets managed.
Three questions that show whether the gap exists
How many Excel exports do we run out of a system that delivers real-time data?
This is the most reliable indicator I know of, and it costs nothing. Every one of those exports is a view someone needed and did not get. The number appears in no report, but any department head can estimate it in five minutes.
How long was it between sign-off on our data layer and its first use by an operator?
Weeks means the application layer worked. Months – or an unanswerable question – means the work sat beyond the project boundary and was improvised afterward.
Did our integration scope say who owns the views?
Most contracts say nothing about it – ours did not either, in earlier years. Asking this before the next project is the cheapest possible moment to ask it.
What the integration delivers, what operations needs
| Subject | Result of the integration | Requirement of operations |
|---|---|---|
| Data access | Open interface, documented | A view that works without explanation |
| Context | Measurement with asset reference and unit | The three values that together make a statement |
| Authorization | Permissions on data points and objects | Roles that match an actual job in operations |
| Documentation | System documentation for IT | Instructions on the screen where the work happens |
| Change | Adjustment to the model or the interface | One more figure in an existing view |
| Who acts | Data team or service provider | Whoever has the question, when they have it |
| Definition of "done" | Data flows reliably | Someone works with it without asking |
The left column is delivered, it is simply not the right one — and no improvement in the left brings the right any closer. A faster API does not turn an interface into a view.
How we approach this differently now
We moved our own project boundary, not as a courtesy, but because the old line capped the effect of our own work. A data layer nobody uses is not a successful project to us, even when it passed sign-off.
The application layer is in scope
Before the project we settle who needs which views and who maintains them later. That question costs an hour up front and decides the impact of the entire investment.
Ready-made compilations instead of code templates
The cts Application Framework delivers production-capable views your team configures. That puts maintenance where the process knowledge is – and not with us.
Existing work is brought in
Whatever was self-built after an earlier project does not get replaced. It moves into the same frame and inherits interface, permissions and documentation binding.
What we do not promise
The frame and the compilations are ready, while mapping them to your assets, roles and processes is project work. How much depends on the setup – we estimate that together up front, not afterward.
The uncomfortable version of this finding: as an industry we spent years delivering data layers and leaving the question of who works with them to the customer. Formally that was correct. Useful it was not. Anyone putting an integration out to tender today should tender the application layer with it – and anyone offering one should offer it with it.
Data layer in place – and the use missing?
You do not need a brief. We look at what is already running and tell you which stretch between your data layer and operations is still open.
Talk to our specialists
