cts Application Framework: How available data becomes usable applications
Available data is not the same as usable data. Between the two sits a question that rarely gets asked: who in your company is allowed to build a view? As long as the answer is "whoever knows the code," the plant floor stays with its Excel exports. The cts Application Framework moves that line – with ready-made compilations your team configures instead of programming.
When a plant needs a new analysis, it usually travels a detour. Someone in production describes what they want to see, someone in IT turns that into a requirement, and eventually a developer builds a view for it. Weeks pass between the question and the answer, sometimes months — not because the question is hard, but because the route to it is long.
That is odd, given how much effort went into the data layer beforehand. Connectivity, modelling, historization, open interfaces: in many companies that part is done and runs stably, an Industrial Data Fabric is in place, and the data is reachable in real time and with context. Access to it still stops with the people who can write code.
I think our industry measures the wrong thing here, and we are squarely part of that. A data project counts as successful when the data flows — that is an IT yardstick, and by it many projects are finished. Operations applies a different one: how many people can work with this data without having to ask someone first. By that measure the same projects are only beginning.
The gap between those two yardsticks has a specific location. It sits in the layer that shows up in architecture diagrams as a single box labeled "Applications" and that in practice is rarely a product, but a collection of one-off builds. The road to it runs through code.
Where it actually gets stuck: the compilation
Technically, a view in an industrial web interface is an assembly of widgets – a chart, a table, an event list, a form, each bound to specific data points and arranged in a specific layout. In the world of inmation WebStudio, that assembly is called a compilation.
inmation ships compilations, though only as examples and in code form. Anyone who needs their own view therefore works in that code: understand how a compilation is structured, know the widget parameters, wire up the data binding, test the result. That is development work, and it comes due again for every single view.
This shifts something that looks like a technical detail at first glance. The question of who is allowed to build a view turns into the question of who commands the code. In practice that is one or two people in the company – or nobody, and then it gets outsourced.
This is where a widely repeated promise runs out. "Democratize your data" has been the call for years, and at the data layer it has been delivered: open interfaces, documented models, access for anyone who needs it. Except that this democratization stops at the API. An interface is not access for someone who runs a plant. Deliver everything but the last step, and you have released data without creating access.
This is exactly where the cts Application Framework starts. It does not hand over examples for someone to build their own thing from. It delivers ready-made, production-capable compilations. Your team picks one, maps its own data points, and sets the view up. Through a configuration interface, not in the code.
Building compilations from code
The shipped examples serve as templates. Every view that actually goes into production is built from them in-house: understand the structure, set widget parameters, wire the data binding, test. That requires working knowledge of the codebase – and that knowledge has to be rebuilt every time someone leaves.
Configuring ready-made compilations
The views exist and they run. Your team selects the right one, maps its own data points, and adjusts presentation and access. No code access required, no ramp-up on its structure – and therefore no dependency on the one person who understands it.
What your team can do on its own
The real difference is not technical. It is about who in the company becomes able to act — in three places specifically.
The code stays open and readable throughout. Anyone who wants to go deeper can – nobody has to, in order to put a view into production. That is the difference between a closed surface and a framework that leaves both routes open.
Taken together, this is not an efficiency topic but a shift in ownership. People who can set up a view themselves stop formulating requirements and start answering questions. That changes what gets asked on a shift in the first place.
What an application layer has to deliver
Ready-made compilations on their own would only be a collection. To turn them into applications that survive shift operations, you need the frame around them – an application layer. It supplies no domain function. It supplies the properties every domain function needs and that nobody should rebuild per view.
Four of them belong in that frame. They apply to every compilation running inside it, and they cannot be ordered separately.
One consistent interface
Every application appears in your corporate design and with the same interaction logic, so that anyone who knows one view can operate the next. That is not a matter of looks, but the lever for adoption in shift operations.
Roles instead of individual grants
Access hangs on roles, not on people and single views. Changing departments means a new role – not fifteen permissions retrofitted across fifteen applications.
New applications are detected
New modules are found and wired in without anyone maintaining a list. A configuration step that does not exist cannot be forgotten on the fourth module.
Documentation where it is used
Manuals are detected and matched to the application they belong to. No separate document management, no manual assignment, no links that go dead after the next release.
Why self-built compilations do not scale
The obvious route is to build a compilation for every view you need. The first one takes a few days, the second one too, which makes the effort look predictable.
The problem shows up at the fourth or fifth. Not because building gets harder, but because the differences between the views start generating work: different color logic, different time axes, different permission concepts. Anyone who wants to change one of them first has to figure out how it was built.
It is the same pattern as point-to-point integration at the data layer, one floor up and with the same outcome. At the data layer our industry learned this and built integration layers, while at the application layer we are still wiring point to point.
Self-built versus framework
| Criterion | Building compilations from code | Ready-made compilations in the framework |
|---|---|---|
| Who creates a view | A developer who knows the codebase | A domain expert, through configuration |
| Prerequisite | Working knowledge of structure and widget parameters | Knowing your own data points |
| Change to an existing view | A development task, waiting for capacity | A setting, available immediately |
| Interface | Decided again for every view | Consistent, in the corporate design |
| Permissions | Maintained per view | Central, through roles |
| Documentation | A separate system, or none | At the module, assigned automatically |
| Effort per further view | Stays constantly high | Drops, because the frame already stands |
| When someone leaves | Ramp-up on the code comes due again | The configuration stays transferable |
| Existing in-house applications | Stay one-offs | Can be brought in |
Every line in the middle column is doable. The difference sits in the right-hand one: there it is decided once and available afterward.
The three modules cts ships
The cts Application Framework is the application layer to the data layer we build in industrial informatics anyway. In production today it runs on AspenTech Inmation – the industrial data platform we put the fabric core on. The data layer stays unchanged. The framework adds the tier above it.
Three modules are included: Trending for time series and trajectories, Events for messages and events, and Compilations, through which views get assembled and managed. All three come ready-built, and they get configured rather than programmed.
What your team has built stays
The most common objection to a framework is: we already have something. Usually built over years, usually by people who knew exactly what production needed.
Those applications can be brought in rather than replaced: they become part of the same interface, with the same design, the same permission model and the same documentation binding as the shipped modules. Four handwritings become one, without anyone rebuilding four applications.
Why "Application Framework" and not "inmation extension"
We chose the name to be platform-agnostic on purpose. The modules are built so they are not tied to a single platform, and our customers' data platforms keep moving – vendors get acquired, products renamed, components recut — most recently in May 2026, when Emerson made the OT Data Fabric a building block of an "AspenTech Inmation Data Platform". A product name that carries someone else's brand ages with it. So for us the platform sits in the description, not in the name.
One platform is demonstrated so far, and we are evaluating others. As long as no module demonstrably runs on a second one, we will not say it is platform-independent.
The three questions decision-makers should ask
How many people here can create a new view today?
If the answer is "one" or "nobody anymore," the bottleneck is not the data. It is access to the code. Being able to configure compilations instead of programming them spreads that capability across the whole team.
How long does one additional figure in an existing view take us?
If the answer is measured in weeks, the request is not difficult – it is simply sitting in a queue. In a configurable view that is a setting, made by whoever needs it.
What happens when the person who built our views leaves?
Self-built code stays maintainable only as long as its author is reachable. Ready-made compilations stay traceable, because their structure did not emerge project by project – and because the documentation hangs on the view.
Where the value actually shows up
The measurable part is the smaller one, but the more tangible: development effort that disappears for every new view, ramp-up time nobody has to invest in the codebase anymore, and changes that no longer consume developer capacity. Those effects can be estimated as soon as you know how many views are in production today, who built them, and how long a change currently takes.
The larger part is harder to quantify and, in practice, more durable. It shows up when the application stops being worked around on a shift. When maintenance checks at night why a line throttled, instead of asking in the morning. When quality assurance traces a batch without requesting an export. That is not a software effect, but a change in who makes decisions with data.
So we do not treat the application layer as an afterthought to the data layer, but as part of the same job. A data fabric without usable applications is not half a solution – it is a complete solution to a problem the customer did not have. Availability was never the goal. It was the prerequisite.
When the right moment is
The cheapest entry point would be before the third self-built compilation exists — it is almost never used, because the pain is not there yet. The second best is the moment an existing view stops being maintainable: the developer is gone, the requirement has changed, and the change costs more than a rebuild. Consolidating under real pressure does more for adoption, in our experience, than any amount of upfront persuasion.
What does your application layer look like today?
You do not need a brief and you do not need a requirements list. We look at your existing setup and tell you what the framework takes over and what stays project work.
Talk to our specialists
