IT Analytiker: Buchhalter oder Künstler?

Worin unterscheidet sich ein Künstler von einem Buchhalter? Während der Künstler kreativ Neues gestaltet, dokumentiert ein Buchhalter – von Erscheinungen wie „kreativer Buchhaltung“ einmal abgesehen – ein bereits feststehendes Geschehen.

In der Literatur, aber auch in der Praxis, gibt es beide Denkschulen: Der IT Analytiker, der kreativ eine Lösung gestaltet („Künstler“), auf der einen Seite – und auf der anderen Seite der Requirements Engineer, der penibel Anforderungen erhebt und dokumentiert („Buchhalter“).

Im Folgenden sollen diese beiden Metaphern – Buchhalter und Künstler – verwendet werden, um die Tätigkeit des IT Analytikers zu beleuchten. Natürlich sind beide Bezeichnungen nicht wertend gemeint – sowohl Buchhalter als auch Künstler üben ehrenwerte Betätigungen aus. Und es ist auch klar, dass ein IT Analytiker (hier und in weiterer Folge sind selbstverständlich weibliche und männliche Analytiker gemeint) weder Buchhalter noch Künstler ist – die Bezeichnungen drücken aber sehr gut das jeweils erforderliche Mindset und das Muster der Tätigkeit aus.

• „IT Analytiker als Buchhalter“:
  Im Mittelpunkt steht der Begriff der „Anforderung“. Die Aufgabe des Analytikers – der in diesem Fall oft Requirements Engineer genannt wird – ist es, diese Anforderungen zu erheben und zu dokumentieren. Auf Basis der dokumentierten Anforderungen wird dann von jemand anderem (einem Solution Engineer, einem Architekten oder auch vom Entwickler) eine Lösung gefunden. In diesem Modell nimmt der IT Analytiker eher die Rolle eines Buchhalters ein – die Anforderungen existieren, sie werden vom Analytiker ermittelt und aufgezeichnet – Kreativität ist in diesem Modell von untergeordneter Bedeutung.

• „IT Analytiker als Künstler“:
  Die andere Denkschule sieht den IT Analytiker als kreativen Gestalter. Ausgehend von einer Aufgabenstellung entwirft er ein System. Um dazu in der Lage zu sein, muss er das Fachgebiet, für das die Software erstellt werden soll, gut kennen. Die Lösung muss den Gesetzmäßigkeiten dieses Fachgebietes entsprechen. In manchen Fällen kennt der Analytiker diese bereits, da er schon lange auf diesem Gebiet tätig ist. Meistens muss dieses Wissen aber erst erarbeitet werden. Genau das bezeichnen wir dann als „Anforderungserhebung“. Anforderungen sind in diesem Modell nicht die persönlichen Wünsche der Stakeholder (also aller Personen, die Interesse an der zu entwickelnden Lösung haben) – sondern sie sind genau das Wissen, das benötigt wird, um eine Lösung zu entwerfen. In dieser Denkschule stehen nicht die Anforderungen im Zentrum, sondern die Lösung – für diese müssen jedoch die Anforderungen bekannt sein.

Im Detail lassen sich die Unterschiede zwischen den beiden Modellen durch folgende Punkte konkretisieren:

1. Das Ziel der Tätigkeit
   a) „Buchhalter“: Das Ziel der Tätigkeit ist eine vollständige Liste der erhobenen Anforderungen, die verschiedenen Qualitätskriterien genügt. Eines der Qualitätsmerkmale ist die „Traceability“, d. h. die Anforderungen werden zueinander in Beziehung gesetzt, sodass unter anderem nachvollzogen werden kann, welche Anforderung durch welche andere Anforderung erfüllt wird.
   
   b) „Künstler“: Am Ende der Tätigkeit steht das Design der Lösung, es wird ein System beschrieben, das von der Entwicklung unmittelbar umgesetzt werden kann.
   
   

2. Die Rolle der „Anforderungen“
   a) „Buchhalter“: Die Anforderungen werden – vor allem durch Befragung der Stakeholder – erhoben sowie aufbereitet und dokumentiert. Sie beschreiben das System vollständig. Die Anforderungen sind der Output des IT Analytikers.

   b) „Künstler“: Auch in diesem Modell spielen die Anforderungen eine Rolle. Die zu entwickelnde Lösung muss den Regeln und Gesetzmäßigkeiten des Fachgebietes entsprechen. Wenn der IT Analytiker diese nicht von vorneherein kennt, muss er sie in Erfahrung bringen. Eine der wichtigsten Quellen dafür sind die Stakeholder – insbesondere die Experten, die das Fachgebiet kennen. Anforderungserhebung ist in erster Linie Wissensaufbau.
   
   

3. Erforderliche Soft-Skills: Die erforderlichen Skills unterscheiden sich nicht wesentlich in den beiden Modellen. Aber doch gibt es Schwerpunkte:
   a) „Buchhalter“: Hier ist Genauigkeit besonders wichtig. Die Anforderungen müssen vollständig erfasst und exakt dokumentiert werden.

   b) „Künstler“: Die wichtigste Eigenschaft ist Kreativität. Auf Basis des Wissens über das Wissensgebiet muss eine passende Lösung entwickelt werden.
   
   

4. Beziehung zu den Stakeholdern:
   a) „Buchhalter“: Die Stakeholder kennen die Anforderungen – und wissen, was die Lösung können muss. Ein Problem ist, dass dieses Wissen auf mehrere, vielleicht auf viele, Stakeholder verteilt ist. Es ist Aufgabe des IT Analytikers, dieses Wissen zu erheben. Das ist durchaus nicht einfach, weshalb man im Englischen auch von „Elicitation“ – also etwa „Herauskitzeln“ – spricht.

   b) „Künstler“: Der IT Analytiker ist Berater der Stakeholder. Ausgehend von der Aufgabenstellung schlägt er eine Lösung vor, deren Basis die Anforderungen der Stakeholder sind. Diese sind aber niemals vollständig, sondern betreffen immer nur einzelne Features und können auch hinterfragt werden. Was zählt ist die Gesamtlösung, diese muss zwischen IT Analytiker und Stakeholder abgestimmt werden.
   
   

5. Art der Kommunikation:
   a) „Buchhalter“: Ziel der Kommunikation zwischen IT Analytiker und Stakeholder ist die Erhebung der Anforderungen. Deshalb ist der Informationsfluss einseitig – vom Stakeholder zum IT Analytiker. Die Aufgabe des Analytikers ist es, die richtigen Fragen zu stellen, um die Anforderungen vollständig ermitteln zu können.

   b) „Künstler“: Der „Künstler“- Analytiker ist Berater. Er sieht es als seine Aufgabe, die bestmögliche Lösung zu finden. Diese Lösung erarbeitet er gemeinsam mit den Stakeholdern. Das führt dazu, dass die Kommunikation immer in beide Richtungen geht. Der Analytiker wird laufend Lösungselemente vorschlagen, die von den Stakeholdern entweder angenommen oder abgelehnt werden – oder die gemeinsam – hin zu einer optimalen Lösung – optimiert werden.

IT Analyse in der Literatur

Buchhalter oder Künstler? Was sagen die für die IT Analyse relevanten Standards dazu? Einer der beiden bedeutenden Standards wurde vom „International Requirements Engineering Board“ (IREB^®) festgelegt. Hier wird die Analyse in IT Projekten als „Requirements Engineering“ bezeichnet. Im Lehrplan für die Zertifizierung zum „Certified Professional for Requirements Engineering“ (CPRE^®) sind folgende Haupttätigkeiten vorgesehen:

1. Anforderungen ermitteln
2. Dokumentation von Anforderungen
3. Anforderungen prüfen und abstimmen
4. Anforderungen verwalten

Ermitteln – dokumentieren. Das kreative Finden von Lösungen kommt hier nicht vor. Verschiedene Autoren erklären das Finden von Lösungen auch explizit nicht als die Aufgabe des Requirements Engineers. Gemessen an der oben ausgeführten Unterscheidung von „Buchhalter“ und „Künstler“ ist der IT Analytiker hier also eindeutig als „Buchhalter“ beschrieben.

Auch wenn diese grundsätzliche Beschreibung im CPRE^®-Lehrplan später im Detail teilweise relativiert wird. Etliche der Ermittlungs- und Dokumentationstechniken (z. B. Prototyping oder Datenmodellierung) implizieren, dass doch auch das Design einer Lösung Inhalt der Tätigkeit ist. Der zweite bedeutende Standard, der die IT Analyse betrifft, wurde vom „International Institute of Business Analysis“ (IIBA^®) entwickelt. Festgehalten ist er im „Business Analysis Body of Knowledge“ (BABOK^®- Guide). Im Gegensatz zum IREB^®- Lehrplan sieht der BABOK^® das Design der Lösung als Output des Analytikers vor. Allerdings legt auch der BABOK^® einen klaren Schwerpunkt auf die Erhebung und Verwaltung der Anforderungen und sagt relativ wenig darüber, wie aus den Anforderungen das Lösungsdesign wird.

IT Analyse in der Praxis

Wie wir gesehen haben, neigen die bestehenden Standards von IREB^® und IIBA^® eher zum Bild des IT Analytikers als Buchhalter. Wie sieht die Tätigkeit des Analytikers aber in der Praxis aus? Wir wollen uns zu diesem Zweck zunächst die üblichen Rollen in einem IT Projekt ansehen. Wenn es nicht der Analytiker ist, der das Design der Lösung entwirft, dann muss dies durch eine andere Rolle geschehen. Wer kommt dafür in Frage? Einerseits könnte das der Entwickler sein. Um das Lösungsdesign gestalten zu können, ist Domänenwissen (Wissen über das Fachgebiet) erforderlich. Der Entwickler hat dieses Wissen in der Regel nicht und es ist auch gar nicht seine Aufgabe, dieses Wissen zu haben. Es ist also unwahrscheinlich, dass ein Entwickler ein gutes fachliches Lösungsdesign aus einer Liste von Anforderungen erstellen kann.

Eine weitere Möglichkeit wäre es, dass es eine zusätzliche Rolle im IT Projekt gibt, deren Aufgabe es ist, aus einer Anforderungsliste ein Lösungsdesign zu schaffen. In diesem Zusammenhang wird oft die Bezeichnung „Solution Engineer“ genannt. Hierzu ist einerseits zu sagen, dass insbesondere die agilen Softwareentwicklungsmethoden eher einen Trend zum Generalisten mit sich bringen – und eine weitere Spezialisierung gegen diesen Trend läuft. Außerdem lässt sich das Finden der fachlichen Lösung nur schwer von der Erhebung der Anforderungen trennen. Viele Anforderungen sind nur in einer bestimmten Lösungsvariante von Interesse, während sie bei einer anderen irrelevant sind. In der Praxis lässt sich also die kreative Lösungsfindung nicht von der Anforderungserhebung trennen. Um bei unserer Metapher zu bleiben – der IT Analytiker muss immer auch „Künstler“ sein, mit einer Beschränkung auf die Tätigkeit als „Buchhalter“ (der Anforderungen) wird er seiner Aufgabe nicht gerecht.