Software-Plattformen und
Entwicklungsumgebungen (SEU)

Selten werden Systeme auf der grünen Wiese entwickelt, sondern passen in eine vorgegebene Unternehmenslandschaft, die mit den entsprechenden Märkten für Methoden, Verfahren und Werkzeugen korrespondiert. Zuweilen aber wird durch den technologischen Wandel eine generelle Neubestimmung erforderlich. Hier sollen einige Aspekte diskutiert werden die für eine Neubestimmung einer technischen Plattform hilfreich sein können:

Wie soll die zukünftige IT-Basis ausgerichtet sein?

Zunächst ist es nicht wichtig, mit dem Vergleich aktueller Technologien einzusteigen, sondern eine bedarfsgetriebene Analyse anzufangen. Aus dem Top-Down Entscheidungsbaum lassen sich einige Präferenzen erarbeiten, die aus der Perspektive der Technologie übersehen oder anders priorisiert werden würde.

Generische Betriebsanforderungen

Einige Anforderungen sind allgemein gültig, fast schon banal, und in den einzelnen Unternehmen nur leicht unterschiedlich gewichtet.

  • IT sollte die Geschäftsprozesse effizient und sachgerecht unterstützen
  • Die technische Basis soll zuverlässig und robust auf potentielle Störquellen vorbereitet sein, so dass ein reibungsloser Betrieb sichergestellt ist.
  • Interoperabilität in einem Umfeld eines Konzerns oder enger Kunden-Lieferanten-Beziehungen sind gegebenenfalls entscheidend.
  • Flexibilität hinsichtlich sich ändernder fachlicher und technischer Anforderungen ist erforderlich
  • Auch langfristig soll die technische Basis - so weit erkennbar - Bestand haben, da weiter Migrationsschritte möglichst vermieden werden sollten.
  • Bei allem sollte der Aufwand für die entsprechenden Komponenten einer IT-Lösung möglichst niedrig sein.

Kurz: Der Kosten-Nutzen-Aspekt sollte im Vordergrund stehen. Oftmals wird jedoch die Kostenseite überbetont, und darin die Fokussierung auf den Nutzen verloren (meist bei Projektplanung). Oder aber es wird aus scheinbar strategischer Technik-Orientierung der Kostenaspekt aus den Augen verloren – das beobachtet man überraschend häufig in großen Organisationen, die sich aus Vereinheitlichung Synergie-Effekte versprechen.

Die Auswahl der IT-Umgebung, inklusive der Software-Entwicklungsumgebung, sollte sich nach diesen Zielen richten.

Requirements Management

Im Mittelpunkt sollten die Anforderungen stehen, die in der jeweilige Betriebssituation konkret verfolgt, da sich die Anforderungen ständig ändern, bzw. einige Anforderungen vorher nicht bekannt sind oder sich in der Priorität verschieben. Requirements Management hat zuerst die Aufgabe, die Anforderungen möglichst präzise zu verfolgen, d.h. diese in ihrer Priorisierung zu dokumentieren und jede Änderung fortzuschreiben. Eine Verknüpfung mit Lösungen ist notwendig.

Die Bedeutung der Requirements im Prozess soll durch ein Gedankenexperiment verdeutlicht werden:

Stellen wir uns vor, zu einem Problem X gibt es 4 Lösungsalternativen:

  • Eine klassische Lösung mit Pflichtenheft und aktueller High-End-Programmierumgebung, aber eher schwachem Requirements-Management.
  • Eine innovative RAD-Lösung (Rapid Application Development) mit schwachen Requirements-Management, aber mit agilen Methoden (XP)
  • Eine Open Source Tool Umgebung, die ad-hoc Lösungen, ggf, als Ergänzung zu gekauften Lösungskomponenten produziert
  • Ein dominierendes ERP-Produkt, dass durch integrierte Werkzeuge angepasst und erweitert wird.

Keiner der Lösungsansätze kann per se ohne Betrachtung der Unternehmenssituation als besser oder schlechter angesehen werden. Hier gilt es, die Anforderungen genauer zu beachten, um dann eine sachgerechte Entscheidung zu fällen. Einige Anmerkungen zu einem fiktiven Unternehmen mögen dies beleuchten:

  • Die klassische Lösung ist tendenziell als teuer und wenig flexibel verschrien. Da aber andere Risiken vermieden werden, kann es dennoch die richtige Umgebung sein. Gehen wir davon aus, dass hier durch bekannte Kommunikationsprobleme und nicht bekannte Einschränkungen eine Bedarfsdeckung von 70 % erreicht werden kann.
  • Die RAD-Lösung / XP verursacht weniger Overhead, kommt schnell zu Ergebnissen und sorgt für eine hohe kurzfristige Bedarfsdeckung (bis zu 95 %). Architektonisch können sich allerdings massive Probleme auftun, da die Struktur der Anwendung mitunter nicht hinreichend geplant wurde. Zuweilen werden die hohen Erwartungen nicht erfüllt.
  • Open Source ad-hoc Lösungen können ebenfalls sehr effizient zu Lösungen kommen, jedoch droht hier um so mehr, dass ein unwartbares Dickicht entsteht. Durch Mängel im Hersteller-Support und/oder der Funktionalität der Werkzeuge bestehen Risiken, die aber oft überschätzt werden. Der Integrationsbedarf der unterschiedlichen Komponenten nimmt dann einen großen Anteil des Aufwandes ein. Vermutete Bedarfsdeckung: 80 %
  • Im Falle eines dominierenden ERP-Produktes wird durch Anpassungen und den spezifischen Unternehmensbedarf entweder zusammen mit den Lizenzkosten ein Gesamtaufwand generiert, der zwar hoch bedarfsdeckend ist, aber dann doch am teuersten. Oder aber die Betriebsorganisation wird strikt nach den Vorgaben der Fertig-Lösung umgebaut. Das kann im Extremfall ebenso zu erheblichen Reibungsverlusten führen. Gehen wir von einem starken Customizing aus; neben hoher Bedarfsdeckung ist auch eine aufwändigere Wartung erforderlich, da diese mit neuen Releases abgeglichen werden muss.

Einige der beschrieben Merkmale lassen sich auch in anderer Kombination darstellen. Es handelt sich hierbei nur um eine Beispielillustration. Um beim Beispiel zu bleiben: Rechnen wir mit einem potentiellen Nutzen in Höhe von 10 Mio. Euro bei 100 % in 5. Jahren und Kosten entsprechend der Tabelle:

Nutzen in % Nutzen in Mio. € TCO in 5 Jahren
klassische Lösung 70 7 3
RAD-Lösung / XP 90 9 2
Open Source ad-hoc Lösung 80 8 1
dominierendes ERP 85 8,5 2,5

Daran wird deutlich, dass ein Mehrnutzen zum Teil die Mehrkosten deutlich übersteigt. Man kann mit den Zahlen spielen und erkennen, wann ein Lösungsweg jeweils vorteilhaft ist.

Auch Open Source Produkte sind kostenträchtig; zuerst zur Entwicklungkosten an, hernach Betreuungs- und Betriebskosten. Allerdings ist der Support-Bedarf meist erheblich einfacher, denn die aufwendige Lizenzverwaltung und Beschaffung entfällt weitgehend. Zudem kann eine Open Source Lösung durchaus bedarfsgerechter sein als eine Standard-Lösung und hier weitere Punkte gut machen. Die Beurteilung des Nutzens ist alles andere als trivial.

Soweit das Beispiel. Hieran wird deutlich, das eine Auswahl der SEU starke Unterschiede hinsichtlich der Kosten-Nutzen-Beziehung nach sich zieht.

Mein Punkt ist nun, durch Requirements Management eine höhere Deckung zu erzielen und unnötige Aufwendungen zu vermeiden. Erfahrungsgemäß führen nachfolgende Änderungen (Anforderungsshift) zu stark wachsenden Kosten.

Es geht also darum, an das altbekannte Min-Max-Prinzip der Betriebswirtschaft neu zu beleben. Die 100 %-tige Bedarfsdeckung ist zum einen wegen Zielkonflikten grundsätzlich nicht möglich und zum anderen wegen des exponentiell steigenden Aufwands in der Nähe der Sättigungsgrenze meist nicht sinnvoll. Im Folgenden werde ich die TCO (Total Cost of Ownership) und deren Beeinflussung durch die Auswahl geeigneter Plattformen diskutieren.

Vorüberlegungen Total Cost of Ownership

Bei der TCO geht es nicht nur um die isolierte Betrachtung des Preises einer Komponente, sondern gegebenenfalls aller aufwandsrelevanten Aspekte, einschließlich der Verzinsung des eingesetzten Kapitals und einer Risiko-Bewertung. Hier sollten also nicht nur die eigentlichen Software-Entwicklungskosten, einschließlich der benötigten Werkzeuge, Training und Personalbedarf hinsichtlich Plattform und Anwendungsarchitektur berüchsichtigt werden, sondern auch Betriebsaspekte einschließlich der Überwachung und Service Level Agreements-relevantem Incident und Problem Management geprüft werden.

So ist die Frage eines stabilen Systembetriebes zum einen unter dem Aspekt des Nutzens zu sehen: Wenn eine Anwendung nicht verfügbar ist, dann entgeht der Nutzen. Zum anderen ist der Support eine aufwändige Angelegenheit, die organisiert sein will. Die Kapazität, einen komplexen Fehler sachgerecht zu analysieren, muss auch ohne Störfall bereit gestellt werden. Zum Dritten werden qualitätssteigernde Maßnahmen, die die Ausfallwahrscheinlichkeit proaktiv reduzieren, mitunter als Betriebs- oder als Entwicklungsaufwand klassifiziert.

Hier zeigt sich aber eine Architektur-Abhängigkeit im Kontext des Tool-Bedarfes: In einer Multi-Tier Application ist die produktionsnahe Störungsanalyse nur sehr schwierig möglich. Entweder werden architekturmäßige Test-Sockets bei der Entwicklung mit programmiert, oder es werden aufwendige Werkzeuge wie AD4J in das Portfolio aufgenommen. In jedem Fall stellt neben der vorsorglichen Inbetriebnahme von Überwachungswerkzeugen einen nicht unerheblichen Aufwand dar, der in den Plattform und Architekturentscheidungen berücksichtigt werden muss.

Der Bedarf nach derartigen Werkzeugen ist in einer integrierten Software-Umgebung, die diese Aspekte bereits gut abdeckt (z.B. Visual Studio) nicht in gleichem Maße gegeben, eine einfache Architektur, z.B. AJAX/PHP/APACHE hat hier wenige kritische Komponenten, so dass hier ein Bedarf zum Debugging weit geringer angesetzt werden muss.

Die Komponenten, die für die Kalkulation des TCO zu beachten sind:

  • Personalaufwand zur Entwicklung, Support und Betrieb
  • Lizenzkosten Entwicklungswerkzeuge, Zusatztools, Management-Software und gegebenenfalls Anwendungen
  • Wartungskosten der lizenzierten Software.
  • Hardware- und Betriebskosten für Entwicklung und Betrieb
  • Netzwerk und sonstige Kosten

Eine Amortisationsperiode sollte nicht zu kurz aber auch nicht zu lang angesetzt werden. Ein Zeitraum von 5 Jahren ist je nach Anwendung eine gute erste Näherung. Es sei hier auf die Sequenzierung und Life-Cycle Betrachung innerhalb von IFM (Incremental Funding Methodology) verwiesen.

Früher galt die Faustregel, dass die Kosten vor allem in der SW-Entwicklung lägen. Mittlerweile werden diese von den Betriebskosten oft deutlich überholt. Es sind also auch Betriebskosten-senkende Maßnahmen bereits in Konzeption und Entwicklung zu berücksichtigen. Auch sind Kosten für Lizenzen und externe Services mittlerweile zum ernst zu nehmenden Faktor geworden.

Produktivität ist ein Schlüsselwort. Wie lange die Bereitstellung einer definierten Funktionalität benötigt, kann bestenfalls abgeschätzt werden. Und diese ist auch von der Qualität des Entwicklers in hohem Maße abhängig. Allerdings stellt diese Größe das A und O für Entscheidungen dar. Denn wenn die Produktivität in Abhängigkeit von Architektur / Plattform sich um 25 % unterscheidet, ist auch von analogen Support-Kosten auszugehen. Denn eine effizienter Umgebung lässt sich oft überproportionaler Ersparnis im Support niederschlagen:

Weniger Code – weniger Fehleranfälligkeit - weniger Analysebedarf.

Selbst bei einem kleinen Team von 4 Personen wäre bei vergleichbarer Leistung das produktivere Tool mit einer AK sparsamer, selbst wenn die Lizenzkosten deutlich höher wären als bei der Konkurrenz. Aber die Regel von hohen Lizenzkosten = höhere Effizienz stimmt nicht im Allgemeinen.

Entwicklungsparadigmen

Hausbau

Der klassische Ansatz ist

  • die Analyse des Fachproblemes, (Reqirements)
  • der fachliche Entwurf (Pflichtenheft oder Fachkonzept,
  • der technische Entwurf (Technische Spezifikation) und die
  • Implementierung in einer geeigneten Umgebung.

Bekannt ist dieses Vorgehen als das Wassefall-Modell. Da hierin viele Schwächen sind, wie z.B. aufwendige Anpassungen durch Änderungen (Moving Target), begrenzte Antizipationsfähigkeit der Auftraggeber und hohe Kosten, erkannt wurden, hat man von dem Wasserfall Weiterentwicklungen und Alternativkonzepte zu Vorgehensmodellen betrieben. Besonders zu nennen sind das V-Modell, RUP und CMMi. Ein Thema darin ist die Abdeckung von Aufgaben, Effizienzsteigerung, Bereitstellung von Prototypen, kurze Entwicklungszyklen und planbare Schritte.

Als Metapher bleibt hierbei der Bau eines Hauses: Nach der Planung durch den Architekten beauftragt der Bauherr das Fundament, dann den Rohbau und Innenausbau.

In den letzten Jahren haben vor allem agile Methoden (XP, Scrum), sogenannte Leight Weight Processes, von sich reden gemacht. Ein sehr empfehlenswerter Aufsatz von Martin Fowler: The New Methodology und Is Design Dead?

Golfspiel

Alternativ findet sich heute oft ein anderer pragmatischer Ansatz:

  • Nach einer Grobanalyse wird ein vorgegebenes konfigurier- und erweiterbares Basiskonzept ausgewählt und daran weiter entwickelt.
  • Generische Basiskonzepte sind z.B. ERP, Dokumentenverwaltung / Collaboration, CMS, CRM
  • Spezifische Basiskonzepte sind Businessfunktionen, z.B. Materialwirtschaft, FiBU etc.
  • Die Entwicklung orientiert sich an den bereits vorhanden Funktionen und ergänzt die fehlenden Funktionen.
  • Hintergrund ist das Interesse, das Rad nicht erneut erfinden zu wollen
  • Oft finden sich Mischformen dieser Ansätze.

Als Metapher ist hierbei das Golfspiel: Nach Anpeilung des Zieles wird mit dem Driver möglichst nah an das Loch heran geschlagen. Schließlich eingelocht mit dem Putter.

Werkzeugkasten

Überlegungen um Werkzeuge und Methoden zeigen: Durch die Festlegung auf einen Werkzeug-Satz wird das Entwicklungsparadigma bereits zum gut Teil vorgezeichnet. So sollte es zumindest sein, wenn in den Werkzeugen viel Methodik vorgesehen ist.

Einige Teams gehen jedoch davon aus, dass sie sich mehr Freiheiten, vor allem die Nutzung eigener Vorerfahrungen, stärker im Projektvorgehen vorbehalten möchten. Das kann durchaus angemessen sein, jedoch ist dann bei Auswahl der Werkzeuge eben kein umfassendes methodengetriebenes Werkzeugset zu präferieren, denn dann würden die Inkonsistenzen der Methodik einen zusätzlichen Stressfaktor bringen.

Merke: Werkzeuge und eingesetzte Methoden müssen zueinander passen. Weitere Hinweise im Artikel ERD Werkzeuge.

Das RAD neu erfinden?

Noch vor wenigen Jahren war der Hype auf sogenannten 4GL-Umgebungen, die auf Rapid Application Developent (RAD) und leistungsstarker Client-Server-Applications setzten. Namen wie Powerbuilder, Delphi oder Centura waren damit bekannt. Mit dem Trend zu Web-Basierten Applikationen verloren diese an Zuspruch und leben mangels Anwendern eher ein Schattendasein.

Heutzutage wird häufig von einem Architektur-getriebenen Ansatz ausgegangen. Dies wäre z.B. ein Model-driven Ansatz mit J2EE Application Server und Persistenz-Framework. Die Frage ist hierin weniger Nutzengetrieben, sondern orientiert sich an dem Architekturmodell. Als Besonderheit dieser Architektur ist das kombinieren mehrerer Werkzeuge unterschiedlicher Hersteller, teils Open Source, teils High-End-Produkte.

Ähnliche Ansätze hat man in der Microsoft.NET Architektur. Nur läuft hier vieles herstellerzentriert ab. Neben einer breiten und soliden Grundplattform von Microsoft Visual Studio, MS Windows Server, IIS, SQL Server etc. gibt es weitere Zusatz-Anbieter. Allerdings ist das Entwicklungsparadigma deutlich kompakter und auf weniger umfangreiche Varianten eingeschossen. Der Visual Studio-Ansatz entspricht weit mehr dem RAD-Konzept als dies bei der klassisch Java-Welt der Fall ist.

Microsoft bietet mehrere Plattformen, um von diesen ausgehend, Zusatzfunktionalität mit .NET zu entwickeln. Z.B. CRM oder SharePoint Services liefern eine Anwendungsbasis für weitergehende Entwicklungen.

Der Open Source Ansatz mit PHP hat eher seine Wurzel in der pragmatischen ‚Simplicity’ als im architektonischen ‚Overhead.’ Als Bottom-Up Geschichte hat er neben einer großen Verbreitung auf Tausenden von Web-Sites und einer Menge beeindruckender erweiterbaren Produkte eine besondere Beachtung verdient. Diese Plattform hat sich als ebenfalls als leistungsfähig erwiesen und kann auch große kommerzielle Anwendungen effizient handhaben. Hier steht nicht eine durchdachte Architektur im Vordergrund, sondern schlichte Pragmatik: Die Umsetzung ist oft nicht elegant, aber schnörkellos und transparent. Ergänzend zu dem Code-basierten Ansatz lassen sich mit Generatoren und RAD-Tools (z.B. Delphi for PHP) auch PHP-Anwendungen mit modernen Bearbeitungsweisen bearbeiten. Oder aber, es werden Module zu eine bestehenden PHP-Plattform erstellt, z.B. Joomla! oder Drupal s.u.

Der Ansatz von Oracle Application Express (APEX) ist die Bereitstellung von schnell zu entwickelnden Anwendungen in PL/SQL, die direkt in der DB ausgeführt werden und über HTML direkte Browser-Anwendungen erstellt. Ursprünglich für kleine Anwendungen konzipiert verfügt diese Plattform mittlerweile über Merkmale, die auch größere DB-Anwendungen damit bearbeitbar erscheinen lassen.

Ruby on Rails (RoR) ist ein innovativer RAD-Ansatz, der auf höchste Produktivität setzt. Die Lines of Code und die Entwicklungszeit konnte abermals dramatisch reduziert werden.

Erweiterungsplattformen

Völlig anders ist das Angebot der Application Lieferanten: SAP und andere liefern eine sehr breite Grundkonfiguration für Geschäftsanwendungen, die durch Customizing und Erweiterungen mit ABAP/4 und Java Vorteile versprechen. Wenn der Leistungsumfang der Application bereits in Zielnähe liegt, ist eine derartige Lösung oft recht effizient.

So kann ein vorgegebenes anwendungsnahes Szenario einen Kickstart geben, der schnell zu Ergebnissen führt. Wenn es nicht bereits eine vorgegeben fachliche Anwendungslogik wie z.B. bei SAP ist, dann eignen sich generische Produktkategorien zu einem derartigen Ansatz. Beispiele:

  • Mit Drupal ist eine Produktplattform im PHP-Umfeld definiert, dass mit Content/Dokumentenmanagement, User-Management, Community-Funktionen und strukturierten Verwaltungsfunktionen die Basis für spezielle DB-Applikationen liefern kann.
  • CRM - Customer Relationship Management ist zunächst ein Konzept, kein Programm. Meist versteht man darunter aber die Implementierung, z.B. bei Microsoft Dynamics CRM. Ausgehend von einer Grundfunktionalität für Marketing, Kontaktmanagement und Servicees kann dies per Plug-Ins beliebig erweitert werden.

Alle Ansätze könnten alternativ zur Problemlösung eines weiten Spektrums von Anwendungen eingesetzt werden.

Simplicity und Main-Stream

Eine Lehre aus der Vergangenheit: Nicht die effizienteste Umgebung ist auch langfristig die Vorteilhafteste. Auch heute noch gibt es große COBOL-Anwendungen, obwohl dieses Sprachkonzept lange schon verpönt ist und mit wesentlich produktiveren und ausdrucksstärkeren konkurriert. Grunde dafür sind:

  • Breite Basis bestehender Anwendungen macht diese Plattform zum Selbstläufer
  • Simplicity: Cobol ist zwar geschwätzig und für bestimmte Anwendungsbereiche begrenzt, aber einfach zu verstehen und zu warten. Darum können auch COBOL-Altanwendungen weiter geführt werden, selbst wenn der Trend zu moderneren Plattformen führt.

Letzteres halte ich nicht für ein zwingendes Argument, aber gerade ‚Simplicity’ und ‚Marktakzeptanz’ sind nicht zu unterschätzende Faktoren, die unter anderem auch dazu führen, dass Visual Basic zu den meist genutzten Plattformen für Anwendungsentwicklung wurde. Also: nicht architektonische Finesse, sondern wartbare Einfachheit sind starke Argumente für den Bestand.

Infrastruktur

Für alle Anwendungsentwicklung ist allerdings eine Infrastruktur erforderlich die folgende Komponenten abdeckt.:

  • Server-Infrastuktur für Entwicklung, Test und Produktion. (App-Server und DB-Server)
  • Requirements und Bug-Tracking
  • QS / Tests / Testfälle und Testdatenbereitstellung
  • Dokumentationsverfahren
  • Source Code-Verwaltungen und Versionierung
  • Configuration Management und Freigabe-Verfahren
  • Produktionsüberwachung und Diagnose-Werkzeuge
  • Incident Tracking und Application Suppport

Einige der SEU liefern bereits Unterstützung für einzelne Aspekte, hier sind aber vor allem Methoden und Organisation gefragt, nicht primär die Werkzeuge.

Architekturdiskussion - Objektorientierung

Die Frage nach der angemessenen IT-Architektur wurde bereits be dem Design von Programmiersprachen gestellt, erreichte aber mit der Objektorientierung ein hohes Niveau. Man fragte: Wie bilde ich Vorgänge in der realen Welt sachgerecht in einer IT-Lösung ab?

Denn wenn diese Frage gut beantwortet wird, vermeide ich grundsätzliche Probleme durch falsche Abbildungen. Gute Architektur führt demnach zu besseren und wartungsfreundlicheren Lösungen.

Ein weiterer Ausgangspunkt war die Wiederverwendbarkeit: Einmal erstellte Lösungen sollten nicht abermals in Varianten neu erfunden werden. Synergie ist gefragt ... und Vererbung.

Zum Dritten machte man die Beobachtung, dass gerade bei einer Änderung an einer Stelle völlig unerwartete Nebenwirkungen an anderer Stelle auftraten. Es ging um eine Isolation der Architektur-Bestandteile - Kapselung. Aus diesen Ansätzen entwickelten sich Objekt-Orientierte Architekturen, die mit Smalltalk, einer Sprache jenseits des aktuellen Hypes, sehr konsequent entwickelt wurde. Aus unterschiedlichsten Gründen wurde allerdings der Strang um C++ und seiner Weiterentwicklung in Java präferiert und in den Mittelpunkt des Interesses gehoben.

Die unterschiedlichen Ziele gerieten nicht nur mit sich selber, sondern auch mit der beschworenen Realität in Konflikt. Um den Spagat einer Zielharmonie zu schaffen, wurden Abstraktionen und Vererbungsbäume konstruiert, die sich eben so weit von der realen Welt entfernten, dass man weder von Fachproblemen mehr sprach, noch von Bits, Bytes und Prozessorzyklen. Die OO Welt hatte sich weitgehend verselbstständigt und ist zu einem eignen Universum 'gereift'. Denn da es wegen der Komplexität der realen Welt eben keine Engführung auf nur ein Lösungszenario gibt, sprossen die abstrakten Konzepte in immer neue Richtungen.

Die Ablösung der Architekturdiskussion von der realen Welt führte eben auch zu deren Zersplitterung. Die Bemühungen, methodisch und technisch die Herde auf Spur zu halten, waren immens aber nur partiell von Erfolg gekrönt. Man diskutierte und arbeitete an Baustellen, die letztlich ihre Wurzeln in sich selber haben, nicht mehr in den Fachproblemen der realen Welt. Eingeweihte mögen schmunzeln, wenn sie Klassennamen wie UseCaseController finden ...

Praktiker schütteln da eher mit dem Kopf und machen irgendeine Lösung ... Hauptsache, sie funktioniert. Dies führt allerdings zu einer weiteren Zersplitterung. Da die Wahl eben häufig nicht geordnet und rational durchgeführt wird. Dritte können dann raten, auf welcher Seite das Chaos größer ist.

Zwischen beiden Extremen gilt es nun einen Kompromiss zu finden: Architektur-Probleme sollten durchdacht und nicht dem Zufall überlassen werden, aber die Bodenhaftung zum konkreten Problem darf nicht aus den Augen verloren werden.

Exkurs: RDBMS

Die permanente Datenhaltung ist in den allermeisten Fällen ein Muss. Hier haben sich relationale Datenbank-Management-Systeme (RDBMS) durchgesetzt. Oft bietet die Die Auswahl der DB eine bestimmte Infrastruktur für das SEU, denn DB-Hersteller versuchen zwar einerseits, den universellen Charakter zu betonen, schaffen aber besondere Vorteile für ein gewisses Gespann.

Die aktuellen RDBMS im Überblick

  • Oracle 10g / 11g gehört sicher zu den verbreitetsten Systemen, die plattformübergreifend eingesetzt werden. Neben einer kostenlosen Einstiegsversion (Express Edition) gibt es die teuren Enterprise Edition und Standard-Edition. Als Besonderheit ist hier die prozedurale Sprache PL/SQL zu nennen, die auch in OLTP-SEUs wie Oracle Forms und APEX Einsatz findet. Ansonsten unterstützt Oracle vor allem Java, aber auch in .NET Umgebungen versucht sich Oracle als die bessere Alternative darzustellen.
  • IBM DB2 UDB - auch DB2 LUW genannt - ist ebenfalls verbreitet, hat aber neben Ähnlichkeiten noch immer gravierende Unterschiede zu der z/OS-Implementierung von DB2. Die Lizensierung ist vergleichbar mit Oracle. UDB hat eine eigene prozedurale Sprache SQL PL, die aber weit weniger bedeutsam als PL/SQL ist. Ferner lehnt sich DB2 an vorhandene Sprachen an, die allerdings etwas schwieriger in den Kern einzubinden sind. IBM unterstützt hauptsächlich Java, ist aber für andere SEU offen.
  • MS SQL-Server 2005 ist mit den beiden anderen großen RDBMS vergleichbar, bleibt aber in den Lizenzaufwendungen deutlich unter diesen. Neben der von Sybase übernommenen prozeduralen Sprache Transact-SQL für Stored Procedures und Trigger werden mittlerweile .NET Sprachen unterstützt. Auffällig ist vor allem die reichhaltige Aussatattung der Datenbank-Linzenz bereits ab Standard Edition Grundpaket:
    • Leistungsfähige Verwaltungswerkzeuge, inkl. Modellierungstools mit ERD
    • Integration Services (ehemals DTS): eine mächtige ETL-Umgebung
    • Analysis Services: Ein zweiter multidimenionaler Server, der marktführende OLAP-Storage
    • Reporting Services: Grundlage für Enterprise Reporting.
Jede dieser Komponenten alleine könnte bereits Kaufargument sein. Als Nachteil wird allerdings genannt, dass ein Windows Server Betriebssystem erforderlich ist.
SQL-Server ist für .NET Umgebungen die erste Wahl, kann aber auch mit anderen SEU betrieben werden.
  • MySQL ist mittlerweile eine durch die Menge an Installationen und beeindruckende Merkmale wie Spitzenperformance eine ernstzunehmende Konkurrenz für die anderen RDBMS geworden. Und das nicht nur wegen seine kostenlosen Open Source-Herkunft. MySQL arbeitet im Standard ohne Transaktionssicherung, kann aber optional auch mit einer transaktionalen Engine betrieben werden. Dieser vermeintliche Nachteil ist de facto ein Vorteil, denn so können langsame (d.h. teure) Transaktionsverarbeitung auf die Anwendungsteile reduziert werden, wo diese auch benötigt werden. DWH-Anforderungen brauchen dies nicht und können somit ohne Ballast effizienter arbeiten.Auch große Datenbestände lassen sich mit MySQL verwalten.
    MySQL wird zwar sehr häufig im Kontext mit PHP genannt, kommt aber mit den meisten SEU gut zurecht.
  • HSQLDB ist neben MySQL eine neue Open Source Plattform, die sich mit ganz erstaunlichen Merkmalen einen Platz unter den starken RDBMS erobert. Mit minimalem Ressourcen-Profil eignet sie sich als Embedded-DBMS. Als Server unterstützt sie Firewall-freundliche Protokolle. Und glänzt mit spitzen-Performance, die sogar MySQL in den Schatten stellt - u.a. mit InMemory-Tables. Einziger Schwachpunkt: Zur Zeit werden nur DB-Größen bis 8 GB unterstützt.
    Vor allem in Open Source Java-Projekten hat HSQLDB seine Unterstützung gewonnen (Open Office, JBoss, Xamba uvm.), ist aber weben der offenen Protokoll-Unterstützung grundsätzlich auch für Dritt-SEU geeignet.

Entscheident ist mitunter der Entwurf des DB-Modelles. Ob dieser im Kontext eines umfassenden modellbasierten Toolsets geschiehl, konventionell mit der ad-hoc Erstellen von Create-Table Scripten oder mit klassischen DB-Design-Werkzeugen ... siehe dazu den Artikel ERD Werkzeuge

Die SEU - Kandidaten im Einzelnen

Im Folgenden werden einige SEU spezifischer betrachtet und in seinen Merkmalen kurz vorgestellt.

Java - Eclipse

Java wird häufig heute als der Standard in der herstellerunabhängigen Software-Entwicklung angesehen. Neben einer reichen objektorientierten Sprache und dem Merkmal auf allen Hardware- und OS-Plattformen vertreten zu sein, wird er sowohl von großen Herstellern, als auch von vielen Open Source Projekten unterstützt.

Die alten Makel, dass Java wenig effizienten Code erzeugt, relativ langsam läuft und Java-Projekte meist katastrophal hinter ihren Erwartungen zurück liegen, ist mittlerweile Vergangenheit, denn es gibt mittlerweile viele effiziente Anwendungen, die zeigen, das auch Java-Anwendungen schnell arbeiten können. Bestehen bleibt die schier unüberschaubare Menge an Entwicklungsvarianten, Ergänzungskomponenten und Frameworks, die jeweils eine eigene Welt darstellen.

Ob nun Servlets mit J2EE-Beans in einem Persistenz-Framework entwickelt werden oder modulare Applets ... innerhalb der Java-Plattform gibt es viele Welten.

Als SEU für Java hat sich Eclipse fest etabliert: Eine leistungsfähige Oberfläche, die auch für Plug-Ins und erweiterte Funktionalität offen ist.

Allerdings ist hier kein Standard-Framework oder RAD-Komponente für DB-Anwendungen direkt vorgegebenen. Auf dieser Ebene müsste vieles mit der Hand gemacht werden, wenn man keine ergänzenden Werkzeuge hinzu nimmt.

Persistenz-Frameworks und O/R-Mappers (ORM) wie z.B. Hibernate versuchen den Mangel zu beheben und liefern Zusatzelemente zur Entwicklung, die für die Entwicklung sehr sinnvoll sind. Dies aber zeigt auch die Problematik der Frameworks: Jedes Framework ist wiederum so komplex, dass man von einem eigenen Paradigma sprechen kann. Das Entwicklungsparadigma verengt sich von einer globalen Java-Perspektive auf eine spezifische Framework-Perspektive. Und Frameworks gibt es viele.

Alleine um Konzepte wie J2EE, EJB, CMP und JDO tun sich Welten auf. Entity Beans können nach dem Modell BMP (Bean Managed Persistence) oder CMP (Container Managed Persistence) entworfen werden. Bei der Inflation der Konzepte und Begriffe hat sich mittlerweile auch POJO etabliert: Plain Old Java Objects. Die Experten drücken damit aus, dass ihnen die Konzeptpermutation zu Vielfältig ist und man sich auf die Grundlagen besinnt.

Bei diesen unterschiedlichen Konzept- und Implementierungsoptionen kommen dann selbstverständlich Fragen auf: Wie mache ich es denn nun richtig?

Im Gegensatz dazu kommen RAD-Tools mit einem vordefinierten Konzept- und Methodensatz, der den Entwickler von derartigen Architekturentscheidungen entbindet. Er ist dann aber nicht mehr in der weiten Java-Welt, sondern auf der Insel des RAD-Tools. Es gibt auch für Java RAD-Tools für Java, s.u. Xamba.

ORM-Frameworks bremsen oft die Performance der Datenbank aus. Und erfordern höhere Hardware-Kosten um diesen Nachteil zu kompensieren.

Ferner ist meist die Notwendigkeit gegeben, für Java Web Apps einen Application Server zu wählen. Neben dem bekannten JBoss stehen hier teure Angebote namhafter Hersteller im Raum.

Es kann also nicht genug sein, die Plattform mit Java/Eclipse zu identifizieren, sondern eine Anwendungsentwicklung sollte sich auf eine leistungsfähige RAD-Lösung festlegen, die schnelle Ergebnisse hinsichtlich User-Interface und DB / Persistenz-Schicht ermöglicht. Dabei ist eine robuste Infrastruktur vordefiniert, die aber hinreichende Flexibilität hinsichtlich der Leistungsanforderungen ermöglicht. Festzuhalten ist allerdings: Durch die Zersplitterung in Architektur-Varianten kann Java nicht mit dem COBOL-Effekt des Mainstreams identifiziert werden.

Ein Ausweg könnte die Integration (PlugIn) eines starken Design-Toolsets in die Eclipse-Umgebung sein, z.B. Visual Paradigm Smart Devevelopment Environment for Eclipse. Neben den fehlenden Designwerkzeugen ergänzt SDE mit einer runden Methodik zu O/R-Mapping.

Einen anderen Weg geht IBM Rational Application Developer for WebSphere Software. Dieses Eclipse Bundle wird in IBM-orientierten Konzernen gerne standardisiert eingesetzt, nicht nur weil man die speziellen Module für die WebSphere Entwicklung benötigt, sondern weil man einen Hersteller für den Support seiner Entwicklungsumgebung heranziehen möchte - rein Eclipse ist als Open Source für diesen Bedarf problematisch - obwohl ansonsten hinreichend. Allerdings hat der Nutzen des Hersteller-Supports einen hohen Preis, der mittlere und kleine Unternehmen abschreckt.

Zusammenfassung der Pros:

  • Breite Unterstützung vieler Hersteller
  • Plattformunabhängig
  • Genereller Lösungsansatz für alle Arten von Aufgaben.
  • Mainstream - Experten verfügbar

Zusammenfassung der Cons:

  • Zersplittertes Angebot - Unübersichtliche Konzeptvielfalt
  • Zusätzliche Werkzeug- und Konzeptselektion erforderlich
  • Multi-Vendor-Strategie: Wartungsprobleme nicht auszuschließen.
  • Sehr komplexe Umgebung mittlerer Effizienz.

Java - Xamba

Xamba ist exemplarisch ein RAD Ansatz auf Java-Basis, der die beiden Hauptaspekte GUI und DB-Access kompakt vordefiniert und somit den Spagat von produktiven SEU im Stile Visual Studio verbindet mit der Java Welt.

Als technische Besonderheiten definiert Xamba:

  • Kompakte Entwicklungsumgebung und einfaches Deployment
  • Dynamische und performante Applets
  • Kern-DBMS ist HSQL-DB, optional MySQL
  • Definitionssprache alternativ zu Java ist ein VB-ähnlicher Dialekt. Generiert wird aber immer Java.

Insgesamt beeindruckt Xamba durch die produktive, runde und einfach zu erlernende Plattform der Applikationsentwicklung.

Nachteilig an Xamba ist eine eher exotische Ausprägung, die in der Java-Welt eine neue Nische schafft. Die Stabilität von Xamba hinsichtlich langfristiger Entwicklungsperspektiven ist unklar: Wie weit reicht das Commitment des Herstellers?

Denn nichts ist tödlicher, als sich auf eine Plattform einzulassen, die in wenigen Monaten und Jahren zum Exoten mutiert, der nicht weiter gewartet werden kann. Die Verbindung zur Java-Welt verspricht zwar die Ankopplung an den Entwicklungszug, aber die Beurteilung der eingesetzten Methoden und Techniken bleibt unsicher.

Auch ist die eingeengte Sicht auf wenige RDBMS ein Problem, auch wenn Optionen (HSQLDB, MySQL, PostgreSQL, MS Access) durchaus hinreichend leistungsfähig erscheinen, mittlere bis größere Anwendungen zu entwickeln und zu warten.

Alternativ zu Xamba gibt es auch andere Java-basierte RAD-Tools, die allerdings unter ähnlichen Problemstellungen leiden. DB-Hersteller wie Oracle oder IBM haben hier ein perfektes Match für ihre Systemumgebungen anzubieten, die selbstredend ebenfalls zu Verengungen führen. Aber auch große Hersteller bieten keine Gewähr für eine dauerhafte Produktentwicklung. Durch ein buntes Portfolio und Zukaufspolitik sehen zuweilen auch große Tools in einer unsicheren Zukunft.

Zusammenfassung der Pros:

  • Effiziente RAD Umgebung für schnelle Ergebnisse
  • Aufbauend auf erweiterbarem Java Satndard
  • Architektur-Entscheidungen vorselektiert und damit kanalisiert

Zusammenfassung der Cons:

  • Kleiner Hersteller, Umgebung selber ist kein Standard
  • Applet-Konzept ist nicht mehr im Mainstream
  • Fokussierung für Webanwendungen - Integration in bestehende Environments unklar
  • Unterstützung nur weniger RDBMS: HSQL, MySQL und PostgreSQL

Microsoft.NET / Visual Studio

Als Nachfolger von VB 6.0 / Visual Studio hat Microsoft eine umfassende leistungsfähige und moderne Konzeption vorgelegt, die in allen Bereichen brillieren will. Sowohl die architekturbezogene objektorientierte Welt wurde mit C# und VB.NET unterstützt und hat ungeniert Konzepte von Java verarbeitet, dabei aber restriktiv die unterschiedlichsten Ströme kompakter zusammengeführt und übersichtliche Basis-Libraries geschaffen, die konsistent Überlappungen und unnötige Verästellungen vermeidet.

Das führte rein im Sprachvergleich zu höherer Effizienz in der Entwicklung und Performance, da man mit weniger Ballast auskommt und homogenere Toolumgebungen hat.

Im Bereich der Entwicklungstools knüpfte man bei den RAD-Fähigkeiten von Visual Studio 6 / Visual Basic an. Auch wenn andere Tools in der Geschichte im direkten Vergleich noch klare Vorteile Verzeichnen konnten, z.B. Delphi oder PowerBuilder, hat es VS geschafft die breite Basis einer All-Purpose Sprache mit speziellen OLTP-Anwendungsunterstützung zu verbinden.

Auch ist das Commitment von Microsoft zu ihrer technologischen Basis eher ausgewogen zu nennen. Durch Innovationen wurde nicht immer die Kundenbasis zufrieden gestellt, da Abwärts-Kompatibilität kein vorrangiges Ziel ist. In der Regel wurden aber Migrationspfade bereitgestellt, die Altanwendern hinreichende Sicherheit gab, mit ihren Anwendungen nicht in einer Sackgasse gelandet zu sein.

Bei allem blieb MS technisch in führenden Positionen: AJAX und sehr ansprechendes GUI-Design auch in Browser-Applikationen übten eine starke Attraktion aus.

Ergänzt wird das Angebot von Server-Plattformen, die in entsprechenden Bereichen ein gut Teil an Basis-Funktionalität mitbringen. Im Besonderen erwähne ich hier SharePoint neben anderen Applikationsbasen. Gegenüber eine Open Source Strategie wird neben der starken Herstellerbindung und den Lizenzkosten vor allem die ‚Geheimnisse’ des Codes angeführt.

Hinsichtlich der Lizensierung ist festzuhalten, dass diese sicher deutlich aufwendiger ist als eine reine Open-Source-Lösung. Oft aber verwenden Open Source-Projekte für den Betrieb großer Anwendungen sehr teure Lizenzen für unternehmenskritische Komponenten, die eben nicht im Open Source Bereich mit den erforderlichen Merkmalen zu haben sind. Auch wird durch den Wunsch der Unternehmen, auf einen belastbaren Support zurück zu greifen (den es auch für viele Open Source Produkte kostenpflichtig gibt), die Spanne für Drittaufwendungen relativiert. Microsoft bietet einige starke Werkzeuge (z.B. .NET Entwicklungsumgebung, Visual Studio Express 2008) ebenfalls kostenlos an. Im Allgemeinen sind die Kosten für MS-Plattformen jedoch sehr konkurrenzfähig zu Alternativen in allen Segmenten.

Das Problem der SEU Auswahl ist dann das Problem der Edition. Zum Vergleich kommen für professionelle Anforderungen in Frage:

  • Standard Edition: Preisgünstige Lizenz mit allem wesentlichen:
    • Code Editor, Code Snippets, IntelliSense
    • Web-Application-Project, JavaScript IntelliSense, Web Data Controls, ASP.NET AJAX Projekt Vorlagen
    • Debugging, auch XSLT, JavaScript, clientseitiger Skripts in ASP.NET-Seiten, SQL/CLR-Datenbankobjekten, T-SQL
    • Objektrelationaler Designer
    • Visual Studio-Berichts-Designer
Damit leistet die Standard-Edition bereits mehr, als viele alternativen Plattformen anzubieten haben. Im Gegensatz zur kostenlosen Express-Edition gibt es die Möglichkeit, mit AddIns die Funktionalität zu erweitern (Z.B. SDE).
  • Professional Edition (mit MSDN Professional) : Liefert wichtigen Mehr-Nutzen bei noch überschaubaren Kosten:
    • Unit Testing
    • Erstellen von wiederverwendbaren Komponenten
    • Crystal Reports mit integrierbaren Viewer
    • Visual Studio Tools for Office (u.A. AddIns)
    • Visual Database Tools, Oracle und DB2 Datenbankzugrif, XSD Editor, XSLT Editor und Debugger
  • Team Suite und Rollenbasierte Team Editionen: Hier werden eine Vielzahl von erweiterten High-End Tools eingebunden. Jedoch stellt sich die Frage, ob der Mehrnutzen die exorbitant höheren Preise rechtfertigt. Immerhin wollen auch die Entwickler die nötige Zeit aufwenden, sich hinreichend mit den Werkzeugen zu beschäftigen, damit sich der Nutzen überhaupt auszahlen kann. Für besondere Aufgaben und Problemstellungen ist allerdings bereits das Angebot dieser Umgebungen hilfreich: Es kann im Bedarfsfall darauf zurück gegriffen werden.

Meine Empfehlung für den professionellen Einsatz:

Professional Edition mit der Integration von Visual Paradigm Smart Devevelopment Environment for Visual Studio - SDE-VS - Professional Edition. Vorteile:

  • Optimale Funktionalität mit starken Design-und DB-Werkzeugen und ORM Generierung
  • Code-Basis bleibt single Vendor: Keine Support-Probleme zu erwarten
  • Kosten bleiben überschaubar.

Hochpreisige Mitbewerber anderer SEUs argumentieren mit der angeblich höheren Effizienz, die ihr Produktportfolio leistet, bzw. mit Leistungsfähigkeit wirklich großer Anwendungen / große Datenmengen. MS konnte allerdings durch viele Referenzinstallationen zeigen, dass sie sehr wohl auch Mission-.critical Applications im Hochlast-Bereich bedienen können und dass die generelle Produktivität mit zu den führenden der Branche steht.

Das Negativ-Image von Microsoft bezieht sich häufig auf die Verengung der OS-Plattform und der Dominanz dieses Anbieters gegenüber Dritten. Hier setzt eine wohl vor allem psychologisch begründbare Gegenreaktion ein.

Das Ergebnis: Andere Leute haben auch schöne Töchter. Es gibt Alternativen auf dem Markt, aber Microsoft hat ein sehr rundes und attraktives Angebot.

Microsoft Angebote scheiden aus, wenn es strategische Entscheidungen im Unternehmen gibt, andere Plattformen (Unix, ZOS, AS400 etc.) zu präferieren.

Zusammenfassung der Pros:

  • Effiziente RAD Umgebung
  • Umfassende Entwickler-Unterstützung und Degging-Optionen
  • Co-Mainstream: Experten verfügbar
  • Architektur-Varianten konzentrierter als bei Java
  • Effiziente Integration in OS, starker Laufzeit-Umgebung und Office-Anwendungen
  • Single Vendor: Support aus einer Hand

Zusammenfassung der Cons:

  • Herstellergetriebener Ansatz
  • Oft nicht im Konzernstandard
  • Hardware und OS-Plattformen eingeschränkt (allerdings hinreichend)

PHP – Die Open Source Alternative

Der Open Source Ansatz mit PHP hat eher seine Wurzel in der pragmatischen Simplicity als im architektonischen Overhead. Die Grundidee ist einfach. Die Module sind meist als Scripts in HTML-Seiten zu verstehen, die serverseitig bereits ausgewertet werden und somit dynamichen Content an den Browser liefern. Dort korrespondieren sie oft mit HTML-Forms. Die Syntax ist nicht revolutionär und lehnt sich an bekannte Script-Standards an. Sie ist gut lesbar, aber mittlerweile etwas unübersichtlich und um objektorientierte Merkmale erweitert worden.

Gerade die Schlichheit ist auf Effizienz getrimmt. PHP-Seiten sind, obwohl sie eigentlich ‚nur’ interpretierende Scripts sind, erstaunlich schnell und mit anderen Konzepten bestechend konkurrenzfähig. Auch wenn PHP meist im Verbund mit MySQL eingesetzt wird, so sind auch andere DBMS einsetzbar.

Nicht zuletzt wegen seiner Beliebtheit wurden Generatoren und RAD-Tools für DB-Anwendungen entwickelt. Z.B. Delphi für PHP, Eclipse-Support, Visual Paradigm Design Tools und diverse andere Tools. schafft über der PHP-Plattform eine leistungsfähige Software-Entwicklungsumgebung.

Beliebte CMS-Systeme wie Typo3, Joomla! oder Drupal wurden auf Basis von PHP entwickelt. Diese liefern neben einer fertigen und konfigurierbaren Basis und einer Vielzahl bereits verfügbaren zusätzlichen Module, die Möglichkeiten, selbstentwickelte Module aufzusatteln. Somit kann auf einen reichen Funktionssatz zurückgegriffen werden und das Rad muss nicht erneut erfunden werden. Vor allem Drupal liefert hier eine interessante konzeptionelle Basis.

Gegen den Einsatz von PHP spricht seine eher spartanische Grundkonzeption in Bezug auf Business Process Modellierung und sein eher unelegantes Sprachdesign. Es ist in Unternehmen schlicht unüblich, dass sich Kernprozesse auf dieser Plattform abgebildet werden. PHP ist als reine Web-Plattform bekannt und keine All-Purpose Sprache.

Zusammenfassung der Pros:

  • Verbreitete und effiziente Laufzeit-Umgebung für Web-Anwendungen
  • Unterstützung viele Tool-Hersteller
  • Einfaches Konzept - Wartungsstandards können eingehalten werden
  • Erweiterbare Basis-Anwendungen verfügbar (z.B. Drupal)
  • Weitgehend Plattform-Übergreifend.

Zusammenfassung der Cons:

  • Multivendor-Umgebung - Support-Probleme nicht auszuschließen
  • Toolset muss zusammengestellt werden
  • Beschränkung auf einen Anwendungstyp
  • Eingeschränkte Integration in Office-Umgebungen

Oracle Application Express (APEX)

APEX verfolgt eher einen pragmatischen RAD-Ansatz für Anwendungen in der Sprache PL/SQL, reine HTML-Anwendungen können direkt Browser ausgeführt werden und schnell entwickelt werden. Vor allem in Unternehmen, in denen Oracle als DBMS-Plattform' gesetzt ist werden sich von diesem Ansatz beeindrucken lassen. Oracle selber positioniert APEX in der hausinternen Konkurrenz mit Oracle Forms (veraltet) und Java-Anwendungsentwicklungsumgebung eher als diese SEU für kleine ad hoc-Anwendungen, aber es ist nicht einzusehen, warum dieses ansonsten gradlinige und effiziente Konzept limitiert sein sollte. Auch größere Anwendungen lassen sich effizient damit entwickeln.

Pro

  • Effizient Webanwendungen in einer Oracle Umgebung entwickeln
  • Leichter Einstieg, keine hohen Up-Front-Kosten (Bei gegebener Oracle DB)

Gegen APEX als SEU spricht:

  • Herstellerspezifischer Ansatz jenseits des Mainstreams
  • Halbherziger Support des Herstellers
  • Keine All-Purpose Sprache
  • Begrenzter Architektonischer Support
  • Herstellerbindung / Exotische Umgebung am Rande der kritischen Masse

Ruby on Rails (RoR)

RoR ist ein innovativer RAD-Ansatz, der sowohl mit architektonischer Eleganz und klarer Struktur kompromisslos auf höchste Produktivität setzt. Mit dem Prinzip ‚Convention over Configuration’ wird eine pragmatische Effizienz auf eine Konzeptebene gehoben. In RoR wird im Gegensatz zu RAD-Generatoren kein Code generiert, sondern viele Code-Fragmente als überflüssig weggelassen.

Ergebnis: Weniger Lines of Code und Reduktion von Entwicklungs- und Wartungszeit. Innovativ denkende Menschen mit Best-of-Breed Mindset werden sich von RoR stark angezogen fühlen. Auf diesem starken Konzept aufbauend gibt es bereits das RAD-Tool CodeGear 3rdRail.

Eine ansehnliche Community sorgte für ein hinreichendes Medien-Hype, so dass man diese Plattform sehr ernst nehmen kann. Allerdings steht RoR noch am Anfang und kann noch nicht sicherstellen, ob es sich gegen die anderen Plattformen als respektabel und dauerhaft behaupten kann. RoR bietet sich in Konkurrenz zu anderen RAD-Ansätzen vor allem zum Prototyping an.

Für konservative und risikobewusste Umgebungen wird der innovative Ansatz eher unattraktiv sein.

Zusammenfassung der Pros:

  • Innovativer Ansatz mit Potential
  • Höchste Effizienz durch kompromissloses Design
  • Weitgehend Plattform-Übergreifend.

Zusammenfassung der Cons:

  • Multivendor-Umgebung - Support-Probleme nicht auszuschließen
  • Verbreitung im bereich Mission crtical Apps gering
  • Abseits des Mains Streams
  • Eingeschränkte Integration in Office-Umgebungen

Fazit

In der Branche ereignen sich oft glühende Meinungskriege zum Thema Plattform und SEU, in denen die Vertreter ihre Präferenzen mit religiösem Eifer aus den unterschiedlichsten Gründen vehement als die ultimative Wahrheit verkünden. Profis kaschieren dies unter einer seriösen Decke: Unaufgeregtes Expertentum gegen emotionale Bewegtheit. Tatsächlich sind aber völlig unterschiedliche Ansätze mitunter vergleichbar vorteilhaft. Ein indifferentes Punkteverteilen (Jedes Konzept hat seine Berechtigung) als plurales Schlusswort ist mir allerdings zu wenig.

Vielmehr kommt den Requirements Management eine zentrale Bedeutung zu. Nur so kann eine halbwegs rationale Entscheidung getroffen werden, die sich nicht in überbewerteten Einzelaspekten verliert. Zu den Requirements gehören auch politische Konzernstrategien und Zukunftserwartungen, die sich mitunter kaum vom Kaffeesatzlesen unterscheiden.

Konzernstrategien können gerade Effizienz durch Synergie im Verbund den entscheidenden Ausschlag geben, oder aber durch unglückliche Rahmenbedingungen den Erfolg eines ansonsten guten Ansatzes zunichte machen, bzw. innovative Ansätze unerreichbar werden lassen. Darum ist das Thema Konzernstrategie nicht die ultimative Trumpfkarte, die ein Requirements-Management sticht: Fehlgeschlagene Projekte, die sich brav im Rahmen der Konzernvorgaben gehalten haben, werden keineswegs besser beurteilt als eine innovative und funktionale Implementierung, die durch ihren faktischen Erfolg ihre Abweichung von Konzernstrategien rechtfertigt. Allerdings sind Abweichungen vom Konzernstandard solide zu begründen, ein Rebellentum-Mythos und die ‚Macht der Macher’ wird kaum ausreichen, um mäßige Erfolge gegen konforme Umsetzungen positiv darzustellen.

Eine mit Bedacht ausgewählte SEU kann die Effizienz der Entwicklung und die Wartung sicherstellen. Ein Investment - dass keineswegs sehr hoch sein muss - zahlt sich durch Einsparung in den Personalaufwendungen aus. Darin ist der Spagat ziwschen möglichst einfachen und überschaubaren Ansätzen einerseits und der ausgefeilten und mächtigen Eleganz andererseits zu suchen.

Bei all diesen Überlegungen muss daran erinnert werden, dass Projekterfolg auch von vielen anderen Faktoren abhängig ist, vor allem von Management Commitment und Anwenderakzeptanz. Der Einfluss einer guten oder schlechten Plattform-Entscheidung kann erfolgsbestimmend sein, wenn auch ansonsten alles richtig gemacht wurde.