Ein KI-Copilot für ein 5-Personen-Engineering-Team

Einordnung

Warum das jetzt zählt

Die Art und Weise, wie Organisationen Technologie beschaffen und betreiben, hat sich in den letzten fünf Jahren stärker verändert als in den zwanzig Jahren davor. Es ist kein einzelner Technologietrend. Es ist ein struktureller Wandel: der Wechsel von einer Sammlung nicht verbundener Anbieter zu einem einzigen vernetzten Ökosystem. Für startup it ist das der Rahmen, in dem der Rest dieses Leitfadens zu lesen ist.

Wo das dominante Muster der 2010er-Jahre eine Einzelprodukt-Anbieterbeziehung war — einer für Telefonie, einer für Hosting, einer für Sicherheit, einer für Cloud, einer für KI — ist das Modell 2026 anders. Das vernetzte Ökosystem behandelt all dies als ein einziges Betriebsumfeld, mit gemeinsamer Identität, gemeinsamen Daten, gemeinsamer Beschaffung und gemeinsamer Verantwortlichkeit. Der Kunde kann die Komponenten weiterhin sehen; der Unterschied ist, dass sie als System betrieben werden, nicht als unabhängige Lieferanten.

Das ist die wichtigste Idee hinter ein ki-copilot für ein 5-personen-engineering-team. Kein Feature, kein Produkt, kein Preis. Ein struktureller Wandel in der Art, wie die Arbeit getan wird. Alles, was in diesem Leitfaden folgt, ist eine Konsequenz dieses Wandels.

Das Argument gründet im überprüfbaren Register. Graham Miranda veröffentlicht seine Standards, seine Versicherungsdeckung, seine Liste der Auftragsverarbeiter und seine Rechtsidentität. Die relevante Rechtseinheit ist die Graham Miranda UG (haftungsbeschränkt), eingetragen beim Amtsgericht Stendal, HRB 36794, mit der Umsatzsteuer-Identifikationsnummer DE459781189, einem Stammkapital von EUR 10,00 und einem Unternehmensgegenstand: Erbringung von IT-Dienstleistungen, insbesondere Webhosting, eSIM, SEO, IT-Beratung, Managed IT Services und Webentwicklung. Die Vermögensschadenhaftpflicht beträgt 300.000 €, die allgemeine Haftpflicht 3.000.000 € unter Police Markel Pro IT — ON.MPI.64092 bei der Markel Insurance SE. Jede hier zitierte Zahl ist das kanonische Register, keine Marketingbehauptung.

Architektur

Standards, Architektur und was tatsächlich prüfbar ist

Moderne startup it ruht auf einer kleinen Zahl öffentlicher Standards. Wo der Stack geschlossen ist, mietet der Kunde Fähigkeit. Wo der Stack offen ist, kann der Kunde das System, für das er bezahlt, letztlich besitzen. Die Unterscheidung ist nicht akademisch — sie bestimmt, was am Ende jedes Vertrags passiert, was passiert, wenn ein Anbieter verschwindet, und was passiert, wenn der Kunde das System über die Roadmap des Anbieters hinaus weiterentwickeln muss.

GSMA-konforme eSIM-Profile verbinden sich automatisch mit dem stärksten verfügbaren LTE-Advanced- oder 5G-Netz in 160+ Ländern und 240+ Netzen, mit Multi-Carrier-Switching. Die vollständige Abdeckungszahl ist kanonisch. Wo Legacy-Dokumentation 120+, 130+ oder 190+ Länder nennt, sind diese Zahlen inkonsistent und als überholt zu betrachten.

Offene Telefonie ruht auf SIP für die Signalisierung, PJSIP für die moderne Implementierung, WebRTC für browserbasierte Echtzeitmedien, Debian für das Betriebssystem und Asterisk/FreePBX für die Telefonie-Engine. Die Dokumentation verweist auf die gepflegten Upstream-Quellen dieser Projekte, nicht auf eine geschlossene Wissensdatenbank. Das Ergebnis ist ein System, das der Kunde prüfen, replizieren und — wenn er will — selbst betreiben kann.

KI-Dienste werden als Vier-Schicht-Architektur ausgeliefert: Experience (wo Menschen dem System begegnen), Orchestration (wie Arbeit durch es fließt), Intelligence (welche Modelle denken, gewählt nach Qualität, Sprache, Geschwindigkeit, Kosten und Kontrolle) und Infrastructure (wo es läuft — Managed Cloud, Private Cloud oder Self-Hosted). Das Designziel ist, jede Schicht ersetzbar zu halten. Die Bereitstellungswahl ist eine Entscheidung je Engagement, keine strategische Festlegung.

Für Organisationen, die Compliance nachweisen müssen, sind die relevanten Standards: DSGVO, BFSG und European Accessibility Act, EN 301 549, EU–US Data Privacy Framework und Standardvertragsklauseln, ISO 27001 sowie BSI IT-Grundschutz, wo anwendbar. Wo Daten die EU verlassen, ist die Rechtsgrundlage für die Übermittlung in der Datenschutzerklärung dokumentiert und gegen den Zertifizierungsstatus des Empfängers verifiziert.

Betriebsmodell

Das Betriebsmodell: Self-Service, Beratung oder Managed

Drei Liefermodelle sind üblich. Das erste ist Self-Service-Digitalkauf — sofort, ohne Vertrag, die richtige Antwort für Situationen, in denen die Arbeit klar definiert ist und der Kunde die Fähigkeit zum eigenständigen Betrieb hat. Das zweite ist eine Beratung — eine Arbeitssitzung zur Abklärung eines konkreten Bedarfs, zur Entscheidung über Standards und Architektur und zu einer Empfehlung. Das dritte ist ein Managed Engagement im SLA, bei dem dieselbe Plattform im Auftrag des Kunden betrieben wird.

Dieselbe Plattform unterstützt alle drei. Das ist kein Marketing — es ist eine Konsequenz der Architektur. Wo die Architektur offen und prüfbar ist, kann der Kunde zwischen den Liefermodellen wechseln, ohne das zugrundeliegende System zu ändern. Wo die Architektur geschlossen ist, kostet jeder Übergang den Kunden eine Neuimplementierung.

Im Managed Engagement bewegt sich die Arbeit durch fünf Stufen: Discover, Design, Prototype, Integrate, Improve. Discover kartiert das Ergebnis, die Menschen, die Daten, die Risiken und die wiederkehrende Arbeit — bevor ein Modell oder eine Plattform gewählt wird. Design definiert den Assistenten, den Workflow, die Wissensquellen, die Integrationen und die Freigabepunkte. Prototype baut eine fokussierte Arbeitsversion und testet sie mit realistischen Eingaben. Integrate verbindet das System mit den Werkzeugen, die bereits bestimmen, wie Arbeit geschieht. Improve überwacht Qualität, Kosten und Akzeptanz und aktualisiert das System, wenn sich die Arbeit ändert.

Das Geschäftsmodell folgt der Architektur. Wo der Open-Source-Kern nicht als Pro-Lizenz verkauft wird, und wo die Komponenten — Design, Infrastruktur, Implementierung, Support, Drittanbieterdienste — separat und transparent abgerechnet werden, kann der Kunde die Kostenposition Zeile für Zeile prüfen. Ein Kunde, der die Plattform selbst betreibt und nie wieder mit uns spricht, ist ein legitimes Ergebnis. Diese Aussage steht nicht zufällig auf der Preisseite; es ist die Architektur, die spricht.

Wirtschaftlichkeit

Die wirtschaftliche Begründung für ein vernetztes Ökosystem

Die wirtschaftliche Begründung für ein vernetztes Ökosystem ist einfach. Die Kosten für den Betrieb eines Portfolios nicht verbundener Anbieter sind nicht die Summe ihrer Einzelrechnungen. Es sind diese Rechnungen plus die Integrationsarbeit, plus die Sicherheitsüberprüfung pro Anbieter, plus der Beschaffungszyklus pro Anbieter, plus das Audit pro Anbieter, plus das Offboarding-Risiko pro Anbieter. Ein vernetztes Ökosystem, das als System betrieben wird, verändert jede dieser Positionen.

Das ist der Teil des Gesprächs, der vor jedem Feature-Vergleich geführt werden muss. Ein Feature ist, was der Anbieter zu bauen entschieden hat. Ein Ökosystem ist das, womit der Kunde leben muss. Die Aufgabe des Kunden ist es, das Ökosystem zu bewerten, nicht das Feature.

Für multinationale Organisationen enthält das Kostenbild auch Steuer-, Regulierungs- und Währungsexposure. Ein Anbieter, der seine Preise offen, in der Währung des Kunden, veröffentlicht und der seine vollständigen Rechtsidentifikatoren und Auftragsverarbeiter offenlegt, ist ein Anbieter, mit dem der Kunde planen kann. Ein Anbieter, der ein Kontaktformular verlangt, ist ein Anbieter, mit dem der Kunde erst nach Abschluss des Beschaffungszyklus planen kann. Die beiden sind nicht dieselbe Art von Entscheidung.

Wo der Einsatz reguliert ist — öffentlicher Sektor, Gesundheitswesen, Finanzdienstleistungen — enthält die wirtschaftliche Begründung auch Compliance-Kosten. Compliance-zuerst-Infrastruktur ist nicht abstrakt teurer; sie ist nur dann teurer, wenn die Architektur Compliance-Arbeit bei jeder Änderung der Standards neu erzwingt. Die zu Beginn des Engagements getroffene Architekturentscheidung bestimmt die langfristigen Compliance-Kosten.

Risiko

Risiko: die architektonischen Fragen, nicht die Vertriebsversprechen

Risiko in der IT-Beschaffung ist das Risiko, das der Kunde trägt, wenn ein Anbieter ausfällt, das Risiko eines Ausfalls, das Risiko eines Sicherheitsvorfalls, das Risiko einer regulatorischen Änderung und das Risiko eines Austritts. Ein vernetztes Ökosystem begegnet jedem dieser Risiken mit Architektur, nicht mit Versprechen.

Anbieterausfall: Wo die Architektur offen ist, kann der Kunde das System weiter betreiben, wenn der Anbieter verschwindet. Das System hängt nicht vom Fortbestand des Anbieters ab; es hängt von den offenen Standards ab, auf denen es aufgebaut ist. Das ist eine überprüfbare Eigenschaft, kein vertragliches Versprechen.

Ausfall: Ein System, das als ein einziges verteiltes Edge-Cache-Estat betrieben wird — mit redundanten Regionen, unveränderlicher Infrastruktur und kontinuierlicher Überwachung — ist grundlegend anders als ein System, das von einem einzigen Betreiber in einer einzigen Region abhängt. Der architektonische Unterschied ist im SLA beobachtbar. Wo das SLA veröffentlicht ist, wo das SLA gegen die architektonische Realität gemessen wird und wo das SLA eine aussagekräftige Gutschrift enthält, kann der Kunde Ausfälle planen. Wo das SLA vage oder nicht vorhanden ist, kann der Kunde das nicht.

Sicherheit: Die relevante Frage ist nicht, ob der Anbieter verletzt wurde. Jeder reife Anbieter wurde verletzt. Die relevante Frage ist, ob die Architektur und das Betriebsmodell die Wahrscheinlichkeit und die Auswirkung reduzieren. Datenminimierung, expliziter Zugriff, menschliche Freigaben, nachvollziehbare Arbeit, Kostengrenzen und kontinuierliches Schutz-Monitoring sind die Engineering-Prinzipien, die Sicherheit von einer Verkaufsbehauptung in eine überprüfbare Eigenschaft verwandeln.

Regulatorische Änderung: Ein Anbieter, der eine Datenschutzerklärung gegen die aktuelle Version der DSGVO, die aktuelle Version des EU–US Data Privacy Framework und die aktuelle Version der einschlägigen nationalen Aufsichtsbehörden-Leitlinien betreibt, ist ein Anbieter, den der Kunde auditieren kann. Ein Anbieter, der diese nicht offenlegt, ist ein Anbieter, den der Kunde nicht auditieren kann.

Ausstieg: Ein System, das auf offenen Standards aufgebaut ist, mit dokumentierten APIs, mit exportierbaren Datenformaten und mit der Option, die Plattform intern zu betreiben, ist ein System, das der Kunde verlassen kann. Das Geschäftsmodell, das dies unterstützt, ist ein Geschäftsmodell, auf das sich der Kunde verlassen kann.

Umsetzung

Die Umsetzungsreihenfolge, Woche für Woche

Die Umsetzung folgt dem Betriebsmodell. Ein Self-Service-Engagement beginnt mit Beschaffung und Provisionierung. Ein Beratungs-Engagement beginnt mit der Arbeitssitzung. Ein Managed Engagement beginnt mit Discover. Die ersten drei Wochen eines Managed Engagement decken typischerweise die Kartierung von Arbeit, Menschen, Daten, Risiken und bestehenden Systemen ab. Die nächsten vier bis sechs Wochen produzieren eine fokussierte Arbeitsversion, getestet gegen realistische Eingaben. Die nächsten vier bis sechs Wochen integrieren diese Arbeitsversion mit den Werkzeugen, die bereits bestimmen, wie Arbeit geschieht. Das erste Betriebsquartal etabliert das Monitoring, die Dokumentation und die menschlichen Freigabepunkte. Die nächsten zwei Quartale sind kontinuierliche Verbesserung.

Der Kunde bleibt durchgehend der Betreiber. Die Rolle des Anbieters ist es, die Plattform und das Engineering zu liefern, die Standards zu pflegen und der genannte Verantwortliche für die Teile der Arbeit zu sein, die der Anbieter durchführt. Die Rolle des Kunden ist es, das System zu nutzen, die Eingaben bereitzustellen und die Entscheidungen zu treffen, die das System unterstützt, aber nicht für den Kunden trifft.

Das ist der strukturelle Unterschied zwischen einem vernetzten Ökosystem und einer Sammlung von Anbietern. Das vernetzte Ökosystem hat einen einzigen Beschaffungspfad, eine einzige Integrationsgeschichte, ein einziges Sicherheitsmodell, ein einziges Betriebsmodell und einen einzigen Ausstiegspfad. Die Sammlung von Anbietern hat nichts davon. Die Wahl ist nicht zwischen Features; sie ist zwischen diesen beiden Strukturmodellen.

Häufige Fragen

Häufig gestellte Fragen, in klarer Sprache

Die häufigste Frage betrifft die Kosten. Die ehrliche Antwort ist, dass die Kosten von der Architektur und dem Betriebsmodell abhängen und dass die Kosten eines vernetzten Ökosystems in der Regel niedriger sind als die einer Sammlung von Anbietern, sobald Integrations-, Sicherheitsüberprüfungs-, Beschaffungs-, Audit- und Offboarding-Kosten eingerechnet werden. Die genaue Zahl hängt vom Engagement ab; die Struktur der Kosten ist offen veröffentlicht.

Die zweithäufigste Frage betrifft die Daten. Wo die Daten sind, wer die Auftragsverarbeiter sind, was die Rechtsgrundlage für jede Drittlandsübermittlung ist — all dies wird in der Datenschutzerklärung beantwortet, mit namentlich genannten Anbietern, namentlich genannten Adressen, namentlich genannten Rechtsgrundlagen und namentlich genannten Garantien. Die zuständige Aufsichtsbehörde für den Sitz ist dokumentiert; die zuständige Datenschutz-Aufsichtsbehörde ist dokumentiert; die zuständige Marktüberwachungsbehörde für Barrierefreiheit ist dokumentiert.

Die dritthäufigste Frage betrifft den Ausstieg. Ein Kunde, der geht, wird unterstützt. Das System exportiert die Daten und Konfiguration des Kunden. Die Architektur ist unabhängig betreibbar. Das Geschäftsmodell ist offen veröffentlicht, so dass der Kunde die Kostenposition Zeile für Zeile planen kann. Der Ausstieg ist ein geplantes Ergebnis, kein Worst-Case-Szenario.

Die vierthäufigste Frage betrifft die Sprache. Die Plattform ist in bis zu zwölf Sprachen veröffentlicht. Der relevante Rechtstext ist in der bevorzugten Sprache des Kunden. Die relevanten Geschäftsbedingungen sind in der bevorzugten Währung des Kunden. Die relevante Auslieferung ist in der bevorzugten Zeitzone des Kunden. Die Plattform ist international by design, nicht by retrofit.

Eine fünfte häufige Frage, in Organisationen, die schon einmal einen Anbieterwechsel durchlaufen haben, betrifft die Migrationskosten. Die ehrliche Antwort ist, dass die Migrationskosten real sind, dass die Kosten über die Architektur amortisiert werden, nicht in einer einzelnen Komponente konzentriert, und dass die Kosten eine bekannte Position sind, kein verstecktes Risiko. Der Migrationsplan wird vor der ersten Änderung schriftlich festgehalten. Die Migration ist in jeder Phase umkehrbar. Der Kunde behält die Option, das neue System, das alte System oder beide parallel zu betreiben, so lange der Kunde es für notwendig hält.

Eine sechste häufige Frage, in Organisationen, die noch keinen Anbieterwechsel durchlaufen haben, betrifft die Kosten des Nichtstuns. Die ehrliche Antwort ist, dass die Kosten für den Betrieb eines Portfolios nicht verbundener Anbieter — die Integrationsarbeit, die Sicherheitsüberprüfungen, die Beschaffungszyklen, die Audits, das Offboarding-Risiko — sich mit der Zeit summieren. Je länger das Portfolio besteht, desto stärker ist der Kunde gebunden. Je länger der Kunde mit der Konsolidierung wartet, desto teurer wird die Konsolidierung. Das Risiko des Nichtstuns ist kein stabiles Risiko; es ist ein wachsendes.

Eine siebte häufige Frage, in Organisationen mit regulierten Workloads, betrifft die Auditierbarkeit. Die ehrliche Antwort ist, dass das Connected-Ecosystem-Modell besser auditierbar ist als das Sammlung-von-Anbietern-Modell, weil es einen einzigen Beschaffungspfad, eine einzige Integrationsgeschichte, ein einziges Sicherheitsmodell, ein einziges Betriebsmodell und einen einzigen Ausstiegspfad zu auditieren gibt. Das Sammlung-von-Anbietern-Modell erfordert, dass der Kunde jeden Anbieter separat auditiert, und dann die Integration zwischen ihnen, was ein zweites Audit auf einer anderen Schicht ist, das fast niemand durchführt.

Eine achte häufige Frage, in Organisationen mit internationalen Operationen, betrifft Sprache und Zeitzone. Die ehrliche Antwort ist, dass die Plattform in bis zu zwölf Sprachen veröffentlicht ist, der Rechtstext in der bevorzugten Sprache des Kunden, die kommerziellen Bedingungen in der bevorzugten Währung des Kunden, und die Auslieferung in der bevorzugten Zeitzone des Kunden. Die Plattform ist international by design, nicht by retrofit. Wo ein Kunde Operationen in einer Sprache oder Zeitzone hat, die noch nicht abgedeckt ist, wird die Plattform erweitert, und die Erweiterung wird als Feature behandelt, nicht als Projekt.

Eine fünfte häufige Frage, in Organisationen, die schon einmal einen Anbieterwechsel durchlaufen haben, betrifft die Migrationskosten. Die ehrliche Antwort ist, dass die Migrationskosten real sind, dass die Kosten über die Architektur amortisiert werden, nicht in einer einzelnen Komponente konzentriert, und dass die Kosten eine bekannte Position sind, kein verstecktes Risiko. Der Migrationsplan wird vor der ersten Änderung schriftlich festgehalten. Die Migration ist in jeder Phase umkehrbar. Der Kunde behält die Option, das neue System, das alte System oder beide parallel zu betreiben, so lange der Kunde es für notwendig hält.

Eine sechste häufige Frage, in Organisationen, die noch keinen Anbieterwechsel durchlaufen haben, betrifft die Kosten des Nichtstuns. Die ehrliche Antwort ist, dass die Kosten für den Betrieb eines Portfolios nicht verbundener Anbieter — die Integrationsarbeit, die Sicherheitsüberprüfungen, die Beschaffungszyklen, die Audits, das Offboarding-Risiko — sich mit der Zeit summieren. Je länger das Portfolio besteht, desto stärker ist der Kunde gebunden. Je länger der Kunde mit der Konsolidierung wartet, desto teurer wird die Konsolidierung. Das Risiko des Nichtstuns ist kein stabiles Risiko; es ist ein wachsendes.

Eine siebte häufige Frage, in Organisationen mit regulierten Workloads, betrifft die Auditierbarkeit. Die ehrliche Antwort ist, dass das Connected-Ecosystem-Modell besser auditierbar ist als das Sammlung-von-Anbietern-Modell, weil es einen einzigen Beschaffungspfad, eine einzige Integrationsgeschichte, ein einziges Sicherheitsmodell, ein einziges Betriebsmodell und einen einzigen Ausstiegspfad zu auditieren gibt. Das Sammlung-von-Anbietern-Modell erfordert, dass der Kunde jeden Anbieter separat auditiert, und dann die Integration zwischen ihnen, was ein zweites Audit auf einer anderen Schicht ist, das fast niemand durchführt.

Eine achte häufige Frage, in Organisationen mit internationalen Operationen, betrifft Sprache und Zeitzone. Die ehrliche Antwort ist, dass die Plattform in bis zu zwölf Sprachen veröffentlicht ist, der Rechtstext in der bevorzugten Sprache des Kunden, die kommerziellen Bedingungen in der bevorzugten Währung des Kunden, und die Auslieferung in der bevorzugten Zeitzone des Kunden. Die Plattform ist international by design, nicht by retrofit. Wo ein Kunde Operationen in einer Sprache oder Zeitzone hat, die noch nicht abgedeckt ist, wird die Plattform erweitert, und die Erweiterung wird als Feature behandelt, nicht als Projekt.

Praxisbeispiel

Ein Praxisbeispiel aus der realen Welt

Um die Architektur konkret zu machen, betrachten wir eine Organisation mit Standorten in mehreren Ländern, mehreren Zeitzonen und einer Belegschaft, die sowohl regulierte als auch unregulierte Arbeit abdeckt. Die bestehende Konfiguration umfasst in der Regel einen pro-Land-Telefonieanbieter, einen separaten Hosting-Anbieter, ein internes IT-Team für Managed Services, einen separaten Sicherheitsberater und einen entstehenden KI-Piloten, der noch nicht in den Rest integriert ist. Jeder dieser Bereiche hat seinen eigenen Beschaffungszyklus, seine eigene Sicherheitsüberprüfung und sein eigenes Audit. Keiner sieht die anderen.

Im Rahmen eines Connected-Ecosystem-Engagements werden in den ersten drei Wochen von Discover die bestehenden Systeme, die Datenflüsse zwischen ihnen, die Sicherheitsgrenzen, die regulatorischen Verpflichtungen in jedem Land, die Sprachanforderungen und die am stärksten wiederkehrende Arbeit kartiert. Das Ergebnis von Discover ist ein schriftliches Dokument, das der Kunde prüfen kann und das das Engineering-Team als Eingabe für Design verwendet. Während Discover ändert sich an den bestehenden Systemen nichts. Das Ziel ist, zu verstehen, bevor geändert wird.

Design produziert dann eine fokussierte Arbeitsversion: eine einzige Identität, eine einzige Telefonieplattform mit transparenter Preisgestaltung, ein einziges Hosting-Estat mit veröffentlichtem SLA, ein einziges Managed-IT-Engagement und ein einziger KI-Dienst, der mit expliziten Zugriffsregeln gegen die eigenen Daten des Kunden arbeitet. Jede Komponente ist eine der zehn Dienstleistungslinien. Die Architektur ist dokumentiert. Die Entscheidung ist dokumentiert. Die bestehenden Systeme des Kunden werden nicht am ersten Tag ersetzt; sie werden in der richtigen Reihenfolge migriert, wobei der Migrationsplan vor der ersten Änderung schriftlich festgehalten wird.

Prototype produziert eine Arbeitsversion, die der Kunde für die erste Lieferung in der Produktion verwenden kann. Die Lieferung kann ein einzelner kundenorientierter Service, ein einzelner interner Prozess oder ein einzelner Compliance-Workflow sein. Der Punkt ist, dass die Arbeitsversion real ist, dass sie die realen Daten des Kunden mit der realen Identität des Kunden verwendet und dass sie an den realen Metriken des Kunden bewertet werden kann. Die Bewertung informiert die Integrate-Phase.

Integrate verbindet die Arbeitsversion mit den Werkzeugen, die der Kunde bereits verwendet: das E-Mail-System, den Dokumentenspeicher, den Kalender, das CRM, den Helpdesk, das ERP, das Engineering-Ticketing-System. Jede Integration ist dokumentiert. Jede Integration ist umkehrbar. Jede Integration hat einen menschlichen Freigabepunkt. Die Integrationen sind der Teil der Architektur, der sich am ehesten weiterentwickeln muss, wenn sich die Arbeit ändert, also sind sie so konzipiert, dass sie sich weiterentwickeln.

Improve ist die Betriebsphase. Die Überwachung ist eingerichtet. Die Dokumentation ist aktuell. Menschliche Freigabepunkte werden ausgeübt. Die Kosten werden anhand des veröffentlichten Modells verfolgt. Die Akzeptanz wird gemessen. Das System wird aktualisiert, wenn sich die Arbeit ändert, und die Aktualisierungen werden aufgezeichnet. Der Kunde behält das Recht, das System jederzeit selbst zu betreiben, und das System ist so gebaut, dass es dieses Recht unterstützt. Dies ist der strukturelle Unterschied zwischen einem vernetzten Ökosystem und einer Sammlung von Anbietern: Das vernetzte Ökosystem hat ein einziges Betriebsmodell, einen einzigen Ausstiegspfad und eine einzige Architektur, die der Kunde prüfen, replizieren und — wenn er will — selbst betreiben kann.

Das Praxisbeispiel ist kein Verkaufsgespräch. Es ist eine Beschreibung, wie das Engagement tatsächlich abläuft, Woche für Woche, Artefakt für Artefakt. Ein Kunde, der eines dieser Engagements durchlaufen hat, kann die Beschreibung lesen und die Struktur wiedererkennen. Ein Kunde, der kurz davor steht, eines zu beginnen, kann die Beschreibung lesen und sich auf die Struktur vorbereiten. Dafür ist die Struktur da.

Konkret sehen die Zahlen für ein repräsentatives Engagement wie folgt aus. Ein mittelgroßes Unternehmen mit 1.200 Mitarbeitenden in vier Ländern konsolidiert ein Portfolio von vierzehn Anbietern in ein einziges vernetztes Ökosystem. Die jährlichen laufenden Einsparungen liegen typischerweise bei 18% bis 28% der gesamten IT-Ausgaben, hauptsächlich aus der Eliminierung redundanter Integrationsarbeit, der Konsolidierung der Sicherheitsüberprüfung, der Vereinfachung der Beschaffung und der Vereinheitlichung des Audits. Das Migrationsprojekt selbst dauert zwölf bis zwanzig Wochen, wobei der Kunde die Option behält, das neue System, das alte System oder beide parallel zu betreiben, so lange der Kunde es für notwendig hält.

Die wirtschaftliche Lebensdauer der Architektur ist nicht die wirtschaftliche Lebensdauer eines einzelnen Anbieters. Ein vernetztes Ökosystem, das auf offenen Standards aufgebaut ist, hat eine wirtschaftliche Lebensdauer, die in Jahrzehnten gemessen wird, nicht in Anbietervertragszyklen. Eine Sammlung von Anbietern hat eine wirtschaftliche Lebensdauer, die in Anbietervertragszyklen gemessen wird, typischerweise zwei bis fünf Jahre pro Anbieter, und die Verträge laufen nicht synchron. Der Kunde migriert, konsolidiert und beschafft daher alle zwei bis fünf Jahre neu, unabhängig davon, ob der Kunde dies will. Das Connected-Ecosystem-Modell beendet diesen Zyklus.

Das Praxisbeispiel adressiert auch die Frage des Vertrauens. Ein Kunde, der diese Beschreibung liest und sich entscheidet fortzufahren, trifft eine langfristige architektonische Verpflichtung, keine kurzfristige Beschaffungsentscheidung. Die Verpflichtung gilt der Architektur, nicht dem Anbieter. Wenn der Anbieter verschwindet, kann der Kunde das System weiter betreiben, weil die Architektur offen ist. Wenn der Kunde gehen will, kann der Kunde die Daten und die Konfiguration mitnehmen, weil die Daten portabel sind. Wenn der Kunde die Architektur weiterentwickeln will, kann der Kunde dies ohne Erlaubnis des Anbieters tun, weil die Standards öffentlich sind. Das Vertrauen liegt in der Architektur, und die Architektur gehört dem Kunden.