Paradigmen betriebswirtschaftlicher Standardsoftware und Visual Composer

Ist Visual Composer nur ein weiteres Werkzeug zur Erstellung betriebswirtschaftlicher Applikationen?

In meinem zweiten Blog der Visual Composer Blogserie möchte ich versuchen Ihnen diese Frage anhand der Paradigmen betriebswirtschaftlicher Software zu beantworten. Sie werden sich sicherlich fragen, was haben die Paradigmen betriebswirtschaftlicher Standardsoftware mit Visual Composer zu tun? – Diese Frage ist berechtigt, wahrscheinlich denken Sie jetzt, dass ich nur die Werbetrommel für unser Visual Composer Buch rühren möchte und finden es vielleicht sogar anmaßend, dass ich Visual Composer mit den Paradigmen der betriebswirtschaftlichen Standardsoftware assoziiere.


Vermutlich haben Sie auch von den Gerüchten auf Veranstaltungen wie der SAP TechEd oder von DSAG Veranstaltungen gehört, dass Visual Composer nur ein weiteres Werkzeug des SAP Portfolios ist, dass bald aussterben wird wie zum Beispiel der BEx Report Designer. Es ist ja auch naheliegend, weil mit Business Objects Xcelsius haben Sie ein weiteres Werkzeug mit dem Sie innerhalb weniger Sekunden schön animierte Flash Anwendungen zaubern können. An dieser Stelle muss ich jedoch die Visual Composer Gegner enttäuschen, da Visual Composer nicht durch Business Objects Xcelsius substituiert wird. Zur Beantwortung unserer Frage betrachten wir also nun zunächst die historische Entwicklung von betriebswirtschaftlicher Standardsoftware und deren Paradigmenwechsel in den letzten Jahrzehnten.


Historische Entwicklung von Standardsoftware


In den 1960er Jahren gab es nur Individualsoftware und keine Standardsoftware. In den 1970er Jahren wurden die ersten Standard Einzelpakete entwickelt, jedoch handelte es sich dabei nicht um integrierte Standardsoftware. Zu dieser Zeit wurde auch die SAP gegründet und begann mit der Entwicklung ihrer ersten betriebswirtschaftlichen Anwendungen mit dem Fokus auf Lohnabrechnung und Buchhaltung. Diese Software war als Standardsoftware konzipiert, d.h. diese Software konnte auch von anderen Kunden verwendet werden. SAP wird deshalb auch als Mitbegründer der Standardsoftware bezeichnet. SAP setzte im Gegensatz zu IBM auf die Eingabe am Bildschirm anstatt auf Lochkarten, deshalb bezeichneten die SAP Gründer ihre Software als Realtime-System. Viele SAP Softwareprodukte waren deshalb durch ein R in der Namensgebung gekennzeichnet für Realtime. Dieser Paradigmenwechsel war sicherlich einer der Gründe für das Wachstum der SAP.

In den 1980er Jahren wurden immer mehr Einzelpakete betriebswirtschaftlicher Anwendungen angeboten. Diese Einzelpakete waren jedoch nicht integriert, d.h. jedes Einzelpaket hatte seine eigene Datenbank. Die Folge davon, waren die in der Literatur häufig als „Insellösungen“ bezeichneten Systeme. Diese Insellösungen hatten zur Folge, dass Datenredundanzen in den jeweiligen System vorlagen und Daten mehrfach eingegeben werden musst für die jeweiligen Geschäftsprozesse, das wiederum hatte Fehleingaben zur Folge und Dateninkonsistenzen.

Dies hat man erkannt und in den 1990er Jahren wurden die „Insellösungen“ zusammengeführt zu einer integrierten Standardsoftware. Diese unterstützte beinahe alle innerbetrieblichen Prozesse vom Auftragseingang, Materialplanung bis zur Rechnungsstellung und hatte eine gemeinsame Datenbank als Basis, so dass auch Datenredundanzen, Mehrfacheingaben und Dateninkonsistenzen vermieden wurden. Diese Softwaresysteme werden in der Literatur auch sehr oft als integrierte Enterprise Resource Planning (ERP) Systeme bezeichnet. Die IT-Architektur erlebte zu dieser Zeit ebenfalls einen Paradigmenwechsel hin zur Client-Server Architektur weg von der Mainframe Architektur. Der wohl prominenteste Vertreter der integrierten ERP-Systeme auf Basis der Client-Server Architektur ist SAP R/3. Diese Systeme waren die Basis für eine signifikante Optimierung der innerbetrieblichen Geschäftsprozesse über die verschiedenen Abteilungen hinweg und die integrierte Standardsoftware hat sich durchgesetzt. Die Geschäftsprozesse entlang einer Wertschöpfungskette sind jedoch dadurch charakterisiert, dass diese über Unternehmensgrenzen hinweg verlaufen.

In den 2000er Jahren wurden diese unternehmensübergreifende Prozesse dann durch Standardsoftware unterstützt wie zum Beispiel zur Optimierung der Lieferketten über sogenannte Supply Chain Management (SCM) Systeme oder zur Optimierung des Beschaffungsprozess eines Unternehmens über Supplier Relationship Management (SRM) Systeme, die das Lieferantenbeziehungsmanagement umfasst, d.h. die strategische Planung und zentrale Steuerung von Beziehungen eines Unternehmens zu seinen Lieferanten. Bei diesen unternehmensübergreifenden Prozessen wurden zunächst individuell entwickelte und nicht standardisierte Schnittstellen zwischen den jeweiligen Unternehmen realisiert. Diese Schnittstellen waren sehr kostenintensiv in der Implementierung und Wartung. Fusionen und Akquisitionen führten zudem zu einer heterogenen Systemlandschaft in den Unternehmen. Dies war ein weiterer Grund für die Entwicklung, der sehr kostenintensiven individuellen Schnittstellen zwischen den heterogenen Systemen. An für sich war dieses Problem kein Neues in der IT-Welt und zur Beseitigung dieses Dilemma wurde auf Standardisierung gesetzt. Standards zum Datenaustausch wie Extensible Markup Language (XML) und standardisierte Schnittstellen über Web Services legten den Grundstein für einen weiteren Paradigmenwechsel der serviceorientierten-Architektur (SOA).



SOA als eierlegende Wollmichsau?


Die SOA stellen Teilprozesse und Funktionen als Services zur Verfügung über standardisierte Schnittstellen, so dass neue IT gestützte Geschäftsprozesse schnell und flexibel implementiert werden können indem bestehende Funktionen und Teilprozesse zu neuen innovativen Geschäftsprozessen über Unternehmensgrenzen hinweg kombiniert werden. In der Literatur spricht man dann von der Integration und Orchestrierung der Geschäftsprozesse. Theoretisch hört sich dies an als wäre die SOA die „Eierlegende Wollmichsau“. An für sich würde ich dem zustimmen, wenn die Prozessverantwortlichen in den Fachabteilungen ein Informatikstudium im Lebenslauf ausweisen könnten. Dem entspricht jedoch so gut wie nie der Realität. Warum braucht man nach wie vor ein Informatikstudium?
Ganz einfach, die SOA führt zwar dazu, dass man das Rad nicht jedes Mal neu erfinden muss, da Funktionen und Teilprozesse in Form von Services über standardisierte Schnittstellen bereitgestellt werden und somit die Businesslogik wiederverwendet werden kann. Allerdings muss bei der Implementierung neuer IT gestützter Geschäftsprozesse auf Basis der SOA meistens immer noch selbst Coding geschrieben werden. Je nachdem auf welcher IT Plattform man sich befindet ist dies meistens ABAP, Java oder C#. Dies führt in der Regel auch dazu, dass die IT Projekte nach dem klassischen Vorgehen umgesetzt werden, d.h. die Fachabteilungen definieren die Anforderungen in Form eines Lastenhefts. Auf Basis des Lastenhefts definieren die IT Spezialisten dann das Pflichtenheft, dass mehr oder weniger detailliert beschreibt, welche Anforderungen wie umgesetzt werden. Dieses Pflichtenheft muss dann von der Fachabteilung abgenommen werden. Dann wird mit der Implementierung und den Tests begonnen. Wenn alles gut geht und die Kommunikation zwischen Fachabteilung und IT stimmt, erlebt die Fachabteilung keine böse Überraschung wenn sie die Anwendung zum ersten Test sichtet nach Monaten oder sogar Jahren seit Projektbeginn. SOA löst zwar die Probleme der heterogenen Systemlandschaften und bringt Kosteneinsparungen bei der Anwendungserstellung mit sich durch die Wiederverwendung von Services, aber von der Eierlegenden Wollmilchsau kann man trotz des Hypes um SOA leider nicht sprechen.


Anwendungserstellung auf Basis von SOA


Sicherlich ist die SOA ein Schritt Richtung eierlegender Wollmichsau, jedoch sollte man die Vorteile der SOA auch sinnvoll nutzen. Dazu muss man sich die folgenden Fragen stellen. Wäre es nicht genial, wenn man neue Anwendungen erstellen könnte ohne zu programmieren? – Indem man lediglich die bestehenden Services zu einer neuen Anwendung kombiniert mit einer Bedienoberfläche, die man per „Drag and Drop“ aus bestehenden Elementen kreiert. Vermutlich würde dies nicht nur Zeit sparen, sondern sich auch positiv auf das Projekt Budget auswirken. Wenn der Anwender seine Anwendung selbst entwickeln könnte, dann würde er vermutlich auch viel zufriedener mit den neuen Anwendungen sein und diese eher akzeptieren als die Ergebnisse von Lastenheft und Pflichtenheft, die hin und wieder an stille Post erinnern.

Die Antwort auf diese Fragen und Probleme der klassischen Anwendungsentwicklung ist Visual Composer. Dieses Werkzeug der SAP ermöglicht es betriebswirtschaftliche Anwendungen zu entwickeln ohne eine Zeile Code zu schreiben. Im Gegensatz zur klassischen Anwendungsentwicklung werden die Anwendungen mit Visual Composer modelliert. Dies umfasst sowohl den Datenfluss als auch die Bedienoberflächen. Nach einer kurzen Einarbeitungszeit können Mitarbeiter aus den Fachabteilungen damit beginnen neue Anwendungen zu erstellen. Die serviceorientierte Architektur der SAP NetWeaver Plattform ermöglicht dem Anwendungsmodellierer mit Visual Composer auf unterschiedlichste Datenquellen und Services zugreifen zu können. Der Einsatz von betriebswirtschaftlicher Standardsoftware auf Basis einer SOA kombiniert mit Werkzeugen zur modellgetriebenen Anwendungserstellung, wie dem Visual Composer, versetzt die Unternehmen und deren Fachabteilungen nun tatsächlich in die Lage durch eine schnelle und flexible Orchestrierung ihrer Geschäftsprozesse sich an neue Marktbedingungen anzupassen.


Fazit


Die Möglichkeit, dass Anwender aus dem Fachbereich Ihre Anwendungen selbst implementieren können ohne ein Informatikstudium absolviert haben zu müssen, stellt ein Paradigmenwechsel in der Anwendungsentwicklung dar. Die anfangs gestellte Frage, ob Visual Composer nur ein weiteres Werkzeug zur Erstellung betriebswirtschaftlicher Applikationen ist, muss also ganz klar verneint werden. Trotz des Hypes um SOA und meiner Euphorie für die Anwendungsentwicklung mit Visual Composer muss man fairerweise gestehen, dass meistens doch noch eigenes Coding von Entwicklern geschrieben werden muss, da oft nicht alle benötigten Services zur Verfügung stehen.
Die Möglichkeit das Anwendungen von den Anwendern selbst innerhalb kürzester Zeit erstellt werden können durch die Anwendungsmodellierung wirft die Frage auf, ob die klassischen Vorgehensweisen in der Anwendungsentwicklung noch Ihre Berechtigung haben. Dies möchte ich in meinem nächsten Blog erörtern.



The english version of this blog can be found on SDN.

Getagged mit:
2 Kommentar auf “Paradigmen betriebswirtschaftlicher Standardsoftware und Visual Composer
  1. Klaus von Kentzinsky sagt:

    Guten Tag Herr Salein

    Ein sehr Interessanter Artikel.
    Bisher verstehe ich den Visual Composer als eine Art von Componente, die Anwendungsteile aus verschiedenen Bereichen zusammenfügt / koordiniert.

    Der Gedanke einer modellartigen Beschreibung eines (oder mehrerer) Unternehmens, erstellen zu können, die hinreichend ist, daraus Software zusammenzustellen oder per Softwarelogik programmieren zu lassen, ist faszinierend.

    Es wäre schon ein Schritt, mittels socher standardisierter Modellierung ein Pflichten/Lastenheft zu erstellen. Für die programmierte Implementierung Top Down vermute ich allerdings Konflikte, allein dadurch, dass bisher eher Bottom Up gearbeitet worden ist.

    Die jetzige reale BW Implementierungen würden wohl an Gewicht gewinnen, da die steuernden Zahlen hier bereitgestellt werden….

    Jedenfalls vielen Dank für Ihren Beitrag und weiterhin viel Erfolg
    Klaus von Kentzinsky

  2. Nicolet sagt:

    Schönen Guten Tag Herr Salein
    Ihr Beitrag vom letzten Januar zum Thema Anwendungserstellung und Visual Composer hat mich hoch interessiert. Gerne würde ich mich mit Ihnen darüber ausführlicher austauschen, im Hinblick auf die Simplicite Software. Hätten Sie eine Rufnummer oder Email Adresse?
    vielen Dank
    Jerome Nicolet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*