Geschäftsanwendungen unterliegen einem kontinuierlichen Wandel. Vor allem die typischen Aufwandstreiber, die erst im Laufe eines Projekts auftreten – allen voran fachliche Anpassungen und Integrationen – werden immer wieder unterschätzt und sind langfristig für das Scheitern auch sehr großer IT-Projekte verantwortlich.

 

Kurz & Knapp

  • Typische Aufwandstreiber in SW-Entwicklung und Betrieb und was dahinter steckt
  • Warum Datenmodelle so wichtig sind
  • Wie technische Anpassungen und Betrieb im Lebenszyklus einer Anwendung beherrschbar bleiben

 

Whitepaper zum Thema Low Code für individuelle Enterprise Software

Als Softwarehaus entwickelt mgm seit über 25 Jahren individuelle Enterprise Software. Der Kerngedanke der Low Code Plattform A12 geht auf eine Reihe wiederkehrender Beobachtungen aus den unterschiedlichsten Projekten zurück.

A12 ist eine Enterprise Low Code Plattform für die Entwicklung, Integration, Wartung und den Betrieb von Unternehmensanwendungen in komplexen IT-Landschaften. Sie kombiniert einen Low Code Ansatz, bei dem Fachexperten eine Anwendung ohne Programmierkenntnisse erstellen können, mit professioneller Individualsoftwareentwicklung und Systemintegration.

Dies ist ein Auszug aus dem Whitepaper “A12 Low Code und Co-Innovation für individuelle Enterprise Software”. Das ganze Whitepaper gibt es hier zum Download.

Aufwandstreiber: Gestiegene Anforderungen an Unternehmensanwendungen im Lebenszyklus

Geschäftsdomänen – alles andere als Standard

Die Modelle, die jeder Enterprise Software zugrunde liegen, folgen keinem Standard. Im Gegenteil: Sie sind hochindividuell und enthalten immer wieder Ausnahmen und in einigen Fällen auch Widersprüche.

Jede Enterprise Software modelliert einen bestimmten Ausschnitt der unternehmensspezifischen Realität. Die Modelle der Entitäten unterliegen einem kontinuierlichen Wandel. Das ist ein ganz wesentlicher Aufwandstreiber der Enterprise Software Entwicklung.

Verantwortlich für den Wandel sind vor allem folgende Punkte:

  • Ein gewachsenes Geschäft ist ein komplexes Geflecht. Das Wissen darüber ist über viele Köpfe verteilt. Es gibt viele Stellschrauben, an denen ganz unterschiedliche Unternehmensvertreter immer wieder drehen.
  • Das Geschäft entwickelt sich kontinuierlich weiter. Das Portfolio ändert sich. Vertriebswege treten hinzu oder fallen weg. Je nach Branche müssen neue regulatorische Vorgaben eingehalten werden.
  • Unternehmen organisieren ihr Geschäft individuell nach ganz unterschiedlichen Regeln. Darüber hinaus verwenden sie eigene Terminologien, die sukzessive erweitert und angepasst werden.

Ein weiterer Aufwandstreiber hängt ebenfalls mit den zugrundeliegenden Modellen zusammen: Sie bilden immer größere Ausschnitte der geschäftlichen Realität ab, die für den Erfolg in der jeweiligen Geschäftsdomäne relevant sind. Die Modelle werden sukzessive also komplexer.

 

Aufwandstreiber: Fachliche Anpassungen für Unternehmensanwendungen in integrierten und komplexen IT-Landschaften

Unterschiedliche Repräsentationen von Geschäftsentitäten

Aus Perspektive der Softwareentwicklung sind jegliche Änderungen der Geschäftsentitäten mit hohem Aufwand verbunden. Der Grund: Sie müssen in unterschiedlichen technischen Zusammenhängen unterschiedlich repräsentiert werden.

Zwischen diesen unterschiedlichen Repräsentationen sind Abbildungen nötig. Die Repräsentation müssen aufeinander gemappt werden. In der Praxis bringt dadurch selbst die kleinste fachliche Änderung eine ganze Kaskade von Anpassungsschritten in der Software mit sich.

Die folgende Auflistung zeigt eine Übersicht dieser verschiedenen Repräsentationen und Abbildungen, die typischerweise in Enterprise Software auftreten.

Den Ausgangspunkt bildet die Spezifikation (1). Sie stellt als Vorlage für die Implementierung die erste Repräsentation der modellierten Geschäftsentitäten und ihrer Beziehungen zueinander dar. In einer Drei-Schichten-Architektur treten folgende Repräsentationen hinzu:

  • In der Datenhaltungsschicht sind die Geschäftsobjekte in einer Datenbank abgelegt. Hierfür ist eine Repräsentation erforderlich, die den Vorgaben dieser Persistenzebene genügt (2). Bei einer relationalen Datenbank nimmt sie eine tabellarische Form an. Um die Daten der Tabellen in einer objektorientierten Hochsprache wie Java verarbeitbar zu machen, findet eine Objektrelationale Abbildung statt (3).
  • In der Businessschicht befindet sich die Anwendungslogik. Sie bringt noch mal eine eigene Repräsentation (4) mit sich, die sich aus der jeweiligen Verarbeitung der Geschäftsobjekte, -komponenten und Workflows ergibt.
  • In der Präsentationsschicht ist wieder eine andere Repräsentation (5) erforderlich. Hier geht darum, wie die Geschäftsentitäten in der Benutzeroberfläche dargestellt werden und welche Interaktionen mit ihnen möglich sind.

Darüber hinaus fallen weitere Repräsentationen und Abbildungen der Geschäftsentitäten in folgenden Zusammenhängen an:

  • Bereitstellung von Services für bestimmte Funktionalitäten – zum Beispiel das Abrufen des Warenbestands (6)
  • Generierung von Word- oder PDF-Dokumenten, beispielsweise Versicherungspolicen oder Bescheide (7)
  • Integration mit weiteren Systemen innerhalb der IT-Infrastruktur des Unternehmens (8)
  • Umfangreiche Migrationen, die aufgrund von Weiterentwicklungen des Schemas der zugrundeliegenden Datenbank erforderlich werden (9)

Jede dieser Abbildungen bringt ihre eigenen Herausforderungen und Aufwände mit sich. Einige von ihnen treten erst nach einiger Zeit in den Fokus. Geschäftsanwendungen stehen in der Regel nicht für sich alleine stehen. Und wenn sie das doch tun, dann nicht für lange Zeit. Sie sind vielmehr eingebettet in komplexe IT-Landschaften und entfalten erst ihr volles Potenzial, wenn sie mit einer Reihe interner und externer Anwendungen verknüpft sind.

Aufwandstreiber: Technische Anpassungen und Betrieb für Unternehmensanwendungen im Lebenszyklus

Heterogene IT-Landschaften

Die IT-Landschaft von mittelgroßen bis großen Unternehmen teilen branchenübergreifend ein charakteristisches Merkmal. Sie bestehen aus großen Anwendungen wie SAP oder größeren Individualanwendungen sowie einer Mehrzahl von kleineren Anwendungen. In Hinblick auf ihre Einbindung in der Abwicklung von Geschäftsvorfällen und den Datenaustausch arbeiten alle Anwendungen im Idealfall integriert.

Aufgrund der Vielfalt der Technologien ihrer Anwendungen (SAP, Java-Anwendungen, Cloudbasierte Anwendungen, etc.) sind diese IT-Landschaften in der Regel auf einer dauerhaft heterogenen technologischen Basis gebaut.

Das bedeutet im Einzelnen:

  • Die einzelnen Anwendungen in dieser Landschaft haben in der Regel ein eigenes Projektteam, eigene Release Zyklen, und eine eigene technologische Basis
  • Bei Individualanwendungen werden je nach Alter der Anwendung und den Vorlieben und Entscheidungen des Projektteams jeweils andere Technologie- und Architekturentscheidungen getroffen. Dies gilt auch für eingebundene Anwendungen die auf einem Produkt wie SAP oder MS Dynamics bestehen.
  • Unterschiedliche Anwendungen haben in der Regel auch unterschiedliche Ansprechpartner auf der Fachseite, die die fachlichen Vorgaben für die Erst- und Weiterentwicklung der Anwendung erstellen.

Die Heterogenität der IT-Landschaft ist ein weiterer Aufwandstreiber, der sich auch durch die heutigen Low Code Ansätze nicht vollständig auflösen lässt. Individuelle Entwicklungsarbeiten lassen sich reduzieren, bleiben aber nicht vollständig aus. Auch wenn Geschäftsanwendungen klein starten, entstehen meist früher als später Integrationsfragen – denn erst integriert entfalten die Anwendungen ihr volles Potenzial.

A12 ist deshalb nicht als reine Low Code Plattform ausgelegt, sondern ein ganzheitlicher Ansatz, der die Systemintegration von Anfang an berücksichtigt.

Jetzt das ganze Whitepaper lesen und mehr über innovative Softwareentwicklung auf Basis von Enterprise Low Code erfahren. Zum Download.