Die minimale Totalschwierigkeit

Vom Fluch der Komplexität

Gutes muss auch einfach sein. So eine oft wiederholte Forderung. Wenn etwas kompliziert ist, dann ist es wahrscheinlich auch nicht gut. Mit diesem Paradigma wurden bereits viele große (aber auch viele fatale) Ideen geboren. Das erinnert an das Sparsamkeitsprinzip der Wissenschaften: Wenn es zwei Lösungen gibt, dann ist die einfachere vorzuziehen!

Dieses Prinzip ist in Anlehnung an Occams Razor formuliert worden:
Don't multiply unneccessary entities.

Doch was ist unnötig? Wann ist eine einfachere Lösung gleichwertig?

Die IT beschäftigt sich mit Fachproblemen. Die Aufgabe des Analytikers ist, diese Probleme möglichst umfassend zu erfassen, zu abstrahieren und so einfach wie möglich zu formulieren. Daraus kommt auch die Regel:

Vereinfache so weit wie möglich, aber nicht einfacher!

Fachprobleme sind also stets mit einem Maß an Komplexität ausgestattet, die potentiell so weit zu vereinfachen sind, bis sie die minimale Totalschwierigkeit erreichen. Wenn man weiter vereinfacht, schafft man nur noch Scheinlösungen, die das gegebene Problem nicht mehr angemessen beschreiben. Dies ist ein große Gefahr, denn dieses Maß nicht zu treffen, heißt, Verluste an Lösungskompetenz hinnehmen. Warum aber passiert es dann? Menschen reagieren recht unterschiedlich, wenn sie eine Sache nicht verstehen. Si klammern sich an Lösungskonzepte, so wie das oben beschriebene der Vereinfachung. Also wird nicht mehr vereinfacht, um das Problem zu beschreiben, sondern um ein verstehbares Konzept zu haben. Die Sachgerechtigkeit bleibt dann auf der Strecke. In der Politik bezeichnet man das Verfahren auch als Populismus: Einfach muss es sein, damit es auch alle verstehen.

Die Gegenbewegung ist aber mindestens ebenso verbreitet, wahrscheinlich in viel größerem Maß: Man bläst die Anforderungen um nicht-essentielle Punkte auf, schafft komplexere Modelle bis schließlich die Lösung ebenso unzureichend wird, zumindest aber viel Optimierungspotential erhält. Auch hier ein zu vermeidender Zustand. Warum tritt dieser ein?

• Man hat schlicht Angst, etwas wichtiges übersehen zu haben
• Man ersetzt unbekannte Komplexität durch bekannte Komplexität. Das vermittelt Sicherheit.
• Man immunisiert sich gegen Kritik. Ist der Expertenstatus erst gegeben, wird dieser belegt und verfestigt durch komplexe Darstellungen, die eben die Rolle des Experten rechtfertigen.

Wenn wir also sehen, dass man auf beiden Seiten vom Pferd fallen kann, so kommt man unweigerlich zu der Frage:

Wie finde ich das angemessene Maß an Komplexität?

Darauf gibt es keine Universalregel und kein totsicheres Verfahren. Ein Irrtum ist nicht auszuschließen. Dennoch gibt es einige Kontrollfragen, die man sich selber und Anderen stellen kann. Mit Hilfe dieser lassen sich vielleicht einige Fehler vermeiden:

1. Mut zur Lücke: Kann man auch unter dem Risiko der Unvollständigkeit zu wünschenswerten Ergebnissen kommen?
2. Sind alle genannten Anforderungen wirklich wichtig? Oder kann man Sonderfälle und Ausnahmen reduzieren?
3. Habe ich hinreichend Zeit aufgewandt, um das Problem zu analysieren?
4. Was ist das Interesse desjenigen, der mehr oder weniger Komplexität fordert oder produziert?
5. Habe ich Alternativen betrachtet? Gibt es diese?
6. Habe ich die Möglichkeit der Vereinfachung untersucht?
7. Wird aus Angst vor einem Fehler die Analyse zu weit getrieben?
8. Wie bewerte ich die Qualität einer Lösung

Beispiel: Business Rules Processing

In Reinform kann man diese Probleme bei der Verfahrensauswahl für die Abbildung von Geschäftsregeln und deren Formulierung finden.

Traditionell werden die Abbildungen von feste Geschäftsregeln in spezialisieten Programmen gemacht, z.B. Vertriebsanwendungen, Produktkalkulation, Buchführung. Eine klassische Programmiersprache ist eben darauf angelegt, Datenobjekte strukturiert zu kennen und diese mit einer Logik zu versehen.

• Vorteile: Überprüfte und dokumentierte Verfahren. Der Benutzer kann nicht viel falsch machen und die Bedienung ist einfach
• Nachteile: Erstellung sehr aufwändig und unflexibel. Anpassung erfordert hohe Kosten und Release-Vorlauf

Die Gegenbewegung setzte früh mit den Tabellenkalkulationsprogrammen ein. Um den Nachteilen zu begegnen, bauten sich Fachexperten einfach ihre Excel-Modelle selber.

• Vorteile: Flexibel und schnelle Erstellung und Wartung. Kostengünstig
• Nachteile: Schwach überprüfte und schlecht dokumentierte Verfahren, meist nicht revisionssicher. Der Benutzer kann viel falsch machen und die Bedienung ist an starke Einarbeitung gebunden. Begrenzt tauglich bei steigender Komplexität und Datenmenge.

Da beide Ansätze in vielen Fällen nicht wirklich überzeugen können, da die Nachteile jeweils unakzeptabel sind, suchte man nach Alternativen:

Business Rules Engines (BRE) sind Ansätze, um den Anwendungskern, die Datenhaltung und Dialogführung, von den flexiblen Geschäftsregeln zu trennen. Man lagert in gewisser Weise die Komplexität aus. Die Vorteile liegen auf der Hand: Jeweils Spezialisten kümmern sich um das, was sie am Besten können, in jeweils der für die Problemstellung optimierten Zyklizität.

• Vorteile: Flexibeler und schnellere Erstellung und Wartung als bei klassischen Anwendungsenwicklungen undter Nutzung der Vorteile spezialisierter Programme hinsichtlich komplexer Datenstrukturen großer Volumina.
• Nachteile: Ein Mehr an Komplexität. Programmierer benötigen nicht mehr die Kodierung der Geschäftsregeln, aber müssen die Einbindung der BRE übernehmen. Diese ist alleine hier schon aufwändiger. Zusätzlich müssen Experten den Prozess der Erstellung und Test der Geschäftsregeln unterstützen. Um die Fehler der schwach dokumentierten Verfahren und fehlenden Revisionssicherheit zu vermeiden sind erhebliche Maßnahmen einzuplanen.

Auch dieser Aufwand schreckte viele potentielle Anwender ab. Allein die Wahl einer BRE erscheint mit umfangreicher Arbeit verbunden. Um vielleicht die beiden bekanntesten BRE zu nennen, die sich aus einer Vielzahl von Unterschiedlichen Anbietern herausragen:

• ILOG JRules ist der gefühlte Marktführer (fundierte Marktanalysen liegen mir nicht vor) und von einem breiten und reichen Funktionssatz getrieben.
• Drools als bekannteste Open Source BRE kann ebenfalls auf einen reichen Funktionssatz, jedoch mit weit weniger ausgefeilten Tools und Verfahren dienen.

Da der Aufwand einer BRE-Einbindung oft abschreckend ist, wurde konsequent an einer Flexibilisierung der spezialisierten Programme gearbeitet. So reichen die Lösungsansätze von einer weitgehenden Offenlegung und Anpassbarkeit der Entscheidungsparameter bis hin zu eingebauten Regelprozessoren, die Regelsprachen implementieren, die von Excel inspiriert sind.

Die Palette der Lösungen bewegt sich aber auch hier zwischen den Polen der Flexibilität und Dynamik einerseits und der Stabilität und Einfachheit andererseits. Je nach Problemstellung wird man sich für ehr die eine oder andere Variante entscheiden, wobei es nun

Zwei Domänen der der Totalschwierigkeit

gibt - Hier am diskutierten Beispiel:

1. Fachproblem: Die Anforderung, komplexe Regeln übersichtlich, flexibel und revisionssicher umzusetzen, lässt sich nicht beliebig vereinfachen.
2. Implementierungsproblem: Auf welchem Weg die Lösung hinsichtlich der konkreten Ausgangslage optimal zu lösen ist, ist kaum mehr transparent darzustellen. Oft sind persönliche Präferenzen und Kenntnisse der Desigener und Entscheider ausschlaggebend. Dies sollte aber selten ein von der fachlichen Problemstellung her solides Verfahren sein.

Fazit

Optimierung von komplexen Problemstellungen ist eine Totalschwierigkeit, die man gerne auf objektivierbare und reflektierte Verfahren beziehen möchte. In der Regel ist der Einsatz von Experten unumgänglich, oder es kommt zu Bauchentscheidungen.