Anforderungen und Strategie

Der erste Schritt, um ein neues System zu erstellen, ist die Anforderungsanalyse. Manch ein System kommt nie darüber hinaus. Manchmal macht das Ergebnis mehr Probleme, als es weiterhilft. Über das Thema gibt es genug zu schreiben, um Bücher zu füllen. Ich will hier nur zwei Gedanken beisteuern.

Geschäftsstrategie

Firmen holen sich meist unterschiedliche Berater ins Haus, wenn sie über die Geschäftsstrategie nachdenken und wenn sie ein neues IT-System planen. Die Unterstützung im Management wie die Erwartungshaltung sieht auch unterschiedlich aus. Dies führt dazu, daß bei dem Entwurf eines neuen IT-Systems häufig die bisherigen Vorgehensweisen ziemlich ungefragt erfaßt werden. Dazu kommen noch ein paar neue Anforderungen. Dies führt dann schon von Anfang an zu eigenartigen Lösungen, die sich nur aus der Firmengeschichte heraus erklären lassen.

Eigentlich müßte nach einer Bestandsanalyse zuerst untersucht werden, inwieweit die bestehenden Geschäftsprozesse angepaßt werden sollten, um die Grundlage für ein funktionsfähiges neues IT-System zu bekommen. In der Regel gibt es aber mindestens zwei Hindernisse. Zum einen haben die meisten IT-Kräfte von den Geschäftsabläufen zu wenig Ahnung, als daß sie kompetente Vorschläge machen könnten. Zum anderen sind sie mit Mitarbeitern des Kunden konfrontiert, die in ihrer existierenden Welt existieren und weder Interesse noch Kompetenz haben, diese zu ändern.

Am schlimmsten wird es, wenn man als IT-Analyst mit verschiedenen Abteilungen mit unterschiedlichen Interessen konfrontiert wird. Es ist praktisch aussichtslos, diese alle unter einen Hut zu bekommen. Damit das Ergebnis noch umsetzbar bleibt, Bedarf es der Entscheidung aus dem Management über Prioritäten. Nicht alles kann in einer ersten Stufe des Systems umgesetzt werden.

Sicht von unten

Eine andere Gefahr ist, daß man sich als Analyst nur indirekt mit dem Umfeld beschäftigt. Wenn man nur Dokumente liest und mit Analysten des Kunden oder Management redet, wird man viele wichtige Informationen nicht bekommen. Es lohnt sich immer, sich mal einen Tag zu den zukünftigen Anwendern zu setzen und zu beobachten, wie diese ihre Arbeit wirklich erledigen. Häufig wird man da pragmatische Lösungen abseits der Theorie entdecken oder auf Probleme stoßen, die so nirgendswo dokumentiert sind, mit denen die Anwender sich aber jeden Tag herumschlagen. Das neue System sollte die von den Anwendern gefunden Lösungen nicht verbauen ohne eine gangbare Alternative zu liefern. Und wenn die Probleme aus der Praxis erst bei der Einführung auf das neue System stoßen, kann es manche böse Überraschung geben.

Leider wird der direkte Kontakt zwischen IT-Analysten und Endanwendern in vielen Fällen nicht freiwillig gewährt.

Was einen guten Analysten ausmacht

Ein guter Analyst wird möglichst viel von dem Geschäft seines Kunden zu verstehen suchen. Dies bedeutet auch, daß er zuerst auch Fachliteratur darüber liest. Dies ist notwendig, um die richtigen Fragen zu stellen. Und es ist wichtig Fragen zu stellen. Zuerst gibt es ein Verständnisproblem, da die Bedeutung vieler Dinge, von denen der Kunde spricht, nicht klar ist. Man darf nie Annahmen über die Bedeutung eines neuen Begriffs machen, sondern muß unbedingt nachfragen. Es hilft nichts, den alleswissenden Berater zu spielen und am Ende des Tages eine schlechte Analyse abzuliefern.
Am Ende muß der Analyst in der Lage sein, dem Management des Kunden klar die Auswirkungen des von ihm beschriebenen Systems auf die Geschäftsabläufe des Kunden darzustellen. Ein neues System wird hier Auswirkungen haben und es ist wichtig, schon in dieser Phase darauf hinzuweisen. Wenn das Management damit nicht leben will, ist es sicher günstiger, bereits hier abzubrechen, als wenn das System in Betrieb geht. Wenn das IT-Vorhaben aber genügend Unterstützung im Management hat, ist es beruhigend, sich dessen zu versichern.

Zerfallende Architekturen

Erster Akt: Festlegung der Architektur

In der Theorie würde man bei einem neuen Softwareprojekt zuerst einmal hingehen und die fachlichen Anforderungen sammeln. In einem nächsten Schritt würde man sich hinsetzen und die technischen Alternativen zur Umsetzung dieser Anforderungen bewerten und die geeigneste auswählen und damit die Umsetzung beginnen. Soweit die Theorie.

In der Wirklichkeit ist die zu verwendende Technik schon häufig von Beginn an festgelegt. Vielleicht hat der Kunde eine Vorgabe gemacht oder das eigene Team hat sich spezialisiert oder ein Techniker ist bei der Angebotserstellung zwischen Tür und Angel gefragt worden, was im so spontan einfallen würde.

Zweiter Akt: Beginn der Umsetzung

Wir habe eine fachliche Beschreibung, z.B. in Form eines Satzes von Anwendungsfällen (Use Cases) und wir haben eine technische Architektur. Das müßte doch reichen, mit der Umsetzung zu beginnen. Also bekommt jeder Entwickler die technische Architektur vorgesetzt und einen Anwendungsfall zur Umsetzung, jeder einen anderen.
Mit der Zeit kommen bei der Entwicklung Fragen an die Architektur auf, die in dem bisherigen Bild noch nicht enthalten waren. Also wird da ergänzt. Inkrementelle Arbeitsweise ist doch seit Jahren angesagt und nicht nur ich sage immer wieder, daß das die einzige Art ist, die realistisch ist.

Dritter Akt: Erste Risse

Irgendwann kommt dann das unvermeidliche. Jemand fordert eine Änderung an der Architektur an, jemand anderes stellt fest, daß diese Änderung entscheidende Voraussetzung seiner Implementierung untergräbt.

Dann kommen immer häufiger Argumente gegen diskutierte Änderungswünsche, die da etwa so lauten: "Wir können das nicht machen. Wir wissen nicht ob das jemand so braucht, wie es jetzt ist."

Vierter Akt: Verzweiflungstaten

Irgendwann kommt der Punkt, an dem die Rücksichtsmaßnahmen auf bestehende Arbeit als nicht mehr praktikabel angesehen wird. Dann wird ohne Rücksicht auf Verluste aufgeräumt. Das ist eine Krise, die entweder zum baldigen Ableben des Projekts führt oder aber heilsam sein kann. Teuer ist sie in jedem Fall.

Was hier fehlte

Um Zeit, Geld und Nerven zu sparen, ist ein entscheidender Schritt vor Beginn der Umsetzung notwendig. Die fachlichen Anforderungen müssen auf die Architektur abgebildet werden. Es muß genau klar sein, welche Bedürfnisse jede fachliche Anforderung an die Architektur hat.

Es sollten dann Komponenten entstehen, die konkrete Verantwortlichkeiten haben. Die Entwickler werden sich dann eher an den Verantwortlichkeiten der Komponenten orientieren als an den ursprünglichen fachlichen Anforderungen. Diese treten dann wieder bei der Integration des Gesamtsystems zutage.
Ein Vorteil hier ist, daß frühzeitig ähnliche technische Anforderungen von unterschiedlichen Anwendungsfällen identifiziert werden können. Doppelarbeit kann so vermieden werden und noch wichtiger nicht kompatible Lösungsansätze.

Desweiteren sollte ein Bild der Gesamtarchitektur existieren, etwa in der Größe einer Wandtafel. Dieses Bild sollte so aufgehängt werden, daß jeder Entwickler es immer sehen kann. Anhand dieses Bildes kann man dann den Ablauf der Implementierung eines Anwendungsfalls durchspielen und so Probleme und Lösungsmöglichkeiten erkennen.