Application Framework und inmation: Was der Rahmen leistet, was die Plattform nicht leisten soll
Die Frage kommt in fast jedem technischen Gespräch: Was kann das Framework, was inmation nicht kann? Die ehrliche Antwort lautet: nichts. Alles, was das Framework tut, ist mit den Mitteln der Plattform gebaut. Warum die Frage trotzdem eine Antwort verdient – nur eine andere, als sie vermutet.
Ich beantworte diese Frage gern, weil sie von jemandem kommt, der die Plattform kennt. Wer sie stellt, hat meist selbst schon eine Ansicht gebaut und weiß, dass AspenTech Inmation alles Nötige mitbringt. Und er hat recht.
Es gibt im cts Application Framework keine verborgene Engine und keinen Funktionsumfang, der die Plattform überschreitet. Der Rahmen nutzt deren Objektmodell, deren Schnittstellen und deren Web-Ebene. Wer genug Zeit und genug Entwickler hat, kann jede einzelne Eigenschaft davon selbst herstellen. Wir hatten diese Zeit und diese Entwickler, deshalb existiert der Rahmen.
Damit ist die Kategorie „können" erschöpft, ohne dass die Frage beantwortet wäre, die im Betrieb zählt. Die lautet: Wie oft, von wem und zu welchem Aufwand je Wiederholung?
Warum „können" die falsche Kategorie ist
Ein Beispiel aus einem anderen Teil unseres Hauses. Ein Schaltschrank lässt sich für jedes Projekt neu entwerfen und von Hand verdrahten. Das Ergebnis funktioniert, und ein erfahrener Techniker macht es fachlich einwandfrei. Trotzdem arbeiten wir im Schaltschrankbau mit erprobten Bausteinen und wiederkehrenden Aufbauregeln.
Der Grund ist nicht, dass die Handarbeit es nicht könnte. Der Grund ist, dass sie sich nicht wiederholt: Jeder Schrank sieht anders aus, jede Prüfung braucht neue Aufmerksamkeit, jede Änderung braucht die Person, die ihn gebaut hat. Der Baukasten kann nichts Neues – er macht dasselbe wiederholbar.
Für Ansichten auf Prozessdaten gilt dasselbe. Der Unterschied zwischen einer selbst gebauten und einer aus dem Framework konfigurierten Ansicht liegt nicht in der Funktion. Er liegt darin, wie viel Aufwand die zweite, fünfte und zwanzigste kostet – und wer sie erstellen kann.
Beide Wege führen zur selben Ansicht. Der obere braucht Entwicklerkapazität und durchläuft eine Warteschlange. Der untere braucht Prozesswissen. Das ist der ganze Unterschied – und er entscheidet, wie viele Ansichten ein Unternehmen am Ende tatsächlich betreibt.
Was im Standard nicht vorgesehen ist
Ein Wort zur Formulierung, bevor die Tabelle kommt: „nicht vorgesehen" ist nicht dasselbe wie „fehlt". inmation ist als Datenplattform gebaut, und die folgenden Punkte liegen außerhalb dieser Aufgabe, und das ist eine sinnvolle Abgrenzung – keine Lücke im Produkt.
| Aufgabe | Im Standard | Im Application Framework |
|---|---|---|
| Ansicht erstellen | Compilation im Code aufbauen, Beispiele als Vorlage | Fertige Compilation auswählen und konfigurieren |
| Einheitliches Erscheinungsbild | Je Ansicht herzustellen und einzuhalten | Voreinstellung des Rahmens, nicht abwählbar |
| Rechtevergabe | Rechte auf Datenobjekte und Strukturen | Rollen auf Module und Ansichten, betrieblich gedacht |
| Neues Modul aufnehmen | Registrierung und Verdrahtung von Hand | Wird erkannt und eingebunden |
| Dokumentation | Getrennt zu pflegen und zuzuordnen | Wird erkannt und am Modul geführt |
| Bestehende Eigenentwicklung | Bleibt ein eigenständiges Stück Software | Wird eingebunden und erbt Oberfläche, Rechte, Dokumentation |
| Aufwand je weiterer Ansicht | Bleibt konstant, weil jede neu entsteht | Sinkt, weil der Rahmen bereits steht |
Jede Zeile der mittleren Spalte ist machbar. Der Punkt ist die rechte Spalte: Dort ist es einmal gemacht und danach vorhanden.
Die eine Eigenschaft, die im Eigenbau strukturell nicht entstehen kann
Es gibt einen Punkt, an dem der Vergleich kippt – und er hat nichts mit Funktionsumfang zu tun. Datenplattformen verändern sich: Komponenten werden neu geschnitten, Parameter umbenannt, Produktnamen wechseln mit dem Eigentümer. Bei inmation ist beides dokumentiert: Nach der Übernahme durch AspenTech firmiert das Produkt unter neuem Namen, und eine Emerson-Meldung vom Mai 2026 schneidet es neu — aus dem Produkt wird der Baustein einer „AspenTech Inmation Data Platform".
Für selbst gebaute Compilations bedeutet jede solche Änderung: Jede Ansicht ist einzeln zu prüfen und einzeln anzupassen. Bei vier Ansichten ist das ein unangenehmer Tag. Bei zwanzig ist es ein Projekt, das niemand geplant hat – und es wiederholt sich mit jedem größeren Release.
Ein Rahmen hat dafür genau eine Stelle. Die Anpassung an eine veränderte Plattform passiert im Framework, und alle Ansichten erben sie. Das ist die einzige Eigenschaft in diesem Beitrag, die im Eigenbau nicht nur teurer, sondern strukturell nicht herstellbar ist – weil sie einen gemeinsamen Ort voraussetzt, den verteilte Einzelansichten nicht haben.
Was der Rahmen ausdrücklich nicht besser macht
Dieser Abschnitt gehört in einen solchen Beitrag, auch wenn er sich schlecht verkauft. Ein Rahmen um Anwendungen verbessert drei Dinge nicht, und wer das anders darstellt, erzeugt eine Enttäuschung mit Ankündigung.
Datenqualität
Ein unsauber modelliertes Signal wird durch eine gute Ansicht nicht richtig, sondern nur schneller sichtbar falsch. Wer Kontext und Benennung in der Datenschicht nicht geklärt hat, klärt sie auch im Framework nicht.
Antwortzeiten
Performance entsteht in der Datenplattform und in der Abfrage, nicht in der Oberfläche. Wenn eine Auswertung heute langsam ist, bleibt sie das – der Rahmen bringt keine eigene Rechenleistung mit.
Prozessverständnis
Das Framework weiß nicht, welche drei Werte zusammen eine Störung erklären — diese Entscheidung trifft der Fachbereich. Der Rahmen macht sie umsetzbar, ohne sie zu ersetzen.
Die Zuordnung zu Ihrer Anlage
Rahmen und Compilations sind fertig, die Abbildung auf Ihre Anlagenstruktur, Ihre Rollen und Ihre Prozesse dagegen ist Projektarbeit. Wie viel, hängt vom Setup ab – das schätzen wir vorher gemeinsam ab, nicht hinterher.
Die Fragen, die stattdessen zählen
Wie viele Ansichten wollen wir in drei Jahren betreiben?
Bei zwei oder drei lohnt sich kein Rahmen – dann ist Eigenbau der kürzere Weg, und wir sagen das auch. Ab etwa fünf kippt die Rechnung, weil der Pflegeaufwand die Bauzeit übersteigt. Diese Zahl kennt nur das Unternehmen selbst.
Führen wir Ansichten als Projekt oder als Betriebsaufgabe?
Ein Projekt hat einen Anfang, ein Ende und ein Budget. Eine Betriebsaufgabe braucht jemanden, der sie dauerhaft übernehmen kann. Solange Ansichten Codearbeit sind, lassen sie sich nicht als Betriebsaufgabe führen – unabhängig davon, wie man es organisatorisch nennt.
Was ist uns Unabhängigkeit von einem Dienstleister wert?
Diese Frage stellen wir bewusst, obwohl wir der Dienstleister sind. Jede Ansicht, die Ihr Team selbst konfiguriert, ist ein Auftrag, den wir nicht bekommen. Uns ist ein Kunde lieber, der handlungsfähig ist, als einer, der bei jeder Kennzahl anrufen muss.
Bleibt die Ausgangsfrage, und die Antwort darauf steht schon im ersten Absatz: Das Application Framework kann nichts, was inmation nicht kann. Es macht das, was die Plattform ermöglicht, wiederholbar und für mehr Leute zugänglich. Ob das den Aufwand wert ist, hängt nicht von der Technik ab, sondern davon, wie oft Sie es brauchen. Diese Rechnung stellen wir gern gemeinsam auf – auch mit dem Ergebnis, dass sie in Ihrem Fall gegen den Rahmen ausfällt.
Die Grundlagen dazu stehen in den beiden anderen Beiträgen dieser Reihe: was das Application Framework ist und warum die Integration von inmation allein nicht reicht.
Rechnen wir es für Ihr Setup durch
Wie viele Ansichten betreiben Sie heute, wie viele wollen Sie betreiben, und wer soll sie pflegen? Aus diesen drei Zahlen ergibt sich die Antwort – mit oder ohne Rahmen.
Sprechen Sie mit unseren Experten
