Braucht man alle diese Funktionen tatsächlich, um ein IT-System zu schaffen? Gehen wir für die Beantwortung dieser Frage einmal ganz zurück an den Anfang.

Wie entsteht ein IT-System? Ein IT-System besteht aus Hardware und Software. Die Hardware soll in dieser Betrachtung ausgeblendet werden. Der Fokus liegt hier auf der Software.

Software entsteht dadurch, dass in einer Programmiersprache Code geschrieben wird. Benötigt werden also Menschen, die diesen Code schreiben – landläufig Developer genannt.

Das ist die Tätigkeit, ohne die gar nichts geht – ohne die Entwicklung von Code gibt es keine Software. Developer schreiben Software – wozu braucht man aber dann all die anderen oben genannten Funktionen? Braucht man sie überhaupt?

Es ist eine Frage der Größe des Vorhabens. In der Tat gibt es viele Projekte, die durch die Arbeit eines einzelnen Developers erledigt werden können. Vor allem im Wissenschaftsbereich ist das häufig der Fall. Ein Forscher benötigt für sein Projekt Software zur Auswertung und Aufbereitung seiner Daten. Das Budget lässt die Beauftragung eines Entwicklers oder gar eines Entwickler-Teams nicht zu. Also bringt sich der Forscher oder die Forscherin selbst die Programmiersprache R oder Python bei und schreibt sich die Software selbst. Projekt-Manager, IT-Analysten, Tester oder andere Funktionen gibt es in diesem Szenario nicht – und es funktioniert.

Eine Frage der Arbeitsteilung
Sehr bald aber erreicht ein IT-Vorhaben eine Größe, die von einem Developer nicht in akzeptabler Zeit zu bewältigen ist. Das gesamte Arbeitspensum muss dann auf mehrere Personen aufgeteilt werden.

Naheliegend ist es, dass dann eben zwei, drei, vier Developer Code schreiben. Je größer ein derartiges Team wird, umso mehr treten auch Aufgaben auf, die nicht unmittelbar mit Code-Schreiben verbunden sind. Zumindest muss die Arbeit der einzelnen Developer so koordiniert werden, dass sich die einzelnen Leistungen zu einem sinnvollen Ganzen fügen.

Arbeitsteilung im Allgemeinen
Arbeitsteilung ist immer dann erforderlich, wenn das gewünschte Arbeitsergebnis nicht in der vorgesehenen Zeit von einem Einzelnen hergestellt werden kann. Das gilt für alle Bereiche der Wirtschaft. So ist eine einzelne Person wohl in der Lage, einen Tisch herzustellen. Für ein ganzes Haus werden aber immer mehrere Personen zusammenwirken müssen.

Einer der Hauptvorteile der Arbeitsteilung ist die höhere Produktivität. Der Philosoph und Begründer der klassischen Nationalökonomie Adam Smith (1723 – 1790) erläutert das anhand seines Stecknadel-Beispiels: Ein einzelner Arbeiter könne maximal vier Stecknadeln pro Tag herstellen, wenn er alle dafür erforderlichen Arbeitsschritte selbst durchführt. Werden die einzelnen Arbeitsschritte aber auf mehrere, darauf spezialisierte Personen aufgeteilt, dann könnten 10 Arbeiter bis zu 48000 Stecknadeln pro Tag erzeugen^[1].

Die höhere Produktivität ist nur einer der Vorteile der Arbeitsteilung. Dazu kommt das höhere Wissen und Können der Beschäftigten durch die Spezialisierung. Das wiederum führt zu einer höheren Qualität der Produkte.

Dem stehen jedoch auch Nachteile gegenüber: Arbeitsteilung kann zu monotonen Tätigkeiten führen, die durch einseitige Belastung auch Gesundheitsschäden bewirken können. Durch die Spezialisierung verlieren die Arbeitnehmer an Flexibilität und schränken dadurch auch die Möglichkeiten zu einem Berufswechsel ein. ^[2]

Arbeitsteilung in der IT
Das Stecknadel-Beispiel des Adam Smith lässt sich auch auf den Software-Erstellungsprozess anwenden. Natürlich haben wir es hier mit völlig anderen Arbeitsschritten zu tun. Im Falle der Produktion einer Stecknadel gibt es etwa folgende Arbeitsschritte: das Ausziehen, Begradigen oder Zuschneiden des Drahtes, das Schleifen der Nadelspitze, das Anfertigen des Stecknadelkopfes, das Bleichen oder das Verpacken der fertigen Nadeln.

In der Software-Entwicklung ist das Schreiben des Codes – wie oben schon ausgeführt – die wichtigste Tätigkeit, ohne die gar nichts geht. Daneben gibt es jedoch eine Reihe von weiteren Aufgaben, die erfüllt werden müssen, um zu einem zufriedenstellenden Ergebnis zu kommen:

1. Der Fachbereich, für den die Software geschrieben wird – oft auch „Domäne“ genannt – hat seine eigenen Regeln und Gesetzmäßigkeiten. Unter diese Gesetzmäßigkeiten fallen gesetzliche Vorschriften, innerbetriebliche Regelungen, technisches oder betriebswirtschaftliches Wissen oder auch einfach nur Wünsche und Vorlieben der Auftraggeber. Alle diese Punkte müssen bekannt sein und analysiert werden, bevor sie in Programmcode gegossen werden können – auch wenn dabei durchaus eine zeitliche Überlappung sinnvoll und möglich ist.
2. In der Welt der beschränkten Ressourcen, in der wir leben, spielen Zeit und Kosten eine bedeutende Rolle. Die Software-Entwickler wollen in der Regel bezahlt werden. Dem Auftraggeber wird es daher nicht egal sein, wie lange die Entwickler brauchen. Es muss also eine Aussage darüber gemacht werden können, wieviel Aufwand an Zeit und an Geld erforderlich sein werden und dieser Aufwand muss über die Projektlaufzeit verfolgt und gesteuert werden.
3. Sobald mehrere Personen für das Ergebnis zusammenarbeiten, spricht man von einem Team. Ein Team muss koordiniert werden, damit es funktioniert. Auch das verursacht zeitlichen Aufwand.
4. Mit dem Schreiben des Codes ist es nicht getan. Es muss auch dessen Qualität gesichert werden. Programmcode kann Fehler enthalten. Je komplexer ein Programm-System ist, desto schwieriger – und zeitaufwendiger – ist es, diese Fehler zu finden.
5. Wenn mehrere Developer an einem gemeinsamen IT-System arbeiten, dann sind auch Entscheidungen über Struktur, Werkzeuge und prinzipielle Regelungen zu treffen.

Alle diese Aufgaben und noch mehr sind bei der Entwicklung eines IT-Systems zu erledigen. Damit ist noch nicht zwingend gesagt, dass dafür eigene Rollen im Projekt vorhanden sein müssen. Die jedenfalls erforderliche Arbeitsteilung kann auf verschiedene Arten erfolgen. Es kann das geplante System auf viele Developer aufgeteilt werden – und jeder von ihnen kümmert sich auch um Zeit und Kosten, um die Kommunikation mit den Auftraggebern, um die fachlichen Herausforderungen, um die Qualitätssicherung, usw.

Das ist möglich – und für kleine Projekte auch normal. Für größere Projekte aber hat sich eine andere Form der Arbeitsteilung als zweckmäßig herausgestellt.

Diese Form der Arbeitsteilung sieht eigene Rollen für die einzelnen Funktionsgruppen vor. Es gibt also Projektmanager, IT-Analysten, Tester, Architekten. Das ist auch deshalb vorteilhaft, weil jede dieser Funktionsgruppen unterschiedliche Herausforderungen hat, unterschiedliche Fähigkeiten erfordert, ja vielleicht sogar unterschiedliche Denkweisen bedingt.

Jede dieser Funktionsgruppen hat auch unterschiedliche Ziele im Projekt. Dadurch, dass jeder diese Ziele verfolgt – bei vorhandenem Verständnis für die jeweils anderen Ziele – kann ein Optimum im Projekt erreicht werden.

Das Ziel der Entwicklung ist ein eleganter, sauberer Programmcode, der auch sonst eine Reihe weiterer Qualitätseigenschaften aufweist. Das Ziel des Projektmanagements ist eine möglichst kostengünstige Umsetzung des Vorhabens. Das Ziel der IT-Analyse ist eine möglichst weitgehende Umsetzung der fachlichen Anforderungen. Diese Ziele stehen zueinander in Konkurrenz. Eine höhere Erreichung eines Zieles wirkt sich negativ auf die Erreichung der jeweils anderen aus. Dadurch, dass die Vertretung dieser Ziele auf mehrere Köpfe verteilt ist, ist gewährleistet, dass es zu einem Ausgleich der Ziele kommt.

Auch das ist ein Argument dafür, dass die Arbeitsteilung entlang dieser Funktionsgruppen erfolgt.

IT-Analyse als Aufgabe und Rolle im Projekt
Nach dieser allgemeinen Betrachtung nehmen wir nun die Aufgabe der IT-Analyse in den Fokus.

IT-Analyse ist eine Aufgabe, die es in jedem Projekt gibt. Davon unabhängig ist aber die Frage, wer diese Funktion wahrnimmt. Gibt es eine eigene Rolle für diese Aufgabe? Oder aber ist diese Aufgabe Bestandteil einer anderen Rolle?

Wir wollen zunächst noch einmal zusammenfassen, worum es bei dieser Aufgabe geht.

Der Auftrag zur Erstellung eines IT-Systems ist praktisch nie so formuliert, dass er unmittelbar in Code umgesetzt werden kann. Fast immer muss die fachlich formulierte Aufgabenstellung in die Sprache der IT transformiert werden. Für diesen Transformationsprozess ist detailliertes Wissen über die Fachdomäne erforderlich.

Ein Beispiel
In einem Projekt zur Erstellung eines Logistik-Systems könnte die Anforderung enthalten sein: „Es ist der optimale Lagerbestand mithilfe des Wilson-Modells zu ermitteln.“ Daran knüpfen sich eine Reihe von Fragen:

• Was ist das Wilson-Modell?
• Aus welchem Prozess kommen die erforderlichen Parameter?
• Müssen diese persistiert werden? Wie und wo?
• Wann wird die Ermittlung angestoßen?
• Wie sieht die Benutzeroberfläche aus?
• Was passiert mit dem Output?

Diese Fragen bedürfen intensiver Beschäftigung mit der Materie. Rund um diese Anforderung müssen Prozesse, Datenmodelle, Schnittstellen gestaltet werden. Und genau das ist der Kern der IT-Analyse.

Das heißt immer noch nicht, dass es dafür zwingend eine eigene Rolle geben muss. Im Folgenden sind die einzelnen Optionen angeführt, wo die Aufgabe der IT-Analyse auch angesiedelt sein könnte.

Development und IT-Analyse
Es ist wohl die ursprüngliche Kombination. IT-Analyse und Development liegen in einer Hand. Und es spricht auch manches dafür. Es gibt keinen Bruch in der Kommunikation und keine Reibungsverluste zwischen den zwei verschiedenen Rollen.

Aber es gibt auch gute Gründe, dass es sich letztlich so entwickelt hat, dass die beiden Aufgaben personell getrennt wurden. Software-Entwicklung und alles technische Wissen, das man dafür braucht, ist ein umfangreiches Gebiet. Wenn dazu auch noch das Wissen der Fachdomäne dazukommt, das ebenfalls beträchtlich sein kann und noch dazu meist anderer Natur, d.h. nicht-technisch, ist, dann kann das die Kapazität einer einzelnen Person überstrapazieren, sodass eine Spezialisierung auf die einzelnen Gebiete zweckmäßig und vorteilhaft ist.

Projektmanagement und IT-Analyse
Beiden gemeinsam ist, dass sie Vorgaben machen, die im Projekt Berücksichtigung finden – beim Projektmanagement sind es zeitliche Vorgaben, bei der IT-Analyse inhaltliche. Wohl aus diesem Grund wurde früher die IT-Analyse manchmal als Teil des Projektmanagements gesehen. Auch wird die Analyse manchmal als „Fachliche Projektleitung“ oder „Teilprojektleitung“ bezeichnet. Im Allgemeinen werden die beiden Funktionen heute aber – zu Recht – getrennt.

Test und IT-Analyse
Auch zwischen Test und IT-Analyse gibt es etliche Berührungspunkte. Gelegentlich liegen IT-Analyse und Test in einer Hand. Die Vorteile davon sind nicht gänzlich von der Hand zu weisen, ist doch der geplante – und zu testende – Soll-Zustand in der Analyse wohlbekannt. Ab einer gewissen Projektgröße ist jedoch eine personelle Trennung empfehlenswert. Softwaretest erfordert andere Qualifikationen – und vielleicht sogar andere Persönlichkeitsprofile – als die IT-Analyse.

Architektur und IT-Analyse
Die Abgrenzung zwischen Architektur und IT-Analyse ist schwierig. Das liegt auch daran, dass oft nicht klar ist, was unter Architektur zu verstehen ist. Es kann die Auswahl der technischen Komponenten und Entscheidung über deren Zusammenspiel im Projekt sein. Das sind dann Vorgaben für die IT-Analyse, innerhalb derer sie sich bewegen muss.

IT-Analyse ist aber immer auch Architektur. Es gibt keine Gestaltung, die nicht auch die Struktur des geplanten IT-Systems, also Architektur, betrifft. Deshalb können IT-Analyse und Architektur auch als Synonyme betrachtet werden. Wenn die Architektur auch das übernimmt, was man die „Erhebung der Anforderungen“ nennt, die Abstimmung mit den Stakeholdern und die Kommunikation mit Development und Test, dann IST die Architektur die IT-Analyse und es werden nicht beide Rollen im Projekt benötigt. Meistens ist es aber so, dass die Architektur den technischen Rahmen vorgibt und die IT-Analyse die fachliche Gestaltung innerhalb dieses Rahmens verantwortet.

Zusammenfassung
Braucht man nun also IT-Analyse in einem Projekt? Kaum ein Projekt ist so trivial, dass nicht die fachlichen Erfordernisse untersucht werden müssen. Kaum einmal ist es von Haus aus klar, was programmiert werden muss. Diese Übersetzung der fachlichen Sprache in die Sprache der IT muss immer passieren. Nicht zufällig hat sich in der Praxis gezeigt, dass es in den meisten Fällen zweckmäßig ist, diese Aufgabe einer eigenen Rolle zuzuweisen. So hat sich das Berufsbild der IT-Analyse herausgebildet.

Mit diesem Berufsbild wollen wir uns in den folgenden Artikeln beschäftigen. Im nächsten Beitrag sollen die Funktion der IT-Analyse im Lauf der Zeit und einige moderne Ansätze betrachtet werden.

Quellen:
^[1] https://www.wissen.de/bildwb/adam-smith-was-bringt-die-arbeitsteilung

^[2] https://welt-der-bwl.de/Arbeitsteilung

Weitere Artikel aus dieser Reihe:
IT-Analyse II – Eine Bestandsaufnahme

IT-Analyse III – das Modell im Überblick