© Ekaphon maneechot/Shutterstock.com
Architekturbeispiel für eine „User-owned Application“

Architekturbeispiel für eine „User-owned Application“


Betrachtet man eine Fachapplikation als ein Haus, so übernimmt die IT-Abteilung jede Art von Instandsetzungs- und Umbauarbeiten, und die Fachabteilungen müssen jede noch so kleine Arbeit beauftragen, warten bis sie umgesetzt wird und beschränken sich auf das reine „Bewohnen“. Wie kann eine Architektur einer User-owned Application aussehen, in der die Fachabteilungen wieder „Herr im eigenen Hause sind“?

Kontinuierliche Innovation und der wachsende Umfang gesetzlicher Regelungen erfordern eine steigende Anzahl kurzfristig umzusetzender Änderungen an den Fachapplikationen der Unternehmen. In der Regel sind Prozesse zur Umsetzung einer solchen Änderung langwierig und kostspielig, da die Übersetzung von der Fach- in die IT- und schlussendlich in die Maschinensprache sehr aufwändig und verlustbehaftet ist. Ein möglicher Ansatz zur Beschleunigung der Umsetzungsprozesse ist die Überführung der Hoheit über die Anwendung von der IT- in die Fachabteilungen. Wir möchten in diesem Zusammenhang von einer User-owned Application sprechen. Sind die Fachbenutzer klassischerweise für die Pflege der Daten in „ihrer“ Anwendung verantwortlich, erstreckt sich der Verantwortungsbereich in einer User-owned Application zusätzlich auf das Domänen(daten)modell und die Geschäftsregeln. Die IT-Abteilung stellt für diese Arbeit ein fachliches Anwendungsframework als Plattform zur Verfügung, das Aspekte wie Nachvollziehbarkeit, Versionierbarkeit, ein Lebenszykluskonzept und Ähnliches bietet [1]. Das Anwendungsframework basiert auf der in Abbildung 1 dargestellten Architekturblaupause.

Diener_Kaminsky_Architektur-Blaupause_1.tif_fmt1.jpgAbb. 1: Architekturblaupause des fachlichen Anwendungsframeworks

Zusätzliche Rolle für den Fachanwender

Grundlegend lassen sich in der Interaktion der Benutzer mit einer Fachapplikation zwei Rollen unterscheiden. Recht anschaulich können diese Rollen durch einen Seitenblick auf den Sprachgebrauch der SQL abgegrenzt werden: Die Data Definition Language (DDL) dient dem Erzeugen, Verändern und Löschen von Datenstrukturen und die Data Manipulation Language (DML) dem Erstellen, Verändern oder Löschen von Inhalten für diese Datenstrukturen. In einer klassischen Anwendung liegt die Data-Definition-Rolle in der Verantwortung der IT- und die Data-Manipulation-Rolle bei der Fachabteilung. In User-owned Applications hat die Fachabteilung beide Rollen inne. Das Konzept der „Definition“-Rolle gilt dabei sowohl für das Domänenmodell als auch für die Geschäftsregeln. Die Regeln werden nicht nur durch den Fachanwender a...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang