Thema

Entwicklung Migration betriebswirtschaftlicher Software: von Microsoft Excel-basierten Lösungen hin zu agilen serviceorientierten Architekturen.

Vorstellungstermin

Die PG-Vorstellung findet am kommenden Mittwoch, dem 19.05.2010 im Gebäude OH14-Raum 105 statt. Beginn der Vorstellung ist 10 Uhr.

Aufgabe

In dieser Projektgruppe geht es um die Migration von Softwarelösungen aus dem kaufmännischen Kontext. Ziel ist es dabei, auf Microsoft Exel basierende Tabellenkalkulationen in eine vollständige und agile serviceorientierte Architektur [1] [2] [3] [4] zu überführen.

Motivation

Gerade im betriebswirtschaftlichen Umfeld ist es üblich, dass softwaretechnische Lösungen „auf die Schnelle“ auch von Personen entwickelt werden, die über kein ausgereiftes Informatikwissen verfügen. Das Mittel der Wahl für die Umsetzung dieser Lösungen ist dabei meistens eine Tabellenkalkulation wie zum Beispiel Microsoft Excel. Diese Software ist dem Mitarbeiter mit kaufmännischem Hintergrund bekannt und sie bietet alle nötigen Funktionen, um Berechnungen durchzuführen und die damit zusammenhängenden Zahlen übersichtlich darzustellen. Diese Lösungen haben dabei oft einen sehr prototypischen Charakter. Trotzdem bleiben sie meist für lange Zeit im Einsatz und werden sogar kontinuierlich weiterentwickelt, so dass erstaunlich große Lösungen entstehen. Allerdings sind solche Lösungen häufig mit einer Reihe von Nachteilen behaftet. Eine wie oben beschriebene  Lösung kann oft nur von der Person bedient werden, die sie auch erstellt hat. Wenn diese Person die Firma verlässt oder auch nur in eine andere Abteilung versetzt wird, ist es mit sehr viel Aufwand verbunden – manchmal sogar unmöglich - , diese Lösung  zu erklären und weiterzugeben. Die stete Weiterentwicklung führt häufig zu Unübersichtlichkeit und einer Fülle kleiner „Tricks“, die vom Entwickler verwendet wurden, weil ihm keine bessere Lösung eingefallen ist, um mit den beschränkten Mitteln einer Tabellenkalkulation sein Ziel zu erreichen. Das Hauptproblem liegt darin, dass sehr viel implizites Wissen nötig ist, um die „Software“ zu bedienen. Wenn jemand etwas bestimmtes berechnen oder eintragen möchte, so muss er genau wissen, wo er die entsprechenden Zahlen eintragen muss und wo er danach das Ergebnis ablesen kann. Eventuell ist auch noch eine bestimmte Reihenfolge einzuhalten. Ein solcher Use-Case mit dem damit verbundenen Prozess ist in den meisten Fällen nicht dokumentiert bzw. einfach in Freitext verfasst. Der Text kann dabei u.U. missverständlich formuliert sein. Außerdem sind die Excel-basierten Lösungen extrem fehleranfällig, denn sehr schnell kommt es vor, dass der Benutzer vergisst, ein bestimmtes Feld mit einem Wert zu füllen oder einen bestimmten Wert zu aktualisieren. Dies führt natürlich unweigerlich zu falschen Berechnungen. Im Allgemeinen muss noch hinzugefügt werden, dass eine Tabellenkalkulation wie Excel über recht limitierte Mittel verfügt, so dass der Aufruf externer Services schwer möglich ist und eine konsistente Datenhaltung mit anderen im Betrieb eingesetzten Systemen nur manuell oder sehr schwierig zu realisieren ist.

Beispielszenario

Ein Beispiel für eine solche „Lösung“ ist dem Lehrstuhl für Programmiersysteme von einem großen deutschen IT-Dienstleister zur Verfügung gestellt worden. Hier geht es um die Akquise-Applikation für den Bereich des SAP-Hostings. Die Dienstleistung besteht also in der Bereitstellung und Wartung von Servern, auf denen ein SAP-ERP-System läuft und die dazugehörige Akquise-Applikation besteht lediglich aus einem sehr komplexen Excelsheet, welches der Kundenbetreuer dazu benutzt, die Angebote für die (potenziellen) Kunden zu berechnen. Die Komplexität (und damit Unübersichtlichkeit) der Excel-Datei zeigt sich in folgenden Zahlen: Die Datei besteht aus 7 Tabellen mit folgenden Größen: 

Tabelle Nr.	Spaltenzahl	Seitenzahl
1	24	300
2	6	626
3	11	113
4	11	131
5	8	76
6	7	25
7	4	6

In diesen Tabellen kommt es nun beispielsweise zu fehleranfälligen Lösungen wie in Abbildung 1. Hier wird vom Benutzer erwartet, dass eine der Zeichenketten „ja“ oder „nein“ angegeben wird. In Formeln, wie z.B.

=WENN($T$85="ja";WENN($Q$61="ja";'rates of Basic Services'!$G$51;
'rates of Basic Services'!$F$51)*(1-M$64)*M66*(1-$Q$62);0)

wird dieser Wert dann benutzt. Das bedeutet, sobald der Benutzer z.B. „Ja“ oder „J“ eingibt, wird dies als „nein“ interpretiert, da die abgebildete Formel auf Gleichheit mit „ja“ testet.

Formeln wie oben beschrieben befinden sich dabei nicht nur in einzelnen Feldern, sondern hundertfach in den Tabellen. Oft werden diese Formeln auch manuell einfach umgangen. Wenn zum Beispiel ein Preis berechnet wird, der dem Kundenbetreuer insgesamt zu hoch erscheint, so ist es hier gängige Praxis, die Formel in Klammern zu setzen, mit 0 zu multiplizieren und anschließend einen fixen Betrag zu addieren. Leider sieht man einem Feld in der Tabelle nicht direkt an, ob es so manipuliert wurde oder noch „richtig“ rechnet. Dazu muss  in die Formel hinein gesehen werden.

 Konzeptidee zur Softwaremigration

Die beschriebenen Lösungen besitzen zwar die genannten Nachteile, sie bieten jedoch andererseits eine recht gute Basis, um von hier aus eine Migration in Richtung serviceorientierte Architekturen zu starten. Die Tabellenkalkulationen definieren als Prototypen recht genau, was der Anwender auf jeden Fall benötigt. Die Anwendungsfälle können (nach zusätzlichen Interviews mit dem Ersteller und evtl. den Benutzern) recht gut ermittelt und die dazu passenden Prozesse identifiziert werden. Auch kann man den Tabellen gut ansehen, um welche Daten es in der Applikation geht. Zusammen kann dies dann die Grundlage für eine moderne serviceorientierte Architektur bilden. Diese besteht aus vier Schichten: Der Datenbankschicht, der Serviceschicht, der Prozessschicht [5] [6] [7] und der Präsentationsschicht (siehe Abbildung 2). Die Datenbankschicht wird definiert auf Grundlagen der Daten aus den Tabellen. Danach können einzelne Services definiert und implementiert werden, die diese Daten nach außen anbieten und sie entsprechend manipulieren können. Diese Dienste werden anschließend wiederum auf der Prozessschicht durch die komplexen Geschäftsprozesse orchestriert. In der Präsentationsschicht werden  schließlich die einzelnen Prozesse dem Benutzer zur Verfügung gestellt. Nun muss der Benutzer nur noch wissen, was er ausführen  möchte und schon wird er vom System entlang des Geschäftsprozesses geführt. Der Prozess steckt nun in der Software und nicht mehr im Kopf des Benutzers oder in einer Freitext-Dokumentation.

Bei der Entwicklung des neuen Systems soll besonders beachtet werden, dass nicht jeder Dienst immer selbst implementiert werden muss. Viele Lösungen gibt es bereits fertig implementiert und sind als Services einfach in eine SOA zu integrieren. Man kann zum Beispiel wiederum vom Prozess aus bei Bedarf Excelsheets erstellen, ein OpenOffice-System ansteuern oder Daten mit ERP-Systemen wie z.B. SAP R/3, Microsoft Dynamics NAV oder Intuit Quickbooks synchronisieren. Open-Source-ERP-Lösungen sollten hier ebenfalls betrachtet werden. Auch das automatische Verschicken von Benachrichtigungen z.B. per E-Mail oder SMS ist so möglich. Einfacher als in der Excel-Tabelle ist auch das Nachhalten einer History. In den Excel-Lösungen werden oft alte Werte durch neue überschrieben und man weiß nachher nicht mehr, was vorher berechnet wurde. Zur Lösung kann man die Excel-Dateien natürlich einfach beliebig oft kopieren und bei jeder Änderung eine neue Kopie anlegen; schöner ist es jedoch, die alten Daten sauber in dafür vorgesehenen Datenbanktabellen zu hinterlegen und entsprechende Dienste zu definieren, die diese Daten dem Benutzer zugänglich machen.

Generelle Vorgehensweise

Nach der Einarbeitung in die die theoretischen Grundlagen von serviceorientierten Architekturen und Geschäftsprozess-Management und die zu benutzenden Werkzeuge soll zunächst anhand einer bestehenden Excel-Lösung und durch Interviews mit deren Benutzern eine Anforderungsanalyse durchgeführt werden. Dazu gehört unter anderem die Erarbeitung der Datenstrukturen sowie der Geschäftsprozesse. Ganz besonders stehen hier die Anwendungsfälle im Mittelpunkt. Für jeden Anwendungsfall soll später ein entsprechender Prozess existieren, der diesen abdeckt. Für die Realisierung des neuen Systems soll dann geplant und recherchiert werden, welche bestehenden Softwarelösungen und Bibliotheken man als Services einbinden kann, um nicht alles selbst programmieren zu müssen. Dann werden die einzelnen Schichten der SOA in Kleingruppen bearbeitet. Eine Gruppe befasst sich mit der Datenbankschicht, eine Gruppe mit der Implementierung der Dienste, eine Gruppe ist für die Prozesse zuständig und eine Gruppe kümmert sich um die Präsentationsschicht. Die resultierende Anwendung soll eine Webanwendung werden. Die Dienste sollen dabei in einer JEE-Umgebung [8] laufen (EJB [9]), die Präsentationsschicht wird mit einem zeitgemäßen Web-Framework wie z.B. Tapestry [10] erstellt. Bei Bedarf kann die GUI noch mit Techniken wie z.B. Ajax erweitert werden. Bei der Entwicklung soll insgesamt sehr agil vorgegangen werden (Stichworte „Rapid Prototyping“ und „Extreme Programming“). Es wird also recht schnell ein kleines, laufendes System entwickelt, welches sukzessive durch Funktionen erweitert wird. Dabei soll das System stets lauffähig bleiben und begleitend getestet werden.

Teilnahmevoraussetzungen

Erforderlich

• Fundierte Kenntnisse mindestens einer objektorientierten Programmiersprache (z. B. Java)
• Kenntnisse in dem Gebiet Software-Design/Implementierung durch erfolgreiche Teilnahme an mindestens einer der Vorlesungen „Formale Methoden des Systementwurfs“, „Darstellung, Verarbeitung und Erwerb von Wissen“, „Effiziente Algorithmen“, „Modellgestützte Analyse und Optimierung“, „Mensch-Maschine-Interaktion“.

Wünschenswert

• Grundlegende Kenntnisse serviceorientierter Architekturen
• Grundlegende Kenntnisse zur Geschäftsprozessmodellierung
• Objektorientierte Modellierung (UML)
• Datenbankkenntnisse 

Minimalziele

1. Einarbeitung in grundlegende Theorien und Formalismen von serviceorientierten Architekturen und zur Modellierung von Geschäftsprozessen
2. Erstellung einer Anforderungsanalyse mit Datenschicht und Prozessen
3. Recherche bzgl. Software, die als Services in das System eingebunden werden kann
4. Implementierung der Datenbankschicht
5. Festlegung und Implementierung der Services
6. Modellierung und Implementierung der Geschäftsprozesse
7. Implementierung der Präsentationsschicht (GUI)
8. Implementierung einer History-Funktion
    

Zeitraum

 Wintersemester 2010/2011 und Sommersemester 2011

Umfang

Jeweils 8 Semesterwochenstunden

Ansprechpartner

• Dipl.-Inform. Markus Doedt
• Dr. Ralf Nagel
• Prof. Bernhard Steffen

 

Literatur

[1]  He, H. What is Service-Oriented Architecture. http://www.xml.com/pub/a/ws/2003/09/30/soa.html 
[2] Tiziana Margaria, Bernhard Steffen: Agile IT: Thinking in User-Centric Models. ISoLA 2008: 490-502
[3]  Tiziana Margaria, Bernhard Steffen: Service Engineering: Linking Business and IT.
 IEEE Computer 39(10): 45-55 (2006)
[4]  Tiziana Margaria, Bernhard Steffen, Manfred Reitenspieß: Service-Oriented Design: The Roots.
  ICSOC 2005: 450-464
[5] W.M.P. van der Aalst: Business Process Management Demystified: A Tutorial on Models,
  Systems and Standards for Workflow Management. In Lectures on Concurrency and Petri Nets,
  volume 3098 of Lecture Notes in Computer Science, pages 1-65. Springer-Verlag, Berlin, 2004.
[6] Peter Dadam: The Future of BPM: Flying with the Eagles or Scratching with the Chickens?, In
  Business Process Management, volume 5240 of Lecture Notes in Computer Science, Springer-
 Verlag, Berlin, 2008
[7] Stephane Cagnon, Thomas Woodley: BPM and SOA: Synergies and Challenges. In Web
 Information Systems Engineering – WISE 2005, volume 3806 of Lecture Notes in Computer Science,
 Springer-Verlag, Berlin, 2005
[8] Sun Microsystems: Java EE at a Glance, http://java.sun.com/javaee/ 
[9] Sun Developer Network: Enterprise JavaBeans Technology: http://java.sun.com/products/ejb/ 
[10] Apache Software Foundation: Tapestry, http://tapestry.apache.org/