Salesforce-Partnersteuerung mit mehreren Dienstleistern

Partnersteuerung auf Kundenseite hält ein Salesforce-Programm mit mehreren Umsetzungspartnern unter Kontrolle. Dazu gehören gemeinsame Standards, klare Verantwortung für jedes Objekt und jeden Prozess, ein Release-Prozess und jemand, der jede Lieferung technisch prüft, bevor sie weitergeht. Ohne das optimiert jeder Partner seinen eigenen Bereich, und der Kunde bezahlt die Konflikte dazwischen. Diese Rolle übernehme ich als unabhängiger Architekt, ohne Bindung an Hersteller oder Partner.

Wie sieht das in einem echten Programm aus?

Das größte Programm, das ich gesteuert habe, hatte mehr als 30 Entwickler in acht Streams, geliefert von fünf Umsetzungspartnern und internen Teams. Zu Beginn hatte niemand klar festgelegt, wer für welche Prozesse, Objekte und Metadaten im Lead war. Änderungen überschrieben sich, und die technischen Ansätze der Teams lagen weit auseinander.

Der erste Schritt war einfach und wirksam: Jede Änderung ging über einen Pull Request mit Review, und eine Zeit lang lief jeder einzelne über meinen Schreibtisch. Aus diesen Reviews haben wir Standards aufgeschrieben. Sie deckten die üblichen Themen ab, etwa Namenskonventionen, eine Automatisierung pro Objekt und Kontext und Testabdeckung. Zwei Elemente haben den größten Unterschied gemacht:

• Eine Object Ownership Matrix, die festlegte, welcher Stream für welches Objekt verantwortlich war. Bevor ein Team ein fremdes Objekt änderte, musste es sich mit dem Verantwortlichen abstimmen.
• Regeln für Konfiguration, zum Beispiel welche Werte in Custom Metadata Types oder Custom Labels gehören, statt fest im Code zu stehen.

Bis die Standards stabil waren, hat es etwa drei Monate gedauert. Die erste Version deckte rund 80 Prozent der Fälle ab. In den Wochen danach kamen neue Randfälle hinzu. Wir haben sie in regelmäßigen Center-of-Excellence-Calls besprochen, in denen anstehende Änderungen mit genug Vorlauf für alle Streams auf den Tisch kamen. Irgendwann fielen die Randfälle ganz weg, weil Themen besprochen wurden, bevor sie zu Konflikten wurden. Als der Prozess rund lief, habe ich ihn an einen internen Kollegen übergeben, der ihn seitdem verantwortet.

Warum gehört die Governance auf die Kundenseite?

Auch ein Partner kann gute Standards schreiben. Besitzt aber ein Partner die Regeln, entscheidet er auch, wie alle anderen Partner bauen, auch seine Wettbewerber. Dasselbe gilt für Repository, Pipeline und Tools wie Jira oder Miro. Mehr dazu in warum Kunden ihre DevOps-Tools selbst besitzen sollten.

Liegen Standards, Freigaberechte und Tools beim Kunden, werden Partner vergleichbar. Ein neuer Partner lässt sich in ein dokumentiertes Setup einarbeiten, und ein scheidender Partner gibt nichts weiter ab als seine Benutzer. Das ist auch die Grundlage für einen fairen Vergleich von Angeboten und für ehrliche Gespräche über Qualität.

Wie passen Reviews hinein, ohne das Programm auszubremsen?

Reviews sind das Werkzeug, das aus schriftlichen Standards tägliche Praxis macht. Sie funktionieren, wenn Pull Requests klein sind, Reaktionszeiten vereinbart sind und die wiederholbaren Prüfungen in der Pipeline automatisiert laufen. Die Details beschreibe ich in warum Pull-Request-Reviews in Großprojekten Pflicht sind.

Partnersteuerung funktioniert am besten zusammen mit einem soliden Release-Prozess, deshalb geht sie meist Hand in Hand mit DevOps und Release-Management. Wenn in Ihrem Programm mehrere Partner an einer Org arbeiten und Sie eine zweite Meinung möchten, schreiben Sie mir oder lesen Sie mehr über mich.