Engineering von Geschäftssystemen

Glossar zum Engineering von Geschäftssystemen

Achtzehn praxisnahe Definitionen, die Begriffe aus Architektur, Daten, Integration, KI und Automatisierung mit Geschäftsentscheidungen und betrieblichen Folgen verbinden.

01

Geschäftssystem

Das Zusammenspiel von Menschen, Entscheidungen, Prozessen, Daten, Anwendungen, Regeln und Kontrollen, das ein Geschäftsergebnis hervorbringt.

Warum das geschäftlich wichtig ist

Der Begriff verhindert, dass eine einzelne Technologiekomponente mit dem gesamten betrieblichen Problem gleichgesetzt wird.

Beispiel

Zur Auftragserfüllung gehören Entscheidungen, die Bedeutung von Bestandsdaten, der Austausch mit Partnern, Ausnahmen und Nachweise – nicht nur die Auftragsanwendung.

Auch bekannt als · soziotechnisches System · betrieblicher Systemkontext

02

Unternehmensarchitektur

Eine zusammenhängende Sicht auf Fähigkeiten, Informationen, Anwendungen, Technologien, Entscheidungen und Übergänge zur Steuerung organisatorischer Veränderungen.

Warum das geschäftlich wichtig ist

Sie verbindet Investitions- und Umsetzungsentscheidungen mit den Fähigkeiten und Einschränkungen, auf die sie wirken.

Beispiel

Eine Zielarchitektur zeigt nicht nur künftige Komponenten, sondern auch Verantwortlichkeiten, Übergangszustände und Entscheidungsprinzipien.

Auch bekannt als · EA · Geschäfts- und Technologiearchitektur

03

Integration

Der gezielt gestaltete Austausch und die Koordination von Daten, Ereignissen oder Aktionen über Systemgrenzen hinweg.

Warum das geschäftlich wichtig ist

Verlässliche Integration bewahrt Bedeutung und Status an den Stellen, an denen keine einzelne Komponente das Gesamtergebnis kontrolliert.

Beispiel

Beim Austausch von Partneraufträgen werden neben dem Nachrichtentransport auch Identität, Validierung, Antworten, Wiederholungsversuche und Wiederherstellung geregelt.

Auch bekannt als · Systemintegration · Anwendungsintegration

04

Interoperabilität

Die Fähigkeit unabhängiger Systeme und Organisationen, Informationen auszutauschen und auf Grundlage einer gemeinsamen, betrieblich sinnvollen Interpretation zu nutzen.

Warum das geschäftlich wichtig ist

Eine empfangene, aber missverstandene Nachricht ist technisch übertragen, in der Praxis jedoch nicht interoperabel.

Beispiel

Beide Seiten interpretieren die Zustände „angenommen“, „abgelehnt“ und „ausstehend“ einheitlich und wissen, wer jeweils handeln muss.

Auch bekannt als · semantische Interoperabilität · systemübergreifende Kompatibilität

05

Daten-Governance

Entscheidungen, Verantwortlichkeiten, Richtlinien und Kontrollen, die Daten eine verlässliche Bedeutung geben und ihre verantwortbare Nutzung sicherstellen.

Warum das geschäftlich wichtig ist

Data Governance verknüpft Datenqualität und Zugriffssteuerung mit wesentlichen Geschäftsentscheidungen, statt sie als isolierte Compliance-Aufgabe zu behandeln.

Beispiel

Eine verantwortliche Person kann einen kritischen Begriff definieren, seine Nutzung genehmigen und ein Qualitätsproblem anhand eines benannten Entscheidungsrisikos bewerten.

Auch bekannt als · Datenverantwortung · Informationsmanagement

06

Datenherkunft

Nachvollziehbare Informationen darüber, woher Daten stammen, wie sie verändert wurden und wo sie Verwendung fanden.

Warum das geschäftlich wichtig ist

Die dokumentierte Herkunft unterstützt Erklärung, Auswirkungsanalyse und Kontrolle, wenn eine Entscheidung von transformierten Daten abhängt.

Beispiel

Ein ausgewiesener Wert lässt sich von seiner Quelle über Validierung und Aggregation bis zur entscheidungsrelevanten Auswertung verfolgen.

Auch bekannt als · Datenprovenienz · Rückverfolgbarkeit der Daten

07

Datenvertrag

Eine ausdrückliche, versionierte Vereinbarung über Struktur, Bedeutung, Qualität, Verantwortung und Verhalten von Daten, die eine Grenze überschreiten.

Warum das geschäftlich wichtig ist

Ein Datenvertrag macht Erwartungen bei Änderungen und Fehlern überprüfbar, statt sie den Empfängern zur Interpretation zu überlassen.

Beispiel

Ein Vertrag benennt Pflichtfelder, semantische Definitionen, Versionsrichtlinien, das Verhalten bei Ablehnung und die verantwortliche Stelle.

Auch bekannt als · Schnittstellendatenvereinbarung · Schemavertrag

08

Ereignisgesteuerte Architektur

Eine Architektur, in der wesentliche Zustandsänderungen als Ereignisse ausgedrückt und von interessierten Komponenten asynchron verarbeitet werden.

Warum das geschäftlich wichtig ist

Sie kann zeitliche Abläufe und Zuständigkeiten entkoppeln – vorausgesetzt, Bedeutung, Identität, Reihenfolge und Wiederherstellung der Ereignisse sind bewusst gestaltet.

Beispiel

Ein Ereignis „Auftrag genehmigt“ hält den fachlichen Sachverhalt und eine stabile Identität fest, statt nur eine vage Änderungsbenachrichtigung zu senden.

Auch bekannt als · EDA · Ereignisbasierte Architektur

09

Idempotenz

Eine Verarbeitungseigenschaft, durch die dieselbe Anfrage oder dasselbe Ereignis mehrfach angewendet werden kann, ohne eine unbeabsichtigte zusätzliche Geschäftswirkung auszulösen.

Warum das geschäftlich wichtig ist

Idempotenz ermöglicht einen sicheren erneuten Versuch, wenn der Absender nicht erkennen kann, ob der erste Versuch erfolgreich abgeschlossen wurde.

Beispiel

Die erneute Übermittlung einer Zahlungsstatusänderung liefert das bereits festgelegte Ergebnis, statt eine zweite Zahlung auszulösen.

Auch bekannt als · sichere Wiederholung · Duplikatschutz

10

Zielarchitektur

Die beabsichtigte künftige Struktur mit ihren Verantwortlichkeiten und Prinzipien zur Unterstützung einer definierten Geschäftsfähigkeit und Richtung.

Warum das geschäftlich wichtig ist

Sie gibt Entscheidungen ein zusammenhängendes Ziel, ohne einen einzigen unumkehrbaren Umsetzungsweg vorauszusetzen.

Beispiel

Die Zielarchitektur beschreibt Domänenverantwortung, Schnittstellen und Kontrollgrenzen, die für eine verlässliche Partneranbindung erforderlich sind.

Auch bekannt als · Zukunftsarchitektur · Soll-Architektur

11

Übergangsarchitektur

Ein bewusst gestalteter und betriebener Zwischenzustand zwischen Ausgangs- und Zielarchitektur.

Warum das geschäftlich wichtig ist

Sie macht Parallelbetrieb, vorübergehende Kontrollen sowie Risiko- und Ausstiegskriterien zu geplanten Bestandteilen statt zu zufälligen Umsetzungsresten.

Beispiel

Alte und neue Bestelldienste laufen parallel mit festgelegten Kriterien für Abstimmung, Befugnisse und Außerbetriebnahme.

Auch bekannt als · Zwischenarchitektur · Migrationszustand

12

KI-Bereitschaft

Der Grad, in dem ein konkreter KI-Einsatz über einen tragfähigen Nutzen, geeignete Daten und Arbeitsabläufe, passende Architektur, Aufsicht, Bewertung und betriebliche Verantwortung verfügt.

Warum das geschäftlich wichtig ist

Der Begriff verhindert, dass die technische Machbarkeit eines Modells mit der Fähigkeit zum verantwortbaren Produktivbetrieb verwechselt wird.

Beispiel

Ein Anwendungsfall ist erst bereit, wenn Entscheidungsverantwortung, Dateneignung, menschliche Prüfung, Überwachung und Ausweichverfahren ausdrücklich geregelt sind.

Auch bekannt als · KI-Bereitschaft für den Produktivbetrieb · organisatorische KI-Bereitschaft

13

Menschliche Aufsicht

Die Gesamtheit menschlicher Verantwortlichkeiten, Informationen, Befugnisse und Eingriffspunkte bei automatisierten oder KI-unterstützten Handlungen.

Warum das geschäftlich wichtig ist

Eine menschliche Prüfung ist nur dann wirksam, wenn die betreffende Person das Ergebnis rechtzeitig verstehen, hinterfragen und verändern kann.

Beispiel

Eine prüfende Person erhält den relevanten Kontext, kann eine Empfehlung ablehnen und weiß, wann die automatische Ausführung auszusetzen ist.

Auch bekannt als · menschliche Prüfung · menschliche Kontrolle

14

Prozessautomatisierung

Die technische Ausführung wiederholbarer Prozessschritte, Regeln oder Austausche mit explizitem Ausnahme- und Kontrollverhalten.

Warum das geschäftlich wichtig ist

Prozessautomatisierung soll vermeidbaren Aufwand beseitigen, ohne Verantwortung zu verschleiern oder einen fehlerhaften Prozess lediglich zu beschleunigen.

Beispiel

Ein Arbeitsablauf leitet Standardfälle automatisch weiter, während bei festgelegten Ausnahmen die menschliche Entscheidungsbefugnis erhalten bleibt.

Auch bekannt als · Arbeitsablaufautomatisierung · Automatisierung von Geschäftsprozessen

15

Betriebsmodell

Die Verantwortlichkeiten, Entscheidungsrechte, Prozesse, Fähigkeiten und Maßnahmen, durch die ein System betrieben und verbessert wird.

Warum das geschäftlich wichtig ist

Einer technischen Fähigkeit ohne Betriebsmodell fehlen dauerhafte Verantwortung und ein geregelter Umgang mit Veränderungen und Störungen.

Beispiel

Das Betriebsmodell einer Datendomäne legt fest, wer über Bedeutungen entscheidet, Kontrollen überwacht und die Behebung von Mängeln finanziert.

Auch bekannt als · Betriebsmodell · Servicebetriebsmodell

16

Technische Schulden

Eine gegenwärtige Einschränkung durch frühere technische Entscheidungen, die die Kosten, das Risiko oder die Verzögerung nützlicher Änderungen erhöht.

Warum das geschäftlich wichtig ist

Technische Schulden werden handhabbar, wenn sie mit einer Geschäftsentscheidung oder einem Veränderungsweg verknüpft sind, statt lediglich als mangelhafter Code aufgelistet zu werden.

Beispiel

Eine gemeinsame Datenbank blockiert die unabhängige Freigabe von zwei Funktionen und erhöht das Migrationsrisiko.

Auch bekannt als · Architekturschulden · Engineering-Schulden

17

Systemkontext

Die relevanten Akteure, Grenzen, Abhängigkeiten, Informationen, Einschränkungen und Umgebungen, die ein System oder eine Entscheidung umgeben.

Warum das geschäftlich wichtig ist

Der Kontext entscheidet darüber, ob eine lokal stimmige Gestaltung auch in der realen Organisation tragfähig bleibt.

Beispiel

Die Gestaltung einer Automatisierung umfasst beteiligte Teams, Genehmigungsbefugnisse, Quellsysteme und Ausnahmewege rund um den Arbeitsablauf.

Auch bekannt als · Kontextkarte · Kontext der Systemgrenze

18

Entscheidungsprotokoll

Eine kurze, dauerhaft verfügbare Dokumentation einer folgenreichen Entscheidung, ihres Kontexts, der Optionen, Begründung, Folgen und Anlässe für eine erneute Prüfung.

Warum das geschäftlich wichtig ist

Sie bewahrt den Grund einer Entscheidung, damit spätere Veränderungen die richtigen Annahmen prüfen können, statt die damalige Analyse zu wiederholen.

Beispiel

Ein Protokoll erklärt, warum ein asynchroner Austausch gewählt wurde und bei welchen Änderungen von Volumen, Laufzeit oder Kontrollen eine erneute Prüfung erforderlich ist.

Auch bekannt als · ADR · Architekturentscheidungsprotokoll

MTera · MTera kontaktieren

Systemherausforderung besprechen

Gestalten Sie, was als Nächstes kommt, ohne zu verlieren, was wahr bleiben muss.

Systemherausforderung besprechen
MTera · Suche

MTera-Wissensbasis durchsuchen

Finden Sie Leistungen, Herausforderungen, Methoden, Fachartikel und Definitionen.