Enterprise Apps sind eine ganzheitliche IT Lösung – keine rohe Technik

Diese zugegebenermaßen etwas anmaßend klingende Aussage ist nichts desto weniger die Grundidee und die Zielrichtung von ISA - weil ISA universelle, technologieunabhängige Module als konkrete Top Level Objekte einer nur aus Modulen bestehenden IT Architektur einführt und Modularität auf diese Weise zum übergreifenden Grundkonzept macht.

Darauf aufbauend bietet ISA gleichzeitig einen vollständigen Architektur-, Verfahrens- und Technologie-Rahmen, der “out of the box” verwendbar ist und der trotzdem zu nichts zwingt und in allen Bereichen einfach an alle individuellen Erfordernisse angepasst werden kann.

ISA Modularität ist ein Konstruktionsprinzip, das dazu dient, Systeme und Dienste aus einer einfachen, funktionalen IT Perspektive heraus abzubilden. Erst nach dieser Ebene folgt dann die entkoppelte, technische Ebene der Realisierung der Module, die sich nahtlos in jede bestehende Landschaft einfügt.

In der Objektorientierung ist die Klasse mit ihren Attributen, Methoden und ihren verschiedenen Beziehungen das Top Level Objekt der Abbildung.

In der “ISA Modulorientierung” ist es das Modul,

  • das einen eindeutigen Namen hat und durch eine Datei mit diesem Namen realisiert wird
  • das eine öffentliche API bzw. Schnittstelle (Funktionalität) definieren kann
  • das die öffentlichen Schnittstellen anderer Module nutzen kann

Damit kann jede benötigte Funktionalität, ohne konkrete Technik, aus einer reinen Nutzersicht heraus eindeutig definiert und zugeordnet werden. Hierbei sind Module sowohl die abstrakt konzeptionellen als auch die konkret realen Objekte der Systemlandschaft. Auf dieser Ebene gibt es daher auch noch keinen Unterschied zwischen Fachlichkeit und Technik – beides ist im Modul vereint – aber technisch nicht festgelegt.

Aus einer Außensicht repräsentiert das Modul nur funktionale Fachlichkeit und deren nutzungsbezogenen Zusammenhang – und erst aus einer Innensicht deren konkrete technische Umsetzung. ISA Module sind rein funktionsorientiert – dagegen sind Klassen in der OO primär strukturorientiert.1

ISA als technisches Java Framework tritt in der Außensicht überhaupt nicht in Erscheinung, weil es nur dazu dient, diese Art eines konzeptionellen Modulverständnisses im Hintergrund auch technisch zu ermöglichen.2

Die zweite Eigenschaft, die ISA zu einer Lösung macht ist die, dass ISA auf Basis seines Modulbegriffs auch den Umgang mit diesen Modulen auf allen beteiligten Ebenen beschreibt oder festlegt. Damit ist ISA

  • ein klar definiertes Konstruktionsprinzip
  • eine konkrete Systemarchitektur mit Verfahren
  • und ein konkrete technische Realisierung

eine vollständige, sofort einsetzbare Lösung zur Umsetzung von Enterprise Systemen und Diensten, die durchgängig modular sind und sich evolutionär entwickeln können.

Siehe auch Module und Objekte sowie ISA und OSGi

________________________
1: Der Unterschied ist wichtig, weil Strukturen “nur” statische Zusammenhänge darstellen, die interpretiert werden müssen – wohingegen Funktionen und deren Nutzung das konkrete, erwartete Verhalten beschreiben.

2: Das genau ist bei gängigen Enterprise Technologien anders. Hier steht immer erst eine Technologie zur Auswahl und dann erst eine konzeptionelle, fachlich/funktionale Abbildung. Das hat zur Folge, dass diese Abbildungen immer von der Technologie und deren Möglichkeiten getrieben werden – und damit auch nie als universelles, übergreifendes Bauprinzip geeignet sind.

Ein Beispiel dafür sind WebServices, weil sie auf den ersten Blick ISA Modulen sehr ähnlich scheinen – das allerdings nur auf der abstrakten Ebene eines “Funktionsbausteins”. Tatsächlich aber ist der Sinn und damit der Einsatzbereich von WebServices vollkommen spezifisch – weil sie real nur eine ganz konkrete RPC Technologie darstellen, die auch nur für diesen Zweck sinnvoll eingesetzt werden kann. Ein GUI Baustein z.B. kann damit nicht abgebildet werden. Ein ISA Modul hingegen ist technisch nicht spezifisch – und kann daher alles repräsentieren.