Das Frankenstein-Prinzip in der IT-Analyse

Das Lesen von IT-Blogs und Fachzeitschriften macht einen sicher: Es wird alles anders in der IT im Allgemeinen und in der IT-Analyse im Speziellen. Digitale Transformation und disruptive Innovation lassen keinen Stein auf dem anderen. Dazu kommt noch die Artificial Intelligence, die selbst den Beruf des Analysten ersetzen könnte. Dass die Agile Softwareentwicklung auch den Analyse-Prozess revolutioniert, gehört ohnehin schon zum Allgemeingut.

Der angekündigte Wandel unserer Tage ist aber nichts Neues. Vor etwa 20 Jahre war es die Objektorientierung, die alle IT-Berufe (angeblich) umkrempelte, später – wenn auch in geringerem Maße – die Serviceorientierte Architektur (SOA). Anscheinend ist unser Berufsbild einem stetigen Wandel unterworfen. Und es ändert sich ja auch tatsächlich Vieles, was von uns auch stetiges Lernen erfordert. Hier sei aber die Frage gestellt: Gibt es nichts, das bleibt? Hat die IT-Analyse, so wie wir sie heute betreiben, noch etwas zu tun mit der – sagen wir – der Siebziger Jahre? Existiert so etwas wie die „Essenz“ der IT-Analyse, die sie im Innersten ausmacht und die allen Modeerscheinungen zum Trotz konstant bleibt?

Ingenieur – Gestalter – Manager

Machen wir doch ein Gedankenexperiment: Vergessen wir kurz einmal alle Job-Titles, die es in IT-Projekten so gibt. Vergessen wir die Requirements Engineers, Business Analysten, Solution Designer, Delivery Manager, Data Analysten, UX-Designer und alle anderen. Und dann überlegen wir, was wir brauchen, um ein Software-Projekt abzuwickeln. Wir werden dabei auf drei Gruppen kommen:

• Wir brauchen Leute, die sich mit der Technik auskennen – also jemand, der die Programmiersprache beherrscht, eine Datenbank aufsetzen kann, mit all den anderen Werkzeugen umgehen kann, die man für die Herstellung einer Software-Applikation und deren Test so braucht. Wir wollen diese Gruppe die Ingenieure
• Die zweite Gruppe kümmert sich darum, was die Software überhaupt leisten soll. Software ist kein Selbstzweck – sie muss Wert schaffen für die betroffene Organisation. Jemand muss das Wissen über die Gesetzmäßigkeiten des Fachgebietes kennen, muss sich dafür sorgen, dass die entwickelte Software diesen Gesetzmäßigkeiten entspricht, damit die Ziele erreicht werden können. Diese Gruppe nennen wir die Gestalter.
• Und schließlich ist da noch die Sache mit der Zeit und den Kosten. Jedes Software-Projekt ist mit knappen Ressourcen konfrontiert. Die dritte Gruppe kümmert sich darum. Das sind die Manager.

Ingenieur – Gestalter – Manager. Das ist die zeitlose Arbeitsteilung in jedem Software-Projekt. Jede neue Funktion, die oft aus der Zeit heraus entsteht, lässt sich in eine dieser Gruppen einteilen. Das war in den Siebziger Jahren so, und wird auch in Zukunft so sein.

Als Business Analysten sind wir ganz klar den „Gestaltern“ zuzurechnen. Damit hätten wir unsere Rolle in einem IT-Projekt definiert. Wir wollen aber nun die Aufgabe der Analytiker noch näher beleuchten. Was tut ein Analytiker, wenn er gestaltet? Was ist seine Aufgabe? Und wie sieht die von ihm gestaltete Lösung aus?

Die Essenz der IT-Analyse – das Frankenstein-Prinzip

Natürlich gleicht keine Lösung der anderen, jede hat ihre Besonderheiten. Aber auch hier sei die Frage gestellt: Gibt es nicht ein Muster, dem (fast) alle Lösungen im IT-Bereich folgen? Gibt es so etwas, wie die „Essenz“ einer Lösung, die auch über die jeweilige Zeit und ihre Moden hinweg gilt?

Kennen Sie Victor Frankenstein? Wahrscheinlich haben Sie keine positive Assoziation zu diesem Namen. Das war doch der mit dem Monster?! Ja genau, den meine ich. Und dabei hatte Frankenstein die besten Absichten. Ein perfektes menschliches Wesen wollte er erschaffen. Dabei brauchte er drei Elemente: ein Skelett als tragfähige Basis; Muskeln, um dem Wesen Dynamik, Bewegung zu geben; eine Haut als Schnittstelle zur Außenwelt.

In diesem Punkt liegt die Parallelität zur IT-Analyse. Die Lösungen, die wir gestalten, sind zwar im Allgemeinen keine menschlichen Wesen. Aber es sind Systeme, die – genau wie das Wesen Frankensteins – drei Elemente benötigen: Skelett, Muskeln, Haut.

Das Skelett

Das Skelett ist der statische Teil unserer Lösung. Es ist das System aus den Entitäten und den Beziehungen dazwischen. Die im betrachteten Fachgebiet relevanten Dinge, ob abstrakt oder konkret, werden durch ein Datenmodell ausgedrückt. Die Art der Darstellung hat sich im Lauf der Zeit gewandelt. Wurden früher vorwiegend Entity-Relationship-Diagramme dafür verwendet, so kommen heute in erster Linie UML-Klassendiagramme zur Anwendung. Auch für die technische Umsetzung gibt es verschiedene Varianten: Noch immer sind relationale Datenbanken der State of the Art. Objektorientierte Datenbanken waren lange im Gespräch, konnten sich aber nie wirklich durchsetzen. Sogenannte NoSQL-Datenbanken werden wohl in naher Zukunft an Bedeutung gewinnen.

Die Muskeln

Muskeln – das ist der dynamische Aspekt unserer Lösung. Sie bringen die Bewegung in unsere Systeme. Wir sprechen hier im Allgemeinen von Prozessen, die die an sich statischen Daten schaffen und verändern und so die Realität abbilden. Es sind hier zwei verschiedene Typen an Prozessen zu unterscheiden:

Einerseits die „Prozesse im Großen“. Das ist die Reihenfolge, in der einzelne Bausteine oder Funktionen verwendet werden, um ein bestimmtes Ziel zu erreichen. Zum Beispiel ist das die Art und Weise, wie ein bestimmter Geschäftsfall von verschiedenen Stellen in einer Organisation bearbeitet wird. Manchmal spricht man hier auch von einem Workflow. Business Analysten, die sich auf diesen Bereich spezialisieren, werden Prozessanalysten oder Prozessmanager bezeichnet.

Andererseits gibt es die „Prozesse im Kleinen“. Darunter sind die Algorithmen zu verstehen, die innerhalb der Bausteine ablaufen. Beispiele dafür sind diverse Berechnungen. In vielen Fällen legt diese Algorithmen erst der Entwickler fest. In manchen Fällen – vor allem dann, wenn es um fachliche Verfahren geht – macht auch bereits der Analytiker einen entsprechenden Vorschlag.

Die Haut

Jedes von Analytikern gestaltete System braucht eine Schnittstelle nach außen, über die es mit seiner Umwelt interagiert. In unserer Metapher zu einem künstlich geschaffenen Wesen wäre das die Haut. In den meisten Fällen, in denen es um die Kommunikation des Systems mit Menschen geht, wird diese Schnittstelle durch Bildschirm-Screens abgebildet, über die Information eingegeben oder zur Verfügung gestellt wird.

Je nach Art des Systems gibt es aber auch andere Schnittstellen nach außen. Vielleicht werden Daten über Sensoren geliefert. Wenn nicht Menschen, sondern andere Software-Systeme die Kommunikationspartner sind, dann wird die „Haut“ des Systems möglicherweise API-Schnittstellen abgebildet.

Das Konstante in der IT-Analyse …

Skelett – Muskeln – Haut. Oder anderes gesagt: Datenmodell, Prozesse, (Benutzer-)Oberfläche. Das sind die Elemente jeder Lösung, die ein IT-Analytiker gestaltet. Nicht Anforderungen sind das Ziel – und auch nicht User-Stories. Das Ziel ist das Design dieses Systems aus Skelett, Muskeln, Haut (ganz wie bei Victor Frankenstein 😉 ) – oder in IT-Sprache aus Datenmodell, Prozessen, Benutzeroberfläche.  Und dieses Ziel ist zeitlos. Das galt in den Siebziger- und Achtziger-Jahren für den Entwurf von Mainframe-Systemen, das galt später beim Design von Client-Server-Lösungen, es hat heute seine Gültigkeit, wenn wir Web-Systeme entwerfen – und es wird für die innovativsten Artificial-Intelligence-Lösungen gelten.

… und die Änderungen

Damit soll aber nicht ausgedrückt sein, dass es in der IT-Analyse keine Änderungen und keinen Fortschritt gibt. Diese Änderungen sind sogar notwendig. Sie lassen sich in drei Gruppen teilen:

• Technik: der Fortschritt der IT-Technik gibt dem Analytiker einen größeren Spielraum bei der Gestaltung seiner Lösungen. So eröffnen uns die heutigen Web-Technologien ganz andere Möglichkeiten als etwa die Mainframe-Systeme der Achtziger Jahre.
• Methodik: die Methoden, wie Analyse durchgeführt wird, führen ebenfalls zur Veränderung der Arbeitsweise. Als Beispiel dafür sei die Durchsetzung der UML (Unified Modeling Language) genannt.
• Vorgehen: das Agile Softwareentwicklungs-Vorgehen erfordert auch eine Änderung in der IT-Analyse. Es ist nicht mehr möglich, ein durchgängiges, durchdachtes Modell zu erstellen. Ein grobes Gesamtmodell wird auf eine iterativ-inkrementelle Art und Weise schrittweise verfeinert.

Alle diese Änderungen führen dazu, dass der Analytiker seine Arbeit besser und effizienter durchführen kann. Aber trotz dieser Änderungen bleibt der Kern der Tätigkeit der gleiche: es ist die Aufgabe des Analytikers ein System zu gestalten, ein System aus Skelett, Muskeln und Haut – bzw. aus einem Datenmodell, aus Prozessen und einer Oberfläche.

Fazit

Anforderungen erheben und dokumentieren, User-Stories schreiben, … So werden häufig die Aufgaben eines IT-Analytikers beschrieben. Ja, das gehört schon auch dazu – je nach gewählter Vorgehensweise. Aber es trifft nicht den Kern der Tätigkeit. Bei allen Änderungen, Neuerungen, Entwicklungen, mit der die Tätigkeit der IT-Analyse konfrontiert ist, bleibt die eigentliche Aufgabe des Analytikers konstant: Diese Aufgabe heißt Gestaltung. Ebenso wie Victor Frankenstein gestaltet der Analytiker Skelett, Muskeln und Haut eines Systems. Im Fall der IT-Analyse sprechen wir jedoch nicht von Skelett, Muskeln und Haut, sondern von Datenmodell, Prozessen, Benutzeroberfläche.

Ein IT-Analytiker muss sich dieser Aufgabe immer bewusst sein. Auf dieser soliden Basis können neue Entwicklungen zu einer Effizienz- und Qualitätssteigerung führen, sodass dem System, das in der IT-Analyse geschaffen wird, ein größerer Erfolg beschieden ist als dem Geschöpf Victor Frankensteins.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Josef Falk bloggt regelmäßig im SEQIS Experten Blog.

Und im t2informatik Blog hat Josef Falk zwei weitere Beiträge veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.