Software-Entwicklung vs. Lösungs-Entwicklung

Beim regelbasierten Ansatz werden die Programmcodes wie eigentliche Daten behandelt, und das Geschäftswissen wird von der Technologie entkoppelt.

Artikel erschienen in IT Reseller 2004/07

   

Schon vor Jahren wurde von «industrieller Software-Entwicklung» gesprochen. Damit war vor allem die einmalige Entwicklung von Komponenten mit mehrfacher Wiederverwendung gemeint. Nach dem Vorbild der Fertigungsindustrie verfolgten die professionellen Anbieter die Idee, diese standardisierten «Software-Stückli» einzukaufen und in den Lösungen zu verarbeiten.
Mit diesem Ansatz erhoffte man sich nicht zuletzt auch eine Professionalisierung der Software-Entwicklerszene.

Individual-Entwicklung – ein Auslaufmodell?

Die Entwicklung bei Standardsoftware-Lösungen schreitet rasant voran. Bei den Funktionalitäten unterscheiden sich ähnlich positionierte Lösungen kaum mehr. Man könnte fast annehmen, dass Individual-Entwicklungen immer weniger gefragt sind. Das Gegenteil ist aber der Fall.
Der Aufwand zur Adaption von Standardlösungen mit grosser Funktionsbreite und -tiefe ist aufwendig. Hier führen selbstentwickelte Ergänzungen zu Standardlösungen oftmals schneller und günstiger zum Ziel.
Letztlich stellt sich aber die Frage, weshalb Software entwickelt werden soll, wenn die Lösung einfach gebaut werden kann. Traditionell entwickelte Lösungen stellen Funktionen bereit, die auf Daten angewendet werden. Die Daten sind heute in der Regel in relationalen oder objektorientierten Datenbanken abgelegt.
Die Funktionen sind programmiert und in Tausenden von Zeilen Code eingepackt. Der Nachteil dieser Strukturen liegt auf der Hand: Die Programme sind starr und unflexibel. Zudem sind sie – wenn es sich dabei um kleine Zusatzentwicklungen handelt – oftmals von einer Person entwickelt, nur mässig gut dokumentiert und können ohne das Know-how dieser Person nicht gewartet werden.

Daten leben länger als Programme

Eine Möglichkeit aus diesem Korsett auszubrechen besteht darin, die bisher im Programmcode definierte Funktionalität gleich wie die Daten, also die eigentlichen Inhalte und Informationen, zu behandeln. Mit dem Einsatz eines geeigneten Frameworks kann dies verwirklicht werden.
Metadaten beschreiben die Programmlogik. Die Definition erfolgt mittels Prozessbeschreibungen (virtuelle Objekte wie Views, Reports, Workflows), die zur Laufzeit von einer im Application Server laufenden «Engine» interpretiert werden.
Die so in Metadaten gefassten Regeln beinhalten also die für Ablauflogik und Datenpräsentation erforderlichen Informationen – im Webbrowser notabene.
Der Programmierer wird dadurch zum eigentlichen Anwendungsbauer. Seine Ausgangslage sind die
Businessanforderungen und das Datenmodell. Dieses ist oftmals vorhanden und wird aus den Strukturen von unterschiedlichen Datenbanken, die weltweit verteilt sein können, generiert.
Nicht funktionale Anforderungen an die Lösungen wie etwa Authentifizierung, Transaktionssicherheit, Datenschutz, Nachverfolgbarkeit von Änderungen sind mit dem Einsatz des Frameworks gelöst. Dank bitemporaler Datenhaltung kann auch jeder einmal vorhanden gewesene Datenzustand zeitgenau rekonstruiert werden.

Entkoppelung von Technologie und Wissen

Mit den Metadaten werden die Strukturen und Beziehungen von anderen Daten und von Schnittstellen beschrieben. Zudem beschreiben sie den fachlichen Sachverhalt und dienen darüber hinaus auch als Regeln, auf denen die einzelnen Prozesse basieren.
Da sie der eigentliche Kern (Inhalt) der Business-Anwendung sind und das Wissen (die Geschäftslogik) beinhalten, leben Metadaten länger als IT-Technologien. Mit der Verwendung von Metadaten erfolgt also eine Entkoppelung von Technologie und Wissen. Dementsprechend kann die Technologie ohne Anpassung der Metadaten immer auf dem neuesten Stand gehalten werden.
Diese Strukturen bieten einige wesentliche Vorteile. Bei einem Projekt vereinfacht sich die Organisation, da weniger Schnittstellen für den Know-how-Transfer nötig sind. Daraus ergibt sich eine effizientere Projektrealisierung mit weniger Know-how-Verlust. Das Know-how des Kunden wird zentral dokumentiert und mit Daten beschrieben (und nicht im Programm-Code versteckt).
Dadurch sind die implementierten Lösungen nicht von einzelnen Programmierern abhängig und können bedeutend besser gewartet werden. Die klare Abtrennung derjenigen Aspekte, die zwar nicht funktional sind aber zwingend vorhanden sein müssen und in der verwendeten Applikations-Infrastruktur gelöst sind, erlaubt bei der Lösungsentwicklung den Fokus ausschliesslich auf die Funktionen.
Dies führt letztlich zu einer schnelleren und qualitativ besseren Lösungsentwicklung. Überall, wo eine konsolidierte Sicht auf verteilte Daten (in unterschiedlichen Anwendungen, an unterschiedlichen Standorten), sichere Datenbewirtschaftung auf verteilte Systeme oder flexibel anpassbare Ablaufstrukturen gefordert sind, lohnt es sich deshalb, den Einsatz der regelbasierten Methodik zumindest zu prüfen.

Aufbau von Metadaten


Für die Erzeugung der Metadaten sind folgende Schritte notwendig:

1. Einlesen des physischen Datenmodells aus einem Case-Tool oder aus dem System-Katalog einer Datenbank.
2. Erzeugung der logischen Objekte (Sichten, Berichte, Arbeitsabläufe)
3. Test der Definitionen gegenüber den Zieldaten.
4. Speichern der Definitionen in ein externes Format (z.B. XML).
5. Aktualisieren der Definitionen in der produktiven Instanz über Kommandozeilenaufrufe der
Business-Komponente.

Die Autoren

Philipp Künsch, Geschäftsführer von Datalizard AG, hat ein Framework für die Implementierung von metadatengesteuerten Lösungen entwickelt und in Projekten eingesetzt.
Kurt R. Meier ist Geschäftsführer von Conanima Marketing GmbH und bietet Go-to-Market-Dienstleistungen für IT-Firmen an.


Artikel kommentieren
Kommentare werden vor der Freischaltung durch die Redaktion geprüft.

Anti-Spam-Frage: Wie hiess im Märchen die Schwester von Hänsel?
GOLD SPONSOREN
SPONSOREN & PARTNER