Fallstricke der Middleware-Verwaltung 10. Das Problem der Abhängigkeiten

Dies ist der erste Blog in einer Serie, die die Top 10 der Java EE Middleware-Managementprobleme beschreibt. Der Titel könnte auch "Single Point of Failure" lauten. Hier geht es nicht um Software. Stattdessen geht es um die Person in Ihrem Middleware-Team, auf die sich alle verlassen und an die sie sich klammern, wenn die Dinge schwierig werden oder, noch schlimmer, völlig aus dem Ruder laufen. Stellen Sie sich ein typisches Middleware-Team in einem mittelgroßen Unternehmen vor. John ist der Manager dieses Teams. Das Middleware-Team kämpft ständig damit, mit all den neuen Produkten Schritt zu halten, die von den Entwicklungsteams und ihren Lösungen eingeführt werden. Die Teammitglieder und Unix-Administratoren Leo und Lloyd betreuen die J2EE-Anwendungsserver, Webserver und ein Warteschlangenprodukt zur Anbindung an den Mainframe des alten Unternehmens. Sie sind recht erfolgreich in ihrem Job, zumindest ist die Zahl der Vorfälle zurückgegangen, die Leistung ist einigermaßen gut, sie wissen, wie man neue Softwareversionen einsetzt, und sie führen in den Abendstunden Middleware-Upgrades durch. Die Unix-Gurus Leo und Lloyd sind beide schon lange im Unternehmen und werden wahrscheinlich bis zu ihrer Pensionierung dort bleiben. Der neue Mann Dave (ursprünglich auch ein Unix-Administrator) hat sich die Mühe gemacht, sich mit all dem neuen, ausgefallenen Java-Kram vertraut zu machen. Wenn Dave nicht im Büro ist, sind Leo und Lloyd etwas hilflos, was den Anwendungsserver angeht. Dave hat kürzlich die Verfügbarkeit der Unternehmenswebsite durch die Einführung von Clustering verbessert, er hat Deployment-Skripte geschrieben, um die Deployment-Geschwindigkeit und -Qualität zu verbessern, und er hat mit den Entwicklern zusammengearbeitet, um bessere Log-Statements von der Anwendung zu erhalten. Er zeigt Ehrgeiz. Er arbeitet bis spät in die Nacht und ignoriert scheinbar den anhaltenden Strom von Vorfällen und die nörgelnden Kunden am Helpdesk. Immer wieder lobt John Dave, gibt ihm Gehaltserhöhungen und Boni, überredet ihn mit einigem Erfolg, sein Wissen zu verbreiten und stellt neue Mitarbeiter ein, die ihn unterstützen sollen (sie sind übrigens alle gegangen). John ist von Dave abhängig geworden, was das Tagesgeschäft und die Middleware-Entwicklung im Zusammenhang mit dem wachsenden Middleware-Management-Stack angeht, und diese Situation macht John Sorgen. Wenn Dave jemals beschließt, das Unternehmen zu verlassen, wird es große Probleme geben. Ein neues Projekt möchte BPM-Werkzeuge einführen und Dave liest bereits die Produktdokumentation. Leo und Lloyd sind nicht in der Lage, mit Dave Schritt zu halten, und nebenbei bemerkt, ist BPM-Tooling für sie eine Nummer zu groß. Die Beauftragung eines teuren externen Beraters könnte hier Abhilfe schaffen, aber nur vorübergehend. Ein gewisses Maß an Wissen über das BPM-Produkt sollte in der Organisation sichergestellt werden. John fällt es schwer, die Stabilität der Website zu gewährleisten und Innovationen bei neuen Projekten zu unterstützen. Dave ist zwar bereit, kann aber seine intimen Kenntnisse des Anwendungsservers nicht weitergeben, weil es niemanden gibt, der etwas anderes als die Grundlagen versteht. Dave selbst mag seinen Job, hat aber vielleicht auch noch andere Ziele und Träume, wie einen gelegentlichen Urlaub oder die Gründung einer Familie, Dinge, die mit der Arbeit am Wochenende und in der Nacht kollidieren. Außerdem hat er gerade herausgefunden, dass er die vielen sich wiederholenden Aufgaben, die er jeden Tag erledigen muss, eigentlich leid ist. Er wäre lieber ein Entwickler oder sogar ein Architekt. Wie ist er hier gelandet? John hat ein "Abhängigkeitsproblem", denn er ist "süchtig" nach Dave geworden, der der "Held" ist, der den Middleware-Betrieb und die Middleware-Entwicklung am Laufen hält. Dies ist ein Risiko für die Verfügbarkeit der Website des Unternehmens und die Projekte, die in Testumgebungen durchgeführt werden müssen. Das Unternehmen könnte Kunden verlieren und Projekte könnten sich verzögern. Es besteht ein wachsender Bedarf an Experten im Bereich Middleware, die über mehr Fähigkeiten als der durchschnittliche Administrator verfügen, aber die Probleme und Sorgen des Administrators verstehen. Oft handelt es sich bei Middleware-Experten um externe Berater, die an Entwicklungsprojekten mitarbeiten und sich dann neuen Projekten zuwenden, anstatt an einer Arbeit festzuhalten, die sie als sinnlos empfinden. Was kann John also tun, um ein gesundes Team von Middleware-orientierten Fachleuten zu erhalten? Vor allem muss John eine Person finden, mit der Dave ein Team bilden kann. John könnte versuchen, Leo oder Lloyd (oder beide) zu motivieren, die erforderlichen Fähigkeiten zu erlernen, um ein bestimmtes Niveau an Fachwissen zu erreichen, das Dave anerkennt. Das Problem dabei ist, dass Leo und Lloyd hervorragende Unix-Administratoren sind und Java und BPM nicht in Frage kommen. Ein weiteres Problem könnte die (mangelnde) Fähigkeit von Leo und Lloyd sein, dieses neue, ausgefallene Java und die BPM-Middleware zu erlernen.Wenn John seinem Vorgesetzten beweisen kann, dass das Middleware-Team im Hinblick auf die Arbeitsmenge nicht richtig skaliert ist (das Team ist unterdimensioniert), dann könnte John versuchen, einen oder mehrere qualifizierte Middleware-Experten zu finden und das Team zu erweitern. John könnte hier vor einer großen Herausforderung stehen, denn qualifizierte Middleware-Experten sind heutzutage schwer zu finden, es sei denn, Sie sind bereit, dafür zu bezahlen. Daves Aufgabe wird es sein, "Wissen zu teilen". Aber wenn Dave nicht kooperieren will, muss John ihn dazu überreden, sein Verhalten zu ändern. Außerdem muss er Dave dazu bringen, sein Wissen zu teilen, indem er ihm seine Sachkenntnis in dieser Angelegenheit darlegt und auf die negativen Auswirkungen seines Verhaltens hinweist (wie seine eigene Müdigkeit oder das Risiko von Ausfallzeiten, wenn er im Urlaub ist). Wenn das nicht hilft, sollte John vielleicht tiefer graben, um Daves persönliche Beweggründe herauszufinden. Ist es Konkurrenzdenken, Prestige, Perfektionismus oder ein Mangel an sozialen Fähigkeiten? Das könnte zu einer psychologischen Übung werden. Das Problem könnte auch in der Technologie selbst liegen. Wenn John nicht in der Lage ist, das System mit seinen Teammitgliedern zu unterstützen, könnte er versuchen, die Komplexität zu beseitigen, so viel wie möglich zu standardisieren, fehleranfällige Verfahren herauszunehmen und langweilige, sich wiederholende Aufgaben zu automatisieren. Oder auf andere Technologien umsteigen, die weitgehend unterstützt werden.Wie sich herausstellt, waren viele von uns selbst schon in heldenhaften Situationen. Wenn ich zurückblicke, frage ich mich: "Was hat mich dort überhaupt gehalten? War es das Gefühl, gebraucht zu werden, das sich angenehm anfühlte? Es hat mich daran gehindert, als Mensch und als Profi zu wachsen. Ich bin froh, dass ich am Ende gegangen bin und raten Sie mal, es gibt sie immer noch..."