Enterprise-Softwareentwicklung: Was Sie Wirklich Kaufen

Enterprise-Softwareentwicklung bedeutet, so wie der Begriff auf den meisten Agenturseiten benutzt wird, dieselbe Arbeit mit einer größeren Zahl daneben. Das Team ist dasselbe, der Prozess ist derselbe, das Pitch-Deck bekommt eine Logo-Wand, und der Preis verdreifacht sich. Käufer wissen das, weshalb Beschaffungsabteilungen gelernt haben, das Wort zu ignorieren und stattdessen die Vertragsanlagen zu lesen.

Darunter liegt ein echter Unterschied, und er hat nichts mit der Unternehmensgröße zu tun. Ein Versicherer mit vierzig Beschäftigten kann ein wirklich unternehmensweites Programm fahren, und ein Händler mit zwölftausend Beschäftigten kann etwas beauftragen, das in Wahrheit nur eine Website ist. Was beide trennt, sind die Pflichten, die das System demjenigen auferlegt, der es baut: mit wie vielen anderen Systemen es sprechen muss, wie lange es ausfallen darf, wer ein Release blockieren kann, welche Aufsichtsbehörde ein Interesse hat, und was passiert, wenn der Anbieter geht.

Was folgt, definiert die Kategorie über diese Pflichten, damit ein Käufer einen Anbieter, der sie tragen kann, von einem unterscheiden kann, der einen gewöhnlichen Build mit einem Enterprise-Deckblatt verkauft.

Was macht ein Softwareprojekt wirklich zu einem Enterprise-Projekt? Nicht die Größe des Käufers. Ein Projekt ist Enterprise, wenn es Randbedingungen trägt, die ein gewöhnlicher Build nicht hat: eine breite Integrationsfläche, eine vertragliche Verfügbarkeits- und Wiederherstellungspflicht, regulatorische Exponierung, mehrere Stakeholder-Gruppen, die jeweils ein Release blockieren können, Datenmengen, die naive Entwürfe sprengen, und die Anforderung, mit Systemen zu koexistieren, die derzeit niemand versteht. Diese Randbedingungen entscheiden über Architektur und den Großteil der Kosten, nicht die Funktionsliste.

Was ein Projekt zu einem Enterprise-Projekt macht

Der brauchbare Test ist eine Liste von Randbedingungen, und ein Projekt qualifiziert sich, wenn es die meisten davon trägt statt nur eine. Ehrlich angewendet disqualifiziert er vieles, was als Enterprise verkauft wird, und qualifiziert Arbeit, die als kleiner Build verkauft wurde und dann scheitert, weil sie auch so geschnitten war.

Die Integrationsfläche

Zählen Sie die Systeme, mit denen Ihre neue Software Daten austauschen muss, und zählen Sie dann, wie viele getrennte Teams oder Anbieter diese Systeme besitzen. Die zweite Zahl sagt die Kosten voraus. Drei Integrationen im Besitz eines internen Teams sind zwei Wochen Arbeit. Drei Integrationen im Besitz von drei Anbietern, jeder mit eigenem Änderungsfenster, eigener Sandbox-Verfügbarkeit und eigenem Support-Desk, sind ein Quartal.

Jeder Eigentümer bringt einen Zeitplan mit, den Sie nicht kontrollieren. Ein Anbieter, dessen Sandbox monatlich erneuert wird, gibt Ihren Testrhythmus vor, und ein Zahlungsdienstleister, dessen Zertifizierung sechs Wochen dauert, setzt Ihren Go-Live-Termin. Bei einem Dutzend Gegenparteien wird der Integrationskalender zum Projektplan, und die Entwicklung fügt sich in die Lücken ein.

Die Verfügbarkeitspflicht

Von gewöhnlicher Software wird erwartet, dass sie funktioniert. An dieser Erwartung hängt bei Enterprise-Software eine Zahl, meist in einem Vertrag mit einer Gutschrift dahinter. Die Zahl verändert zuerst die Architektur, denn eine Bereitstellung auf einer einzigen Instanz kann sie nicht einhalten, wie gut der Code auch sein mag.

Der Schritt von einem Ziel, das ein Wartungsfenster verträgt, zu einem, das keines verträgt, ist die teuerste einzelne Position in den meisten Enterprise-Budgets, und sie wird häufig von Leuten vereinbart, die den Preis nie gesehen haben. Unser Beitrag zu Verfügbarkeits-SLAs, die etwas bedeuten behandelt, wie diese Zahlen geschrieben werden und wie regelmäßig sie schlecht geschrieben werden.

Stakeholder mit Vetorecht

Ein gewöhnliches Projekt hat einen Product Owner. Ein Enterprise-Projekt hat einen Product Owner, eine Informationssicherheitsfunktion, einen Datenschutzbeauftragten, eine Einkaufsleitung, ein Infrastrukturteam, dem das Netzwerk gehört, einen Service Desk, der die Supportlast erbt, und oft einen klinischen, juristischen oder Compliance-Prüfer.

Jeder Einzelne kann ein Release stoppen, und keiner berichtet an die Person, die die Arbeit bezahlt. Entscheidungen brauchen deshalb Kalenderzeit, die nichts damit zu tun hat, wie schwer sie sind, und ein Anbieter, der das nicht eingeplant hat, verfehlt ab dem zweiten Monat jeden Termin.

Die Systeme, die niemand mehr versteht

Jede Enterprise-Landschaft enthält mindestens ein System, dessen Verhalten nur durch seine Ausgabe dokumentiert ist. Die Leute, die es geschrieben haben, sind fort, und die Spezifikation beschreibt, falls sie existiert, eine frühere Version. Es funktioniert, es ist tragend, und es zu ändern gilt als unklug.

Neue Software muss damit koexistieren, also muss zuerst jemand feststellen, was es tatsächlich tut. Das ist Archäologie, nicht Entwicklung: Produktionsdaten lesen, Aufrufe verfolgen, kontrollierte Experimente gegen eine Kopie fahren und die Regeln aufschreiben, die der Code impliziert. In einer großen Landschaft sind das Wochen an Arbeit, und es ist die Position, die in Verhandlungen am häufigsten gestrichen wird, weil sie kein sichtbares Feature erzeugt.

Sie zu streichen verschiebt die Arbeit in den Integrationstest, wo sie unter Zeitdruck von Leuten entdeckt wird, die bereits Fehler beheben. Ein Anbieter, der Discovery getrennt ausweist und verteidigt, sagt Ihnen etwas Wahres darüber, wie diese Programme scheitern. Unsere Notiz zu Legacy-Modernisierung und der Entscheidung zwischen Neubau und Refactoring behandelt, was diese Archäologie findet.

Beschaffung ist die halbe Arbeit

Die meisten Techniker unterschätzen diesen Teil um den Faktor drei. In einem wirklich unternehmensweiten Auftrag dauert die Arbeit zwischen dem ersten Gespräch und der ersten Codezeile länger als das erste Lieferinkrement, und sie verbraucht auf beiden Seiten Zeit von Führungskräften.

Seit dem 24. Februar 2025 arbeitet der britische öffentliche Sektor nach dem Procurement Act 2023, und Anbieter, die sich um öffentliche Aufträge bewerben, müssen auf der zentralen digitalen Plattform innerhalb des erweiterten Dienstes Find a Tender registriert sein. Die private Beschaffung hat keine vergleichbare einzelne Eingangstür, was sie paradoxerweise langsamer macht, weil jeder Käufer seine eigene erfunden hat.

Der Sicherheitsfragebogen

Sie werden eine Tabelle zugeschickt bekommen. Sie fragt nach Ihrem Entwicklungslebenszyklus, Ihren Zugriffskontrollen, Ihrem Patch-Rhythmus, Ihren Unterauftragnehmern, Ihrer Datenresidenz, Ihren Reaktionszeiten bei Vorfällen und Ihren Hintergrundprüfungen. Größere Käufer schicken mehrere hundert Fragen, und eine Bank oder ein NHS-Trust schickt mehr.

Die Fragen sind nicht schwer, aber sie sind nur beantwortbar, wenn die Antworten bereits als Richtlinie existieren. Ein Anbieter, der sie während einer Ausschreibung zum ersten Mal zusammenstellt, braucht vier bis sechs Wochen und liegt bei mehreren falsch. Wer es schon getan hat, antwortet in Tagen aus einer gepflegten Antwortbibliothek, was ein legitimer Grund ist, ihn vorzuziehen.

Lieferantenaufnahme, Versicherung und Bonitätsprüfung

Das Onboarding ist von der Ausschreibung getrennt und läuft oft parallel dazu. Rechnen Sie damit, eine Berufshaftpflicht und eine Cyber-Haftpflicht in einer vom Käufer festgelegten Höhe nachzuweisen, dazu eine Betriebshaftpflicht für Beschäftigte und manchmal eine Produkthaftpflicht. Enterprise-Käufer verlangen üblicherweise Deckungssummen, die eine kleine Beratung nicht standardmäßig hält, und die Deckung mitten in der Ausschreibung zu erhöhen kostet Zeit.

Danach folgen die Finanzprüfungen. Käufer ziehen eingereichte Jahresabschlüsse, holen eine Bonitätsauskunft ein und verlangen bei größeren Verträgen betriebswirtschaftliche Auswertungen oder eine Konzernbürgschaft. Ein Anbieter, dessen Bilanz den Auftragswert nicht trägt, wird unabhängig von fachlicher Eignung ausgeschlossen, weshalb fähige kleine Firmen Ausschreibungen verlieren, für die sie die Richtigen waren.

Warum der Vertriebszyklus länger dauert als das erste Inkrement

Legt man die beiden Zeitleisten nebeneinander, wird die Form des Problems deutlich. Qualifizierung, Anforderungen, Sicherheitsprüfung, Vertragsverhandlung, Versicherungsnachweise und Onboarding nehmen bei einem Vertrag im Wert von mehreren hunderttausend Pfund üblicherweise vier bis neun Monate ein. Das erste nützliche Softwareinkrement dauert danach vielleicht zehn Wochen.

Schätzungen, die zu Beginn dieses Zyklus geschrieben wurden, sind bei Unterschrift veraltet, und ein Anbieter, der über die Lücke hinweg einen Festpreis hält, kalkuliert entweder großzügig oder plant, später über den Umfang zu streiten. Auch Technologieannahmen altern, und eine Version, die bei Angebotsabgabe aktuell war, kann beim Kickoff aus dem Support gefallen sein.

Datieren Sie jede Schätzung, nennen Sie ihre Annahmen und vereinbaren Sie bei Unterschrift eine Neubasierung, statt so zu tun, als hätte die Zahl überlebt. Käufer, die auf der ursprünglichen Zahl bestehen, kaufen eine Pipeline von Änderungsanträgen. Unser Leitfaden zum Schreiben eines Software-RFP, das brauchbare Angebote bringt behandelt, was in das Dokument gehört.

Nichtfunktionale Anforderungen sind die eigentliche Lieferung

Funktionslisten sind leicht zu schreiben und entscheiden selten etwas. Die nichtfunktionalen Anforderungen entscheiden über die Architektur, die Infrastrukturrechnung, die Teamgröße und die Länge des Testzyklus, und in den meisten Enterprise-Programmen sind sie zwei Absätze lang in einem Dokument, dessen Funktionsliste vierzig Seiten füllt.

Dieses Missverhältnis ist der zuverlässigste Vorbote einer Überschreitung. Ein Anbieter, der den ersten Workshop auf Verfügbarkeit, Wiederherstellung, Latenz, Durchsatz, Nachvollziehbarkeit und Aufbewahrung verwendet, verzögert nicht: diese sechs Zahlen streichen die meisten architektonischen Optionen, und sie spät festzulegen bedeutet Neubau.

Schreiben Sie sie als prüfbare Aussagen mit einer Zahl und einer Bedingung. Das System muss hochverfügbar sein ist keine Anforderung. Der Bestelldienst muss eine monatliche Verfügbarkeit von 99,9 Prozent aufrechterhalten, gemessen am Load Balancer, ausgenommen ein Fenster von zwei Stunden, das fünf Werktage im Voraus angekündigt wird: das ist eine, weil ein Test sie durchfallen lassen kann.

Recovery Point und Recovery Time in einfachen Worten

Zwei dieser Zahlen treiben die Kosten stärker als jedes Feature, und sie werden regelmäßig von Leuten genannt, die ihre Bedeutungen vertauscht haben. Das Recovery Point Objective ist, wie viele Daten Sie zu verlieren bereit sind: ein RPO von einer Stunde heißt, Sie akzeptieren, dass nach einer Katastrophe bis zu eine Stunde an Transaktionen fehlen kann, und Ihr Backup- oder Replikationsverfahren darf nicht schlechter sein. Das Recovery Time Objective ist, wie lange Sie bereit sind, ausgefallen zu sein, ein RTO von vier Stunden heißt also, dass der Dienst innerhalb von vier Stunden nach Beginn des Vorfalls wieder Verkehr bedient.

Beide Zahlen übersetzen sich direkt in Architektur. AWS beschreibt in seiner Anleitung zur Notfallwiederherstellung vier grobe Strategien: Backup and Restore, Pilot Light, Warm Standby und Multi-Site Active/Active. Sie reichen von billig und langsam bis teuer und nahezu sofort, und die Wahl wird Ihnen abgenommen, sobald die beiden Ziele vereinbart sind.

Vermeiden Sie es, aggressive Zahlen zu vereinbaren, weil sie verantwortungsvoll klingen. Ein RPO von null bei einem RTO von Minuten bedeutet kontinuierliche Replikation und eine zweite Live-Umgebung, was die Infrastrukturrechnung ungefähr verdoppelt. Unsere Ausarbeitung zur Notfallwiederherstellung für kleine Softwareteams zeigt, was die günstigeren Stufen kaufen.

Verfügbarkeitsarithmetik und was ein SLA tatsächlich kauft

Verfügbarkeitsprozente verstecken ihre Bedeutung hinter einem Komma. Über einen Monat von 30 Tagen erlauben 99,9 Prozent rund 43 Minuten Ausfall, 99,95 Prozent rund 22 Minuten und 99,99 Prozent rund 4 Minuten. Das ist das Budget des ganzen Monats, einschließlich Deployments, Zertifikatserneuerungen und des Datenbank-Failovers, das länger gedauert hat als erwartet.

Vier Minuten im Monat sind für ein Team, das zu Bürozeiten deployt und einen einzelnen Ingenieur alarmiert, nicht erreichbar. Es braucht Redundanz auf jeder Ebene, automatisches Failover, Deployments, die den Verkehr nicht unterbrechen, und jemanden, der um drei Uhr nachts wach ist. Der letzte Punkt kostet meist mehr als die Infrastruktur und steht fast nie im ursprünglichen Budget. Legen Sie auch den Messpunkt im Vertrag fest, denn am Load Balancer gemessene Verfügbarkeit und aus echter Nutzertelemetrie gemessene Verfügbarkeit können sich beim selben Vorfall um eine Größenordnung unterscheiden.

Latenz, Durchsatz und die Last, die niemand gemessen hat

Latenzziele brauchen ein Perzentil und einen Geltungsbereich, weil Mittelwerte die Ausfälle verbergen. Ein genanntes Ziel von 200 Millisekunden im 95. Perzentil für den Checkout-Endpunkt bei 400 Anfragen pro Sekunde ist prüfbar. Ein Ziel von schnell ist es nicht, und ein Mittelwert auch nicht, denn ein Mittelwert von 200 Millisekunden verträgt sich damit, dass einer von zwanzig Nutzern vier Sekunden wartet.

Durchsatz braucht eine Spitze, keinen Mittelwert. Händler dimensionieren für den Freitag vor Weihnachten, Lohnsysteme für den letzten Arbeitstag des Monats und öffentliche Dienste für die Frist in dem Brief, der herausgegangen ist. Für den Jahresdurchschnitt zu dimensionieren ist der Weg, auf dem ein Start in seiner ersten geschäftigen Stunde scheitert. Nehmen Sie die Spitze aus den Logs des bestehenden Systems, wo Verhältnisse von zehn zu eins üblich sind, denn dieses Verhältnis entscheidet, ob der Entwurf eine Queue braucht.

Nachvollziehbarkeit und Aufbewahrung

Regulierte Käufer, und zunehmend auch nicht regulierte, müssen Jahre später beantworten können, wer was wann geändert hat. Das ist eine Entwurfsanforderung und keine Logging-Konfiguration: ein System, das Zeilen überschreibt, kann sie nicht beantworten, und die Antwort muss so lange überleben, wie die Aufbewahrungsrichtlinie es vorgibt.

Entscheiden Sie drei Dinge früh. Welche Ereignisse prüfbar sind, üblicherweise Zustandsänderungen an Datensätzen mit rechtlicher oder finanzieller Bedeutung statt jeder HTTP-Anfrage. Wie lange jede Klasse von Datensätzen aufbewahrt wird, eine juristische Frage mit einer Datenschutzbeschränkung daran, denn personenbezogene Daten länger als nötig zu halten ist selbst ein Verstoß. Und wer die Spur lesen darf, denn ein Audit-Log, das Administratoren bearbeiten können, beweist nichts. Aufbewahrung und Löschrechte kollidieren hier, und die Spannung wird im Schema aufgelöst, nicht in der Richtlinie.

Die Zertifizierungen, nach denen ein Käufer fragen wird

Drei kommen immer wieder vor, sie werden ständig verwechselt, und sie beweisen Verschiedenes. Ein Anbieter, der den Unterschied nicht erklären kann, hält sie nicht.

Cyber Essentials und Cyber Essentials Plus

Cyber Essentials ist die von der britischen Regierung gestützte Grundlinie, entwickelt vom NCSC und über IASME als offiziellen Umsetzungspartner ausgeliefert. Es deckt fünf technische Kontrollen ab: Firewalls, sichere Konfiguration, Verwaltung von Sicherheitsupdates, Benutzerzugriffskontrolle und Schutz vor Schadsoftware. Die Basisstufe ist ein Selbstauskunftsfragebogen, der unabhängig geprüft wird, und das NCSC nennt Preise ab GBP 320 zuzüglich Mehrwertsteuer je nach Organisationsgröße.

Cyber Essentials Plus sind dieselben fünf Kontrollen, durch ein unabhängiges technisches Audit verifiziert statt nur behauptet. Der Prüfer führt interne und externe Schwachstellenscans durch und testet eine Stichprobe von Benutzergeräten, Internet-Gateways und aus dem Internet erreichbaren Servern. Das Plus-Audit muss innerhalb von drei Monaten nach der Basiszertifizierung abgeschlossen sein, und beide Zertifikate gelten zwölf Monate.

Das Schema ist kommerziell ebenso bedeutsam wie technisch. PPN 014, seit dem 24. Februar 2025 in Kraft für zentrale Regierungsressorts, ihre Agenturen, nicht-ministerielle öffentliche Einrichtungen und NHS-Stellen, verlangt eine Zertifizierung, wenn Anbieter personenbezogene Daten von Bürgern, personenbezogene Daten von Regierungsbeschäftigten oder IKT-Systeme handhaben, die Daten der Stufe OFFICIAL verarbeiten.

ISO/IEC 27001

ISO/IEC 27001 ist die internationale Norm für ein Informationssicherheits-Managementsystem, herausgegeben von ISO und IEC. Die aktuelle Ausgabe ist ISO/IEC 27001:2022, mit Amendment 1 aus dem Jahr 2024, das den Kontextklauseln Formulierungen zum Klimaschutz hinzufügt, im Einklang mit einer Änderung über alle ISO-Managementsystemnormen hinweg.

Es ist eine Managementsystemnorm, und genau das lesen Käufer falsch. Sie schreibt keinen festen Satz von Kontrollen vor, den jede zertifizierte Organisation umgesetzt hätte. Sie verlangt, dass die Organisation ihren Geltungsbereich festlegt, ihre Risiken bewertet, Kontrollen auswählt und einen dokumentierten Zyklus aus Überprüfung und Verbesserung betreibt. Die Zertifizierung wird nach einem Audit von einer akkreditierten Zertifizierungsstelle ausgestellt, nicht von der ISO selbst.

Die nützliche Frage ist deshalb nie, ob ein Anbieter sie hält, sondern was die Geltungsbereichserklärung auf dem Zertifikat abdeckt. Ein auf eine Zentralfunktion begrenzter Geltungsbereich sagt Ihnen nichts über das Team, das Ihren Quellcode und Ihre Produktionszugangsdaten hält. Fordern Sie das Zertifikat an und lesen Sie den Geltungsbereich.

SOC 2

SOC 2 ist amerikanisch und von anderer Art. Die AICPA definiert es als einen Bericht über Kontrollen bei einer Dienstleistungsorganisation, die für Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit oder Datenschutz relevant sind, erstellt nach ihren Trust Services Criteria. Es ist ein Bestätigungsbericht einer Wirtschaftsprüfungsgesellschaft, kein Zertifikat, und es gibt weder eine Bestehensgrenze noch ein Logo zum Anzeigen.

Der entscheidende Unterschied ist der Typ. Ein Bericht vom Typ 1 beschreibt die Kontrollen und beurteilt, ob sie zu einem Zeitpunkt angemessen gestaltet sind. Ein Bericht vom Typ 2 prüft, ob sie über einen Zeitraum wirksam funktioniert haben, üblicherweise sechs oder zwölf Monate. Typ 1 ist eine Fotografie und Typ 2 ein Film, und Käufer, die Typ 1 als gleichwertig akzeptieren, akzeptieren viel weniger, als sie denken.

Lesen Sie den Bericht, nicht das Deckblatt. Der Abschnitt mit den Ausnahmen, in dem der Prüfer Kontrollen festhält, die nicht wie beschrieben funktioniert haben, trägt die Information, und es ist der Teil, bei dem Anbieter hoffen, dass Sie ihn überspringen.

Was keines davon beweist

Keines der drei bescheinigt, dass Ihre Software sicher ist. Cyber Essentials deckt eine Grundlinie an Infrastrukturhygiene ab. ISO 27001 deckt ab, ob die Organisation Sicherheit als Prozess steuert. SOC 2 deckt ab, ob genannte Kontrollen über einen Zeitraum funktioniert haben. Alle drei betreffen den Anbieter, nicht das Produkt.

Anwendungssicherheit ist eine eigene Disziplin mit eigenen Nachweisen. Fragen Sie nach dem letzten Penetrationstestbericht und dem Stand der Behebung statt nach der Zertifikatswand, und prüfen Sie, wer ihn durchgeführt hat und gegen welchen Geltungsbereich. Das ist die Substanz hinter unseren Penetrationstests.

Regulatorische Exponierung nach Branche

Regulierung ist der Punkt, an dem generische Enterprise-Ratschläge unsicher werden. Was folgt, nennt überprüfbare Pflichten und hört vor der Rechtsberatung auf, die Sie bei einem qualifizierten Berater einholen sollten.

UK GDPR, das fast jeden betrifft

Wenn das System personenbezogene Daten berührt, gilt Artikel 32 der UK GDPR sowohl für den Verantwortlichen als auch für den Auftragsverarbeiter. Er verlangt geeignete technische und organisatorische Maßnahmen und benennt vier: Pseudonymisierung und Verschlüsselung, dauerhafte Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Verarbeitungssysteme, die Fähigkeit, die Verfügbarkeit personenbezogener Daten und den Zugang zu ihnen nach einem Zwischenfall rasch wiederherzustellen, und ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit dieser Maßnahmen.

Lesen Sie die dritte davon noch einmal, denn sie macht die Notfallwiederherstellung zu einer Datenschutzpflicht statt zu einer betrieblichen Vorliebe. Der Leitfaden des ICO zur Datensicherheit verweist auf Cyber Essentials als nützliche Grundlinie und stellt zugleich klar, dass es nur ein Basissatz an Kontrollen ist und nicht die Umstände jeder Organisation oder die Risiken jedes Verarbeitungsvorgangs abdeckt.

Finanzdienstleistungen und Gesundheit, kurz und vorsichtig

Im Finanzsektor verlangt das Regime der operationellen Resilienz der FCA von betroffenen Firmen, wichtige Geschäftsdienste zu identifizieren, Auswirkungstoleranzen für sie festzulegen und in der Lage zu sein, bei schwerwiegender, aber plausibler Störung innerhalb dieser Toleranzen zu bleiben. Die Übergangsfrist endete am 31. März 2025, die Pflicht ist also aktiv und prägt, was ein Anbieter für solche Firmen nachweisen muss.

Im Gesundheits- und Pflegewesen berührt ein Gesundheits-IT-System die Standards von NHS England zum klinischen Risikomanagement: DCB0129 für Hersteller und DCB0160 für die Organisationen, die es einsetzen. Beide stehen unter nationaler Überprüfung, mit einer öffentlichen Konsultation vom 29. Juni 2026 bis zum 11. September 2026, prüfen Sie also die aktuelle Lage, bevor Sie sich auf eine Zusammenfassung verlassen, auch auf diese.

Wenn Ihre Branche hier nicht genannt ist, behandeln Sie die Pflicht generisch: Identifizieren Sie die Aufsichtsbehörde, lesen Sie ihre eigenen veröffentlichten Anforderungen und lassen Sie den Anbieter dagegen Nachweise erbringen statt gegen eine allgemeine Zusicherungserzählung.

Integrationsarchitektur ist, wo das Geld hingeht

Enterprise-Kosten konzentrieren sich in den Nahtstellen zwischen Systemen, nicht in ihnen. Die Funktionen sind meist gut verstanden. Sechs Systeme mit unterschiedlichen Datenmodellen und unterschiedlichen Vorstellungen davon, was ein Kunde ist, zur Übereinstimmung zu bringen, ist der Ort, an dem der Zeitplan verschwindet.

Punkt zu Punkt gegen einen Broker

Punkt zu Punkt ist der Standard, weil die erste Integration so tatsächlich einfacher ist. Die Kosten sind kombinatorisch: bei n direkt miteinander sprechenden Systemen steuern Sie auf n zum Quadrat Verbindungen zu, jede mit eigener Wiederholungslogik, eigenen Zugangsdaten und eigener Überwachung. Bei vier Systemen ist das in Ordnung. Bei fünfzehn ist es nicht mehr wartbar.

Ein Broker oder Event-Bus kehrt diese Kurve um. Er fügt eine Komponente, eine Betriebslast und einen Single Point of Failure hinzu, den man einplanen muss, und rechnet sich etwa ab dem sechsten oder achten Teilnehmer. Der Fehler geht in beide Richtungen: kleine Landschaften kaufen eine Integrationsplattform, die sie nicht brauchen, und große schieben sie auf, bis das Geflecht verkalkt ist.

Synchron gegen ereignisgesteuert

Ein synchroner Aufruf ist leicht zu durchdenken und koppelt die Verfügbarkeit. Wenn Ihr Dienst vier Systeme inline aufruft und jedes zu 99,9 Prozent der Zeit verfügbar ist, liegt Ihre eigene Obergrenze bei rund 99,6 Prozent, bevor Sie einen Fehler geschrieben haben. Jede synchrone Abhängigkeit ist ein Anteil Ihrer Verfügbarkeit, den Sie dem Betriebsteam eines anderen übergeben.

Ereignisgesteuerte Entwürfe entkoppeln das, zum Preis von Eventual Consistency und deutlich schwierigerem Debugging. Behalten Sie synchrone Aufrufe für den Pfad, auf dem der Nutzer wartet und eine veraltete Antwort inakzeptabel ist, und verlagern Sie alles andere auf Ereignisse. Entscheiden Sie das pro Interaktion statt als Hausstil.

Idempotenz, Replay und Abstimmung

Verteilte Systeme liefern Nachrichten mehr als einmal aus und verlieren sie gelegentlich, also muss jeder Schreibpfad, der eine Grenze überquert, gefahrlos wiederholbar sein. Das etablierte Muster ist ein vom Client erzeugter Idempotenzschlüssel. Die Umsetzung von Stripe speichert Statuscode und Body der ersten Anfrage zu einem Schlüssel, gibt bei Wiederholungen dasselbe Ergebnis zurück, entfernt Schlüssel nach mindestens 24 Stunden und meldet einen Fehler, wenn derselbe Schlüssel mit anderen Parametern eintrifft.

Replay ist die betriebliche Hälfte derselben Idee. Nachdem ein nachgelagertes System sechs Stunden lang nicht verfügbar war, muss jemand die verpassten Nachrichten durchschieben, was nur sicher ist, wenn die Verbraucher idempotent sind und die Nachrichten aufbewahrt wurden. Entwerfen Sie das Aufbewahrungsfenster und den Replay-Mechanismus neben dem Happy Path, denn sie nachzurüsten heißt, jeden Verbraucher zu ändern.

Abstimmung wird als Nachgedanke behandelt und sollte es nicht sein. Sie ist ein geplanter Job, der den Zustand zweier Systeme vergleicht, die übereinstimmen sollten, Unterschiede meldet und sie entweder korrigiert oder für einen Menschen aufwirft. Ohne sie findet ein Prüfer Monate später eine stille Abweichung von einem Finanzsystem. Kalkulieren Sie sie als vollwertige Lieferung mit einem Verantwortlichen und einem Alarmweg, nicht als Skript, das jemand am Ende schreibt.

Legacy-Koexistenz und der Strangler Fig

Der vollständige Ersatz eines funktionierenden Systems ist die riskanteste verfügbare Option und wird weit häufiger gewählt, als er sollte. Die inkrementelle Alternative ist von Microsoft als Strangler-Fig-Muster dokumentiert: eine Fassade vor das Altsystem setzen, Anfragen durch sie leiten und Funktionalität Stück für Stück hinüberziehen, bis das alte System keinen Verkehr mehr hat und abgeschaltet werden kann.

Jedes Inkrement ist eigenständig wertvoll und eigenständig umkehrbar: geht die dritte Scheibe schief, leiten Sie sie zurück. Microsoft ist deutlich darin, wo es nicht gilt, nämlich wenn Anfragen an das Backend nicht abgefangen werden können, wenn Sie den Legacy-Quellcode nicht ändern können oder wenn das System klein genug ist, dass ein direkter Ersatz einfacher ist.

Zwei Details entscheiden, ob es funktioniert. Die Fassade darf nicht zum Engpass oder zum Single Point of Failure werden, sie braucht also dieselbe Verfügbarkeitstechnik wie die Dienste dahinter. Und systemübergreifende Aufrufe während des Übergangs brauchen eine Anti-Corruption-Layer, damit Legacy-Semantik nicht in den neuen Entwurf sickert. Die Daten sind schwieriger als der Verkehr: die Tabellen einer Domäne herauszulösen bedeutet eine Erstbeladung, einen Change-Data-Capture-Strom, eine Validierungsphase, in der beide Speicher beschrieben und verglichen werden, und erst dann eine Umschaltung, mit möglichem Rollback, bis die alten Objekte gelöscht sind.

Testen im Enterprise-Maßstab

Testen in einem Enterprise-Programm ist ebenso ein Logistikproblem wie ein technisches, und dort sterben optimistische Pläne.

Umgebungen

Sie werden mehr brauchen, als Sie eingeplant haben: Entwicklung, eine Integrationsumgebung, die an die Sandboxes der Gegenparteien angebunden ist, eine Performance-Umgebung, die der Produktion nahe genug ist, damit ihre Zahlen etwas bedeuten, eine Abnahmeumgebung, die stabil genug für beschäftigte Nichttechniker ist, und die Produktion. Jede hat Infrastrukturkosten, einen Auffrischungsprozess und einen Verantwortlichen. Die, die immer rutscht, ist Performance, und sie zu überspringen heißt, in der Produktion Lasttests zu fahren.

Testdaten und das Problem personenbezogener Daten

Enterprise-Systeme brauchen realistische Daten zum Testen, und die realistischen Daten sind Produktionsdaten, die personenbezogene Informationen enthalten. Sie in eine Testumgebung zu kopieren ist eine Verarbeitung nach UK GDPR, und die Pflichten aus Artikel 32 folgen ihnen dorthin, einschließlich Zugriffskontrolle und Sicherheit der Umgebung, die sie hält.

Die vertretbaren Antworten sind Anonymisierung, die unumkehrbar sein muss, um die Daten aus der Verordnung herauszunehmen, oder Pseudonymisierung, die das Risiko senkt, sie aber im Anwendungsbereich hält. Beide brauchen Entwicklungsarbeit, um die statistische Form zu erhalten, die die Daten nützlich macht, und einen dokumentierten Prozess. Eine Produktionsdatenbank in eine geteilte Testumgebung zurückzuspielen ist üblich, in vielen Konfigurationen unrechtmäßig und genau das, was eine Lieferantenprüfung aufdecken soll.

Performance-Tests

Performance-Tests beantworten, ob das System die zuvor vereinbarten Durchsatz- und Latenzzahlen erreicht, sie können also nur existieren, wenn diese Zahlen aufgeschrieben wurden. Testen Sie das Spitzenprofil statt des Durchschnitts, und schließen Sie die Form der Spitze ein, denn eine Rampe über zehn Minuten und ein Sprung in einer Sekunde belasten unterschiedliche Fehlermodi.

Fahren Sie sie gegen Produktionsdatenmengen. Eine Abfrage, die gegen 10.000 Zeilen sofort und gegen 40 Millionen unbrauchbar ist, ist der häufigste Performance-Defekt in Enterprise-Software, und auf einem kleinen Datensatz ist er unsichtbar.

Abnahmetests mit Leuten, die andere Aufgaben haben

UAT wird als Fenster von zwei Wochen geplant und ist die Phase, die am zuverlässigsten überzieht, weil die Tester die Fachexperten sind und das Geschäft sie weiterhin braucht. Sie bekommen ein paar Stunden pro Woche, und ihre Verfügbarkeit bricht zum Monatsende ein.

Benennen Sie die Tester im Vertrag, vereinbaren Sie die Stunden pro Woche, skripten Sie die Szenarien im Voraus, statt Leute erkunden zu lassen, und führen Sie die Fehlertriage als gemeinsame Sitzung statt als Ticketschlange. Ein Anbieter, der zwei Wochen UAT ohne benannte Teilnehmer anbietet, hat noch keine durchgeführt.

Liefermodell und Steuerung

Die Teamform, die funktioniert, ist klein und stabil statt groß und rotierend: eine technische Leitung, die die Architektur für das gesamte Programm verantwortet, drei bis sechs Ingenieure, eine Lieferleitung, die den Kalender der Gegenparteien führt, und geteilter Zugriff auf einen Qualitätsingenieur und einen Infrastrukturspezialisten. Mitten im Flug Leute hinzuzufügen bremst ein Programm zuverlässig, denn der Engpass ist Kontext, nicht Hände.

Schreiben Sie die Entscheidungsverantwortung vor dem ersten Sprint auf. Benennen Sie eine Person, die Umfangsänderungen genehmigen kann, eine, die architektonische Abwägungen genehmigen kann, und eine, die ein Release abnehmen kann. Sind das drei Namen, dauern Entscheidungen Tage. Sind es Gremien, dauern sie Wochen und der Plan ist Fiktion.

Ein Steuerungsrhythmus hält ein langes Programm ehrlich: vierzehntägige Lieferbesprechung mit der Arbeitsgruppe, monatliche Steuerung mit dem Budgetverantwortlichen und den Vetoinhabern in einem Raum, und ein schriftlicher Statusbericht gegen die ursprüngliche Baseline statt gegen die revidierte des Vormonats. Ein Anbieter, dessen Status dauerhaft grün ist, steuert kein Risiko, er verbirgt es.

Vertragsmodelle und wer das Risiko trägt

Vier Modelle decken fast alles ab, und jedes legt das Risiko woanders hin. Die Frage ist nicht, welches das beste ist, sondern welche Partei besser aufgestellt ist, die vor Ihnen liegende Unsicherheit zu tragen.

Time and Materials passt zu wirklich unsicherer Arbeit: Discovery, Legacy-Archäologie oder eine Integration gegen eine schlecht dokumentierte Gegenpartei. Der Käufer trägt das Risiko und erhält volle Flexibilität, was Vertrauen und eine Verbrauchsrate erfordert, die jemand tatsächlich beobachtet.

Gedeckelte Time and Materials fügt eine Obergrenze hinzu und ist der übliche vernünftige Kompromiss, so strukturieren wir die meisten unserer Softwareentwicklungsleistungen. Der Anbieter absorbiert Überschreitungen über der Grenze, der Käufer zahlt darunter nur, was verbraucht wird, und beide Seiten halten den Umfang ehrlich. Rechnen Sie damit, dass die Grenze fünfzehn bis fünfundzwanzig Prozent Reserve trägt, denn ein Anbieter, der auf den erwarteten Kosten deckelt, irrt sich entweder oder plant einen Änderungsantrag.

Festpreis funktioniert nur, wo der Umfang wirklich fest ist, was in einem Enterprise-Programm für ein Inkrement gilt und nicht für das Ganze. Festpreisinkremente von sechs bis zehn Wochen, jedes nach dem Landen des vorherigen geschnitten, geben Budgetsicherheit, ohne so zu tun, als könne jemand achtzehn Monate im Voraus spezifizieren.

Managed Service ist die richtige Form, sobald das System live ist: eine monatliche Gebühr für Support, Patching, Überwachung und ein definiertes Änderungskontingent, bepreist als Prozentsatz der Baukosten pro Jahr statt nach Kopfzahl. Lassen Sie die Servicebeschreibung die Reaktionszeiten und den Eskalationsweg benennen.

Enterprise-Softwareentwicklung: Was die Kosten treibt

Kostentreiber nach Wirkung

Die Reihenfolge überrascht, weil Funktionen zuletzt kommen. Die Integrationsfläche steht an erster Stelle, und zwar die Zahl der externen Eigentümer statt die Zahl der Endpunkte. Die nichtfunktionalen Ziele stehen an zweiter, denn der Schritt von einem Dienst, der ein Wartungsfenster verträgt, zu einem, der keines verträgt, verändert jede Schicht des Entwurfs.

Drittens kommt die Prüf- und Regulierungslast: Angebotszeit, Nachweiserstellung, Auditunterstützung und ein langsamerer Release-Prozess über die Vertragslaufzeit. Viertens Datenmigration und Abstimmung, durchgängig unterschätzt, weil die Schwierigkeit in der Qualität der alten Daten liegt und nicht im Volumen. Fünftens die Zahl der Stakeholder-Gruppen, die die Entscheidungslatenz setzt. Sechstens die Zahl der Umgebungen. Der Funktionsumfang ist siebtens, und er ist meist das Einzige im ursprünglichen Budget.

Indikative britische Preisspannen

Die Spannen unten sind Hausschätzungen aus britischen Projekten, ausgedrückt als Kosten des ersten Jahres einschließlich Discovery, Bau, Test und Go-Live, aber ohne die eigene Personalzeit des Käufers. Sie sind indikativ und keine Angebote, und die Spannen sind weit, weil die obigen Treiber sie verschieben.

Ohne die Tabelle gesagt: ein Einzeldienst mit zwei oder drei Integrationen, internen Nutzern und einem Ziel von 99,5 Prozent landet im ersten Jahr zwischen GBP 120.000 und GBP 250.000. Ein kundenorientiertes Abteilungssystem mit fünf bis acht Integrationen bei 99,9 Prozent liegt bei GBP 300.000 bis GBP 700.000. Eine Kernplattform, die ein Altsystem ersetzt, mit zehn bis zwanzig Integrationen und einem Ziel von 99,95 Prozent, liegt bei GBP 900.000 bis GBP 2,5 Millionen. Ein reguliertes Programm über mehrere Einheiten bei 99,99 Prozent beginnt bei etwa GBP 2,5 Millionen und steigt.

Die Betriebskosten, die nicht im Budget stehen

Rechnen Sie jährliche Betriebskosten obendrauf, die zwischen fünfzehn und fünfundzwanzig Prozent der Baukosten pro Jahr liegen, sobald Support, Hosting, Patching, Sicherheitsarbeit und ein bescheidenes Änderungskontingent enthalten sind. Ein Budget, das den Bau und nicht den Betrieb finanziert, erzeugt ein System, das im zweiten Jahr sichtbar verfällt, und unsere Aufschlüsselung der Softwarewartungskosten legt dar, wohin dieses Geld geht.

Ausstieg und Fortführung

Ein Anbieter, den Sie nicht verlassen können, ist ein Risiko in Ihrer Bilanz, und es ist die Klausel, die am häufigsten ans Ende der Verhandlung geschoben wird, wenn niemand mehr aufpasst. Vier Dinge machen einen Ausstieg möglich.

Quellcode und seine Historie gehören in ein Repository, das der Käufer besitzt oder nach Ankündigung übernehmen kann, mit der Build-Pipeline und den Infrastrukturdefinitionen. Code ohne die Pipeline, die ihn baut, ist ein Archiv, kein arbeitsfähiges Gut.

Die Dokumentation sollte einem kompetenten Dritten erlauben, das System zu betreiben: Architektur, Integrationsverträge, Runbooks für Fehlerfälle, die tatsächlich eingetreten sind, und das Verzeichnis der Zugangsdaten. Unser Beitrag zu technischer Dokumentation, die gelesen wird behandelt, was eine Übergabe überlebt.

Escrow deckt den Fall ab, dass der Anbieter ausfällt statt geht, indem der Quellcode bei einem Dritten hinterlegt und bei definierten Auslösern freigegeben wird. Es lohnt sich, wo der Anbieter klein im Verhältnis zum Vertrag ist, und es lohnt sich, genau zu lesen, denn eine ungeprüfte Hinterlegung gibt Code frei, der sich nicht bauen lässt. Wann das gerechtfertigt ist, haben wir uns in Software-Escrow, wer es wirklich braucht angesehen.

Bepreisen Sie schließlich die Übergabe im Vertrag. Eine benannte Anzahl von Tagen Wissenstransfer zu einem vereinbarten Satz, ausgelöst nach Ankündigung, macht aus einem Streit eine Rechnung. Dieselbe Disziplin gilt für die Lieferanten Ihrer Lieferanten, behandelt in unserer Notiz zur Sicherheit der Software-Lieferkette.

Die Enterprise-Glaubwürdigkeit eines Anbieters in einem Termin beurteilen

Fünf Fragen klären das meiste davon in einer Stunde, und das Zögern sagt Ihnen so viel wie die Antwort.

Fragen Sie, gegen welche Verfügbarkeits- und Wiederherstellungsziele sie geliefert haben und wie die Verfügbarkeit gemessen wurde. Ein Anbieter, der eine Pflicht von 99,95 Prozent getragen hat, nennt Messpunkt und Bereitschaftsregelung ungefragt. Wer das nicht hat, spricht allgemein über Redundanz.

Bitten Sie um die Geltungsbereichserklärung auf ihrem Zertifikat nach ISO 27001 oder um den Ausnahmeabschnitt ihres SOC 2 Typ 2. Beides sind gewöhnliche Bitten an einen Anbieter, der sie hält, und unangenehm für einen, der ein Logo hat. Fragen Sie dann, wie sie eine Abstimmungsdifferenz in der Produktion behandelt haben, was niemand aus der Theorie beantworten kann.

Fragen Sie, um wie viel ihre letzten drei Programme überzogen haben und warum. Alle überziehen, und der informative Teil ist, ob sie die Zahl kennen. Fragen Sie dann, wie ihr Ausstiegsprozess aussieht, in Tagen und Lieferungen. Ein Anbieter, der das aufgeschrieben hat, erwartet, daran gemessen zu werden.

Was das für einen Käufer bedeutet

Das Wort Enterprise sollte Pflichten beschreiben, keine Preisklasse. Sobald Integrationsfläche, Verfügbarkeits- und Wiederherstellungsziele, regulatorische Exponierung und Ausstiegsbedingungen aufgeschrieben sind, sortiert sich die engere Auswahl von selbst, weil die meisten Anbieter gegen diese vier keine Nachweise erbringen können.

Mecanik arbeitet an dieser Art von Auftrag über unsere Softwareentwicklungsleistungen und an der Prüfseite über Penetrationstests. Wenn Sie eher die Anforderung als die engere Auswahl zusammenstellen, ist die Checkliste zur technischen Due Diligence ein vernünftiger Start, und über die nichtfunktionalen Zahlen lohnt es sich zuerst zu streiten.

Häufig gestellte Fragen

Was zählt als Enterprise-Softwareentwicklung? Enterprise wird über Randbedingungen definiert, nicht über die Größe des Käufers. Ein Projekt qualifiziert sich, wenn es eine breite, von mehreren Parteien gehaltene Integrationsfläche hat, eine vertragliche Verfügbarkeits- und Wiederherstellungspflicht, regulatorische Exponierung, mehrere Stakeholder-Gruppen, die jeweils ein Release blockieren können, Datenmengen, die naive Entwürfe sprengen, und die Anforderung, mit Altsystemen zu koexistieren, die niemand vollständig versteht. Ein großes Unternehmen kann einen gewöhnlichen Build beauftragen, und eine kleine regulierte Firma einen wirklich unternehmensweiten.

Was kostet ein Enterprise-Softwareprogramm im Vereinigten Königreich? Als Hausschätzungen aus britischen Projekten liegt ein Einzeldienst mit zwei oder drei Integrationen und einem Verfügbarkeitsziel von 99,5 Prozent im ersten Jahr bei GBP 120.000 bis GBP 250.000. Ein kundenorientiertes Abteilungssystem bei 99,9 Prozent liegt bei GBP 300.000 bis GBP 700.000. Eine Kernplattform, die ein Altsystem ersetzt, liegt bei GBP 900.000 bis GBP 2,5 Millionen. Rechnen Sie fünfzehn bis fünfundzwanzig Prozent der Baukosten pro Jahr für Betrieb und Support hinzu.

Braucht ein Enterprise-Anbieter ISO 27001, Cyber Essentials oder SOC 2? Sie beweisen Verschiedenes. Cyber Essentials ist eine von der britischen Regierung gestützte Grundlinie aus fünf technischen Kontrollen, mit einer Plus-Stufe, die durch ein unabhängiges technisches Audit verifiziert wird und von PPN 014 für viele öffentliche Aufträge verlangt wird. ISO/IEC 27001:2022 zertifiziert ein Informationssicherheits-Managementsystem, weshalb die Geltungsbereichserklärung auf dem Zertifikat mehr zählt als das Zertifikat selbst. SOC 2 ist ein US-Bestätigungsbericht einer Wirtschaftsprüfungsgesellschaft, und nur ein Typ 2 prüft, ob Kontrollen über einen Zeitraum funktioniert haben.

Was sind Recovery Point und Recovery Time Objective? Das Recovery Point Objective ist, wie viele Daten Sie nach einer Katastrophe zu verlieren akzeptieren, ein RPO von einer Stunde heißt also, dass bis zu eine Stunde an Transaktionen fehlen kann. Das Recovery Time Objective ist, wie lange Sie nicht verfügbar zu sein akzeptieren, ein RTO von vier Stunden heißt also, dass der Dienst innerhalb von vier Stunden wieder Verkehr bedienen muss. Beide treiben Architektur und Kosten stärker als jedes Feature, weil sie zwischen Backup and Restore, Pilot Light, Warm Standby und Multi-Site Active/Active auswählen.

Was sollte in einem Enterprise-Softwarevertrag zum Ausstieg stehen? Vier Dinge. Eigentum oder übertragbarer Zugriff auf das Quellcode-Repository, die Build-Pipeline und die Infrastrukturdefinitionen. Dokumentation, die einem kompetenten Dritten den Betrieb erlaubt, einschließlich Runbooks und Verzeichnis der Zugangsdaten. Software-Escrow, wenn der Anbieter klein im Verhältnis zum Vertragswert ist, mit geprüften statt ungeprüften Hinterlegungen. Und eine bepreiste Übergabeklausel, die die Tage des Wissenstransfers und den Satz nennt, damit ein Weggang eine Rechnung ist und kein Streit.