QAware-Manifest

QaWare Manifest

Kapitel 1

Manifest - Stufen statt Mammutprojekte

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: Ab einer kritischen Größe scheitern Software-Projekte 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 Manager, Anwender oder sonstige Interessengruppen, die eine gestufte Einführung mit entsprechenden Zwischenlösungen auf keinen Fall akzeptieren können. Manchmal haben sie recht – aber nicht immer.

Das herauszufinden ist die Kunst.

Kapitel 2

Manifest - Komponenten statt Monolithen

Komponenten statt Monolithen

Klare Schnittstellen, hohe Kohäsion, geringe Koppelung – das ist leicht gesagt, aber schwer getan: Viele Schnittstellen sind schlecht dokumentiert, zu generisch oder zu kompliziert. Viele Subsysteme verzichten der Einfachheit halber ganz auf Schnittstellen und kommunizieren stattdessen über die Datenbank. Fehlerbehandlung oder Berechtigungsprüfungen sind oft über das ganze System verschmiert. Nachlässig entworfene Singletons blockieren das System quer über alle Schnittstellen.

Wir hätten da ein paar Vorschläge. Sie sind nicht originell, aber wirksam:

  • Denke in Schnittstellen und Komponenten und halte den Abhängigkeitsgraphen einfach. Vermeide Zyklen um jeden Preis. Dokumentiere alle Schnittstellen.
  • Verwende einen geeigneten Mechanismus (z.B. Dependency Injection) zur Herstellung und Kontrolle der geplanten Abhängigkeiten.
  • Integriere das System von unten nach oben über so viele Ebenen wie nötig.
  • Misstraue Singletons.

Kapitel 3

Manifest -  Services statt Silos

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? Das alles muss man vor einer Sanierung wissen.

Wenn wir neue Systeme planen, entwerfen wir keine neuen Silos, sondern service-orientierte Komponenten mit dem Ziel, Redundanzen Schritt für Schritt zu eliminieren. Wir nähern uns dem Ideal durch eine Reihe von service-orientierten Projekten und nicht durch ein einzelnes Mammutprojekt.

Die gute Nachricht: Solche Projekte sind anspruchsvoller als konventionelle, aber nicht teurer.

Kapitel 4

Manifest - Virtualisierung statt Hardware-Zoo

Virtualisierung statt Hardware Zoo

Oft ist Hardware kein großes Thema: Auswahl des Produkts und der Ausbaustufe der gewählten Hardware, etwas Sizing, und die Planung steht. Aber in Integrationsprojekten ist das oft komplizierter: Zahlreiche Hardware-Produkte mit ebenso vielen verschiedenen Betriebssystemen sind unter einen Hut zu bringen.

Eine maßgebliche Kennzahl 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 wichtig, weil man viele Umgebungen braucht: zum Entwickeln, Testen, Integrieren, Schulen, Simulieren von Alternativen. Lange Rüstzeiten paralysieren ein Projekt.

Was viele nicht wissen: Hardware lässt sich mit Hilfe von VMware und anderen Tools perfekt emulieren. Man spart Hardware-Kosten, mühsame Installationsprozeduren entfallen, und neue Umgebungen kosten nur anonyme CPU, Speicher und ein paar Mausklicks. Weiteres Nachdenken kann zu dem Resultat führen, dass der Hardware- Zoo auch im Zielsystem entbehrlich ist.

Kapitel 5

Manifest - Software-Controlling statt Beten und Hoffen

Software-Controlling statt Beten und Hoffen

Nicht-funktionale Eigenschaften sind Glückssache. Jedes Projekt bekommt eine Reihe von Anforderungen an Performance, Verfügbarkeit und Zuverlässigkeit mit auf den Weg, aber oft stellt sich erst bei der Einführung heraus, ob und wie gut sie erfüllt werden. Das tut weh. Aber es gibt eine einfache Lösung.

Nicht-funktionale Eigenschaften sind bestimmt durch eine Reihe von Kennzahlen, die man automatisch ermitteln kann, am besten bei jedem Commit: Laufzeit-Anomalien, Code-Anomalien, Testüberdeckung, Architekturverletzungen und andere. Software-Controlling bedeutet permanente Messung und 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.

Kapitel 6

Manifest - Systematische Software-Diagnose statt planloser Suche

Systematische Software-Diagnose statt planloser Suche

Manche IT-Systeme sind krank: Sie werden langsam, produzieren Fehler und am Ende reagieren sie überhaupt nicht mehr. Andere laufen lange Zeit problemlos, um dann pötzlich ohne Warnung abzustürzen.

Woran kann das liegen? Zu wenig Speicher, zu viele Threads, zu wenig Bandbreite, Programmierfehler, Versionsprobleme? Je komplexer und heterogener das System, desto schwieriger die Suche. Aber in Ermangelung etablierter Suchstrategien werden verschiedene Messverfahren ad hoc eingesetzt; man misst über zufällige Zeiträume und in der Regel viel zu kurz, Messprotokolle liegen in unterschiedlichen Formaten in diversen Verzeichnissen herum und werden mit trickreichen grep-Aufrufen durchforstet.

Unser Vorschlag: Man messe alle erreichbaren Kennzahlen systematisch über einen langen Zeitraum, sammle sie in einer Datenbank und analysiere sie mit einem geeigneten Werkzeug, z.B. unserem Software EKG. So findet man Schritt für Schritt die Einstiegspunkte für Profiler und Debugger.

Kapitel 7

Manifest - Professionelle Programmierung statt Spaghetti-Code

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.

Manche halten Programmieren 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.

Unser Vorschlag: Die Programmierer bekommen eine vernünftige Ausbildung (egal wo sie sitzen), und die Manager rechnen Nearshore und Farshore ehrlich.

Kapitel 8

Manifest - Kundenorientierung statt Technikverliebtheit

Kundenorientierung statt Technikverliebtheit

Technik ist cool: Jedes Jahr erscheinen neue Produkte und Versionen. Technik ist anspruchsvoll. Man muss 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 von den Anwendern getrieben, 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 NoSQL-Datenbank.

Wir empfehlen zwei Regeln:

  1. Ändere die technische Infrastruktur eines gut laufenden Systems nur aus zwingenden Gründen (z.B. auslaufender Support des Herstellers).
  2. Verwende neue Produkte erst, wenn sie in vergleichbaren Systemen oder einem wirklich belastbaren Prototyp nachweislich funktioniert haben.

Kapitel 9

Manifest - Augenmaß statt Utopie

Augenmaß statt Utopie

Software-Projekte kosten Geld, Schweiß und manchmal auch Tränen. Deshalb glauben wir gerne an Hypes und ihre utopischen Versprechen.

Fast vergessen und weitgehend gescheitert sind 4GL-Sprachen und unternehmensweite Datenmodellierung. Mit Objektorientierung haben wir lange gerungen. Heute ist sie gezähmt und selbstverständlich. MDA ist in der Theorie wunderbar, in der Praxis aber oft die Hölle. SOA hilft uns beim Strukturieren der Anwendungslandschaft, aber ein ganzes Unternehmen darauf auszurichten, erweist sich meist als Herkulesakt. Was denken wir wohl in zehn Jahren über Cloud Computing und Software-Industrialisierung?

Jeder Hype besitzt einen wertvollen Kern, der die IT-Welt einen Schritt voran bringt. Den gilt es zu erkennen.

Augenmaß statt Utopie!

Kapitel 10

Manifest - Agilität ist nicht genug

Agilität ist nicht genug.

Agilität bedeutet flexible Planung und schnelle Reaktion. Fachbereich und Entwickler erkennen gemeinsam Schritt für Schritt, welches System sie eigentlich brauchen. Change Requests sind Teil des Spiels und nicht wie früher Störung eines vorab festgelegten Plans. Allerdings steht in den Texten zu Agilität viel über Wandel, Rollen, Prozesse und nur wenig über Architektur und Management. Doch Agilität ist ein Ticket zur Hölle, wenn man die Grundwahrheiten des Software-Engineering vergisst: Sprintplanungen ersetzen keinen Masterplan, hundert sinnvolle User Stories ergeben nicht automatisch ein sinnvolles Ganzes, Performance und Robustheit sind keine Produkte des Zufalls.

Agilität kann Produktivität und Qualität enorm verbessern, aber nur in Verbindung mit modernen Tools, zweckmäßiger Architektur und kompetentem Management.