Braucht Deutschland nur noch Systemarchitekten?

Hinter dieser Frage stecken zwei verschiedene, aber durchaus verwandte Themen. Beginnen wir mit dem aktuelleren Thema, der Fremdvergabe in Niedriglohnländer (auch Offshoring genannt). Wer sich überlegt, welche Informatik-Aufgaben er nach Osteuropa oder Asien verlagern kann, der beginnt am hinteren Ende der Wert­schöpfungskette. Es sind zuerst Systemwartung und Systembetrieb. Die Wartung von Software (Fehlerbehebung, graduelle Weiterentwicklung) ist leichter zu verlagern als die Hardware-Wartung. Aber auch hier gibt es einen starken Trend in Richtung Fernwartung. Dank der Verfügbarkeit weltweiter Netze ist der Systembetrieb ebenfalls nicht mehr ortsgebunden, wenn man von den dem Arbeitsplatz zuge­ordneten Geräten absieht. Das Cloud Computing entspricht dieser Vorstellung.

Bei der Systementwicklung besteht eine mögliche Trennungslinie zwischen Entwurf und Implementierung. Die mit der Anforderungsdefinition befassten Mitarbeiterinnen und Mitarbeiter müssen wissen, was die Nutzer brauchen und akzeptieren. Sie müssen ferner wissen, wofür und wo es Nutzer gibt. Sie machen Vorgaben, die das Zielsystem erfüllen muss. Ob sie ebenfalls spezifizieren müssen, wie diese Vorgaben erfüllt werden, − also einen Grobentwurf machen − hängt von der Situation ab. Die Spezifikation, also die Entwurfsarbeit, muss zumindest soweit vorangetrieben werden, dass sichergestellt ist, dass das neue System in seine Umgebung passt. Neben der Funktionalität müssen auch alle Nutzer-Interaktionen identifiziert und die Systemschnittstellen festgelegt sein. Diesen Grad der Konkretisierung bezeichnet man im Allgemeinen als Systemarchitektur.

Sowohl den Detailentwurf, also die Strukturierung in Moduln und Komponenten, sowie die Implementierung selbst lässt sich delegieren, sofern eine hinreichende Spezifikation vorliegt. Zur Implementierung gehören auch die Validierung und die Verifikation, also die Inspektionen und das Testen. Wird statt einer Spezifikation vorwiegend mit Prototypen gearbeitet, wie bei der agilen Entwicklung, sieht die Situation etwas anders aus. Darauf soll hier jedoch nicht eingegangen werden.

Der zweite Themenkreis ist so alt wie die Informatik. Es ist die Frage, ob man in der Systementwicklung zwischen professionellen und handwerklichen Tätigkeiten trennen soll und kann. Angetrieben wurde diese Diskussion einerseits von dem Mangel an qualifizierten Entwicklern, andererseits von dem Wunsch Personalkosten zu sparen. Es sind dies übrigens dieselben Gründe, die heute für das Offshoring sprechen. Ich selbst erinnere mich an mehrere Versuche hier zu einer Antwort zu kommen. Fast alle schlugen fehl. Es war oft ein echtes Dilemma. Entweder war die eine Seite nicht bereit, nur nach detaillierten Vorgaben zu arbeiten, oder die andere Seite zog es vor, statt den Entwurf ausführlich zu dokumentieren, ihn lieber selbst zu implementieren. Fast überall auf der Welt wurde das Problem dadurch gelöst, dass die weniger anspruchsvollen Arbeiten von Berufsanfängern ausgeführt wurden, meist unter Anleitung von Routiniers. So lange es innerhalb der eigenen Organisation genügend Anfänger gab, funktionierte dies mehr oder weniger reibungslos. Gibt es keine Neuanstellungen, entfällt diese Lösung. Auch deshalb ist Offshoring heute so attraktiv.

Ein Ansatz, der in der Literatur große Beachtung fand, - ich habe in einem früheren Beitrag darüber berichtet - geht auf Harlan Mills von der IBM in Gaithersburg, MD, zurück. Es war die Idee des Chefprogrammiererteams. Ich erwähne dies nur deshalb, weil dieser Ansatz an der hier angeschnittenen Frage vorbeiging, ja er lief in eine diametral entgegengesetzte Richtung. Es wurde nämlich postuliert, die Implementierung nicht zu delegieren, sondern sie in der Hand von erfahrenen Programmierern zu belassen. Es war dies noch eine sehr primitive Vorstellung bezüglich industrieller Software-Entwicklung.

Die Arbeitsteilung, von der heute fast nur noch gesprochen wird, ist die zwischen Systemarchitekten[1] und System-Implementierern. Im Falle reiner Software-Projekte ist für Letztere die Bezeichnung Software-Entwickler üblich. Auf der Seite des Systemarchitekten befinden sich auch der Anwendungsberater oder System­analytiker (auch Requirements-Ingenieur genannt) sowie der Projekt-Koordinator. Ein Projekt-Koordinator hat die finanzielle und terminliche Kontrolle im Auge. Der Architekt hat primär eine technische Verantwortung. Zur Implementierungsseite gehören Programmierer und Tester. Je kleiner ein Projekt ist, umso weniger Arbeitsteilung ist angebracht, und umso eher werden alle oben erwähnten Rollen von derselben Person wahrgenommen. Der Arbeitsaufwand zwischen diesen beiden Tätigkeitsbereichen teilt sich etwa im Verhältnis 1:3 auf. Das Verhältnis kann von Projekt zu Projekt variieren. Auch spielt es eine Rolle, wie hoch der Grad der Werkzeug-Durchdringung ist, etwa bei der Code-Generierung.

Entscheidend für den Erfolg der skizzierten Arbeitsteilung ist, dass der System­architekt eine möglichst umfassende Verantwortung übernimmt. Er muss nicht nur für die Qualität des Entwurfs gerade stehen, sondern auch für die Qualität des Produkts. Das Endprodukt muss alle Vorgaben erfüllen, vor allem die bezüglich Leistung und Sicherheit. Auch wenn er die Implementierung nicht selbst übernimmt, muss er sie überwachen, und zwar im Sinne einer Bauleitung. Er muss wissen, welche technischen Lösungen gewählt und welche Validierungs- und Verifizierungs- Maßnahmen ergriffen werden. Deshalb muss er in der Lage sein, Detailentwürfe, Testpläne und Programmtext zu verstehen und zu bewerten. Vor allem aber muss er Prototypen und Fertigsysteme bewerten können. Er muss sich auf jeden Fall Feedback verschaffen, um selbst lernen zu können. Dabei lernt er vorwiegend durch Beobachten und Messen, weniger durch eigenes Tun. Nur wer in der Lage ist dazuzulernen, kann in Zukunft bessere Entwürfe machen. Der Architekt steht in der Regel zwischen Anwendern und Entwicklern. Er muss die Brücke bilden und Wissen aus beiden Gebieten zum Einsatz bringen – wahrlich keine leichte Aufgabe. Die Sache wird einfacher, wenn immer man selbst auch Anwender ist, etwa bei Entwicklungswerkzeugen.

So wie hier dargestellt, erfüllt ein Systemarchitekt die wichtigsten Kriterien einer professionellen Tätigkeit. Ob Programmierer und Tester dies ebenfalls tun, darüber wird in der Branche diskutiert. Was dabei alles eine Rolle spielt, soll bei anderer Gelegenheit vertieft werden.

Die generelle Antwort zu der Titelfrage heißt also Ja. Bereits im Jahre 2004 schrieb ich im Informatik-Spektrum: „Informatikerinnen und Informatiker müssen aus der sich ändernden Situation persönliche Konsequenzen ziehen. Sie müssen sich Aufgaben zuwenden, die hoch genug in der Wertschöpfungsskala stehen, damit ihre Personalkosten gerechtfertigt sind. Dazu gehören alle Aktivitäten, die nahe am Anwender ablaufen, so die Beratung, Schulung, Produktbewertung und Produktauswahl, sowie die Planung und der Entwurf von Informatik-Systemen.“ Wo es Ausnahmen gibt, können diese nicht als Regelfall angesehen werden.

Die Frage ist berechtigt, wie die Situation sich langfristig entwickeln wird. Werden die Informatiker in Schwellenländern, die heute die Implementierungen machen nicht auch in Zukunft die Systemarchitektur übernehmen wollen und können? Die Antwort hängt davon ab, wie sich der Markt entwickeln wird. Wenn in späteren Jahrzehnten Nutzer in den heutigen Schwellenländern den Ton angeben, also wichtiger sind als die in Europa und den USA, gibt es keinen Grund mehr, warum nicht auch die Systemarchitekten aus diesen Ländern kommen. Das oft benutzte Argument, dass man immer auch einen Teil der industriellen Fertigung im eigenen Lande behalten sollte, mag vielleicht für Maschinen und Automobilbau gelten, in der Informatik gilt es heute bereits nicht. Nur ein ganz geringer Teil der Hardware eines Notebooks oder eines Smartphones wird heute in den USA oder in Europa produziert. Nur Software ist noch eine Ausnahme.

---

[1] Obwohl bei allen Tätigkeiten sowohl weibliche wie männliche Mitarbeiter gemeint sind, benutze ich hier der Einfachheit halber nur die männliche Form der Tätigkeitsbezeichnung.