Atlassian Data Center läuft aus, und dieser Termin generiert natürlich jede Menge Aufmerksamkeit für die Produkte. Viel weniger Aufmerksamkeit bekommen die kleinen Lösungen, die in vielen Unternehmen seit Jahren still und leise laufen: die Erweiterungen, die sie selbst gebaut haben – eine Workflow-Post-Function von 2017, eine Anbindung an das interne ERP, ein Dashboard, das die Finanzabteilung jeden Montag öffnet. Diese Apps migriert niemand für Sie in die Cloud.
Es gibt eine Java-Codebasis, einen Kollegen, der vielleicht noch im Unternehmen arbeitet oder längst weitergezogen ist, und eine Deadline.
Die gute Nachricht: Forge ist ein echtes natives Zuhause für diesen Code, gehostet von Atlassian, mit Extension Points, die fast alles abdecken, was ein Data-Center-Plugin früher geleistet hat.
Den Zeitplan und die Frage, warum Forge die natürliche neue Heimat für Data-Center-Apps ist, haben wir im Beitrag “Was bedeutet das Ende von Atlassian Data Center für Ihre Apps?” behandelt. Nun widmen wir uns der Reise selbst. Denn es gibt auch eine weniger gute Nachricht: Eine Migration unter Zeitdruck und ohne Landkarte gerät fast zwangsläufig ins Stocken.
In unseren Forge-Entwicklerworkshops haben wir eine Reihe von Enterprise-Teams auf diesem Weg begleitet. Dieser Artikel ist die Landkarte – jedoch nicht für die Entwicklungsteams, die an den Workshops teilnehmen, sondern für die Manager, die entscheiden. Ein Muster zieht sich durch jedes einzelne Projekt: Die kostspieligen und folgenschweren Fehler entstehen durch Entscheidungen, nicht durch Code. Hier sind die sechs, auf die es ankommt.
Entscheidung 1: Wer mit im Raum sitzt
Die hilfreichste Person in einer unserer Discovery-Sessions hatte noch nie eine Zeile Code geschrieben. Sie kannte das alte Tool in- und auswendig: welche Felder tatsächlich ausgefüllt wurden, welche Reports niemand liest, mit welchem Workaround das Team seit Jahren lebt. Nichts davon stand in irgendeiner Dokumentation, aber all diese Details waren entscheidend dafür, was die neue App leisten musste.
Machbarkeit ist ein Gespräch, keine Spezifikation. Sitzen nur Entwickler im Raum, driftet die Diskussion zum Wie ab. Das Fragen nach dem Was und dem Ob – also den Fragen, die entscheiden, ob das Projekt überhaupt sinnvoll ist – können nur die Leute beantworten, die das Problem quasi besitzen: Fachexperten und Entscheider.
Zwei Sätze fallen in fast jeder Session: “Dafür gibt es kein Tool von der Stange” und “Unser Use Case ist zu speziell für die Roadmap irgendeines Anbieters”. Beides sind valide Gründe, selbst eine Lösung zu bauen, und beides sind unternehmerische Entscheidungen.
Bevor also irgendetwas Technisches passiert, sollten Sie gründlich darüber nachdenken, wer am Machbarkeitsgespräch teilnimmt. Es sollten nicht nur die Mitglieder des Entwicklungsteams sein.
Entscheidung 2: Wofür Sie Zeit einplanen
Teams kommen zu uns mit der Annahme, sie müssten Forge lernen. Darum geht es jedoch nicht, jedenfalls nicht zuerst. Die Forge-API ist der gut dokumentierte, überschaubare Teil. Der eigentliche Sprung für ein Java-lastiges DC-Team ist die Welt drumherum: JavaScript statt Java, ein Event-Loop statt Threads, npm statt Maven, React als UI-Modell. Das sind Mindset-Wechsel, doch gute Entwicklungsteams meistern sie schnell, wenn sie die Stolperfallen kennen, statt jede einzelne zur Überraschung werden zu lassen.
Für einen Manager ist das eine Planungstatsache: Budgetieren Sie die Einarbeitung in das Ökosystem, nicht das “Erlernen einer API”. Mit kundiger Anleitung sind es Tage, sonst eher Wochen.
Entscheidung 3: Ob die IT vor Tag eins eingebunden ist
Einmal waren wir nahe dran, einen Workshop-Tag zu verlieren, allerdings nicht wegen der Programmierung. Es war ein Firmennetzwerk, das den Tools stillschweigend die Kommunikation nach außen verweigerte, und die Leute, die das hätten beheben können, waren nicht greifbar.
Ein praxisnahes Forge-Setup macht Dinge, vor denen viele Firmennetzwerke geschützt sind: Pakete aus dem Internet installieren, sich bei Cloud-Diensten anmelden, einen Tunnel zwischen Laptop und Entwicklungsumgebung öffnen.
Es wäre zu einfach, dem strikten Netzwerk die Schuld in die Schuhe zu schieben. Das Problem ist in der Regel der Plan, vor allem wenn er lautet: “Das klären wir am Workshop-Tag.”
Mittlerweile führen wir ein bis zwei Wochen vorher einen kurzen Remote-Check auf den echten Maschinen durch, und das hat seither jeden ersten Morgen gerettet. Wer bei Ihnen Forge-Schulungen durchführt, sollte das genauso handhaben, und Ihre IT- und Netzwerkleute frühzeitig einbinden.
Entscheidung 4: Die Design-Entscheidungen, mit denen Sie leben müssen
Zwei Teams bauen dieselbe kleine Jira-App. Gleiches Feature, gleicher Nachmittag, ungefähr gleich viel Code. Beim einen Team können die User Daten mit JQL filtern, Reports abrufen, Dashboards erstellen. Beim anderen Team existieren die Daten nur innerhalb eines Panels, unsichtbar für jede Suche. Niemand hat schlechteren Code geschrieben. Die Teams haben lediglich unterschiedliche Storage-Entscheidungen getroffen – binnen zehn Sekunden am ersten Tag.
Willkommen in der Welt von Forge! Die Dokumentation listet jedes Modul und jede Storage-Option korrekt auf, aber sie kann Ihnen nicht sagen, welche zu Ihrem Problem passt. Die Wahl bleibt Ihrem Team überlassen.
Das gilt auch für die Frage, mit wessen Berechtigungen die App läuft: Agieren Sie als App, wo eigentlich die User hätten agieren müssen, haben Sie ein stilles Datenleck gebaut, das in jedem Test perfekt funktioniert. Solche Entscheidungen sechs Monate später rückgängig zu machen, ist teuer.
Die Erkenntnis für das Management lautet: Sorgen Sie dafür, dass Design-Entscheidungen bewusst getroffen werden, und am besten sollte jemand beteiligt sein, der die Optionen schon einmal hat scheitern oder gelingen sehen.
Entscheidung 5: Was KI verändert und was nicht
Wir haben einen KI-Builder gebeten, eine Jira-App zu erstellen. Das Ergebnis war beachtlich: Die App funktionierte im ersten Versuch und der Code war wirklich gut, besser als so mancher handgeschriebene erste Entwurf.
Im Review fanden sich trotzdem vier Probleme, und sie hatten eines gemeinsam: Keines von ihnen führte zu einer Fehlfunktion, aber jedes einzelne produzierte eine zwar plausible, doch leider falsche Zahl. Das vollständige Review, und die Checkliste für den Weg einer KI-gebauten Forge-App in Produktion, ist ein eigener Artikel.
Das Management muss sich die 80/20-Regel der KI-gestützten Forge-Entwicklung offen vor Augen führen. Die 80 Prozent entstehen erstaunlich schnell, und mit Rovo-Agents als vollwertigem Forge-Modul wird die KI zu einem mächtigen Werkzeug für Forge-Entwicklungsteams.
Menschliches Urteilsvermögen kann sie indes nicht ersetzen: Zu wissen, welche Fragen man an eine Lösung stellt, die schon fertig aussieht, ist Aufgabe des Teams. “No Code” sagt nichts über die nötige Expertise. Planen Sie Ihre Schulungen entsprechend: Die Fähigkeit, die Ihr Team braucht, verschiebt sich vom Schreiben zum Prüfen des Codes.
Entscheidung 6: Wer die App am Montag verantwortet
Zwei Hälften derselben Entscheidung. Erstens der Betrieb: Die Aussage “Wir sind in die Cloud gewechselt, also ist der Betrieb erledigt!” stimmt nur halb. Das Hosting entfällt, und Atlassian betreibt die Plattform gut. Die App bleibt Ihre: Sie ruft APIs auf, die sich weiterentwickeln, trifft auf Daten, die irgendwann nicht mehr wie Ihre Testdaten aussehen, verbraucht Ressourcen, die jenseits der Free Tier zur Rechnung werden, und ihre Updates benötigen die Zustimmung der Admins, sodass sich die installierte Basis still über mehrere Versionen verteilt. Jemand muss die Developer Console öffnen – und bevor Ihre App live geht, müssen Sie entscheiden, wer das sein wird.
Der zweite Aspekt ist der Weg nach dem Prototyp. Unsere Workshops enden damit, dass jedes Team seine eigene funktionierende App deployt hat. Dann steht die eigentliche Frage im Raum: Was passiert am Montag? Wir haben drei funktionierende Antworten erlebt:
- Selbst bauen – mit Expertenunterstützung auf Abruf.
- Co-Build: Pair Programming an Ihrer echten ersten App.
- Die Umsetzung ganz delegieren, während Ihr Team nahe genug bleibt, um zu verstehen, was passiert.
Alle drei Ansätze sind in Ordnung. Das einzige Ergebnis, das es zu vermeiden gilt, ist die Black Box: Eine App, die niemand im Unternehmen versteht, ist kein Asset, sondern eine Verbindlichkeit mit Login-Seite.
Die Landkarte im Überblick
Hier sind die sechs entscheidenden Punkte, die Ihrem erfolgreichen Umstieg von Data Center auf Forge den Weg ebnen:
- Holen Sie die richtigen Leute ins Machbarkeitsgespräch.
- Budgetieren Sie für den Ökosystemsprung, nicht für die API.
- Klären Sie Netzwerkfragen vor Tag eins.
- Behandeln Sie Storage, Berechtigungen und Entry Points als Entscheidungen, nicht als Defaults.
- Nutzen Sie KI für die 80 Prozent und behalten Sie das Urteilsvermögen für die 20 Prozent.
- Entscheiden Sie, wer die App ab Montag verantwortet, denn der Prototyp ist erst der Anfang.
Nichts davon ist schwer zu realisieren, sobald das Team weiß, warum diese Themen wichtig sind.
Unsere Forge-Entwicklerworkshops sind genau um diesen Weg herum konzipiert – von der Discovery bis zum Prototyp, inklusive der Betriebs- und Review-Module, die die meisten Trainings auslassen. Wenn Ihr Team vor diesem Sprung steht: Hier sind alle Details zu unseren Forge-Schulungen für Entwicklungsteams.