Technische Architektur und DevOps-Architektur

Bei der DevOps-Beratung geht es darum, die Distanz zwischen einer Entscheidung und einem in der Produktion laufenden System zu verkürzen und diese Distanz auch bei wachsender Systemlandschaft gering zu halten. Sie umfasst die Bereitstellungsarchitektur, die Umgebungen, den Release- und Freigabeprozess, die gemeinsame Plattformebene, auf der jedes Team aufbaut, sowie die Zuverlässigkeitsmaßnahmen, die in all diesen Bereichen integriert sind und nicht nur daneben stehen. „ Vivaldi “ arbeitet eine Ebene über der Bereitstellung: Wir legen die Architektur und das Betriebsmodell fest, und Ihre Entwicklerteams sowie Ihre Build-Partner setzen diese um. „ Vivaldi “ berät seit 1999 in den Bereichen Geschäfts- und Technologiestrategie.

• Seit 1999Unternehmens- und Technologiestrategie
• Über 200veröffentlichte Fallstudien
• 10 Niederlassungenauf vier Kontinenten
• 5xWirtschaftsWoche: Das Beste aus den Bereichen Beratung, Strategie und Innovation
• Architektur, nicht PersonalWir entwerfen das Modell, Ihre Teams und Partner setzen es um

Wenn Unternehmen uns beauftragen

Der Auslöser ist so gut wie nie eine Entscheidung bezüglich der Werkzeuge. Es ist der Moment, in dem jemand aus der Führungsetage bemerkt, dass kompetente Entwicklungsarbeit zu langsamen Lieferzeiten führt und niemand sagen kann, wohin die Zeit fließt.

• Die zweite Funktion wird zum gleichen Preis wie die erste angeboten. Es wurde nichts wiederverwendet, da es keine gemeinsamen Komponenten gibt, die wiederverwendet werden könnten. Das sind die Kosten, die im ersten Business Case nie auftauchen.
• Die Pipeline ist automatisiert, dennoch dauert die Veröffentlichung sechs Wochen. Die Automatisierung endet dort, wo die Freigabe beginnt, und die Freigabe wurde für vierteljährliche Veröffentlichungen konzipiert.
• Ein Cloud-Kostenvoranschlag hat die Prognose weit überschritten. Über die Verteilung der Arbeitslast wurde projektbezogen entschieden, sodass niemand jemals über die Kosten auf Basis des tatsächlichen Volumens entscheiden musste.
• Eine KI- oder Datenfunktion steht kurz vor der Inbetriebnahme. Die Modellebene, der Datenpfad und das Release-Modell müssen alle vor dem ersten System festgelegt werden und dürfen nicht nachträglich daran angepasst werden.
• Mit dem Wachstum des Systems hat sich die Bereitstellung verlangsamt. Jedes Team muss sich immer wieder mit Identitätsmanagement, Geheimhaltung, Protokollierung, Bereitstellung und Rollback auseinandersetzen, und diese Verlangsamung wird als Personalproblem interpretiert.

Warum DevOps-Programme ins Stocken geraten, nachdem die Tools eingeführt wurden

Die Tools stellen so gut wie nie ein Hindernis dar. Die meisten Unternehmen, die angeben, bei DevOps auf Hindernisse zu stoßen, haben die Pipeline, die Container-Plattform und die Observability-Suite bereits angeschafft, doch die Vorlaufzeit von der Entscheidung bis zur Produktion hat sich nicht verkürzt.

Drei Gründe, in der Reihenfolge, in der sie normalerweise auftreten.

• Der Weg zur Produktion verläuft über einen Ausschuss, nicht über eine Pipeline. Die Automatisierung endet dort, wo die Genehmigung beginnt. Der Build dauert Stunden, die Veröffentlichung sechs Wochen – und der schnelle Teil ist der Teil, der finanziert wurde.
• Jede Funktion wird von Grund auf neu entwickelt. Da es keine gemeinsame Plattformschicht gibt, müssen Identitätsmanagement, Geheimnisse, Protokollierung, Bereitstellung und Rollback von jedem Team erneut gelöst werden. Die Kosten machen sich erst im zweiten Projekt bemerkbar und nicht im ersten, weshalb sie im Business Case nie berücksichtigt werden.
• Es gibt keinerlei Rückkopplung. Die Produktion gibt dem Team so gut wie keine Informationen darüber, was sie nutzt. Ohne einen Rückkopplungsweg von den Ergebnissen hin zur Festlegung des Umfangs und der Personalausstattung für das nächste Projekt ist das System am 300. Tag dasselbe wie am 1. Tag – nur mit mehr Arbeitsaufkommen.

Das erste ist ein Governance-Problem, das zweite ein Architekturproblem, das dritte ein Problem des Betriebsmodells. Keines davon lässt sich durch den Kauf weiterer Tools beheben, weshalb ein Großteil dieser Ausgaben zwar kompetente Teams hervorbringt, die aber dennoch nichts auf den Markt bringen können.

Was unsere DevOps-Beratungsleistungen umfassen

Vier Arbeitsbereiche. Jeder davon kann für sich betrachtet werden, und die Diagnose weist in der Regel auf einen davon als die eigentliche Einschränkung hin.

1. Bereitstellungsarchitektur und der Weg in die Produktion

Der Weg von einer integrierten Änderung zum laufenden System – zunächst verdeutlicht und dann verkürzt dargestellt.

• Wo die Automatisierung endet und die menschliche Freigabe beginnt, sollte dies bewusst anhand der Wesentlichkeit und Reversibilität festgelegt werden und nicht standardmäßig erfolgen
• Umgebungsstrategie: Durch das Testen erhält man Aufschluss über die Produktion
• Release- und Rollback-Konzeption, denn gerade die Möglichkeit, Änderungen kostengünstig rückgängig zu machen, macht die Veröffentlichung oft sicher
• Die Kennzahlen, die alles andere vorhersagen: Vorlaufzeit für Änderungen, Häufigkeit der Bereitstellung, Ausfallrate bei Änderungen, Zeit bis zur Wiederherstellung

2. Eine Cloud-Architektur, die auch bei einem Sinneswandel Bestand hat

Architekturentscheidungen sind Festlegungen darüber, was man später noch ändern kann. Wir machen diese Festlegungen explizit, bevor sie versehentlich getroffen werden.

• Arbeitsauslastung und Kostenkurve bei tatsächlichem Volumen statt bei Pilotvolumen
• Portabilität, wo sie sich bezahlt macht, und gezielte Bindung, wo sie sich lohnt
• Eine Modellschicht, die austauschbar bleibt, wobei die Modelle je nach Workload ausgewählt werden, sodass der Wechsel eine Entscheidung im Rahmen der Bereitstellung und nicht eine Neuerstellung ist
• Datenstandort, Tenancy und Isolation werden bereits vor der Einführung des ersten Systems festgelegt, da deren nachträgliche Anpassung ein eigenständiges Projekt darstellt.

3. Eine Plattformschicht, sodass die zweite Funktion kostengünstiger ist

Die gemeinsame Grundlage, die jedes Team sonst alleine aufbauen müsste: Identität, Geheimnisse, Bereitstellung, Protokollierung, Nachverfolgung, Kostenzuordnung und der ebene Weg, der den sicheren Weg zum einfachen Weg macht. Wir legen die Anforderungen fest und bestimmen, wer dafür verantwortlich ist. Ihr Plattformteam oder Ihr Build-Partner setzt dies um.

• Was zentral standardisiert ist und was die Teams selbst entscheiden – schriftlich festgehalten
• Selbstbedienung, bei der Teams den schnellsten Weg bieten, und eine Warteschlange nur dann, wenn sie wirklich erforderlich ist
• Die Kosten werden dem Team zugeordnet, das sie verursacht, sodass der Kompromiss dort sichtbar wird, wo er eingegangen wird.
• Das Eigentumsmodell nach dem Projekt, das so benannt wurde, damit die Plattform nicht zu unserer Abhängigkeit wird

4. Zuverlässigkeit und der Rückkopplungspfad

Zuverlässigkeit besteht in erster Linie aus einer Reihe von Vereinbarungen und erst in zweiter Linie aus einer Reihe von Dashboards.

• Service-Levels, die mit dem Unternehmen vereinbart wurden und nicht allein vom Plattformteam festgelegt wurden
• Eine Analyse von Vorfällen, die zu einer Änderung des Designs führt, im Gegensatz zu einer Analyse, die lediglich ein Dokument hervorbringt
• Observability, die sich auf die Fragen konzentriert, die Menschen um drei Uhr morgens stellen
• Der Rückkopplungsprozess von den Produktionsergebnissen hin zur Festlegung des Umfangs und der Finanzierung der nächsten Funktion

So funktioniert ein Projekt im Bereich Technik und DevOps-Architektur

1. Diagnose. Wir verfolgen zwei oder drei kürzlich erfolgte Änderungen vom Entscheidungsprozess bis zur Produktion und erfassen, wo es bei jeder einzelnen zu Verzögerungen kam. Dabei führen wir Gespräche mit den Mitarbeitern aus den Bereichen Entwicklung, Sicherheit und Plattform sowie mit dem Geschäftsverantwortlichen und gleichen diese Informationen mit den Ihnen bereits vorliegenden Bereitstellungsdaten ab. Das Ergebnis ist ein Überblick darüber, wo die Durchlaufzeit tatsächlich verbraucht wird – und das ist selten dort, wo das Team es vermutet.
2. Entscheiden Sie sich. Das Bereitstellungsmodell, das Genehmigungsschema, die Verpflichtungen hinsichtlich der Cloud- und Workload-Platzierung sowie die Grenzen der gemeinsamen Plattformebene. Entscheidungen, bei denen die Ausnahmen schriftlich festgehalten werden, einschließlich der Punkte, die bewusst nicht standardisiert werden sollen.
3. Präzisieren Sie Folgendes: die Plattformebene, das Release- und Rollback-Modell, die Zuverlässigkeitsvereinbarungen sowie die Maßnahmen – und zwar so detailliert, dass ein Entwicklerteam oder ein Build-Partner diese umsetzen kann, ohne dass wir dabei anwesend sein müssen.
4. Übergabe. Die pro Komponente festgelegten Verantwortlichkeiten, die Überprüfungsmechanismen, die die Architektur auf Kurs halten, und das Messmodell – damit die nächste Funktion kostengünstiger ist als diese, ohne dass ein zweiter Auftrag erforderlich wird.

Warum sich Unternehmen bei der technischen Architektur und der DevOps-Architektur für „ Vivaldi “ entscheiden

In den Schriftsätzen, mit denen wir Recht bekommen, tauchen immer wieder drei Gründe auf.

• Wir verkaufen nicht die Implementierung. Wir stellen kein Personal für Pipelines bereit, betreiben keine Plattformen und vertreiben keine Cloud-Dienste weiter – daher wird die Architektur nicht davon bestimmt, wofür wir als Nächstes bezahlt würden, sie zu entwickeln. Die Unternehmen, die die Implementierung übernehmen, werden erst nach der Entscheidung ausgewählt und nicht schon vorher.
• Die Architektur wird unter wirtschaftlichen Gesichtspunkten beurteilt. Der Maßstab, den wir anlegen, ist, wie viel die nächste Funktionsstufe im Vergleich zur vorherigen kostet, sowie die Vorlaufzeit, die Bereitstellungshäufigkeit, die Ausfallrate bei Änderungen und die Zeit bis zur Wiederherstellung. Eine Architektur, die in keiner dieser beiden Richtungen eine Tendenz aufweist, wird allein aus Geschmackgründen verteidigt.
• Governance wird als Teil der Architektur betrachtet. Die Gestaltung des Genehmigungsprozesses, die Zuständigkeiten und der Feedback-Pfad von der Produktion zurück in die Projektplanung werden im selben Dokument wie die Plattformschicht festgelegt, da der langsame Teil der meisten Bereitstellungsumgebungen der Teil ist, den kein Entwickler kontrolliert.

So bewerten Sie ein DevOps-Beratungsunternehmen

Das sollten Sie jedem Unternehmen auf Ihrer Auswahlliste mitteilen – auch uns.

• Wie lang wird die Vorlaufzeit letztendlich sein, und wie werden wir das erfahren? Ein Unternehmen, das sich nicht auf eine Richtung in Bezug auf Vorlaufzeit, Einsatzhäufigkeit und Wiederherstellungszeit festlegen kann, verkauft nur Aktivitäten.
• Was kostet die zweite Funktion nach Abschluss dieser Arbeiten? Der Sinn einer Plattformschicht besteht ja gerade darin, dass die Kosten sinken. Ist dies nicht der Fall, haben Sie eine Migration finanziert.
• Wessen Cloud-Verpflichtungen tragen Sie? Wiederverkäufermargen, Partnerstufen und Vereinbarungen über Mindestausgaben beeinflussen die Architekturberatung. Fragen Sie nach, wie diese aussehen, und ob sich die Empfehlung ohne sie ändern würde.
• Was passiert mit unseren Genehmigungsinstanzen? Ein Unternehmen, das die Pipeline automatisiert und das Freigabe-Komitee unangetastet lässt, hat den schnellen Teil eines langsamen Prozesses verbessert.
• Wer kümmert sich in einem Jahr darum? Wenn die Antwort „die Beratungsfirma“ lautet, haben Sie eher eine betriebliche Abhängigkeit als eine Architektur erworben.

Architekturberatung, Plattform-Engineering-Unternehmen oder Cloud-Reseller?

Verwandte Arbeiten

Die technische Architektur ist selten die einzige Einschränkung. Drei miteinander verbundene Aspekte:

• API und Systemintegration wenn die Einschränkung darin besteht, dass die Systeme nicht miteinander kommunizieren können, und nicht darin, dass die Releases langsam sind.
• Datenstrategie wenn die Plattform zwar in Ordnung ist, die ihr zugrunde liegenden Daten jedoch nicht abrufbar sind oder nicht verwaltet werden.
• Digitale Produkte und Plattformen wenn die offene Frage lautet, was überhaupt entwickelt werden soll, und nicht, wie es auf den Markt kommt.

Diese Arbeit ist Teil unseres Geschäftsbereichs „Business Technology Strategy “ bei Vivaldi, dem Strategieberatungsunternehmen hinter dem „Demand Landscape“ und dem „ Interaction Field “, in dem die These vertreten wird, dass die Plattformarchitektur entscheidend dafür ist, dass Produkte im Zeitalter der KI auf den Markt kommen – und nicht etwa als Kostenposition darunter aufgeführt wird.

DevOps-Beratung in den USA und weltweit

Unsere Arbeit im Bereich der technischen Architektur erfolgt von zehn Niederlassungen auf vier Kontinenten aus, wobei das US-Team in New York ansässig ist. Die meisten Projekte sind von Anfang an regionenübergreifend angelegt, da regionale Entscheidungen am schwersten rückgängig zu machen sind: Wo Daten gespeichert werden, welches Genehmigungsverfahren für eine Veröffentlichung gilt und welche Marktanforderungen letztendlich als Standard für alle anderen Märkte gelten. Diese Entscheidungen einmalig und wohlüberlegt zu treffen, ist kostengünstiger, als sie Land für Land herauszufinden.