Angenommen, ein Unternehmen möchte vertikalisieren, weil die organisatorischen Skalierungsbedürfnisse groß genug geworden sind. Und angenommen, der nächste Schritt der Reorganisation in Domänen und Vertikalen ist auch bereits erledigt. Dann gilt es, die neuen vertikalisierten Strukturen zu befähigen, die technischen und kulturellen Herausforderungen zu bewältigen, die die neue Organisation mit sich bringt.
Die technische Herausforderung einer Vertikalisierung besteht in der Wahl einer technischen Architektur, die hohe Performance, Skalierbarkeit, Stabilität, Wartbarkeit, eine minimale Time-To-Market und maximale Entkopplung bietet.
Die kulturelle Herausforderung findet sich im Grenzgebiet zwischen fachlicher und technischer Architektur: Es müssen kulturelle Veränderungen gefördert und begleitet werden, die im Rahmen der neuen Architektur benötigt werden.
Bei all dem geht es immer um Skalierung: Wir wollen mit vielen Menschen parallel für den Kunden Mehrwert erarbeiten können, ohne uns untereinander häufig synchronisieren zu müssen.
Herausforderung durch technische Vertikalisierung
Für die technische Entkopplung zwischen Systemen gibt es inzwischen das gut etablierte Muster der Self-Contained Systems (SCS). Wenn wir gute fachliche Schnitte gefunden haben, können Teams mit SCSs ihre Fachlichkeit selber entwickeln und wir reduzieren organisatorische und technische Synchronisationspunkte mit anderen Teams auf ein Minimum.
Die Themen Performance, Skalierbarkeit, Stabilität, Wartbarkeit und minimale Time-To-Market werden ebenfalls mit etabliertem Handwerk adressiert und mit dem SCS Muster kombiniert. Stichworte sind hier „Domain Driven Design“, „Continuous Deployment“, „Stateless“, „Denormalisierung“, „Containerisierung“, „Infrastructure as Code“ etc.
Es gibt aber Kopplungen, die sich nicht ganz vermeiden lassen: Im Frontend müssen die Vertikalen zusammenspielen. Und es können teamübergreifende Architekturthemen auftauchen.
Herausforderung durch Kopplung im Frontend
User-Interfaces (UI) für Kunden bieten häufig Kombinationen aus mehreren fachlichen Bereichen. Z.B. ist in E-Commerce-UIs auf vielen Seiten der Warenkorb zu sehen oder das Eingabefeld der Freitextsuche oder die Navigation. Der Hauptteil der Seite wird für die eigentliche Aufgabe genutzt, die der Kunde erwartet: Die Präsentation eines Artikels, ein Suchergebnis, die Homepage oder anderes.
Das führt dazu, dass UIs nicht allein von einem System kommen können, sondern zusammengesetzt werden müssen. Das sollte für die Endkunden aber keine Verschlechterung im Nutzungserlebnis mit sich bringen.
Des Weiteren sollen Kunden ein qualitativ sehr hochwertiges Design erleben können und dabei nicht unangenehm spüren, dass sie zwischen mehreren Systemen springen, je nachdem, welche der möglichen Fachlichkeiten sie gerade nutzen. Bspw. wäre es unglücklich, wenn Seitenaufteilungen, Abstände, Schriften etc. bei UIs für Endkunden nicht identisch wären, wenn sie von verschiedenen Systemen geliefert werden.
Daraus ergeben sich folgende Ziele:
- Das User-Interface muss immer das gleiche Erlebnis bieten, auch wenn es von unterschiedlichen Systemen stammt: „Alles aus einem Guss.“
- Wenn ein User-Interface mehrere Fachlichkeiten verschiedener Systeme vereint, muss es aus UI-Stücken der Systeme so zusammengesetzt werden, dass der Kunde nicht negativ beeinflusst wird: Das Layout muss nahtlos passen.
Um hier die organisatorische Kopplung dauerhaft zu minimieren, haben wir in allen Vertikalisierungsprojekten einen UI-Baukasten entwickelt („Patternlib“ oder „Styleguide“), der die organisatorische Kopplung auf die Entwicklung von neuen UI-Elementen beschränkt.
Da aber das UI bei jedem neuen Feature für Kunden oder kompletten „Rebrushs“ von Plattformen grundsätzlich übergreifenden Abstimmungsbedarf erzwingen kann, wird der Abstimmungsaufwand hier niemals auf Null zu bringen sein. Aber das Ziel muss auch hier sein, den Synchronisationsaufwand so weit wie möglich zu minimieren.
Herausforderung durch teamübergreifende Architekturthemen
Bei gemeinsamen Problemen oder gemeinsam genutzten Technologien kann es notwendig oder hilfreich sein, die Teams organisatorisch locker über sog. „Horizontalen“ zu koppeln. Mitglieder aus den verschiedenen Teams schicken eine Person als Vertretung, wenn sie glauben, davon zu profitieren. Die Horizontalen treffen sich je nach Bedarf und schaffen sich auch selbst wieder ab, wenn sie überflüssig geworden sind.
Z.B. führte in einem Projekt ein Team selbst kubernetes ein, weil es sich starke Erleichterung erhoffte. Nach kurzer Zeit wollten die meisten anderen Teams auch in den kubernetes-Cluster. Damit hatten alle Teams eine Lernkurve zu bewältigen und es musste ein Betriebskonzept entwickelt werden, das alle Teams beteiligte. Dies lösten die Teams über eine „kubernetes-Horizontale“. Auch war zum Start des Projekts in den meisten Teams kein Security-Spezialist vorhanden, so dass eine über einen längeren Ausbildungszeitraum notwendige „security-Horizontale“ gebildet wurde, in die jedes Team ein Mitglied entsandte, das als Wissensverteiler und Stakeholder im Team das Thema Security vertritt.
In der Regel dienen diese Horizontalen dem Wissensaustausch oder dem Lösen einer gemeinsamen Herausforderung. Grundsätzlich ist das Ziel, dass die „Horizontalen“ sich möglichst schnell überflüssig machen, damit die organisatorische Kopplung der Teams minimal bleibt.
Herausforderungen durch Kulturwandel
Um die Vorteile der Vertikalisierung voll nutzen zu können, müssen die Teams viele neue Fähigkeiten erwerben und ihr Wertesystem neu justieren. Alle Teams müssen die Geschäftsziele ihrer Systeme vertreten können, genauso wie die übergreifenden Ziele der Vertikalisierung.
Fachlichen Schnitt vertreten
Die Teams müssen lernen, dauerhaft an der Schärfung der fachlichen Grenzen zwischen den Systemen zu arbeiten. Tun sie das nicht, fehlt eine Qualitätskontrolle, die verhindert, dass sich die fachlichen Zuständigkeiten vermischen.
Beispiel: Angenommen, es gibt eine Domäne für das Suchbedürfnis des Kunden. Nun wird das Team, das die Suche per Navigation bedient, gebeten, eine Newsletterregistrierung in ihr System zu bauen. Begründet wird das damit, dass andere Teams gerade keine Zeit dafür hätten und das Thema sehr dringend sei. Dann muss das Team es gewöhnt sein, sich zu wehren und vertreten können, dass die Umsetzung in seinem System nicht gemacht werden darf. Im Notfall baut es eine fachfremde Funktion, sorgt aber vehement dafür, dass sie später in das fachlich zuständige System wandert.
Auf das Geschäft fokussieren
Ebenso müssen die Teams lernen, alle technischen Entscheidungen vom Geschäftswert abzuleiten, nicht aus geschäftszielneutralen Diskussionen oder aus persönlichen Zielen. Beispiele:
- Microservices bieten separate technische und organisatorische Skalierung. Sie sind aber teuer in Betrieb, Wartung und Weiterentwicklung. Gerne wird in einem Team eine Entscheidung für Microservices aus den Skalierfähigkeiten und der lokalen Fokussierung abgeleitet. Stattdessen sollte das Team sich fragen, ob es diese Eigenschaften benötigt.
- Eine neue Programmiersprache wie z.B. Scala, auf die Teammitglieder neugierig sind, sollte man nicht nur deshalb wählen, weil jemand das für seine persönliche Entwicklung wünscht, denn dadurch kann ein Team verlangsamt oder sogar überfordert werden. Dagegen wäre es in einem sehr leistungsstarken Team ein valides Argument, wenn man weiß, dass gerade ein großer Personalbedarf existiert und man hofft, die Recruiting-Chancen im Bewerbermarkt damit zu vergrößern.
Schaffen die Teams das nicht, werden die Ziele Schnelligkeit und Kundenorientierung nicht mehr direkt bedient und evtl. sogar konterkariert („tolle Technik, aber wir sind dauerhaft langsamer“).
Besonders markant wird dieser Punkt, wenn angestrebt wird, dass die Teams auch das Geschäft selbst mit treiben und steuern. Technik tritt dann immer mehr als Mittel zum Zweck in den Hintergrund und Experimente nach dem Build-Measure-Learn-Muster („datengetriebene Softwareentwicklung“) werden zum zentralen Betätigungsfeld der Teams. Technische Meisterschaft ist eine Voraussetzung, damit die Konzentration auf den Geschäftswert dominieren kann. Das agile fluency model arbeitet diese Abhängigkeit sehr gut heraus.
Redundanz und Synergie gegeneinander abwägen
Viele Menschen im Softwarebereich neigen dazu, bei Ähnlichkeiten von Aufgaben wertvolle Synergieeffekte zu vermuten, die es zu heben gilt. Früher waren Rechner/Netzwerkressourcen deutlich wertvoller als heutzutage. Heute hat der Bedarf, organisatorisch zu skalieren, zugenommen. Der Gewinn im Heben von Synergien hat sich verändert.
Im Zeitalter der Vollautomatisierung (AWS) sinken Betriebskosten. Die Kosten organisatorischer Kopplung bleiben gleich. Beim durch günstige Vollautomatisierung möglichen Skalieren wird Kopplung immer teurer: Viele Teams, die an vielen Stellen aufeinander warten müssen oder sich gegenseitig behindern, potenzieren Kopplungseffekte.
Beispiel: Lieber gebe ich jedem Team seine als SaaS bereitgestellte kleine Datenbank, als dass Teams sich beim Betrieb gegenseitig beeinflussen können, weil sie sich eine große Datenbankinstanz teilen. Die Preise der Datenbanken orientieren sich aufgrund der Vollautomatisierung hauptsächlich an den benötigten technischen Ressourcen und nicht mehr wie früher an den Kosten eines Datenbankadministrator-Teams.
Eine neue Intuition muss entwickelt werden: Kosten durch Kopplung zwischen Teams sind höher zu bewerten als die durch Redundanzen.
Ops in die Teams bringen
Vertikalisierung ist wirtschaftlich nur mit massiver Automatisierung machbar. Diese wird heutzutage von professionellen Cloudanbietern auf einem Niveau angeboten, das eigene Rechenzentren i.d.R. nicht leisten können. In Ausnahmefällen sind diese Anbieter keine Option und man muss versuchen, eine eigene Plattform aufzubauen, die einen hohen Automatisierungsgrad erreicht. In allen anderen Fällen ist ein professioneller Cloudanbieter konkurrenzlos. Je nach gewähltem Anbieter gibt es aus erster und zweiter Hand heutzutage bereits viel Software-as-a-Service (SaaS): Datenbanken, Messagebroker, Containermanagement, Rechtemanagement, DDOS-Protection, CDN uvm. gibt es als vollautomatisierte Lösungen, die sich im Selfservice nutzen lassen.
Vertikalenteams benötigen immer noch ein Verständnis der Funktionen dieser SaaS, müssen sie aber nicht mehr betreiben können. Die früher horrende Arbeit für den Betrieb einer vertikalisierten Softwareplattform ist inzwischen so geschrumpft, dass sich die Frage stellt, ob in einem Cloud-Szenario ein separates Plattform-Team benötigt wird.
Wenn die Teams so besetzt werden, dass ausreichend Plattform-Knowhow vorhanden ist, wird ein separates Team nicht benötigt. Andererseits kann ein Plattform-Team die Teams je nach Besetzung stark entlasten, da nicht immer aller Plattformbedarf als SaaS hinzugekauft werden kann oder soll (z.B. Sorge vor vendor-lock-in) und ggfs. von einzelnen Teams übernommen werden muss.
Ein Risiko eines separaten Plattform-Teams ist wieder die Kopplung. Wenn ein Plattform-Team es schafft, eine Selfservice-Qualität wie die Cloudanbieter zu erreichen, ist es sicher eine große Hilfe und die Kopplung gering. Sobald menschliche Interaktion regelmäßig notwendig wird, haben wir häufige Synchronisationspunkte mit Bottlenecks usw., die die Schnelligkeit der einzelnen vertikalisierten Teams drosseln.
Fazit
Die technischen Muster für eine Vertikalisierung sind inzwischen erprobt und haben sich bewährt. Im Bereich der Kopplung im Frontend ist aufgrund der immer noch starken Dynamik bei Webtechnologie und Apptechnologie Bewegung in den Lösungsmustern. Unterschiedliche Projekte erfordern verschiedene Muster.
Der kulturelle Wandel in den Teams ist die größere Herausforderung. Die Skalierung durch Vertikalisierung kann ihre ganzen Vorteile erst ausspielen, wenn der Fokus der Teams auf Geschäftswert und dem Nutzen für den Kunden liegt. Geschäftswert und Kundennutzen müssen dazu operationalisiert werden, indem die Teams z.B. KPIs entwickeln und ihren Erfolg messbar machen.
Haben die Teams es erst einmal geschafft, diese Hürden zu nehmen, gilt es in der Regel, die Vertikalisierung auch organisatorisch weiter voranzutreiben, denn wenn Teams sehr schnell werden, muss die umliegende Organisation es auch sein. Doch das ist ein eigenes Thema…
