cts Application Framework: Wie aus verfügbaren Daten nutzbare Anwendungen werden
Verfügbare Daten sind nicht dasselbe wie nutzbare Daten. Zwischen beiden steht eine Frage, die selten gestellt wird: Wer im Unternehmen darf eine Ansicht bauen? Solange die Antwort „wer den Code beherrscht" lautet, bleibt die Produktion bei ihren Excel-Exporten. Das cts Application Framework verschiebt diese Grenze – mit fertigen Compilations, die das Team konfiguriert statt programmiert.
Wenn in einem Werk eine neue Auswertung gebraucht wird, läuft das in den meisten Fällen über einen Umweg. Jemand aus der Produktion beschreibt, was er sehen will, jemand aus der IT übersetzt das in eine Anforderung, und irgendwann baut ein Entwickler eine Ansicht dafür. Zwischen der Frage und der Antwort liegen Wochen, manchmal Monate — nicht weil die Frage schwierig wäre, sondern weil der Weg dorthin so lang ist.
Das ist insofern merkwürdig, als zuvor erheblicher Aufwand in die Datenschicht geflossen ist. Anbindung, Modellierung, Historisierung, offene Schnittstellen: In vielen Unternehmen ist dieser Teil inzwischen erledigt und läuft stabil, eine Industrial Data Fabric steht, die Daten sind in Echtzeit und mit Kontext abrufbar. Der Zugang zu ihnen endet trotzdem bei denen, die programmieren können.
Ich glaube, dass wir als Branche an dieser Stelle das Falsche messen, und wir gehören ausdrücklich dazu. Ein Datenprojekt gilt als erfolgreich, wenn die Daten fließen — das ist ein Maßstab aus der IT, und nach ihm sind viele Projekte abgeschlossen. Die Produktion legt einen anderen an: Wie viele Leute können mit diesen Daten arbeiten, ohne vorher jemanden fragen zu müssen. Nach diesem Maßstab fangen dieselben Projekte gerade erst an.
Die Lücke zwischen beiden Maßstäben hat einen konkreten Ort. Sie sitzt in der Schicht, die in Architekturdiagrammen als ein Kasten mit der Aufschrift „Anwendungen" auftaucht und die in der Praxis selten ein Produkt ist, sondern eine Sammlung von Einzelentwicklungen. Der Weg dorthin führt durch den Code.
Wo es tatsächlich hängt: die Compilation
Eine Ansicht in einer industriellen Weboberfläche ist technisch eine Zusammenstellung von Widgets – ein Chart, eine Tabelle, eine Meldungsliste, ein Formular, jeweils an bestimmte Datenpunkte gebunden und in einem bestimmten Layout angeordnet. In der Welt von inmation WebStudio heißt so eine Zusammenstellung Compilation.
inmation liefert Compilations mit, allerdings als Beispiele und in Codeform. Wer eine eigene Ansicht braucht, arbeitet deshalb in diesem Code: Er muss die Struktur einer Compilation verstehen, die Parameter der Widgets kennen, die Datenbindung selbst herstellen und das Ergebnis testen. Das ist Entwicklungsarbeit, und sie fällt für jede Ansicht erneut an.
Damit verschiebt sich etwas, das auf den ersten Blick wie ein technisches Detail aussieht: Die Frage, wer eine Ansicht bauen darf, wird zu der Frage, wer den Code beherrscht. In der Praxis sind das ein oder zwei Personen im Unternehmen – oder niemand, und dann wird es beauftragt.
An dieser Stelle läuft ein verbreitetes Versprechen ins Leere. „Daten demokratisieren" wird seit Jahren gefordert, und auf der Datenebene ist es eingelöst: offene Schnittstellen, dokumentierte Modelle, Zugriff für jeden, der ihn braucht. Nur endet diese Demokratisierung an der API. Eine Schnittstelle ist kein Zugang für jemanden, der eine Anlage fährt. Wer den letzten Schritt nicht mitliefert, hat Daten freigegeben, aber keinen Zugang geschaffen.
Genau an dieser Stelle setzt das cts Application Framework an. Es liefert keine Beispiele, aus denen sich jemand etwas Eigenes baut, sondern fertige, einsatzbereite Compilations. Das Team des Unternehmens wählt aus, ordnet seine Datenpunkte zu und richtet die Ansicht ein. Über eine Konfigurationsoberfläche, nicht im Code.
Compilations selbst aus Code bauen
Die mitgelieferten Beispiele dienen als Vorlage. Jede produktiv nutzbare Ansicht entsteht daraus in Eigenarbeit: Struktur verstehen, Widget-Parameter setzen, Datenbindung herstellen, testen. Voraussetzung ist Einarbeitung in die Codebasis – und diese Einarbeitung ist bei jedem Personalwechsel neu fällig.
Fertige Compilations konfigurieren
Die Ansichten sind vorhanden und lauffähig. Das Team wählt die passende aus, ordnet die eigenen Datenpunkte zu und passt Darstellung und Zugriff an. Kein Zugriff auf den Code nötig, keine Einarbeitung in dessen Struktur – und damit auch keine Abhängigkeit von der einen Person, die ihn kennt.
Was Ihr Team damit selbst machen kann
Der eigentliche Unterschied liegt nicht in der Technik, sondern darin, wer im Unternehmen handlungsfähig wird — an drei Stellen ganz konkret.
Der Code bleibt dabei offen und lesbar. Wer tiefer eingreifen will, kann das – niemand muss es, um eine Ansicht produktiv zu nutzen. Das ist der Unterschied zwischen einer geschlossenen Oberfläche und einem Rahmen, der beide Wege offenlässt.
Zusammengenommen ist das kein Effizienzthema, sondern eine Verschiebung von Zuständigkeit. Wer eine Ansicht selbst einrichten kann, hört auf, Anforderungen zu formulieren, und fängt an, Fragen zu beantworten. Das verändert, was in einer Schicht überhaupt gefragt wird.
Was eine Anwendungsschicht leisten muss
Fertige Compilations allein wären nur eine Sammlung. Damit daraus eine Anwendung wird, die im Schichtbetrieb bestehen kann, braucht es den Rahmen darum – eine Anwendungsschicht, im Englischen Application Layer. Sie liefert keine Fachfunktion, sondern die Eigenschaften, die jede Fachfunktion braucht und die niemand pro Ansicht neu bauen sollte.
Vier Leistungen gehören in diesen Rahmen. Sie gelten für jede Compilation, die darin läuft, und lassen sich nicht einzeln bestellen.
Einheitliche Oberfläche
Jede Anwendung erscheint im Design des Unternehmens und mit derselben Bedienlogik, sodass jemand, der eine Ansicht kennt, auch die nächste bedienen kann. Das ist keine Frage der Optik, sondern der Hebel für Akzeptanz im Schichtbetrieb.
Rollen statt Einzelfreigaben
Zugriffe hängen an Rollen, nicht an Personen und einzelnen Ansichten. Ein Abteilungswechsel bedeutet eine neue Rolle – nicht fünfzehn nachgezogene Berechtigungen in fünfzehn Anwendungen.
Erkennung neuer Anwendungen
Neue Module werden gefunden und eingebunden, ohne dass jemand eine Liste pflegt. Ein Konfigurationsschritt, der nicht existiert, kann beim vierten Modul nicht vergessen werden.
Dokumentation am Ort der Nutzung
Handbücher werden erkannt und der Anwendung zugeordnet, zu der sie gehören. Kein separates Dokumentenmanagement, keine Zuordnung von Hand, keine Links, die nach dem nächsten Release ins Leere zeigen.
Warum selbstgebaute Compilations nicht skalieren
Der übliche Weg ist naheliegend: Für jede benötigte Ansicht wird eine Compilation gebaut. Die erste entsteht in wenigen Tagen, die zweite auch, und damit wirkt der Aufwand kalkulierbar.
Sichtbar wird das Problem bei der vierten oder fünften. Nicht weil das Bauen aufwendiger wird, sondern weil die Unterschiede zwischen den Ansichten beginnen, Arbeit zu erzeugen: unterschiedliche Farblogik, unterschiedliche Zeitachsen, unterschiedliche Rechtekonzepte. Wer eine davon ändern will, muss erst herausfinden, wie sie gebaut wurde.
Es ist dasselbe Muster wie bei Punkt-zu-Punkt-Integrationen auf der Datenebene, nur eine Schicht höher und mit demselben Ausgang. Auf der Datenebene hat die Branche daraus gelernt und Integrationsschichten gebaut, während wir auf der Anwendungsebene weiter Punkt zu Punkt verdrahten.
Selbst gebaut gegenüber Framework
| Kriterium | Compilations selbst aus Code bauen | Fertige Compilations im Framework |
|---|---|---|
| Wer eine Ansicht erstellt | Entwickler mit Kenntnis der Codebasis | Fachanwender über Konfiguration |
| Voraussetzung | Einarbeitung in Struktur und Widget-Parameter | Kenntnis der eigenen Datenpunkte |
| Änderung an bestehender Ansicht | Entwicklungsaufgabe, wartet auf Kapazität | Einstellung, sofort möglich |
| Oberfläche | Je Ansicht neu entschieden | Einheitlich, im Unternehmensdesign |
| Rechteverwaltung | Pro Ansicht gepflegt | Zentral über Rollen |
| Dokumentation | Separates System oder keine | Am Modul, automatisch zugeordnet |
| Aufwand je weiterer Ansicht | Bleibt konstant hoch | Sinkt, weil der Rahmen steht |
| Bei Personalwechsel | Einarbeitung in den Code neu fällig | Konfiguration bleibt übertragbar |
| Bestehende Eigenentwicklungen | Bleiben Einzelfälle | Lassen sich einbinden |
Jede Zeile der mittleren Spalte ist machbar. Der Unterschied liegt in der rechten: Dort ist es einmal entschieden und danach vorhanden.
Die drei Module, die cts mitliefert
Das cts Application Framework ist die Anwendungsschicht zu der Datenschicht, die wir in der Industrieinformatik ohnehin bauen. Im Einsatz ist es heute auf AspenTech Inmation – der Industrial Data Platform, auf der wir den Fabric-Kern aufsetzen. Die Datenschicht bleibt unverändert. Das Framework ergänzt die Ebene darüber.
Drei Module sind enthalten: Trending für Zeitreihen und Verläufe, Events für Meldungen und Ereignisse, und Compilations, mit dem Ansichten zusammengestellt und verwaltet werden. Alle drei sind fertig gebaut und werden konfiguriert, statt programmiert zu werden.
Was Ihr Team gebaut hat, bleibt
Der häufigste Einwand gegen einen Rahmen lautet: Wir haben doch schon etwas. Meist über Jahre entstanden, meist von Leuten gebaut, die genau wussten, was die Produktion braucht.
Solche Anwendungen lassen sich einbinden, statt sie zu ersetzen: Sie werden Teil derselben Oberfläche – mit demselben Design, demselben Rechtemodell und derselben Dokumentationsbindung wie die mitgelieferten Module. Aus vier Handschriften wird eine, ohne dass jemand vier Anwendungen neu baut.
Warum „Application Framework" und nicht „inmation-Erweiterung"
Der Name ist bewusst systemoffen gewählt. Die Module sind so gebaut, dass sie nicht an eine einzelne Plattform gebunden sind – und die Datenplattformen unserer Kunden bewegen sich: Hersteller werden übernommen, Produkte umbenannt, Komponenten neu geschnitten — zuletzt im Mai 2026, als Emerson die OT Data Fabric zum Baustein einer „AspenTech Inmation Data Platform" erklärte. Ein Produktname, der eine fremde Marke trägt, veraltet mit ihr. Deshalb steht die Plattform bei uns in der Beschreibung, nicht im Namen.
Belegt ist bisher eine Plattform, weitere prüfen wir. Solange kein Modul nachweisbar auf einer zweiten läuft, sagen wir nicht, dass es plattformunabhängig ist.
Die drei Fragen, die Entscheider stellen sollten
Wie viele Personen bei uns können heute eine neue Ansicht erstellen?
Wenn die Antwort „eine" oder „keine mehr" lautet, liegt das Nadelöhr nicht bei den Daten, sondern beim Zugang zum Code. Wer Compilations konfigurieren statt programmieren kann, verteilt diese Fähigkeit auf das ganze Team.
Wie lange dauert bei uns eine zusätzliche Kennzahl in einer bestehenden Ansicht?
Wenn die Antwort in Wochen gemessen wird, ist die Anfrage nicht schwierig – sie steht nur in einer Warteschlange. In einer konfigurierbaren Ansicht ist das eine Einstellung, die derjenige vornimmt, der sie braucht.
Was passiert, wenn die Person das Unternehmen verlässt, die unsere Ansichten gebaut hat?
Selbstgebauter Code ist nur so lange wartbar, wie sein Autor erreichbar ist. Fertige Compilations bleiben nachvollziehbar, weil ihre Struktur nicht projektspezifisch entstanden ist – und weil die Dokumentation an der Ansicht hängt.
Wo der Nutzen wirklich entsteht
Der messbare Teil ist der kleinere, aber der greifbarere: Entwicklungsaufwand, der für jede neue Ansicht wegfällt, Einarbeitungszeit, die niemand mehr in die Codebasis investieren muss, und Änderungen, die keine Entwicklerkapazität mehr binden. Diese Effekte lassen sich abschätzen, sobald man weiß, wie viele Ansichten heute im Betrieb sind, wer sie gebaut hat und wie lange eine Änderung derzeit dauert.
Der größere Teil ist schwerer zu quantifizieren und in der Praxis dauerhafter. Er entsteht, wenn die Anwendung im Schichtbetrieb nicht mehr umgangen wird. Wenn die Instandhaltung nachts selbst nachsieht, warum eine Anlage gedrosselt hat, statt am Morgen zu fragen. Wenn die Qualitätssicherung eine Charge nachvollzieht, ohne einen Export anzufordern. Das ist kein Software-Effekt, sondern eine Veränderung darin, wer Entscheidungen mit Daten trifft.
Deshalb behandeln wir die Anwendungsschicht nicht als Nachgang zur Datenschicht, sondern als Teil derselben Aufgabe. Eine Data Fabric ohne bedienbare Anwendungen ist keine halbe Lösung – sie ist eine vollständige Lösung für ein Problem, das der Kunde nicht hatte. Verfügbarkeit war nie das Ziel. Sie war die Voraussetzung.
Wann der richtige Zeitpunkt ist
Am günstigsten wäre der Einstieg, bevor die dritte selbstgebaute Compilation entsteht — genutzt wird dieser Zeitpunkt fast nie, weil der Schmerz noch fehlt. Der zweitbeste ist der Moment, in dem eine bestehende Ansicht nicht mehr wartbar ist: Der Entwickler ist weg, die Anforderung hat sich geändert, und die Änderung kostet mehr als der Neubau. Wer diesen Moment nutzt, konsolidiert unter realem Druck – und das erhöht die Akzeptanz erfahrungsgemäß mehr als jede Vorab-Überzeugung.
Wie sieht Ihre Anwendungsschicht heute aus?
Sie brauchen kein Briefing und keine Anforderungsliste. Wir sehen uns Ihr bestehendes Setup an und sagen Ihnen, was das Framework übernimmt und was Projektarbeit bleibt.
Sprechen Sie mit unseren Experten
