IT-Mitarbeiter und die Command & Control Architektur

Keine Kommentare

Prämisse

Die IT wird in der Zukunft noch wichtiger, als sie jetzt schon ist. Geschäftsprozesse werden immer digitaler, neue rein digitale Geschäftsprozesse kommen hinzu. Outsourcing im großen Stil ist gescheitert. Weil die IT immer näher ans Kerngeschäft rückt, ist es für jedes Unternehmen unerläßlich, selbst gute IT-Mitarbeiter zu haben. Innovation wird in der Zukunft immer häufiger aus der IT heraus stattfinden. Ohne gute IT-Mitarbeiter findet keine Innovation aus der IT heraus statt.

Gute IT-Mitarbeiter benötigt also jeder – und hier startet schon das Problem aus Unternehmenssicht. Der IT-Spezialist kennt die Angst vor dem Arbeitsplatzverlust nicht. Wenn die Bedingungen nicht so sind, wie er sie gerne hätte, zieht er weiter. Viele Unternehmen haben genau das Problem – sie bieten nicht die richtigen Bedingungen und kämpfen damit, dass gute IT-Mitarbeiter das Unternehmen verlassen.

Also, was fordert ein guter IT-Mitarbeiter?

  1. Freiheit
  2. Verantwortung
  3. Geld

Geld an dritter Stelle – denn natürlich ist es so, dass man gute Mitarbeiter nicht bekommt, indem man 10.000 Euro unter Marktdurchschnitt zahlt. Aber auch nur an dritter Stelle, denn die guten IT-Mitarbeiter, die ich kenne, machen ihren Job aus Leidenschaft.

Ein guter Mitarbeiter möchte die Lösung eines Problems nicht in einem sehr stark eingeschränktem Lösungsraum suchen, gleichzeitig möchte er für seine Lösung geradestehen, die Verantwortung übernehmen.

In vielen Unternehmen findet sich ein Command & Control Stil im Management – viele Hierarchie-Ebenen, Micro-Management bis auf Task-Ebene. Die Verantwortung dafür, was gemacht wird, liegt häufig im Management – Mitarbeiter haben wenig Mitbestimmungsmöglichkeiten und können sich leicht selbst zurückziehen – wer kann schon etwas für die Fehlentscheidungen des Managements?

Es gibt viele Ebenen, auf denen sich dieser Stil – Command & Control – verankert hat. In diesem Blogpost möchte ich auf eine Ebene eingehen, die nicht so offensichtlich ist.
Das Command & Control Prinzip findet sich auch in den IT-Architekturen wieder, die in den letzten zwanzig Jahren entstanden sind. Mit dem Siegeszug von Java wurden in vielen Unternehmen eigene Frameworks entwickelt. Häufig bestimmen sie sehr stark, wie Probleme zu lösen sind und geben einen Lösungsweg fest vor. Häufig verhindern sie aktiv alternative Lösungswege. Meist wurde ein Architekturteam installiert, das darüber wacht, dass das Framework richtig eingesetzt und alternative Lösungen im besten Fall wenigstens bewilligt werden müssen, im schlechten Fall direkt abgelehnt werden.

Freiheit und Verantwortung hat der Entwickler in diesem System wenig. Diejenigen, die das nicht so stark stört, dass sie das Unternehmen verlassen, arrangieren sich – es wird alles nach Vorschrift gemacht, und wenn etwas mal nicht funktioniert, wird es schnell mal auf das Framework geschoben. Das Architekturteam macht viel Support und beschwert sich darüber, dass die Entwickler wegen Problemen zu ihnen kommen, die sie auch selbst mit etwas Googeln lösen könnten. Allein Eigenverantwortung, selbstständige Problemlösung sind in diesem System nicht vorgesehen. Und die guten Leute, die sich mit diesem System nicht arrangieren können, gehen wieder (ein paar von ihnen können vielleicht im Architekturteam gehalten werden, da dort tendenziell mehr Freiheiten existieren).

Und nun? Macht man so weiter wie bisher, kann sich Human Resources so anstrengen, wie es geht – die guten Leute bleiben nicht. Ideal wäre es natürlich, wenn Vorstand und Management die Problematik sehen und gegensteuern – das ist aber häufig nicht zu erwarten.
Ich denke aber nicht, dass man deswegen grundsätzlich machtlos ist – das Architekturteam hat die Möglichkeit, zumindest die Voraussetzungen dafür zu schaffen, dass eigenverantwortliches Arbeiten möglich ist:

Bibliotheken über Frameworks

Statt eines ganzheitlichen Frameworks, das alle Aspekte einer Anwendung regelt und bestimmt und nur ganz oder gar nicht verwendet werden kann, sollten besser einzelne Bibliotheken angeboten werden, die eine Sache machen, und die diese eine Sache gut machen. Wenn man beispielsweise einen einheitlichen Umgang mit Properties im Unternehmen hat, könnte es eine Bibliothek property-management geben, die genau diese Sache regelt. Jede dieser Bibliotheken sollte wie ein gutes Open-Source-Projekt behandelt werden, mit Dokumentation direkt am Source-Code-Repository, Issue Tracker, der Möglichkeit, Pull Requests einzureichen, genauer Angabe von Requirements und mindestens einem direkt Verantwortlichen. Das ganzheitliche Framework entstand in vielen Unternehmen auch zunächst, um nur ein Problem zu lösen, häufig eine Innendienst-Verwaltungsanwendung. Heutzutage gibt es viel mehr digitale Kanäle, die alle bedient werden müssen, und für die ein einheitliches Framework nicht die Lösung sein kann.

Pull über Push

Es gibt keinen Zwang, die angebotenen Bibliotheken zu verwenden. Am Ende entscheiden die Linienentwickler, ob die Bibliothek verwendet wird oder nicht.

Community-Kultur

Jeder kann Pull Requests für Bibliotheken erstellen und diese so verbessern. Außerdem können Bibliotheken auch von Linienentwicklern erstellt, gepflegt und bereitgestellt werden, das ist kein Privileg des Architekturteams mehr.

Der nächste Schritt wäre nun, in Zusammenarbeit mit Operations weitergehende Freiheiten zu schaffen, die es erlauben, weitere Typen von Software zu betreiben, wenn das Team die Verantwortung übernimmt – ein erster Schritt zu echter DevOps-Kultur.

Kann das gutgehen? In Diskussionen höre ich immer wieder, dass das mit den Leuten im entsprechenden Unternehmen nicht funktionieren würde. Teilweise sehe ich das so wie im folgenden Zitat:


Ein Teil der Mitarbeiter wird das neue Vorgehen sofort positiv aufnehmen und auch positiv nutzen. Der Mitarbeiter-Spagat ist, die Entwickler mitzunehmen, die sich seit 20 Jahren im Status Quo eingewöhnt haben und mit der neu gewonnenen Freiheit und Verantwortung nicht umgehen können. Im schlechtesten Fall machen diese Entwickler Stimmung gegen die neue Freiheit und bestätigen so die Befürchtungen des Managements.

Wie kann man dem entgegenwirken? Eine mögliche Lösung sieht so aus: Das Architekturteam liefert ein Framework wie bisher, das ein Bundle der nun modularisierten Bibliotheken mit einem übergreifenden Korsett ist. Das Architekturteam macht klar, dass es keinen Zwang gibt, das Bundle zu verwenden. Und dann lässt man den Dingen seinen Lauf. Es wird Teams geben, die die neue Freiheit nutzen, und es wird Teams geben, die sich erst einmal zurückhalten.

Das Wichtige ist: Die Voraussetzungen für selbstständiges, eigenverantwortliches und daher befriedigendes Arbeiten wurden geschaffen.

Tobias Flohre

Tobias Flohre arbeitet als Senior-Softwareentwickler/Architekt bei der codecentric AG. Seine Schwerpunkte sind Java-Enterprise-Anwendungen und Architekturen mit JEE/Spring. Er ist Autor diverser Artikel und schreibt regelmäßig Blogbeiträge zu den Themen Architektur und Spring. Zurzeit beschäftigt er sich mit Integrations- und Batch-Themen im Großunternehmen sowie mit modernen Webarchitekturen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *