Jira: Vom Projekttool zum Betriebssystem

Wenn Sie in Ihrem Unternehmen für Jira und Confluence verantwortlich sind, wissen Sie wahrscheinlich etwas, das der Rest des Unternehmens längst aus den Augen verloren hat: Was Sie betreiben, ist schon seit Langem nicht mehr einfach nur ein weiteres Tool.

Für alle anderen ist es der Ort, an dem Tickets liegen. Für Sie ist es das Ergebnis von zehn Jahren Entscheidungen: Workflows, die festlegen, wie eine Änderungsanfrage durch das Unternehmen läuft. Berechtigungsschemata, die Ihre Organisationsstruktur widerspiegeln. Benachrichtigungsregeln, die bestimmen, wer wann worüber informiert wird.

Und dann ist da noch Confluence. So eng mit diesem System verwoben, dass Architekturentscheidungen, Projektaufträge und zentrale Beschlüsse oft nur im Zusammenhang mit den Jira-Tickets Sinn ergeben, auf die sie sich beziehen.

Irgendwann auf diesem Weg – ohne eigenes Projekt, ohne Budget und ohne dass es überhaupt jemand so genannt hätte – haben Sie das Betriebssystem aufgebaut, auf dem die Arbeit Ihres Unternehmens heute tatsächlich läuft. Ein Schema, ein Workflow, ein Feld und eine Integration nach dem anderen.

Dieser Unterschied ist wichtig. Denn viele Gespräche über die „Modernisierung“ einer solchen Umgebung beginnen mit der gegenteiligen Annahme: Dass darunter im Grunde nur ein Kanban-Board mit ein paar zusätzlichen Feldern steckt. Und dass ein Wechsel kaum mehr bedeutet, als Daten zu exportieren und eine neue Oberfläche darüberzulegen.

Sie wissen, dass das nicht stimmt.

Sie sind die Person, die erklären muss, was passiert, wenn jemand ein Schema ändert. Warum ein Feld, das „eigentlich da sein müsste“, plötzlich nicht mehr angezeigt wird. Oder weshalb das Lieblings-Dashboard des Steuerungsgremiums auf einmal falsche Zahlen liefert, nachdem jemand einen Projektnamen geändert hat.

Bevor wir also in technische Details einsteigen, lohnt es sich, genauer hinzusehen, woraus dieses Betriebssystem eigentlich besteht. Selten ist alles an einem Ort dokumentiert. Und bevor Sie entscheiden können, was als Nächstes damit passieren soll, müssen Sie zunächst klar benennen, was Sie überhaupt aufgebaut haben.

Das Wichtigste auf einen Blick

1. Jira und Confluence sind längst mehr als Tools. Sie sind zum stillschweigenden Betriebssystem des Unternehmens geworden. Zehn Jahre voller Schemata, Workflows und Berechtigungen bestimmen heute, wie Arbeit läuft, wer was sehen kann und wer wann informiert wird. Dokumentiert wurde das selten vollständig – denn die Menschen, die es aufgebaut haben, wussten einfach, wie es funktioniert.

2. Die eigentliche Komplexität steckt in sechs Ebenen, die in keiner Demo sichtbar werden. Schemata, Workflows, Felder, Berechtigungen, Dashboards und Marketplace-Apps können jeweils auf ihre eigene Weise zum Problem werden. Ein Feld, das drei von vier Voraussetzungen erfüllt, wird trotzdem nicht angezeigt. Ein Workflow-Ereignis ohne konfigurierte Benachrichtigung ist nicht defekt – es bleibt einfach still.

3. Das Ende von Atlassian Data Center im Jahr 2029 erzwingt eine Entscheidung, macht sie aber nicht einfacher. Die Frist ist real. Was bis dahin tatsächlich migriert werden muss, ist von außen jedoch selten offensichtlich.

4. Bevor Sie migrieren, müssen Sie Ihre bestehende Umgebung verstehen. Genau hier setzt sovara an. Gemeinsam mit Ihnen klären wir zunächst, was unter die Migrationsgarantie von sovara fällt – etwa Tickets, Workflows, Automatisierungen und zentrale Konfigurationen – und was eine separate Betrachtung benötigt, beispielsweise Plugins oder individueller Code.

Eine Engine, drei Produkte und Confluence mittendrin

Jira ist keine einzelne Anwendung, sondern eine Produktfamilie. Jira Software, Jira Work Management und Jira Service Management basieren alle auf derselben Issue Engine: Issues, Workflows, Felder, Benachrichtigungen und Schemata.

Was sie unterscheidet, sind Benutzeroberfläche, Zielgruppe und Lizenzmodell:

• Jira Software: für Entwicklungs- und Delivery-Teams – mit Scrum- und Kanban-Boards, Sprints und Versionen.

• Jira Work Management: für Business-Teams wie HR, Legal oder Operations – mit einfacheren Vorlagen für Prozesse außerhalb der Softwareentwicklung.

• Jira Service Management: für Support- und Service-Teams – mit Kundenportal, Request Types und SLAs.

In vielen Unternehmen laufen mehrere dieser Produkte gleichzeitig – häufig auf Data Center, Atlassians selbstverwalteter Cluster-Architektur. Sie ist weiterhin dort verbreitet, wo Anforderungen an Datenresidenz, Regulierung oder eine Private-Cloud-Architektur die öffentliche Atlassian Cloud ausschließen.

Und genau hier gibt es eine harte Frist: Atlassian beendet den Support für Data Center im Jahr 2029.

Mehrere Nodes, eine gemeinsame Datenbank, ein gemeinsames Home-Verzeichnis für Plugins und Daten – nach außen funktioniert alles als eine logische Instanz.

Daneben läuft Confluence Data Center. Nicht als isoliertes Silo, sondern eng mit Jira verbunden: Makros ziehen Live-Daten aus Jira in Spezifikationen. Meeting Notes verweisen über Ticket-Keys auf Issues. Architekturentscheidungen beziehen sich auf die Epics, aus denen sie entstanden sind.

All das taucht in keinem Feature-Vergleich auf. Aber all das gehört zu dem, was Sie bei einer Migration tatsächlich berücksichtigen müssen.

Das eigentliche Betriebssystem sind die Schemata

Hier liegt ein Mechanismus, den viele Außenstehende nie wirklich kennenlernen: Ein Jira-Projekt ist kein einfacher Ordner.

Es ist ein strukturierter Container. Sein Verhalten wird durch Schemata definiert: Welche Issue Types es gibt. Welche Felder angezeigt werden. Welche Screens beim Erstellen oder Bearbeiten erscheinen. Welcher Workflow Statusänderungen steuert. Wer Benachrichtigungen erhält. Und wer welche Inhalte sehen darf.

Diese Schemata werden Projekten zugeordnet, statt für jedes Projekt einzeln aufgebaut zu werden.

Genau deshalb kann eine gut geführte Jira-Umgebung beispielsweise 1.300 Projekte mit rund 200 gemeinsamen Workflows betreiben, anstatt den Prozess bei jedem neuen Team neu zu erfinden.

Wenn die Governance jedoch nachlässt, entsteht dieselbe Komplexität schnell in die andere Richtung: Hunderte fast identische, aber in entscheidenden Details unterschiedliche Konfigurationen, die irgendwann niemand mehr gefahrlos ändern kann.

Die interessante Frage war daher nie: „Kann dieses Tool Workflows abbilden?“

Die entscheidende Frage lautet: Können Sie ein Betriebsmodell einmal definieren, breit ausrollen, dort kontrollierte Abweichungen zulassen, wo Teams sie tatsächlich benötigen, und Veränderungen trotzdem zentral steuern?

Und zwar auch Jahre später, wenn die Menschen, die das System ursprünglich aufgebaut haben, längst nicht mehr im Unternehmen sind.

Boards waren nie der Workflow

Ein Board ist eine Ansicht. Scrum ergänzt einen Backlog und Sprints. Kanban ergänzt WIP-Limits. Die Spalten selbst bilden jedoch lediglich Status ab.

Wenn Sie eine Spalte umbenennen, ändern Sie, was die Menschen sehen – nicht unbedingt, was im System tatsächlich passiert.

Genau deshalb sagt Ihnen eine Demo, die hauptsächlich Boards zeigt, fast nichts darüber aus, was bei einer Migration tatsächlich ersetzt werden müsste.

Der eigentliche Prozess liegt eine Ebene tiefer: im Workflow selbst.

Dort gibt es Übergänge, die nur in eine Richtung funktionieren. Einen eigenen Übergang für den Rückweg. Bedingungen, die entscheiden, ob ein Übergang überhaupt sichtbar ist. Validatoren, die bestimmen, ob eine Aktion ausgeführt werden darf. Und Post-Funktionen, die die eigentlichen Nebenwirkungen auslösen: eine Resolution setzen, jemanden zuweisen oder einen Webhook starten.

Wenn ein Workflow inzwischen aus „vierzig Post-Funktionen“ besteht, ist das in der Regel längst nicht mehr nur Standard-Jira.

Dann übernehmen häufig Tools wie ScriptRunner, JSU, JWT oder JMWE einen großen Teil der eigentlichen Logik – unsichtbar hinter einem Diagramm, das auf den ersten Blick immer noch erstaunlich einfach aussieht.

Ein Feld muss vier Ebenen durchlaufen, um überhaupt angezeigt zu werden

Custom Fields sind nicht automatisch überall verfügbar. Jedes Feld existiert innerhalb eines bestimmten Kontexts – also einer Kombination aus Projekt und Issue Type. Gibt es diesen Kontext nicht, ist das Feld nicht einfach verborgen. Es existiert dort schlicht nicht.

Damit ein Feld tatsächlich auf einem Screen erscheint, müssen vier Voraussetzungen erfüllt sein:

1. Es braucht einen passenden Kontext für dieses Projekt und diesen Issue Type.

2. Das Feld muss auf dem entsprechenden Screen platziert sein.

3. Dieser Screen muss aktuell dem richtigen Vorgang zugeordnet sein – also Create, Edit oder View.

4. Das dazugehörige Screen Scheme muss für dieses Projekt ausgewählt sein.

Fehlt nur eine dieser vier Voraussetzungen, kann das Ergebnis erstaunlich unspektakulär aussehen: „Ich habe das Feld doch gerade hinzugefügt“ – und nichts passiert.

Hier wird sichtbar, welche Dimension Ihre Umgebung tatsächlich erreicht hat. Tausende Custom Fields sind nicht einfach eine Datenmapping-Aufgabe, die auf ihre Migration wartet. Sie bilden den operativen Wortschatz Ihres Unternehmens ab: die Begriffe, mit denen HR, Legal oder Delivery ihre jeweiligen Prozesse beschreiben. Diese Begriffe sind mit Kontexten, Screens, Workflows, Filtern und Reports verbunden. Sie als einfache Liste von Feldnamen zu behandeln, die man nur „zuordnen und übertragen“ muss, verfehlt, was sie tatsächlich darstellen.

Berechtigungen sind ein mehrstufiges System – und E-Mail ist ein Event-System

Zugriff ist nicht eine einzelne Einstellung. Er beginnt mit dem Application Access auf Lizenzebene. Danach folgen globale Berechtigungen. Anschließend greift das Permission Scheme des jeweiligen Projekts – idealerweise über Rollen statt über fest codierte Gruppen, die bei der nächsten Reorganisation ohnehin umbenannt werden.

Zusätzlich kann ein Issue Security Scheme auf einzelne Vorgänge angewendet werden, wenn diese stärker eingeschränkt werden müssen als das Projekt insgesamt.

Auch Benachrichtigungen funktionieren über mehrere Ebenen.Ausgehende E-Mails werden durch Ereignisse ausgelöst, die mit einem Notification Scheme verbunden sind. Eingehende Mail Handler können aus Nachrichten eines gemeinsamen Postfachs Tickets erstellen oder bestehende Tickets kommentieren. Und Nutzerinnen und Nutzer können gespeicherte Filter abonnieren und eigene Zusammenfassungen erhalten.

Ein benutzerdefiniertes Workflow-Ereignis, für das keine Benachrichtigung konfiguriert wurde, ist deshalb nicht kaputt. Es bleibt einfach still.

Wenn Ihr Unternehmen also sagt: „Wir bekommen eine E-Mail, wenn X passiert“, dann ist das keine vergessene Checkbox. Es ist eine Prozessentscheidung, die irgendwann getroffen und im System abgebildet wurde.

Filter und Dashboards sind das Reporting-System, das niemand dokumentiert hat

Die Suche in Jira bietet Quick Search, Basic Search und JQL. JQL ist dabei im Grunde eine WHERE-Klausel – kein Report Generator. Filter sind gespeicherte JQL-Abfragen. Dashboards bestehen aus Gadgets, die auf diesen gespeicherten Filtern aufbauen.

In einer Umgebung, die seit Jahren produktiv genutzt wird, ist diese Ebene oft enorm groß. Und gleichzeitig ist sie häufig genau das, was das Management tatsächlich sieht.

Die Folie, die das Steering Committee jeden Monat diskutiert, basiert möglicherweise auf drei oder vier verschachtelten Filtern – erstellt von jemandem, der inzwischen in einem anderen Team arbeitet oder das Unternehmen längst verlassen hat.

Eine ehrliche Bestandsaufnahme muss deshalb auch diese Ebene berücksichtigen. Nicht nur die Issues selbst, sondern alles, was darauf aufgebaut wurde.

In Marketplace-Apps steckt oft ein großer Teil der tatsächlichen Logik

Apps aus dem Atlassian Marketplace – oder JAR-Dateien, die in Air-Gapped-Umgebungen direkt eingebunden wurden – müssen exakt zum jeweiligen Hosting-Modell passen.

Eine App aus der Server-Ära, die auf einem Data-Center-Node läuft, kann genau jene Art von „unerwartetem Verhalten“ verursachen, die sich in keinem Support-Call zuverlässig reproduzieren lässt.

ScriptRunner für individuelle Logik. JSU, JWT und JMWE für Workflow-Erweiterungen ohne oder mit wenig Code. Structure für Portfolio-Hierarchien. Dazu Testmanagement-, Zeiterfassungs- und CMDB-Tools, die alle auf derselben Issue Engine aufbauen.

Das ist keine Dekoration.In vielen Jira-Umgebungen läuft genau dort ein großer Teil der tatsächlichen Prozesslogik.

Eine Bestandsaufnahme, die diese Anwendungen auslässt, ist deshalb unvollständig, bevor sie überhaupt begonnen hat.

Warum rready mit der Analyse Ihres Systems beginnt

All das ist kein Argument gegen Veränderung. Es ist ein Argument dafür, ernst zu nehmen, was Veränderung tatsächlich bedeutet. Über Jahre hinweg nehmen Jira und Confluence gemeinsam die Prozesse eines Unternehmens auf: seinen internen Wortschatz, sein Reporting und seine Governance.

Vieles davon steckt in Konfigurationen, die nie vollständig dokumentiert wurden. Nicht, weil jemand nachlässig war, sondern weil die Menschen, die das System aufgebaut haben, einfach wussten, wie es funktioniert. So wie Sie es heute wissen.

Deshalb beginnen wir mit einem Gespräch, um:

• Ihre Umgebung einzugrenzen: Wir sprechen auf über Ihre Konfiguration, die Anzahl der Projekte, Integrationen und die Probleme, die Sie bereits kennen.

• Zu erfassen, was tatsächlich vorhanden ist: Wir analysieren gemeinsam Ihre realen Schemata, Workflows, Felder, Berechtigungen und Marketplace-Apps – statt eine generische Checkliste abzuarbeiten.

• Klarheit über den Umfang zu schaffen: Wir zeigen Ihnen, was unter die Migrationsgarantie von sovara fällt – darunter Tickets, Workflows, Automatisierungen und zentrale Konfigurationen, abgesichert durch eine Geld-zurück-Garantie – und was außerhalb dieses Rahmens liegt, etwa Plugins und individueller Code. Diese Punkte klären wir separat, bevor überhaupt ein Termin für die Migration festgelegt wird.

Ein Betriebssystem dieser Größenordnung entsteht nicht über Nacht. Es wurde über Jahre aufgebaut. Und genau diese Arbeit lässt sich nicht durch einen Datenexport und eine neue Benutzeroberfläche ersetzen. Sie müssen zunächst verstehen, was Sie aufgebaut haben – bevor irgendjemand, auch wir bei rready, Ihnen eine Alternative dazu verkaufen kann.