Unsere zehn Gebote.
2. Komponenten statt Monolithen
3. Stufen statt Mammutprojekte
4. Virtualisierung statt Hardware-Zoo
5. Software-Controlling statt Beten und Hoffen
6. Systematische Software-Diagnose statt planloser Suche
7. Professionelle Programmierung statt Spaghetti-Code
8. Kundenorientierung statt Technikverliebtheit
10. Standardsoftware als Partner statt Konkurrent
1. Services statt Silos
Systemlandschaften sind meistens historisch gewachsen – deshalb bestehen sie oft aus Silos, dagegen ist nichts zu machen. Aber zwei Dinge sind wichtig: Gerade in einer Welt von Silos braucht man den Überblick: Welche Daten gibt es mehrfach, welchen Inkonsistenzen gibt es, welche davon tun weh? Welche Funktionen gibt es mehrfach – was heißt das für die Benutzer, was heißt das für den Betrieb? Der erste Schritt zu SOA ist immer die sorgfältige Dokumentation des IST-Zustands.
Wenn wir neue Systeme planen, entwerfen wir keine neuen Silos, sondern serviceorientierte Komponenten mit dem Ziel, die Systemlandschaft insgesamt in Richtung SOA zu bewegen. Wir nähern uns SOA durch eine Reihe von SOA-konformen Projekten und nicht durch ein einzelnes Mammutprojekt.
Die gute Nachricht: SOA-konforme Projekte sind vielleicht anspruchsvoller als konventionelle, aber nicht teurer.
2. Komponenten statt Monolithen
SOA ist nichts anderes als Komponentenorientierung im Großen, aber oft hat man den Eindruck, dass Komponenten-orientierung im Kleinen, also auf der Ebene des einzelnen Systems, noch weitgehend unverstanden ist: Übergreifende Konzepte wie Fehlerbehandlung oder Berechtigungsprüfungen sind über das ganze System verschmiert, niemand weiß, was wann genau in der Datenbank steht, Performanceproblemen begegnet man durch ad-hoc-Caches, und wenn es überhaupt Schnittstellen gibt, reduzieren sie sich auf Anlegen/Ändern/Löschen. Dabei wäre alles so einfach:
- Denke in Schnittstellen und Komponenten und halte den Abhängigkeitsgraphen einfach. Dazu gibt es viele gute Lehrbücher.
- Verwende Inversion of Control (oder AOP oder einen anderen Mechanismus) für die übergreifenden Konzepte. Auch dazu gibt es gute Lehrbücher.
- Integriere das System von unten nach oben über so viele Ebenen wie nötig.
3. Stufen statt Mammutprojekte
Von drei Software-Projekten scheitert im Mittel eines vollständig, eines kommt ans Ziel mit einem Vielfachen der Kosten und einem Bruchteil der Funktionen, und eines läuft ungefähr nach Plan. Diese Daumenregel gilt, seitdem es Software-Projekte gibt.
Der Grund ist einfach: Software-Projekte mit mehr als zehn Bearbeiterjahren scheitern eigentlich immer – es sei denn, man zerlegt sie in machbare Teilprojekte.
Die Aufteilung von Mammutprojekten in beherrschbare Teilprojekte und machbare Stufen ist schwer: Am Anfang scheint überhaupt keine Aufteilung möglich zu sein. Später, wenn Vorschläge auf dem Tisch liegen, finden sich immer wieder Anwender, Betreiber oder sonstige Interessensgruppen, die eine bestimmte Zwischenlösung, ein Provisorium, auf keinen Fall akzeptieren können. Manchmal haben sie recht – aber nicht immer. Das herauszufinden ist die Kunst.
4. Virtualisierung statt Hardware-Zoo
In manchen Projekten ist Hardware kein Thema: Ein großer Host oder ein Rack mit 200 Blades, ein bisschen Sizing und die Hardware-Planung steht. Aber in vielen Integrationsprojekten sind zahlreiche Hardware-Produkte verschiedener Hersteller unter einen Hut zu bringen.
Ein ganz maßgeblicher KPI solcher Projekte ist die Rüstzeit: Wie lange dauert es vom Auspacken der Hardware bis zu einer lauffähigen Testumgebung mit allen zugehörigen Hard- und Software-Komponenten? Die Rüstzeit ist deshalb so wichtig, weil man viele Umgebungen braucht: zum Entwickeln, Testen, Integrieren, Schulen, Simulieren von Alternativen. Lange Rüstzeiten paralysieren ein Projekt.
Es hat sich noch nicht so richtig herumgesprochen, dass man Hardware mit Hilfe von VMware und anderen Tools perfekt emulieren kann: Man spart Hardware-Kosten, Installationsorgien entfallen, neue Umgebungen kosten anonyme CPU, Speicher und ein paar Mausklicks. Weiteres Nachdenken kann zu dem Resultat führen, dass der Hardware-Zoo auch im Zielsystem entbehrlich ist. Nur den Hardware-Lieferanten gefällt das nicht.
5. Software-Controlling statt Beten und Hoffen
SLAs sind Glückssache: Jedes Projekt bekommt eine Reihe von Anforderungen in Bezug auf Performance, Verfügbarkeit und Zuverlässigkeit mit auf den Weg, aber in der Regel stellt sich erst kurz vor oder bei der Einführung heraus, wie gut das System tatsächlich ist. Das ist unprofessionell. Dabei wäre alles so einfach:
Die Qualität eines Systems ergibt sich aus einer Reihe von Kennzahlen, die man automatisch messen kann, z.B. jede Nacht. Zu diesen Kennzahlen gehören Komplexitätsmaße, Testüberdeckung, Laufzeit der Testfälle, Prüfung auf illegale Abhängigkeiten u.v.m. Software-Controlling bedeutet die permanente Messung aller Kennzahlen und deren tägliche Analyse: Wenn sich bestimmte Werte von heute auf morgen geändert haben, dann muss etwas passiert sein, und zwar gestern – deshalb ist die Ursache in der Regel leicht zu finden.
6. Systematische Software-Diagnose statt planloser Suche
Manche Systeme sind krank: Sie werden langsam, produzieren Fehler und reagieren am Ende gar nicht mehr. Andere verhalten sich erratisch, laufen tagelang problemlos, um dann plötzlich ohne Warnung zu abzustürzen. Woran kann das liegen? Zuwenig Speicher, zu viele Threads, zu wenig Bandbreite, Programmierfehler, inkompatible Versionen von Software-Produkten, Fehler in einem Produkt? Leider gleicht der typische Diagnose-Prozess der Suche nach der Stecknadel im Heuhaufen: Verschiedene Messverfahren werden ad hoc eingesetzt, die Messprotokolle liegen in unterschiedlichen Formaten in diversen Verzeichnissen herum und werden mit trickreichen grep-Aufrufen durchforstet. Weil es für die verschiedenen Messungen keine gemeinsame Zeitachse gibt, lässt sich kaum feststellen, wie die Benutzer mit ihrem Verhalten das System beeinflussen.
Auch hier ist die Lösung ganz einfach: Man messe systematisch über lange Zeiträume, sammle alle Messwerte in einer einzigen Datenbank mit einer gemeinsamen Zeitachse und werte das Ganze mit einfachen, aber leistungsfähigen Tools aus.
7. Professionelle Programmierung statt Spaghetti-Code
Der Code ist die Wahrheit. Der Code bestimmt, ob ein System läuft oder nicht – frühere Entwurfsdokumente wirken nur mittelbar durch den Code. Die Programmierer verantworten die Qualität des Codes und damit die Qualität des Systems. Neuralgische Punkte sind regelmäßig Datenbankzugriffe (wie oft, wie viel auf einmal?), Netzverkehr (wie oft, wie viel auf einmal?), Caches (wie aktuell sind die?) und Threads (ein weites Feld!).
Manche halten Programmierung für eine langweilige, anspruchslose Beschäftigung. Das ist falsch, denn langweilige, anspruchslose Programme schreibt ein Generator, und den Generator schreibt ein qualifizierter Programmierer. Qualifizierte Programmierer gibt es auf der ganzen Welt: in Mitteleuropa, Osteuropa, Fernost und anderswo. Das Problem ist nur: Je weiter sie weg sind, desto teurer und fehleranfälliger ist die Kommunikation. Deshalb sind Offshore-Projekte in der Regel nur dann erfolgreich, wenn sie insgesamt Offshore stattfinden: auf Englisch, und die Anwendungsexperten sind vor Ort.
Unser Vorschlag: Die Programmierer bekommen eine vernünftige Ausbildung (egal wo sie sitzen), und die Manager rechnen Offshore und Nearshore ehrlich.
8. Kundenorientierung statt Technikverliebtheit
Technik ist cool: Jedes Jahr erscheinen neue Produkte und Versionen. Technik ist anspruchsvoll. Man muss schon Experte sein, um überhaupt zu verstehen, was das neue Produkt eigentlich tut, wie man es einsetzt und welche Möglichkeiten es bietet. So wird die Software-Entwicklung nicht nur getrieben von den Anwendern, die immer mehr DV-Unterstützung wünschen, sondern auch von den Technikern, die ihre Spielzeuge im Einsatz sehen wollen. Das ist in Ordnung, solange die Prioritäten klar sind: Der Kunde kommt zuerst, die Technik ist für die Anwender da. Nicht jeder braucht einen ESB, ein Portal oder die neueste Oracle-Version. Wir empfehlen zwei Regeln:
- Ändere die technische Infrastruktur eines gut laufenden Systems nur aus zwingenden Gründen (z.B. auslaufender Support des Herstellers).
- Sei niemals Pionier. Verwende neue Produkte erst, wenn sie in vergleichbaren Systemen oder einem wirklich belastbaren Prototyp nachweislich funktioniert haben.
9. Augenmaß statt Utopie
Software-Projekte kosten Geld, Schweiß und manchmal Tränen. Deshalb sind Software-Manager anfällig für Heilslehren, die das Ende sämtlicher Probleme der IT-Welt versprechen. Es gab und gibt unternehmensweite Datenmodellierung, Objektorientierung, 4GL-Sprachen, Komponenten, diverse Generator-Ansätze (MDA), heute sprechen wir über SOA und auch das Thema von morgen steckt sicher schon in einer Schublade.
Alle genannten Lehren besitzen einen guten, richtigen Kern, aber keine war auch nur ansatzweise in der Lage, die gesetzten Hoffnungen zu erfüllen. Jeder Ansatz hat die IT-Welt ein Stück weiter gebracht und in der Summe sind wir heute natürlich schlauer als vor 20 Jahren. Aber auf die Effizienz der Software-Entwicklung haben sich diese Erkenntnisse nur sehr maßvoll ausgewirkt. Deshalb bleibt es bis auf weiteres bei Geld, Schweiß und Tränen.
Viele Software-Manager glauben das nicht, sondern nehmen die Versprechungen der jeweiligen Gurus für bare Münze. Unser Vorschlag: Das sollten sie sich abgewöhnen.
10. Standardsoftware als Partner statt Konkurrent
SAP, Siebel und Konsorten sind allgegenwärtig. Niemand würde heute eine Finanzbuchhaltung selber bauen, aber wohl alle großen Unternehmen brauchen auch maßgeschneiderte Software. Nur: Es fehlt ein emotionsfreier Prozess für die Entscheidung zwischen Individual-Software und Erweiterung des Standards. Jedes SAP-Projekt (SAP nur als Beispiel) hat zu Beginn die Vorgabe, die Abweichungen vom Standard zu minimieren. Aber am Ende stellt sich nicht selten heraus, dass die Hälfte des Projektaufwands (und mehr) in Erweiterungen geflossen ist. SAP-Berater können sich einfach nicht vorstellen, dass SAP-ferne Funktionen individuell besser, einfacher und schneller realisiert werden können. Umgekehrt kommt ein Software-Architekt individueller Prägung selten auf die Idee, seinen Entwurf durch die den Einsatz von Standard-Software zu vereinfachen.
Deshalb der Appell an die Vertreter von Standard-Software auf der einen Seite und von Individual-Software auf der anderen: Geht mal zusammen ein Bier trinken, redet miteinander.