Warum Kunden ihre DevOps-Tools selbst besitzen sollten

Kunden sollten ihre Salesforce-DevOps-Tools selbst besitzen, denn wer Accounts, Lizenzen und Zugriffsrechte kontrolliert, kontrolliert das Projekt. Das gilt für Git-Repository und CI/CD-Pipeline genauso wie für Jira, Confluence und Miro. Selbst besitzen heißt nicht, eigene Server zu betreiben. Cloud-Dienste sind in Ordnung, solange Arbeitsbereiche und Admin-Rechte dem Kunden gehören und auch über jede Partnerschaft hinaus beim Kunden bleiben. Partner bekommen persönliche Benutzer mit den Rechten, die sie für ihre Aufgabe brauchen.

Was heißt es, die eigenen DevOps-Tools zu besitzen?

Tools zu besitzen heißt, die Schlüssel in der Hand zu halten, egal wo die Software läuft. In der Praxis bedeutet das:

• Vertrag und Lizenzen jedes Tools laufen auf den Kunden,
• die Admin-Rechte liegen bei Mitarbeitenden des Kunden, nicht nur bei Partnern,
• der Arbeitsbereich (die GitHub-Organisation, die Jira-Instanz, das Miro-Team) gehört dem Kunden,
• Partner werden eingeladen in den Arbeitsbereich des Kunden, nicht umgekehrt.

Eine GitHub-Organisation, eine Jira-Cloud-Instanz oder ein Miro-Team sind an einem Nachmittag eingerichtet. Keine eigenen Server, kein Infrastrukturprojekt. Der Unterschied liegt nur darin, auf wessen Namen der Account läuft und wer Zugriffe vergeben und entziehen kann.

Um welche Tools geht es?

In einem typischen Salesforce-Programm verteilt sich Projektwissen und Kontrolle auf mehr Tools, als vielen bewusst ist:

1. Salesforce-Orgs, Sandboxes und Dev Hub. Sie gehören meist schon dem Kunden. Prüfen Sie aber, wer die Systemadministrator-Accounts hält und ob sie persönlich sind.
2. Git-Repository und CI/CD-Pipeline. Das Repository ist die Historie jeder Änderung, die Pipeline entscheidet, was in die Produktion kommt. Warum beides unverzichtbar ist, erkläre ich im Artikel warum DevOps über Salesforce-Großprojekte entscheidet.
3. Jira oder Azure Boards. User Stories, Akzeptanzkriterien, Fehler und Entscheidungen. Ohne sie kann später niemand erklären, warum etwas so gebaut wurde.
4. Confluence oder ein Wiki. Architekturentscheidungen, Schnittstellenbeschreibungen, Betriebshandbücher.
5. Miro oder ähnliche Whiteboards. Prozesslandkarten, Datenmodelle und Workshop-Ergebnisse, oft der einzige Ort, an dem das Zielbild je gezeichnet wurde.
6. Secrets und technische Benutzer. Integrationsuser, Zertifikate, API-Schlüssel und der Passwort-Tresor, in dem sie liegen.

Jedes dieser Tools kann im Account eines Partners landen, ohne dass es jemand entschieden hat. Ein Partner startet schnell, nutzt seine eigene Jira-Instanz und seine eigene Git-Organisation, und ein Jahr später liegt die Projekthistorie des Kunden im System eines anderen.

Was geht schief, wenn der Partner die Tools besitzt?

Solange die Zusammenarbeit gut läuft, merkt es niemand. Die Probleme zeigen sich, wenn sich etwas ändert:

• Die Zusammenarbeit endet. Daten müssen exportiert und migriert werden. Kommentare, Verknüpfungen, Anhänge und Historie gehen oft verloren. Manchmal hat der Export für einen scheidenden Partner schlicht keine Priorität.
• Ein zweiter Partner kommt dazu. Dann braucht der neue Partner Zugriff auf den Arbeitsbereich eines Wettbewerbers, oder es entsteht ein zweiter Satz Tools. Standards driften auseinander und Teams überschreiben sich gegenseitig.
• Partner sind nicht vergleichbar. Besitzt ein Partner Repository und Pipeline, besitzt er auch den Release-Prozess, und alle anderen Partner arbeiten nach seinen Regeln.
• Menschen gehen. Ist der einzige Admin eines Tools ein Mitarbeiter des Partners, der den Job wechselt, tut sich sogar der Partner schwer, die Kontrolle zurückzubekommen.
• Sicherheit und Compliance. Der Kunde kann einfache Audit-Fragen nicht beantworten: Wer hat Zugriff auf unseren Quellcode, unsere Anforderungen, unsere Zugangsdaten?

Partner kommen und gehen. Repository, Backlog und Architekturentscheidungen sollten bleiben.

Das ist kein Vorwurf an Partner. Die meisten guten Partner arbeiten lieber in den Tools des Kunden, weil das ihren eigenen Ausstieg sauber und ihre Arbeit sichtbar macht.

Was hat das mit Partnersteuerung zu tun?

Sehr viel. Als Architekt auf Kundenseite ist eines meiner wichtigsten Ziele, Umsetzungspartner vergleichbar und austauschbar zu halten. Das funktioniert nur, wenn die Grundlagen dem Kunden gehören: Repository, Pipeline, Backlog und Dokumentation. Dann lässt sich ein neuer Partner in ein bekanntes Setup mit schriftlichen Standards einarbeiten, und ein scheidender Partner gibt nichts weiter ab als seine Benutzer.

Es ist auch die Voraussetzung, um internes Ownership aufzubauen. In dem Programm, das ich in meinem DevOps-Artikel beschreibe, wurde der Release-Prozess am Ende an einen internen Kollegen übergeben. Eine solche Übergabe ist nur realistisch, wenn Tools und Rechte bereits auf Kundenseite liegen. Sonst erbt die interne Person einen Prozess, der weiter an fremden Accounts hängt. Der Besitz der Tools ist die Grundlage guter Partnersteuerung und Governance.

Wie setzen Sie das in der Praxis auf?

Am besten, bevor der erste Partner startet. Diese Regeln haben sich bewährt:

1. Der Kunde legt die Arbeitsbereiche an. GitHub- oder GitLab-Organisation, Jira- und Confluence-Instanz, Miro-Team: alles vom Kunden eingerichtet, mit Lizenzen im Vertrag des Kunden.
2. Mindestens zwei Admins des Kunden pro Tool. Nie ein einzelner Admin und nie nur Partner.
3. Nur persönliche, benannte Accounts. Jeder Mitarbeitende eines Partners bekommt einen eigenen Benutzer. Keine geteilten Logins, damit Zugriffe nachvollziehbar sind und einzeln entzogen werden können.
4. Rollen passend zur Aufgabe. Entwickler bekommen Schreibrechte auf das Repository, keine Admin-Rechte auf die Organisation. Pipeline- und Branch-Schutz-Einstellungen bleiben dem Kunden vorbehalten.
5. Zugriffe haben ein Enddatum. Partner-Accounts werden regelmäßig überprüft und entfernt, wenn die Zusammenarbeit oder die Rolle der Person endet.
6. Secrets bleiben im Tresor des Kunden. Integrationsuser und Zertifikate gehören dem Kunden und werden beim Partnerwechsel erneuert.
7. Im Vertrag festhalten. Die Leistungsbeschreibung regelt, dass alle Arbeitsergebnisse, auch Code, Tickets und Dokumentation, in den Tools des Kunden entstehen.

Besitzt ein Partner bereits einige der Tools, planen Sie den Umzug früh und in einer ruhigen Phase, nicht während eines Ausstiegs. Ein Repository lässt sich mit voller Historie an einem Tag umziehen. Jira und Miro brauchen mehr Planung, sind aber jetzt immer noch deutlich günstiger umzuziehen als später.

Wo fangen Sie an?

Machen Sie eine einfache Liste: jedes Tool im Projekt, wer den Vertrag hält, wer die Admins sind und welche Mitarbeitenden von Partnern Zugriff haben. In vielen Programmen zeigt schon diese Liste, wo die Risiken liegen. Die eigenen Tools zu besitzen kostet wenig und schützt den wertvollsten Teil eines Salesforce-Programms, sein Wissen. Wenn Sie eine zweite Meinung zu Ihrem Setup möchten, schreiben Sie mir.