Heute gibt es einige richtig große und komplexe Systeme, welche alsAllheilmittel” für fast jedes Problem, dass auch nur ansatzweise das ohnehin viel zu groß beworbene Einsatzgebiet der Software streifen, angepriesen werden.

In Wahrheit sieht es aber oft so aus, dass es (sauberes Requirements Engineering vorausgesetzt) eine klare Liste an Anforderungen gab und um diese zu erfüllen ist es nötig die “Eierlegendewollmilchsau” so umzubiegen, dass die Lösung unsauber und instabil wird weil man Kernkonzepte des Basisprodukts verletzten musste. Natürlich kommt es auch vor, dass Anforderungen nur teilweise erfüllt werden können oder man Kompromisse eingehen muss damit es überhaupt mit dem Basisprodukt realisierbar ist.

Oft geht dies sogar soweit, dass Produkte gekauft und mit aller Gewalt genutzt werden nur weil “ein großer Name” darauf steht. Hier wird weder hinterfragt was das Produkt wirklich kann, noch ob es den Anforderungen entspricht und außerdem kümmert sich niemand darum ob es überhaupt eine Zukunft hat. Das alles wäre nämlich nötig bevor man es einsetzt. Ja das ist mit Analysekosten verbunden, aber diese sind sicherlich sehr gering im Vergleich zu dem Aufwand der getrieben werden müsste um “da noch was zu retten” wenn man erst in der Projektphase bemerkt was hier alles eben nicht so läuft wie erwartet.

Der Aufwand der hier oft getrieben wird ist unglaublich hoch und das für ein oft nicht sehr befriedigendes Resultat.

Es gibt aber noch ein anderes Szenario. Als Software Entwickler verstehe ich mich als Problemlöser. Ohne Problem gibt es für mich nichts zu tun. Aus einem realen Problem entstehen Anforderungen an die Software.

Nun passiert es aber, dass aus einer einfachen Anforderung auf Grund der unendlichen Möglichkeiten, welche uns heute zur Verfügung stehen, ein komplexes, kaum noch überblickbares Anforderungsgewirr wird und wir so gezwungen sind selbst eine große Lösung zu bauen, die viel mehr können soll als das Ursprüngliche Problem zu lösen.

Es werden Probleme gebaut, die es vorher gar nicht gab und alles wird so verkompliziert, dass zum Schluss die Benutzerfreundlichkeit, Performance und in extremen Fällen vielleicht sogar die Stabilität leidet.

Denn eines ist sicher: Mehr Entwicklungszeit darf es wegen “dieser paar Kleinigkeiten” nicht kosten.

Ich glaube hier ist ein Umdenken nötig. Weg von “Was wäre denn alles möglich?” hin zu “Was ist den das eigentliche Problem?“.

Hier ist eindeutig besseres Requirements Engineering gefordert. Denn eigentlich wollen wir doch alle nur ein Programm was seine Aufgabe schnell, sicher, benutzerfreundlichen und zuverlässig erledigt und auch wenn es einmal was zu ändern gibt (und dieser Tag kommt garantiert) so sauber entwickelt ist, dass Änderungen und Erweiterungen sich leicht und ohne Kompromisse in das Konzept einbauen lassen.

Services als Lösung

Ich glaube Serviceorientierung ist ein Schritt in die richtige Richtung. Ein Service der genau einen dezidierten Zweck erfüllt kann losgelöst von einem Gesamtsystem spezifiziert und entwickelt werden. Also eben kein Ding das Alles sondern genau eine Sache kann, diese dafür aber perfekt.

Und dann spricht ja Nichts mehr dagegen aus vielen kleinen richtig guten Services eine Applikation im Bausteinprinzip zu bauen. Diese Vorgehensweise hat natürlich auch weitere Vorteile in Bezug auf Skalier- und Wartbarkeit.

Die Großen gibt es schon aus gutem Grund

Doch abschließend sei natürlich noch gesagt, dass es die “Großen” schon auch aus gutem Grund gibt und sie in keinster Weise schlecht sind. Den dort wo sie so eingesetzt sind wie sie sollen, also ohne verbogen worden zu sein, dort machen sie einen richtig guten Job.

Zum Problem werden sie nur dort wo sie eingesetzt  werden weil sie “eh Alles können“.

Ein Produkt – das gilt jetzt für jedes Produkt egal ob groß oder klein – sollte immer nur dort eingesetzt werden wo das Einsatzgebiet und die Anforderungen den Möglichkeiten des Produkts entsprechen und das ohne Kompromisse. Etwas nur zu verwenden weil es “einen großen Namen hat“, “eh jeder hat“, “sooo toll ist” und aus sonstigen unbrauchbaren Gründen ist nie klug und führt in jedem Fall zu keinem so guten Ergebnis wie ein System welches genau auf eine Anforderung passt und das schon gar nicht auf lange Sicht.

Die Eierlegendewollmilchsau gibt es nicht und somit bleibt uns nichts anderes übrig als jedesmal wieder über den Tellerand zu sehen…

…und das ist ja echt nichts schlechtes, oder?