Moin, ich bin Hauke

Viele Jira-Instanzen sind über die Jahre zugewuchert: aufgeblähte Prozesse, doppelte Workflows, unklare Strukturen. Die Folge — Teams klicken sich durch Tickets und suchen, statt vom Flow intuitiv durch den Prozess geführt zu werden. Leider nachvollziehbar, dass über Jira geschimpft wird.

Genau da setze ich an. Mein Schwerpunkt liegt auf Atlassian Data Center — Jira, Jira Service Management und Confluence — sowie auf Prozessautomatisierung mit ScriptRunner und Assets.

Ich verschlanke gewachsene Instanzen, entwerfe saubere Workflows und bilde eure Geschäftsprozesse so im Stack ab, dass sie intuitiv funktionieren. Wo es sinnvoll ist, automatisiere ich wiederkehrende Schritte und binde Umsysteme an (z. B. OpsGenie, StatusPage, Confluence oder eigene Services per REST). Administration und Konfiguration laufen selbstverständlich mit.

Ich designe und baue eine hochverfügbare Infrastruktur für den Stack — reproduzierbar, in Code definiert, mit minimalen Wartungs-Downtimes — und überführe den Betrieb dann in eure IT-Mannschaft.

Mein Ziel für jedes Projekt: dass eure Mitarbeitenden am Ende gerne, intuitiv und ohne Stress mit Jira arbeiten.

Ein einzelner Server, der alles trägt und beim ersten Ausfall die halbe Firma lahmlegt. Deployments, bei denen jedes Mal etwas stillsteht. Über Jahre gewachsene Infrastruktur, die keiner mehr anzufassen wagt. Oder teure Managed-Services in der Cloud, die sich schlanker und günstiger auch selbst betreiben lassen. Klassische Ops-Themen — und genau da bin ich eine helfende Hand.

Mein Schwerpunkt: klassische Linux-Hochverfügbarkeit. Ich baue redundante Setups um bestehende Single-Instances herum, ziehe komplette Infrastruktur von Grund auf hoch oder migriere gewachsene Umgebungen auf ein sauberes, wartbares Fundament. Alles reproduzierbar und in Code definiert (Ansible, GitLab CI), damit sich Umgebungen jederzeit nachbauen und nachvollziehen lassen.

Skalierbarkeit, Stabilität und vor allem Wartbarkeit stehen dabei immer im Vordergrund — ich setze auf bewährte Technik, die auch dann noch trägt, wenn ich längst weg bin.

Für akute Störungen und Engpässe könnt ihr mich kurzfristig hinzuziehen: Ich übernehme direkt im Firefighter-Modus, arbeite mich schnell in bestehende Umgebungen ein und bringe die Situation ohne langen Vorlauf wieder unter Kontrolle.

Vieles läuft bei euch noch per Hand: Deployments, wiederkehrende Betriebsaufgaben, ganze Business-Prozesse. Das funktioniert – kostet aber Zeit, ist schwer reproduzierbar und öffnet Tür und Tor für Fehler. Genau hier setzen wir an.

Ich hole euch da ab, wo ihr steht. Der erste Schritt ist selten ein Tool, sondern ein Mindset: Was lohnt sich zu automatisieren, wo liegen die größten Hebel, und wie reduzieren wir Risiken und Fehlerquellen, statt neue zu schaffen? Reproduzierbare Standards machen den Betrieb ruhiger – und das Leben für alle Beteiligten leichter.

Dabei bleibe ich bewusst tool-agnostisch. Es geht nicht darum, das eine glänzende Werkzeug einzuführen, sondern den Ansatz zu finden, der zu euch passt.

• Einstieg & Mindset: Hebel identifizieren, Kandidaten priorisieren, Risiken und Fehlervektoren minimieren
• Deployment & Betrieb: Provisionierung, Config Management, Deployments, wiederkehrende Betriebsaufgaben
• Business-Prozesse: Onboarding/Offboarding, Reporting, alles Wiederkehrende jenseits der reinen Technik
• Umfang nach Bedarf: vom Konzept über Basis-Schulungen bis zu fertigem Code und produktiven Pipelines

Ich setze bei keinem Schritt etwas voraus und höre bei keinem auf. Ihr bekommt genau so viel, wie ihr braucht – ein Konzept zum Selbermachen oder die schlüsselfertige Umsetzung.

Mein Ziel ist immer dasselbe: das Repetitive automatisieren, damit eure Teams Zeit für die coolen, innovativen Dinge haben – dort, wo echter Wert entsteht.

Manchmal steckt die eigentliche Arbeit nicht in der Umsetzung, sondern im Entwurf dahinter.

Ein Neubau auf der grünen Wiese. Eine über Jahre gewachsene Landschaft, die unter ihrer eigenen Tech Debt ächzt. Oder zwei IT-Welten, die nach einer Fusion zu einer werden müssen.

Ich entwerfe komplexe IT-Systeme und Plattformen, schreibe die Konzepte dahinter und helfe bei Design-Entscheidungen. Aus der DevOps-Praxis weiß ich genau, wie sich jede dieser Entscheidungen im Betrieb anfühlt.

Zu Hause bin ich besonders in der Post-Merger-Integration: wenn nach einer Übernahme zwei oder mehr eigenständige IT-Landschaften zusammenwachsen müssen, mit allem, was an Altlasten, Doppelstrukturen und politischen Spannungen dranhängt.

Ein Architektur-Projekt beginnt bei mir mit Zuhören, und zwar auf beiden Seiten. Ich rede mit euren Entscheidern über Ziele, Budget und Risiken — und genauso mit den Teams, die die Plattform am Ende betreiben und weiterentwickeln.

Aus Ist-Bild, Anforderungen und Randbedingungen wird eine Zielarchitektur, eine Roadmap dorthin und die Entscheidungsvorlagen, um loszulegen. Wenn ihr wollt, bleibt es nicht beim Papier: Ich pitche das Zielbild bei den Entscheidern, schule euer Fachpersonal oder begleite die beteiligten Teams als Mentor durch die Umsetzung.

Die teuersten Fehler in der IT stecken selten im Code — sie stecken in der Architektur, die niemand hinterfragt hat. Genau da setze ich an: das große Ganze zu Ende denken.

Irgendwann wurde eure Infrastruktur nicht mehr gebaut, sondern ist gewachsen. Patches laufen von Hand, das Monitoring wird vorher weggeklickt — sofern es überhaupt eins gibt.

Änderungen passieren direkt auf dem Server, an der Versionsverwaltung vorbei. Nichts davon war je eine falsche Entscheidung, es hat sich so ergeben und es hat funktioniert. Nur wächst der Aufwand mit jedem Jahr, und mit ihm die Zahl der Stellen, an denen ein Handgriff schiefgehen kann.

Meistens beginnt es mit einem Satz wie diesem: „Wir stecken unsere ganze Zeit da rein, die Infrastruktur am Laufen zu halten — alles manuell, alles fehleranfällig.“

Dazu die Themen, die sich nicht ewig vertagen lassen: EOL-Versionen, Compliance-Anforderungen, und der eine Kollege, der als Einziger weiß, warum dieser Server so konfiguriert ist, wie er ist — und nächstes Jahr in Rente geht.

Ich löse das nicht mit einem großen Wurf. Ein Big Bang ist der schnellste Weg, sich neue Ausfälle einzukaufen. Stattdessen definieren wir zuerst gemeinsam den Standard, auf den ihr hinwollt — und dann bewegen wir euch Stück für Stück dorthin: ein Dienst, ein Prozess, ein Server nach dem anderen, jeweils so, wie es für den konkreten Fall am saubersten passt.

Dabei nehmen wir die Leute mit, die das System seit Jahren betreiben; sie kennen die Details, die in keiner Doku stehen. Am Ende steht ein Betrieb, der nicht mehr an Handgriffen und Einzelwissen hängt.

Ich schreibe das Konzept und begleite eure Teams durch die Umsetzung.

• Ist-Aufnahme — was läuft da eigentlich, woran hängt es, und wer weiß darüber Bescheid
• Standard-Definition — gemeinsam mit euch, nicht über eure Köpfe hinweg
• Prozesse — Patch- und Update-Zyklen, Wartungsfenster, Changes
• Automatisierung — von Konfiguration und Deployment bis zum Update-Rollout
• Version Control — Konfiguration nachvollziehbar statt gewachsen
• Monitoring — sauber genug, dass es keiner mehr wegdrückt
• EOL & Migration — abgekündigte Versionen und Systeme schrittweise ablösen
• Wissenstransfer — Doku und Übergabe, damit der Betrieb nicht an einzelnen Personen hängt

Am Ende soll euer Team nicht mehr damit beschäftigt sein, den Status quo zu halten — sondern mit dem, was als Nächstes kommt.

Meistens ist es das Backlog, das nicht mehr kleiner wird. Oder Stakeholder, die nicht mehr sicher sagen können, woran sie eigentlich sind. Das Team arbeitet – nur ist die Arbeitsweise über die Jahre eher gewachsen als gewählt worden.

Ich begleite euch von Wasserfall oder reinem Zuruf-Betrieb hin zu einer Struktur, die trägt: Scrum, Kanban – oder, ehrlich gesagt meistens, etwas dazwischen. Kein Lehrbuch passt zu hundert Prozent auf ein bestehendes Team. Die Methodik, die am Ende wirklich funktioniert, ist immer eure eigene. Genau die entwickeln wir gemeinsam.

Der erste Schritt ist deshalb keine Methode, sondern Zuhören. Ich schaue mir den Status quo an und rede mit allen Beteiligten – Team, Führung und Stakeholdern. Was läuft gut, was nervt, was wünscht ihr euch? Aus diesen Antworten wird der Plan, nicht aus einem Framework.

Zuhause bin ich in Ops- und DevOps-Teams. Das Vorgehen funktioniert aber genauso woanders – es geht um Arbeitsweisen, nicht um Technologie.

• Status quo: wie ihr heute tatsächlich arbeitet, nicht wie es im Prozessdiagramm steht
• Interviews: Gespräche mit Team, Führung und Stakeholdern – Wünsche und Kritik gleichermaßen
• Ableitung: was sich lohnt, was realistisch ist und was zuerst drankommt
• Workshops: Arbeitsweise und Rollen gemeinsam festlegen, statt sie von außen zu verordnen
• Standards: Backlog, Priorisierung, Rituale und Transparenz nach außen – festgehalten und im Alltag gelebt

Mein Ziel ist von Anfang an, mich überflüssig zu machen. Am Ende arbeitet ihr agiler, weil die Struktur zu euch passt – und eure Stakeholder wissen jederzeit, wo was steht und worauf sie sich verlassen können.

Projekte bleiben selten von einem Tag auf den anderen stehen. Meistens werden sie einfach zäh: Termine rutschen, Entscheidungen werden vertagt, und auf die Frage, woran es gerade hängt, gibt es viele verschiedene Antworten.

Woran es hängt, ist von Projekt zu Projekt verschieden. Wenn es an der technischen Seite liegt, hilft manchmal ein Blick von außen — jemand, der nicht seit Monaten in denselben Diskussionen steckt. Oder es fehlt schlicht Kapazität, weil eine Schlüsselperson das Team verlassen hat und ein guter Teil des Wissens mit ihr gegangen ist.

Da komme ich als technischer Sparringspartner dazu. Ich bringe meine technische Erfahrung ein: in der Planung, in der Abstimmung, mit Ideen, wenn eine Richtung fehlt, und auf Wunsch auch als Coach für euer Team.

Wie viel das ist, entscheidet ihr. Ein paar Stunden für eine einzelne Entscheidung, ein paar Tage in einer kritischen Phase oder eine sporadische Begleitung über die ganze Laufzeit. Feste Kontingente oder Mindestlaufzeiten gibt es bei mir nicht. Ich arbeite im Takt eures Teams und mit den Methoden, die dort schon etabliert sind — ihr müsst euch nicht auf eine neue Vorgehensweise umstellen, nur weil ich dabei bin.

Am Ende zählt für mich nur eins: dass das Projekt durchgeht. Nicht, wie viele Tage ich dafür im Haus war.