Application Framework and inmation: What the frame delivers, what the platform is not meant to
The question comes up in almost every technical conversation: what can the framework do that inmation cannot? The honest answer is: nothing. Everything the framework does is built with the platform's own means. Why the question still deserves an answer – just a different one than expected.
I like answering this question, because it comes from someone who knows the platform. Whoever asks it has usually built a view already and knows that AspenTech Inmation brings everything necessary. And they are right.
There is no hidden engine in the cts Application Framework and no capability that goes beyond the platform. The frame uses its object model, its interfaces and its web tier. Anyone with enough time and enough developers can produce every single one of its properties themselves. We had that time and those developers, which is why the frame exists.
That exhausts the category of "can" without answering the question that matters in operations. That one reads: how often, by whom, and at what effort per repetition?
Why "can" is the wrong category
An example from another part of our own house. A control cabinet can be designed from scratch and wired by hand for every project. The result works, and an experienced technician does it flawlessly. Yet in our cabinet building we work with proven building blocks and recurring assembly rules.
The reason is not that handwork could not do it. The reason is that handwork does not repeat: every cabinet looks different, every inspection needs fresh attention, every change needs the person who built it. The kit cannot do anything new – it makes the same thing repeatable.
The same holds for views on process data. The difference between a self-built view and one configured from the framework is not in the function. It is in how much the second, fifth and twentieth cost – and who is able to create them.
Both routes lead to the same view. The upper one needs developer capacity and passes through a backlog. The lower one needs process knowledge. That is the whole difference – and it determines how many views a company ends up actually running.
What the standard does not set out to do
A word on the phrasing before the table: "does not set out to" is not the same as "is missing." inmation is built as a data platform, and the points below sit outside that job, and that is a sensible boundary – not a gap in the product.
| Task | In the standard | In the Application Framework |
|---|---|---|
| Creating a view | Build a compilation in code, examples as templates | Select a ready-made compilation and configure it |
| Consistent appearance | To be produced and upheld per view | A default of the frame, not opt-out |
| Authorization | Permissions on data objects and structures | Roles on modules and views, framed around the job |
| Adding a new module | Registered and wired by hand | Detected and wired in |
| Documentation | Maintained and assigned separately | Detected and held at the module |
| Existing in-house work | Stays a standalone piece of software | Brought in, inheriting interface, access, documentation |
| Effort per further view | Stays constant, because each one is new | Drops, because the frame already stands |
Every line in the middle column is doable. The point is the right column: there it is done once and available afterward.
The one property that cannot arise in a self-built setup
There is a point at which the comparison tips – and it has nothing to do with feature scope. Data platforms change: components get recut, parameters renamed, product names shift with ownership. With inmation both are documented: after the acquisition by AspenTech the product carries a new name, and a May 2026 Emerson release recuts it — the product becomes the building block of an "AspenTech Inmation Data Platform".
For self-built compilations, every such change means every view has to be checked and adjusted individually. At four views that is an unpleasant day. At twenty it is a project nobody planned – and it repeats with every major release.
A frame has exactly one place for this. The adjustment to a changed platform happens in the framework, and every view inherits it. This is the only property in this article that a self-built setup does not merely make more expensive, but cannot structurally produce – because it requires a shared location, and distributed one-off views do not have one.
What the frame explicitly does not improve
This section belongs in an article like this, even though it sells badly. A frame around applications does not improve three things, and presenting it otherwise creates disappointment on schedule.
Data quality
A poorly modeled signal does not become correct through a good view, only visibly wrong faster. Whoever has not settled context and naming in the data layer will not settle them in the framework either.
Response times
Performance comes from the data platform and the query, not from the interface. If an analysis is slow today, it stays slow – the frame brings no compute of its own.
Process knowledge
The framework does not know which three values together explain a fault — that decision belongs to the domain team. The frame makes it implementable without replacing it.
Mapping to your plant
Frame and compilations are ready, while mapping them onto your asset structure, your roles and your processes is project work. How much depends on the setup – we estimate that together up front, not afterward.
The questions that matter instead
How many views do we want to be running in three years?
At two or three, a frame does not pay off – then building in-house is the shorter route, and we will say so. From around five the math flips, because maintenance effort exceeds build time. Only the company itself knows that number.
Do we run views as a project or as an operational task?
A project has a start, an end and a budget. An operational task needs someone who can own it permanently. As long as views are code work, they cannot be run as an operational task – regardless of how it is labeled on the org chart.
What is independence from a service provider worth to us?
We ask this deliberately, even though we are the service provider. Every view your team configures itself is an order we do not get. We would rather have a customer who can act than one who has to call about every figure.
Which leaves the original question, and the answer to it is already in the first paragraph: the Application Framework can do nothing that inmation cannot. It makes what the platform enables repeatable and accessible to more people. Whether that is worth the effort does not depend on the technology, but on how often you need it. We are glad to work that math out together – including with the result that in your case it comes out against the frame.
The groundwork is in the other two articles in this series: what the Application Framework is and why integrating inmation alone is not enough.
Let us work the math out for your setup
How many views do you run today, how many do you want to run, and who should maintain them? Those three numbers give you the answer – with or without a frame.
Talk to our specialists
