Bug-freier Code, fehlerhaftes System

Meine Begeisterung über diese Fortschritte hält sich dennoch ein wenig in Grenzen – beruht das ganze Konzept doch auf einer – in der Regel unausgesprochenen – Annahme, die oft nicht zu halten ist. Nämlich der, dass man bei der Softwareentwicklung tatsächlich in der Lage ist, die Assertions so zu formulieren, dass jedes Fehlverhalten ausgeschlossen wird.  Selbst wenn wir annehmen, dass mit der Sprache für die Assertions alle erdenklichen Anforderungen grundsätzlich formulierbar sind (das Halteproblem ignoriere ich hier einmal), so stellt sich doch die Frage, ob der normalsterbliche Entwickler tatsächlich alle diese Anforderungen kennt und lückenlos formulieren kann. Es mag Ausnahmen geben wie z.B. Steuergeräte mit scharf definiertem Sollverhalten – dort sind diese Verfahren auch wertvoll. Bei den meisten Systemen jedoch, insbesondere denen mit Benutzerinteraktion,  gibt es gelegentlich Anforderungen, die einem trotz sorgfältiger Anforderungsanalyse “durch die Lappen gehen” – und dann auch nicht in Assertions übersetzt werden können. Code wird von Menschen geschrieben, die Fehler machen – das Gleiche gilt für Assertions (und andere formale Spezifikationen).

Und dann gibt es bei den gängigen Systemen noch ganz handfeste praktische bzw. wirtschaftliche Probleme. Wir könnten den selbstgeschriebenen Code mit Assertions versehen – was gerade bei einem großen, gewachsenen System (also dem Normalfall) keiner machen geschweige denn bezahlen will. Aber die ganzen genutzten Libraries, Frameworks, das Betriebssystem und letztlich sogar der Prozessor (ich sage nur “Pentium FDIV Bug“) müssten bereits ab Werk fehlerfrei sein (lesen Sie mal hier, speziell Punkt 17).

Viel lässt sich bereits erreichen, wenn man einfach solide arbeitet und nicht nur programmiert – Anforderungsanalyse, Modellierung, Spezifikation, Test!

Ein Großteil der IT-Abteilungen europäischer Unternehmen behindert das wirtschaftliche Betriebswachstum aufgrund eines mangelnden unternehmerischen Verständnisses. Unternehmen müssen daher jährlich auf durchschnittlich sechs Prozent Wachstum verzichten – allein in Deutschland beläuft sich das dadurch nicht realisierte Umsatzwachstum pro Jahr auf rund 50 Mrd. Euro.

Auch hier wird wieder auf eine Studie verwiesen, laut der “ein wesentliches Grundproblem in den meisten Fällen darin liegt, dass die Anforderungen, die an die IT gestellt werden, im Sinne der Erreichung der strategischen Unternehmensziele noch nicht ausreichend formuliert werden”.

Genau dieser (fehlende) Brückenschlag zwischen wirtschaftlicher und technischer Ebene ist es, den wir mit unserem Ansatz verfolgen. Deshalb kann man auch hier wieder positiv denken. Ist der Leidensdruck erst da (und der misst sich ja in Euro, siehe oben) kommt auch bald die Einsicht. Diejenigen Unternehmen, die ihre IT-Landschaft in Verbindung mit den Geschäftsprozessen gestalten, werden das Problem in einen Vorteil verwandeln können.

Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world.

“We have met the enemy, and he is us.”

Mehr als die Hälfte der IT-Verantwortlichen in Europa haben keinen verlässlichen, aktuellen Einblick in ihre IT-Infrastrukturen.

Laut der im Artikel erwähnten Studie haben “78 Prozent der Befragten keine integrierte Dashboard-Übersicht”, sprich keine Transparenz. Eine Lösung nennt der Text indes nicht und bezeichnet “Transparenz und Automatisierung” als “Wunschträume”. Ich stimme dem zu – aber nur zur Hälfte. Was die Transparenz angeht führt einfach kein Weg an dem vorbei, was der “IT Mensch” (Man verzeihe mir die vereinfachende ad-hoc-Einführung dieser Gattung) meist ungerne tut: Dokumentieren. Alles, was wir nicht direkt sehen und anfassen können – und das ist bei IT Systemen naturgemäß eine ganze Menge – muss eben analysiert, modelliert und aufgeschrieben werden. Wenn man dies jahrelang schleifen lässt, dann wird es natürlich besonders kritisch. Bei INTERVISTA haben wir mit FMC ein bewährtes Mittel an der Hand, welches genau dafür entwickelt wurde und daher bei regelmäßiger Anwendung Heilung oder zumindest deutliche Linderung verschafft.

Eine “Automatisierung” (von was eigentlich genau? Gibt es den automatisierten Durchblick?) wird dagegen Wunschtraum bleiben, zumindest wenn es um das Planen und Gestalten einer IT-Landschaft geht. Genau diese kreative Leistung sollte die Kerntätigkeit der IT-Verantwortlichen sein und ist – eben wegen des Kreativ-Anteils – nicht automatisierbar.

Ein weiteres Problem wird, fast beiläufig, am Ende des Artikels genannt und die dabei genannte Zahl gibt mir wirklich zu denken:

… nur fünf Prozent [der IT Manager] jedoch glauben, dass die IT ein strategischer Teil des Geschäftsmodells des Unternehmens ist.

Danach hat erst eine kleine Minderheit verstanden, dass IT weit mehr ist als nur papierloses Büro. Aber man soll ja positiv denken und darauf vertrauen, dass sich die Einsicht weiter verbreitet – denn für uns als Anbieter strategischer IT Lösungen heißt dies, dass unsere Kundenbasis dann kräftig wachsen wird!

Modellierungsstandard bleibt fett – und verliert an Attraktivität!

Da wundert es nicht, dass Heinrich Mayr dafür plädiert, „nur eine kleine Anzahl grafischer Notationselemente zu verwenden“ und sich an „vielseitig verwendbaren Konzepten“ wie den Petrinetzen zu orientieren. Genau das hatte Professor Siegfried Wendt getan, als er (vor rund dreißig Jahren!) den Grundstein für FMC legte. Deshalb setzen wir diese schlanke Methodik auch weiterhin ein – statt zu hoffen, dass UML irgendwann auf Diät geht. Die OMG wird ihr Baby weiter füttern – getreu Monty Python: „…nur noch ein hauchzartes Minzplätzchen…“

www.agilemodeling.com/whiteboardWarrior.htm

Warum ich diese Seite so interessant finde? Nun, Scott W. Ambler hat einen knackigen Bezeichner gefunden für das, was einen wichtigen Teil praktischer Beratungstätigkeit ausmacht:

A “whiteboard warrior” is someone who uses inclusive tools, such as whiteboards or paper, to do software modeling. On a whiteboard you may create a sketch to explore an architectural idea, to model storm with a project stakeholder to understand a requirement, or to explain your design to a teammate. […] My experience is that the vast majority of modeling within the IT community is actually performed using inclusive tools.

Fast bin ich neidisch – und Neid soll ja die ehrlichste Form der Anerkennung sein -, dass ich nicht selbst auf diese schöne Alliteration gekommen bin. Die zugehörigen Erklärungen bringen auf den Punkt, wovon auch wir bei INTERVISTA überzeugt sind. Wenn es darum geht, ein komplexes Softwaresystem in den Griff zu bekommen, braucht man vor allem eine klare, geradlinige Methodik, die mit einfachen Mitteln auskommt und das Wissen der Macher verfügbar macht (wie z.B. FMC).

Yes, we are whiteboard warriors, too!

„Maggi Fix“ für Softwaresysteme?
Da war er wieder – der Traum vom alle erlösenden Paradigmenwechsel, der uns die ganze Komplexität der Programmierung endlich vom Hals schafft! Kein Herumärgern mehr mit den syntaktischen Fallstricken der Programmiersprache, Schluss mit den Unmengen von Programmzeilen, die doch im Zweifelsfall nur der Autor versteht. Die ganzen komplizierten Entwicklungswerkzeuge können endlich eingemottet werden. An ihre Stelle treten schlanke, für Nicht-Programmierer verständliche Modellierungs-Tools, bei denen nur noch schöne, kundenkompatible Grafiken zu erstellen sind. Den Rest erledigen wir per Knopfdruck im Bau-mir-mein-Warenwirtschaftssystem-Wizard. Alles wird einfacher und Programmierung ist Vergangenheit.

Ich glaube das nicht!
Sicherlich kann bei bestimmten Standard-Anwendungen vieles vorgefertigt werden und in diesen Fällen reicht es dann nur noch Geschäftsprozesse zu beschreiben, die dann später von einer entsprechenden Engine abgewickelt werden. Aber denken wir mal über diesen Standardfall hinaus. Angenommen es sind nicht nur hoch angesiedelte Geschäftsprozesse, sondern auch detailliertere Abläufe festzulegen, die ganz auf individuelle Bedürfnisse des Kunden zuzuschneiden sind. Kann ein Hersteller von Prozess-Engines all diese möglichen Feinheiten im Voraus abdecken? Ist man nicht schnell an dem Punkt angelangt, an dem man anstelle umfangreicher Programmquellen ähnlich umfangreiche Ansammlungen von Workflow-Diagrammen zu verwalten hat? Die grafischen Sprachen und die entsprechenden Engines zur Abwicklung unterliegen ebenso wie Programmiersprachen und -plattformen einer Entwicklung – und die Anforderungen der Kunden ändern sich nach wie vor. Ergo holen uns früher oder später die überwunden geglaubten Probleme wieder ein – Modularisierung, Versionierung, Namenskonflikte – you name it. Ob grafisch oder textuell – die eigentlichen Probleme rühren aus dem Umfang und der Komplexität der Software her.

Back to the Roots!
Modellierung spielt dann ihre Stärken aus, wenn man sie nicht auf die grafische Programmierung reduziert, sondern zu ihrem ursprünglichen Zweck nutzt:

Als Mittel der Abstraktion und Kommunikation zwischen Kunden, Anwendern und Software-Machern.

Das ist auch der Ansatz der Intervista AG. Wir gestalten Lösungen für unsere Kunden mittels verständlicher Modelle und in enger Zusammenarbeit. Die so entworfenen Systeme werden systematisch, nachvollziehbar und zuverlässig realisiert.