Cloud Competence Center sind ein Irrweg
Matthias Popiolek
Associate Vice President - Head of Cloud Consulting Europa | Ihr Ansprechpartner um die Cloud zu einem Hebel für nachhaltig erfolgreiches Geschäft zu machen
Die Versuchung ist groß. Gründen wir ein Cloud Competence Center und dieses löst dann die Cloud Fragen, ist verantwortlich für Data Privacy in der Cloud und Governance. Und diejenigen, die dann hierfür prädestiniert sind, kommen aus der IT Infrastruktur, denn IaaS ist doch der aktuell in der Nutzung dominierende Cloud Service.
Nun gebe ich zu, dass das Label, der Name des Kindes, eigentlich völlig egal ist. Ob sie das nun Competence Center nennen oder Cloud Broker oder anders. Der Umfang der Aufgaben und das Zusammenspiel mit dem Rest der Organisation ist jedoch mehr als kritisch. So kritisch sogar, dass ich behaupte hiervon hängt ihr zukünftiger Erfolg am Markt ab.
Gerade der Kern in der Infrastruktur, die oft unstrukturierte Arbeitsbeschreibung "alles in der Cloud" und die vielfältigen Erwartungshaltungen im Unternehmen gefährden nicht nur den Erfolg der "Cloud-Einheit" sondern den der ganzen Organisation. Analog zur Frage "Brauche ich eine gesonderte Cloud Stratgie" behaupte ich, dass es keine Cloud Einheit braucht sondern etwas anderes, übergreifendes.
Die Design Authority und ihre Aufgaben
Nur ein neuer Schlauch für denselben Wein? Naja, nicht ganz. Es ist eine andere Komposition und Verantwortung. Erstellen wir doch mal eine Liste von Kernelementen:
Welche Aufteilung macht den nun Sinn? Welche Aufgaben gehören zur Design Authority und welche nicht? Wie der Name schon repräsentiert fallen Betriebsaufgaben, also der aktuelle Betrieb nicht in den Bereich. Dies passiert am besten in den jeweiligen Einheiten, entweder klassisch oder im agilen e2e Ansatz, wobei auch dieser einen klassichen Anteil im IT Backbone Betrieb enthält.
Die Definition der übergreifenden Komponenten des Betriebes gehören sehrwohl in die Design Authority. Anstatt jedem Cloud Team die Wahl des eigenen Cloud Management Layers zu überlassen und z.B. primär nativ zu arbeiten und somit den übergreifenden Blick potentiell zu behindern, liegt die Verantwortung der Definition wie eine Multi Cloud Welt gesteuert wird ganz klar in der Design Authority. Ebenso, fällt die Frage, welche Fuktionalität oder welcher Service eines Cloud Anbieters genutzt wird in die Design Authority? Warum, naja bei aller Freiheit die wir Entwicklern ermöglichen wollen, bleibt der Bedarf nach Kontrolle gerade in regulierten Bereichen. Dies bedeutet nicht automatisch ein Nein, sondern die Einführung eines Prozesses zur Freigabe von Features und Services. Wenn die Freigabe nicht erfolgt, ist dem Entwickler eine Alternative aufzuzeigen.
Das klingt für Sie zu sehr nach Gremienarbeit? Ja, in gewisserweise schon. Nur ist die Erfahrung mit Gremien von EA und den verschiedenen IT Einheiten in den meisten Unternehmen vorbelastet und die Zahl der Anfragen übersteigt das leistbare Volumen von Gremien. Deswegen kommen in der Design Authority verschiedene Rollenprofile zusammen um etwaige Entscheidungen von allen Seiten zu beleuchten.
Diese Vorgehensweise verhindert auch, dass Strategie und Cloud Journey einseitig geprägt sind. Die Cloud Diskussion beginnt heute häufig bottom up von der Technologie getrieben. Es ist jedoch inzwischen auch in der Cloud Welt angekommen, dass eine Business-getriebene Sicht top-down auch zwingend notwendig ist. Nur wenn Business-, Daten-, Applikations und Technologiearchitektur zusammenkommen, wird etwas Großes entstehen.
Empfohlen von LinkedIn
Damit fallen sowohl Enterprise Architektur Aufgaben als auch Solution Architektur in die Design Authority. Nein, ich plädiere nicht dafür die Enterprise Architektur komplett aufzulösen und zu verlagern. Doch eine Schwäche, sowohl der Gremien als auch der klassischen Organisationen, ist das Agieren in Silos mit zuwenig Verständnis für Rollen und Bedarfe. Genau das soll die Design Authority durchbrechen. Zum Einen mit Wissen und Erfahrung direkt im Team und zum anderer durch die Befähigung über Teamgrenzen hinaus zu moderieren und zu klären.
Auch in Sachen Governance inkl. der Budgetplanung und des Managements dieses spielt die Design Authority eine wichtige Rolle. Sie wollen in einer Multi Cloud World übergreifende Kontrollmechanismen. Und selbst in einer Single Cloud Welt gilt es einen übergreifenden Blick zu behalten. Übergreifend bedeutet in diesem Fall I,P,SaaS und auch Private Cloud/Legacy. Es macht keinen Sinn die Cloud als Insel zu betrachten, selbst wenn Sie als eine solche beginnt.
Deswegen ist es auch so wichtig wesentliche Elemente der Softwarearchitektur, also des Designs der Applikationen, im Blick zu behalten. Ebenso wichtig ist es, bei aller Reglementierung die Innovationsfreude und die Weiterentwicklung nicht zu unetrdrücken. Auch hier sollte nicht jedes Team, jeder Bereich eigene Wege gehen. Sonst passt das Angebot der Infrastruktur nicht zum Bedarf des Business.
Sie merken, die Aufgaben sind vielfältig und die Vernetzung im Unternehmen geht in alle Richtungen. Es ist auch wichtig zu Verstehen, dass die Design Authority auch Aufgaben wahrnimmt, die nicht zwingend nur Cloud Fragen umfassen. Deswegen heißt es ja auch Design Authority und nicht Cloud Design Authrity. Es braucht für den Erfolg einer Design Authority 3 Dinge:
Die Erfahrung zeigt, dass es durchaus Widerstände gibt. Es ist nicht überraschend, denn wann immer ich Aufgaben neu zuschneide und Entscheidungen verlagere, berührt dies Menschen. Auch ist es so, dass im Zuge der Design Authority Implementierung viele eingefahrene ja liebgewonnene Vorgehensweisen verändert werden. Dies gilt es aktiv zu steuern.
Auf der anderen Seite schaffen sie auch Begeisterung. Die Design Authority eröffnet einen neuen Karrierepfad und neue Rollenkompositionen, welche Fachwissen und Vielseitigkeit benötigen. Gerade in heutigen Zeiten der knappen Fachressourcen ist ein solcher Karrierepfad ein gutes Argument um die besten Mitarbeiter für das Unternehmen zu gewinnen.
Dieser Artikel soll nur einen kleinen Einstiegt in die Diskussion liefern. Das Thema ist größer, umfangreicher und spannender als ich dies hier in wenigen Zeilen darstellen kann. Insbesondere die Betrachtung der Evolution der einzelnen Aufgabenbereiche geht deutlich weiter. Darüber hinaus empfehle ich immer eine individuelle Anpassung auf das jeweilige Unternehmen. Wie gerne würde ich mit Ihnen am Whiteboard stehen und diskutieren, leider ist dies derzeit nicht möglich. Ich hoffe dennoch, dass ich zur Diskussion und zum Nachdenken anregen konnte.
Matthias Popiolek