IT-Analyse 2016 – Eine Bestandsaufnahme

Man hat’s nicht leicht als IT-Analytiker, wenn man den Anspruch hat, auf der Höhe der Zeit in seiner Profession zu sein. Viele Konzepte sind auf dem Markt, die dieses Tätigkeitsfeld unterstützen –  Konzepte, die einander ergänzen, überlagern, teilweise auch widersprechen. Und ständig kommen neue dazu. Hier den Durchblick zu bewahren ist kein einfaches Unterfangen. Es ist Zeit für eine Bestandsaufnahme.

Eine Aufgabe – viele Konzepte

Da gibt es einmal das gut bewährte Requirements Engineering, das sich dank der Tätigkeit des IREB (International Requirements Engineering Board) von Deutschland ausgehend weltweit verbreitet  und so einen Standard geschaffen hat. Obwohl die in erster Linie vom IIBA (International Institute of Business Analysis) definierte Business Analyse ungefähr die gleiche Entstehungszeit hat, ist sie im europäischen Raum doch erst seit wenigen Jahren bekannt. Viel wird diskutiert, in welchem Verhältnis die beiden Konzepte zueinander stehen. Sind überhaupt beide relevant im IT-Umfeld? Ergänzen sie einander? Haben Sie vielleicht sogar den gleichen Inhalt?

Der IT-Analytiker kommt nicht umhin, sich mit den agilen Software-Entwicklungsmethoden auseinanderzusetzen. In deren puristischer Form wird die Notwendigkeit von Analyse überhaupt in Frage gestellt. Auch wenn man nicht so weit geht, stellt sich die Frage: Was bedeutet “agil” für den IT-Analytiker? Wie ändert sie seine Vorgehensweise? Reicht es – vereinfacht ausgedrückt – in den Vorgehensmodellen einen Pfeil vom Ende des Prozesses an den Anfang zu zeichnen, um das iterative Vorgehen auszudrücken? Oder sind die Änderungen doch tiefgreifender?

Neuere Konzepte sind Design Thinking oder – noch aktueller – Hybrid Thinking. Werden sie tatsächlich, wie man manchmal lesen kann, Requirements Engineering ablösen? Und dann gibt es da noch so Entwicklungen wie die Umbenennung des “Swiss Requirements Day” in „Upfront Thinking“. Steigt hier vielleicht ein neues Paradigma am Horizont auf?

IT-Analyse 2016 – eine Bestandsaufnahme

IT-Analyse unplugged

In der Tat, es ist nicht leicht, als IT-Analytiker da auf dem Laufenden zu bleiben und das richtige Konzept auszuwählen. Da hilft es, einmal einen Schritt zurückzutreten und sich die Frage zu stellen, was denn tatsächlich der Kern der Aufgabe ist. Was bleibt übrig, wenn man alle Methoden, alle Techniken, alle Vorgehensweisen – mit den dazu gehörigen Begriffen –  einmal für kurze Zeit beiseitelässt? Was ist denn die eigentliche Aufgabe eines IT-Analytikers?

Wenn man die Tätigkeit auf den konkreten Wesenskern reduziert, dann erstellt der IT-Analytiker einen Plan, einen Bauplan für die Software, die in weiterer Folge von Software-Entwicklern implementiert wird. Was hier etwas branchen-untypisch “Bauplan” genannt wird, heißt im “Business Analysis Body of Knowledge” (BABOK Guide) “Design”.

Um einen derartigen Bauplan erstellen zu können, ist zunächst einmal eines notwendig: Common Sense – oder auf Deutsch: Menschenverstand. Alle eingangs erwähnten Konzepte und Ansätze sind in letzter Konsequenz verzichtbar. In der Tat gibt es auch erfolgreiche Projekte, die keine der obigen Vorgehensweisen unmittelbar und explizit anwenden.

Bevor nun aber das Unbehagen des interessierten Lesers gar zu groß wird, und vielleicht sogar der Aufschrei zu laut, sei es deutlich gesagt: Jedes der genannten Konzepte bringt dem IT-Analytiker Nutzen, erleichtert die Erstellung dieses “Bauplans” und erhöht dessen Qualität. Das möchte ich im Folgenden für die einzelnen Ansätze darlegen:

Requirements Engineering: damit die Software ihren Zweck erfüllen kann, muss der Bauplan des Analytikers die Anforderungen verschiedener “wissender” Personen (Stakeholder) berücksichtigen. Nur wenn diese Anforderungen (oder Requirements) erfüllt sind, wird die Software Nutzen stiften. Auf diese Tatsache hingewiesen zu haben, ist der große Verdienst der Disziplin des Requirements Engineering.

Allerdings – und das muss auch gesagt werden – beschränkt sich die Arbeit des Analytikers nicht auf das Finden, Dokumentieren und Verwalten von Anforderungen. Analyse ist eine gestalterische Aufgabe, es muss das Design der Lösung entwickelt werden. In seiner Eigendefinition schließt Requirements Engineering das Design der Lösung aus seinem Aufgabenbereich aus – Anforderungen müssten “lösungsneutral” sein.

Business Analyse: in der Version 3 des Business Analysis Body of Knowledge (BABOK Guide) ist das Design der Lösung stark aufgewertet worden. In mehreren der “Knowledge Areas” wird das Design explizit angesprochen, meistens allerdings in einem Atemzug mit den Requirements. Wie aus den Requirements das Design entsteht, darüber sagt der BABOK Guide relativ wenig.

Agile Vorgehensweisen: sie haben zweifellos eine Verbesserung im Software-Entwicklungsprozess gebracht. Sie ermöglichen ein rasches Reagieren auf Änderungen. Wie verhält sich das nun zu unserer “Erstellung des Bauplans”? Es kann auf diesen Bauplan, der „upfront“ – also im Vorhinein – erstellt wird, nicht verzichtet werden. Allerdings wird dieser Plan im agilen Umfeld nicht in allen Details und Verästelungen erstellt werden. Vielmehr gibt er die groben Bausteine des Gesamtsystems und deren Beziehungen untereinander vor. Die Detaillierung erfolgt dann je nach Bedarf zeitnah vor der Implementierung.

Weitere Ansätze bilden Teilbereiche der IT-Analyse ab. Wie erwähnt ist die IT-Analyse eine Gestaltungsdisziplin. Design Thinking oder Hybrid Thinking können die dafür erforderliche Kreativität fördern. UX (User experience) und HCD (Human Centered Design) helfen bei der benutzerfreundlichen Gestaltung des Interfaces zum User.

IT-Analyse in der Praxis – Systemanalyse 3.0

Was also kann der IT-Analyst angesichts dieser Vielfalt tun? In der Regel wird er pragmatisch und mit viel Common Sense seine Aufgabe erfüllen: nämlich den Bauplan für die zu entwickelnde Software erstellen. In den meisten Fällen werden dabei viele der Ideen der oben beschriebenen Konzepte angewandt. Man verwendet:

• Requirements Engineering – aber mit Betonung auf die Gestaltung des Lösungsdesigns
• Business Analyse – aber angepasst auf die Bedürfnisse von IT-Vorhaben
• Agile Vorgehensweisen – aber mit dem richtigen und notwendigen Maß an „Upfront thinking“
• Verschiedene andere Methoden und Techniken – dort wo es sinnvoll ist und wo diese zum Ziel der Bauplanerstellung beitragen.

Diese pragmatische und lösungsorientierte Vorgangsweise, die wir seit Jahren anwenden, wollten wir strukturiert zu Papier bringen. Und damit das Kind einen Namen hat, haben wir es „Systemanalyse 3.0“ genannt.

Zur Abgrenzung soll zunächst klargelegt werden, was Systemanalyse 3.0 NICHT ist:

• Systemanalyse 3.0 ist keine Alternative zu Requirements Engineering und Business Analyse und
• Systemanalyse 3.0 ist keine weitere agile Software Entwicklungsmethode, die Scrum, Kanban oder eine andere der Vorgehensweisen ersetzen soll.

Vielmehr ist Systemanalyse 3.0 in IT-Vorhaben angewandtes Requirements Engineering und angewandte Business Analyse. Im Fokus steht dabei das Design der Lösung. Etwas pointiert könnte man auch formulieren: Wichtig ist eine gute Lösung – und nicht gute Requirements; oder noch plakativer: Solution Engineering statt Requirements Engineering. Die Requirements werden dabei als das betrachtet, was sie sind: Sehr wichtige „Rohstoffe“ für das Design der Lösung. Nicht mehr und nicht weniger.

Gerade unter dem Gesichtspunkt der Agilität ist diese Konzentration auf die Lösung von großer Bedeutung. Die Qualität der Lösung steht unmittelbar im Fokus – und nicht auf dem Umweg über die Anforderungen. Anforderungen sind nicht gut und nicht schlecht – sie sind, wie sie sind. Alle Widersprüchlichkeiten, alle Unvollständigkeiten, alle Mängel werden im Zuge des Designs der Lösung – in steter Kooperation mit den Stakeholder – aufgearbeitet.

Systemanalyse 3.0 – wie geht das?

Die Grundidee von Systemanalyse 3.0 ist es, dass von Beginn an die Lösung im Mittelpunkt steht. Sobald minimale Informationen über die Aufgabenstellung vorhanden sind, wird eine so genannte „Lösungshypothese“ formuliert. Das ist ein erstes Design, eine erste Annahme über die Lösung. Diese wird wahrscheinlich nicht großartig ausformuliert werden – ein paar Skizzen und Anmerkungen reichen. Die Lösungshypothese ist die Basis, aufgrund der der Analytiker seine weiteren Tätigkeiten gestaltet, die etwa die Grundlage für die Gespräche mit den Stakeholdern ist.

Der Analyst weiß, dass diese „Lösunghypothese“ nicht die endgültige Lösung ist. Er muss deren Falsifizierung aktiv suchen. Aufgrund von steigenden Informationen und aufgrund von Anforderungen, wird sich die Lösunghypothese weiterentwickeln. Da und dort muss sie überhaupt verworfen und neu formuliert werden.

Die Aktionen, die der Analytiker auf seinem Weg von der ersten Idee bis zum fertigen Lösungsdesign ausführt, lassen sich in drei Gruppen teilen:

Analysieren: Die Aussage, dass ein Analytiker analysiert, mag trivial erscheinen. Wir halten es aber für wichtig, das explizit zu betonen. Weder in Requirements Engineering noch in Business Analyse wird diese Haupttätigkeit ausdrücklich angesprochen.

Analysieren heißt Zerlegen. Das zu betrachtende Fachgebiet wird in kleine, überschaubare Einheiten zerlegt. Die Darstellung, was diese Einheiten sind und wie dieser Vorgang vor sich geht, würde den Rahmen dieses Artikels sprengen. Dadurch, dass diese Einheiten zueinander in Beziehung gesetzt werden, entsteht ein System – und dieses System ist letztlich das Lösungsdesign.

Kommunizieren: “Kommunizieren” ist das Pendant zu “Anforderungen erheben” in Requirements Engineering. Der Unterschied in der Bezeichnung ist nicht zufällig. Er soll zum Ausdruck bringen, dass das Sprechen mit den Stakeholdern ein Geben und Nehmen ist. Es reicht nicht, zu den Stakeholdern zu gehen und sie zu fragen, welche Anforderungen sie haben. Der Analytiker muss immer auch beraten und Vorschläge machen. Die Basis für die Vorschläge ist die jeweils aktuelle Lösungshypothese.

Produzieren: Das Ergebnis der Analyse ist etwas Geistiges, Nicht-Materielles. Trotzdem muss es sich aus praktischen Gründen in materiellen Artefakten manifestieren. Nur so kann es weitergegeben werden: an die Stakeholder zur Überprüfung, an die Entwickler zur Umsetzung.

Die Erstellung dieser Artefakte ist Arbeit – oft auch sehr zeitaufwändige Arbeit. Daher ist es leider auch etwas, das die Flexibilität einschränkt. Jeder Mensch – auch jeder Analytiker – wird es sich dreimal überlegen, etwas zu ändern, das stunden- und gar tagelange Arbeit zunichtemacht.

Systemanalyse 3.0 rät daher, mit dem Produzieren dieser Artefakte (Texte, Modelle, …) zuzuwarten, bis die Lösungshypothese eine gewisse Stabilität erreicht hat.

Systemanalyse und Schwerpunkte